Norma ISO 27035

• Clausula 3.3, Evento de Seguridad de la información:

Aparición identificada del estado de un sistema, servicio o red que indica una posible brecha a la política de seguridad de la información o la falta de controles o una situación previamente desconocida que puede ser pertinente a la seguridad

• Clausula 3.4, Incidente de Seguridad de la información:

Una única serie o series de eventos de seguridad de la información no deseados o inesperados que tiene una probabilidad significativa de comprometer las operaciones comerciales y amenazar la seguridad de la información

•  Evento: Cualquier ocurrencia observable en un sistema o red (NIST) 

Los eventos generalmente requieren que el personal de operaciones de TI tome medidas, y a menudo conducen a incidentes registrados (ITIL)

• Incidente: Es un evento adverso que ha ocasionado o tiene la posibilidad de ocasionar un daño a los activos, la reputación y/o personal de una organización (CISM, ISACA)

Una amenaza inminente de violación de las políticas de seguridad informática, las políticas de uso aceptable o las practicas de seguridad estándar (NIST)

Suceso que origina una interrupción o que posee el potencial para generar una interrupción, (DRII: Disaster Recovery Institute International)

• Problema: Una causa de uno o más incidentes. la causa generalmente no se conoce en el momento en que se crea un Registro de problemas (ITIL)

Es importante distinguir entre un evento y un incidente debido a que los dos términos se utilizan a menudo como sinónimos, a pesar de que tiene diferentes significados.

Un evento es cualquier cambio, error o interrupción dentro de una infraestructura de TI como un fallo del sistema, un error de disco o un usuario que olvido su contraseña.

Si bien hay un acuerdo general en lo que es un evento, hay una mayor variedad en la definición de un incidente. Definición comúnmente utilizada es: “el intento o éxito en el acceso no autorizado, uso, revelación, modificación o perdida de información o la interferencia con las operaciones de red o de sistemas” . Muchas organizaciones definen un incidente como la actividad de un agente de amenaza humana. Otros podrían incluir cualquier cosa disruptiva, incluyendo un mandato judicial para el descubrimiento de la información electrónico o la disrupción por un desastre natural.

Gestión de Incidentes

• Gestión de incidentes: Se define como la capacidad para gestionar efectivamente eventos perjudiciales inesperados con el objeto de minimizar los impactos y mantener o restaurar las operaciones normales dentro de los limites de tiempo definidos. Es un Proceso mediante el cual una organización responde y controla un incidente utilizando procedimientos o planes de respuesta de emergencia
• Respuesta a Incidentes: Es la capacidad operacional de la gestión de incidentes que identifica, prepara y responde a los incidentes para controlar y limitar los daños. es el conjunto de acciones realizadas por una organización ante un desastre u otro evento importante que pueda afectar significativamente a la organización, a su gente o su capacidad de operación normal. Puede incluir: evacuación, activación de un DRP, evaluación de daños o cualquier otra medida necesaria para llevar a la organización a un estatus más estable.

Todas las organizaciones necesitan hacer un esfuerzo significativo en la protección y la prevención de los ciberataques para que estos no causen daños o interrupciones. Sin embargo, los controles de seguridad no son perfectos y no pueden eliminar por completo todos los riesgos; por lo tanto, es importante que las organizaciones se preparen  y sean capaces de detectar y gestionar problemas e incidentes de seguridad/ciberseguridad potenciales.

• IMT: Equipo de Gestión de incidentes (Incident Management Team)
• IRT: Equipo de Respuesta a incidentes (Incident Response Team)

Videos Sugeridos: FACT24 Emergency Notification and Crisis Management
https://www.youtube.com/watch?v=ksMA5GbgQA4 
https://www.youtube.com/watch?v=QPSIZAylYNs 

Evento de seguridad de la Información

• En la mayoría de las organizaciones, la respuesta a incidentes para eventos relacionados con la información y el sistema de información es responsabilidad del gerente de seguridad de la información o un cargo de dicha jerarquía.
• Estos eventos requieren experiencia técnica junto con la competencia de seguridad de la información. 
• El Gerente de Seguridad de la información generalmente es responsable de desarrollar y probar la gestión de incidentes y los planes de respuesta y también se asegura de que se correlacione con el DRP/BCP en caso de que la respuesta a incidentes sea insuficiente para resolver un evento.

Para ITIL (Biblioteca de la Infraestructura de TI) un evento es un cambio de estado que tiene importancia (también se utiliza para indicar una alerta o notificación creada por cualquier servicio de TI), mientras que un incidente es una interrupción no planificada sobre un servicio de TI o la reducción de la calidad de un servicio

A menudo cuando los profesionales de seguridad utilizan la palabra incidente o evento esto puede causar confusión, especialmente en el ámbito de la Gestión de Servicios de TI. Esto debido al hecho de que ITIL define a los eventos e incidentes en un sentido de TI genérico.

Tipos de Incidentes

• Un incidente de Seguridad/Ciberseguridad es un evento adverso que afecta negativamente a la C-I-D de los datos. De acuerdo a CSX Cybersecurity Nexus de ISACA, los incidentes pueden ser:

• Incidente Involuntario: como el que alguien se olvide de activar una lista de control de acceso (ACL) en el router
• Incidente Malintencionado: como un ataque dirigido por un hacker
• Incidente Técnico: incluye virus, malware, ataques de denegación de servicios (DoS) y fallos del sistema
• Incidente físico: pueden incluir ingeniería social, perdida o robo de computadoras portátiles y dispositivos móviles

Independiente de la definición exacta utilizada por una organización en particular, es importante distinguir entre los eventos que se manejan en el curso normal de los negocios y los incidentes que requieren la experiencia en seguridad e investigación para gestionarlos

Tabla de Puntuación de Riesgos

Tabla de puntuación de riesgo: (N = 411) 
* Frecuencia de incidentes ocurridos durante el último año según la media del grupo. Puntuación máxima = 20 
** Impacto del evento ocurrido durante el año pasado basado en la media del grupo donde 1 = Menor y 4 = Extremo

Fuente: BCI (Business Continuity Institute), 2019-2020

El informe de este año revela que los incidentes de salud y seguridad son la principal causa de interrupción en 2019, desbancando a los ciberataques por primera vez desde 2014. Los incidentes de salud, que cubren tanto las enfermedades patológicas causadas por las condiciones laborales como las enfermedades mentales, pueden tener un impacto en operaciones debido al aumento de las bajas por enfermedad y la reducción de la productividad. En caso de un brote de enfermedad en todo el lugar de trabajo (p. Ej. Legionella o intoxicación alimentaria), las operaciones pueden cerrarse y, incluso si el personal puede trabajar desde casa, el bienestar mental de los empleados puede verse afectado si el cierre se prolonga durante un período prolongado.

La legislación del país a menudo requiere que todos los incidentes de salud sean registrados y monitoreados, lo que podría influir en la capacidad de una organización para rastrear y monitorear con mayor precisión este tipo de incidente. Por el contrario, es posible que las interrupciones más pequeñas de TI o telecomunicaciones no se registren con tanta diligencia.

“Las interrupciones que hemos tenido en los últimos 12 meses han sido principalmente interrupciones de“ negocios como siempre ”. Por lo general, se relacionan con cambios en los procesos o los cronogramas que siguen a un cambio legislativo o reglamentario, o para garantizar que nuestro personal reconozca los requisitos y procesos de salud y seguridad en el trabajo, como la notificación de peligros y accidentes ”. Analista de resiliencia, gobierno local, Nueva Zelanda.

Toma de acciones posterior a un incidente:

En muchas empresas, no se evidencian la toma de acciones posteriores a los incidentes, para determinar, por ejemplo:

cómo ingresó el virus (malware), o cómo se suscitó el incidente (a través de alguna vulnerabilidad no identificada), y cómo identificar la naturaleza o la exposición del riesgo y si además fue posible minimizar el impacto del inconveniente al negocio.

No es posible llevar a cabo un Procedimiento de Recuperación del Negocio de forma rápida (recuperar y restaurar los sistemas críticos), dentro de un Tiempo Objetivo de Recuperación (RTO) razonable sin tener impactos adversos para el negocio.

La respuesta a incidentes es un programa formal que prepara una entidad para un incidente, generalmente incluye:

1. Preparación Mapeo de sistemas de TI a funciones, procesos y servicios Red de comunicación empresarial Personal con destrezas y habilidades, establecer roles y responsabilidades y planes de como será manejado un incidente
2. Detección y análisis capacidad para identificar incidentes tan pronto como sea posible y evaluar eficazmente la naturaleza del incidente. Integrar el Análisis de impacto al negocio (BIA) y además de comunicar los incidentes a las partes interesadas del negocio.
3. Contención: Compromiso continuo con las partes interesadas del negocio (Aislar equipos, Desconectar equipos, Copia forense, análisis SandBox, capacidad de investigación, identificación del adversario)
4. Erradicación: Procedimientos de mitigación (Ejecutar plan de recuperación: restaurar imágenes, actualizar parches, hardening del S.O, tuning de aplicaciones, Actualización de ACL, Indicadores de compromiso)
5. Recuperación: Reducir las perdidas y volver las operaciones a la normalidad (Promover al Sitio Alterno/restaurar backups, Evaluar el incidente, decidir si es posible Retornar las operación del Sitio Alterno al Sitio principal). 
6. Lecciones Aprendidas: Análisis de causa raíz y supervisión de remediación

1. Marco de Gestión de Incidentes (ISO 27035)

El Marco de Gestión de Incidentes de Seguridad se basa en los principios de la norma ISO 27035 y describe los pasos a través de los cuales una organización debe seguir para establecer un Proceso de Gestión de Incidentes de Seguridad eficaz junto con los procesos que se utilizarán en caso de que ocurra un incidente. También cubre cómo abordar las lecciones aprendidas y la mejora continua junto con los procesos generales que son necesarios para respaldar el Marco de gestión de incidentes incluso cuando no está en uso. Esto incluye la necesidad de una comunicación eficaz y pruebas, seguimiento y revisiones generales del proceso.

• ISIRT: Equipo de Respuesta ante Emergencias Informáticas (Information Security Incident Response Team)

Es un centro de respuesta a incidentes de seguridad en tecnologías de la información. Se trata de un grupo de expertos responsable del desarrollo de medidas preventivas y reactivas ante incidencias de seguridad en los sistemas de información

La norma ISO 27035 cubre cinco fases que se cubrirán en detalle.

Fuente: PECB Lead Incident Manager

3. Planear y Preparar

4. Detección y reporte

Cuando se detecta un evento relacionado con la seguridad de la información, el responsable inicia el proceso de detección y reporte. Esta persona debe seguir los procedimientos y utilizar el formulario de informe de incidentes para informar el evento de seguridad como se indica en el esquema de gestión de seguridad de la información para llamar la atención del grupo de apoyo operativo y la gerencia sobre el evento de seguridad de la información inicialmente.

Por lo tanto, es fundamental que todo el personal conozca y tenga acceso a las pautas para informar sobre diferentes tipos de posibles eventos de seguridad de la información.

5. Evaluación inicial y decisión

• Evaluación inicial y decisión:

La persona del grupo de apoyo de operaciones que recibe el informe debe acusar que recibe el formulario con el informe de eventos de seguridad de la información, para luego guardar el informe en la base de datos de eventos / incidentes de seguridad de la información y examinarlo.

Esta persona debe buscar aclaraciones de la persona que produjo el informe relacionado con el evento de seguridad de la información y recopilar toda la información adicional conocida requerida y disponible de la persona que produjo el informe o de cualquier otra fuente.

Posteriormente, la persona de apoyo operativo del grupo debe realizar una evaluación para determinar si el evento de seguridad de la información debe clasificarse como un incidente de seguridad de la información o si es una falsa alarma. Si se determina que el evento de seguridad de la información puede ser un incidente de seguridad de la información y si el grupo operacional tiene el nivel apropiado de competencia, se puede realizar una evaluación adicional. Esto puede resultar en acciones correctivas, por ejemplo, los controles de protección de emergencia se identifican y se devuelven a las personas apropiadas para que se puedan tomar las acciones.

• Segunda evaluación y confirmación de un incidente:

La segunda evaluación y confirmación de la decisión de cerrar el evento incidente en la categoría de seguridad de la información, debe ser responsabilidad del CSIRT (Equipo

de respuesta a incidentes de seguridad). Si se determina que el incidente de seguridad de la información es real, entonces un miembro del CSIRT, involucrando a colegas si es necesario, debería hacer un análisis más exhaustivo.

El objetivo es confirmar la naturaleza del incidente de seguridad de la información, cómo se hizo y qué o a quién podría afectar, el impacto o impacto potencial del incidente de seguridad en la organización, una indicación de si el incidente de seguridad de la información se considera significativo o no (utilizando la grilla de seguridad predeterminada de la organización).

6. Respuesta

En la mayoría de los casos, la próxima actividad del CSIRT será identificar las acciones de respuesta inmediata para abordar el problema de seguridad de la información: registrar los detalles en el formulario de incidentes de seguridad de la información y en la base de datos de incidentes/eventos de seguridad de la información e informar a las personas o grupos sobre las acciones necesarias. Esto puede resultar en medidas de protección de emergencia (por ejemplo, aislar o detener un sistema de información, servicio y/o red afectada, con la aprobación previa del gerente de TI y/o el propietario apropiado), y/o la identificación de los controles de protección y informar a la persona o grupo apropiado para la acción.

Dependiendo de la gravedad del incidente , la categorización de la información de seguridad debe determinarse utilizando la escala predeterminada de gravedad de la organización, y si es lo suficientemente importante. Los miembros de la alta dirección correspondiente deben ser notificados directamente. Si bien es evidente que se debe declarar una situación de "crisis", por ejemplo, se debe notificar al director de continuidad del negocio para una posible activación del plan de continuidad del negocio; Además, el director del CSIRT y la alta dirección también deben ser informados.

Una vez que el miembro del CSIRT ha iniciado las respuestas inmediatas y que las actividades de análisis forense y comunicaciones se han completado, se debe hacer una recomendación rápidamente sobre si el incidente de seguridad de la información está bajo control. Si es necesario, el miembro puede consultar con colegas, el director del CSIRT u otras personas.

Si se obtiene la confirmación de que el incidente de seguridad de la información está bajo control, entonces el miembro del CSIRT debe proporcionar todas las respuestas, el análisis forense y las Comunicaciones posteriores necesarias para cerrar el incidente de seguridad de la información y restablecer las operaciones normales del sistema de información afectado.

Habiendo determinado que un incidente de seguridad de la información está bajo control y que no debe estar sujeto a ninguna actividad de "crisis", el miembro del CSIRT debe identificar si hay respuestas adicionales y qué respuestas adicionales se requieren para abordar el problema de seguridad de la información.

Esto podría incluir la restauración de los sistemas, servicios y/o redes de información afectados para reanudar sus operaciones normales. Luego debe registrar los detalles relacionados con la información incidente de seguridad en el formulario de reporte de incidentes de seguridad de la información y en la base de datos de eventos/incidentes de seguridad de la información y notificar a los responsables para completar las acciones relacionadas. Una vez que estas acciones se hayan completado con éxito, los detalles se deben registrarse en el formulario de informe de incidentes de seguridad de la información y en la base de datos de eventos/incidentes de seguridad de la información y luego el incidente de seguridad de la información debe cerrarse y debe notificarse al personal apropiado.

7. Lecciones Aprendidas

• 

8. Comunicación

• Durante un incidente, es posible que haya muchas partes interesadas diferentes con las que debamos comunicarnos. Esto puede incluir diferentes equipos internos y la alta dirección. Al desarrollar un proceso de respuesta a incidentes, se debe prestar especial atención a cada participante interno para considerar sobre qué les comunicaremos y en qué momentos. Necesitamos asegurarnos de que se tengan en cuenta el idioma, la relevancia, la frecuencia y los medios de dicha comunicación.
• Podría decirse que es necesario pensar de manera más específica en las distintas partes externas con las que debemos comunicarnos. ¿Cómo manejaremos las preguntas de los medios? ¿Cuándo informaremos a nuestro cliente y ¿Cómo informaremos al cliente (es posible que tengamos ciertas obligaciones contractuales que considerar)? ¿Necesitamos contar con el apoyo de ISP o proveedores de software y qué pasa con la aplicación de la ley? Claramente, se debe considerar la confidencialidad cuando se trabaja con proveedores de servicios de Internet y proveedores que ciertamente no queremos divulgar información confidencial o sensible.
• Para las fuerzas del orden público, es fundamental comprender cómo denunciar, pero también a quién informar en determinadas circunstancias. Si es posible, se recomienda encarecidamente que una organización establezca relaciones sólidas con las fuerzas del orden siempre que sea posible.

9. Pruebas

Pruebas: (¿Por qué / cómo?)

• La prueba no debe interrumpir las funciones comerciales normales
• Las pruebas deben comenzar con áreas fáciles para desarrollar habilidades y confianza
• El propósito es encontrar debilidades, actualizar y volver a probar
• Proceso iterativo, produce planes viables sólidos

Documentación necesaria (lista estándar):

• Escenarios de prueba
• Razones de la prueba
• Objetivos de la prueba
• Tipo de pruebas
• Programa de pruebas
• Duración de la prueba
• Pasos de prueba específicos
• Quiénes serán los participantes
• Las asignaciones de tareas de la prueba
• Medidas de éxito / fracaso de las pruebas
• Recursos y servicios necesarios

Tipos de planes:

• Lista de verificación

• Paso preliminar para la prueba real, distribuir el plan para que lo revisen los gerentes de la unidad de negocios

• Recorrido estructurado de mesa

• Los gerentes de unidades de negocios revisan el plan de prueba. Cada paso se recorre y se realiza.

• Simulación

• Todo el personal con responsabilidades en la gestión de incidentes se reunirá y realizará una sesión de práctica.
• Activa los procedimientos de recuperación pero no el procesamiento alternativo

• Paralelo

• Prueba completa del plan de recuperación con todo el personal. El procesamiento primario no se detiene.
• Garantiza que el procesamiento se ejecutará en un sitio alternativo. El tipo de prueba más común.

• Interrupción total

• El incidente se replica hasta el punto de cesar las operaciones normales. El plan se implementa como si fuera un incidente
• De alto riesgo y puede causar su propio desastre, pero puede ser la mejor manera de realizar una prueba completa

Lista de Actividades

Antes de implementar un proceso eficaz de Gestión de Incidentes, se debería haber realizado un Análisis de Riesgos para identificar los escenarios de riesgo que pudieran afectar a la organización.  El detalle de cómo llevar a cabo dicha evaluación de riesgos no se cubre en la ISO 27035.

La información sobre Evaluación de Riesgos es cubierta en las normas:

• ISO 27005 (Riesgos de Seguridad de la Información)
• ISO 31000 (Gestión de Riesgos).

La información del proceso de gestión de riesgos es un insumo importante para el proceso de mejora continua de la organización.

Entradas (Input):

• Políticas, procesos y procedimientos de seguridad de la organización
• Informe de análisis de riesgos

Actividades:

Implementación de formas de detección y respuesta a incidencias, adecuada, formación, comunicación de incidencias, gestión y aprendizaje de la experiencia

Salidas (Output):

• Procesos y procedimientos para la gestión de incidencias
• Equipo de gestión de incidentes

ISO 27035-2 Cláusula 4.3 Política de gestión de incidentes de seguridad de la información

La Política de gestión de incidentes de seguridad de la información debe incluir lo siguiente:

• Compromiso y apoyo de la Alta dirección
• Definición de un incidente de seguridad de la información
• Resumen de procesos y actividades para detectar y responder a incidentes
• Roles y responsabilidades de las partes interesadas clave
• Funciones y responsabilidades del equipo de respuesta a incidentes
• Mencionar la recopilación y conservación de registros
• Formación y sensibilización ante incidentes de seguridad
• Referencia a requisitos legales, reglamentarios y contractuales

ISO 27035-2 Cláusula 4.3 Destaca la importancia de una política clara y eficaz con respecto a lo que debe considerar la política de gestión de incidentes de seguridad de la información :

• Compromiso de gestión: La alta dirección debe apoyar las iniciativas establecidas en la política y asegurarse de que todos los miembros de la organización comprendan el valor y la importancia de una política eficaz y los procesos asociados en esta área. De hecho, cuando se produce un incidente, nadie debería tener alguna duda sobre el trabajo en línea y la importancia de la política con los requisitos.
• Definición de un incidente de seguridad de la información: De manera clara y sin ambigüedad. Cualquier persona de la organización debería poder identificar si un evento o un conjunto de eventos constituyen un incidente. Es vital tanto para elaborar informes precisos como para una respuesta efectiva
• Resumen de procesos y actividades para detectar y responder a incidentes:
• Roles y responsabilidades: Todos los involucrados en la organización deben comprender claramente sus roles y posición cuando se trata de identificar incidentes, informar incidentes y responder a incidentes.
• Recopilación y conservación de registros: Durante el reporte, respuesta y análisis de un incidente, se generarán varios registros. Se debe dejar en claro lo que deberían ser registros, dónde se deben guardar los registros, el formato y la seguridad que se aplicará.
• Formación y sensibilización ante incidentes de seguridad: En general, la conciencia de la seguridad de la información es fundamental para la postura de seguridad general de una organización. Una parte clave de este proceso de concienciación debe incluir la descripción clara de qué es un incidente y la importancia de informar el incidente al canal de denuncia correcto.
• Referencia a requisitos legales, reglamentarios y contractuales: Asegurarse de que las personas involucradas en la gestión de incidentes comprendan las leyes y regulaciones pertinentes es fundamental para tener un proceso de gestión de incidentes eficaz. Algunas leyes/reglamentos requieren que los incidentes se aborden y se informen dentro de un plazo establecido. Desde un punto de vista contractual, las organizaciones pueden tener requisitos para informar o manejar incidentes en ciertos plazos por parte de los clientes.

ISO 27035-2 Anexo D Registro de Incidente de seguridad de la información

Se debe registrar toda la información relevante relacionada con el incidente, incluyendo:

1. Identificador único
2. Categoría y prioridad
3. Fecha/hora de la grabación
4. Identificación de la persona que registró el incidente
5. Descripción de los síntomas
6. Estado del incidente (activo, pendiente, cerrado)
7. Activos afectados
8. Grupos o individuos afectados por el incidente
9. Actividades realizadas para resolver el incidente y sus resultados
10. Información de cierre (resolución, fecha/hora del cierre)

Registro de Incidente de seguridad de la información

ISO 27035-2 Anexo D:

• Es importante documentar y registrar cualquier incidente para asegurar que el personal responsable de manejar el incidente pueda tener toda la información necesaria para resolverlo de la manera más efectiva y lo más rápido posible.
• Esta información servirá como entrada para acciones correctivas y evidencia que demuestre a los auditores {interno y externo) que mantiene el SGSI.

Gestionar y responder a eventos perjudiciales inesperados con el fin de controlar el impacto a niveles aceptables

• Los errores pueden ser naturaleza técnica; por ejemplo, ataques montados sobre la red a través de virus, denegación de servicio (DoS) o intrusión del sistema o pueden ser el resultado de errores, accidentes o fallos en el proceso o sistema
• eventos físicos: actividades que tienen lugar como resultado de ataques no anticipados, por ejemplo robo de información privada, ingeniería social, perdida o robo de cintas de respaldo, perdida o robo de equipos portátiles, condiciones ambientales como inundaciones, incendios o terremotos, o cualquier otro evento adverso inesperado que ocurra como resultado de controles fallidos o inexistentes

La gestión y respuesta a incidentes es la parte operativa de la gestión de riesgos.

Se debe considerar cualquier tipo de incidente que pudiera tener un efecto significativo en la capacidad de la organización de funcionar o que pudiera ocasionar algún daño

Las interrupciones pueden derivarse de varios incidentes Técnicos: Ataques de virus, malware, ataques de denegación de servicios (DoS), intrusión del sistema, errores o fallos del proceso, y eventos físicos: robo de información privada, ingeniería social, perdida o robo de cintas de respaldo, perdida o robo de equipos portátiles, condiciones ambientales como inundaciones, incendios o terremotos.

La gestión de incidentes puede incluir actividades que contribuyan a minimizar la posibilidad de que ocurran incidentes o reducir los impactos, o bien ambos, aunque esto suele ser una función de la gestión de riesgos. Un ejemplo seria proteger los equipos portátiles físicamente para reducir la posibilidad de robo y encriptar disco duros para reducir el impacto que tendría el robo o la pérdida.

El proceso de gestión y respuesta a incidentes forma parte de los planes BCP/DRP.

El nivel de capacidad de gestión de incidentes debe considerar en el contexto

• El alcance de la gestión de incidentes y las capacidades de respuesta deben estar en equilibrio con la seguridad básica, la continuidad del negocio y la recuperación de desastres.

La capacidad para detectar y evaluar la situación, determinar las causas y llegar rápidamente a las soluciones, puede marcar la diferencia entre un problema y un desastre.

El proceso de gestión y respuesta a incidentes puede producir una reducción en los costos de la seguridad en general al establecer niveles mínimos para tratar eventos comunes, pero también brindar protección contra incidentes relativamente inusuales con una capacidad de respuesta, contención y recuperación.

Por ejemplo, si la capacidad de respuesta es reducida o nula, puede ser conveniente aumentar los niveles mínimos de seguridad

Existe un punto en el cual resulta menos costoso recurrir a opciones alternativas de procesamiento que mantener un alto nivel de gestión de incidentes y aun alta capacidad de respuesta a incidentes.

• No hay una garantía de que el mejor control posible evitará que ocurran incidentes perjudiciales e incluso, en ocasiones podrían ser catastróficos.
• Los eventos tales como: violaciones a la seguridad, cortes de energía eléctrica, incendios y desastres naturales pueden frenar las operaciones del negocio.

La gestión de respuesta permite a un negocio responder con eficacia cuando ocurre un incidente, continuar con sus operaciones en caso de una interrupción y superar cualquier interrupción o violación a la seguridad de los sistemas de información

Muchas organizaciones cuentan con un departamento independiente que tiene la responsabilidad del BCP y de la recuperación en caso de desastre (DR), y el grado de participación y autoridad. Sin importar como estén estructurados dichos departamentos, es esencial que trabajen de manera cercana y que los planes se contemplen y estén bien integrados.

Debe definirse claramente quien estará a cargo de cada tipo de evento y se deberán establecer criterios claros de gravedad y declaración.

Los criterios de gravedad deben describirse en términos consistentes y concisos, y deben ser fáciles de entender, de tal forma que eventos similares se determinen de manera uniforme con respecto a su nivel de gravedad.

También deben establecerse los criterios de declaración de tal forma que quede claro quien tiene la autoridad de determinar el nivel de respuesta, la activación de los equipos y declarar un desastre y poner en marcha el proceso de recuperación. Los criterios de severidad y su uso deben divulgarse ampliamente.

El personal debe recibir capacitación para reconocer los incidentes posibles y su adecuada clasificación, así como para conocer los requerimientos de notificación, reporte y escalamiento.

Se debe estar consiente de que siempre existe la posibilidad de que los eventos aumenten y se transformen en desastres, sin importar que tan bien se hayan previsto y manejado los incidentes.

Algunos de los factores que agravan la necesidad de una gestión eficaz de incidentes incluyen:

• La tendencia de mayores incidentes y de pérdidas causadas por incidentes de seguridad de la información
• El aumento de vulnerabilidades en el software o sistemas que afecta a gran parte de la infraestructura de una organización y tiene un impacto en las operaciones
• Falla de los controles de seguridad para prevenir incidentes.
• La creciente sofisticación y capacidades de los atacantes (estados-naciones) que buscan un beneficio económico
• Amenazas Persistentes Avanzadas (APT, Phishing, Ransomware)
• Aumento de los ataques de día cero (Zero-Day)
• Mandatos legales y regulatorios que exigen una capacidad de gestión de incidentes

A medida que las organizaciones confían cada vez más en los procesos y sistemas de información, y la interrupción significativa de esas actividades da como resultado impactos inaceptablemente severos, la importancia de una gestión y respuesta efectiva a los incidentes ha aumentado.

La gran cantidad de información y actividades manuales en sistemas cada vez mas complejos ha contribuido al desarrollo de sistemas automatizados para la gestión de incidentes:

Sistema Distribuido para la gestión de Incidentes:

• Sistemas de detección de incidentes basado en la red (NIDS)
• Sistemas de detección de intrusos basada en el HOST (HIDS)
• Registro (logs) de servidores/dispositivos

Sistema Centralizado para la gestión de Incidentes:

• Administrador de Eventos de Seguridad de la Información (SIEM)

Combina eventos críticos y los registros de muchos sistemas diferentes y los correlaciona con información mas significativa del incidente

• Proporcionar información filtrada que puede identificar posibles incidentes técnicos y alertar al equipo de gestión de incidentes (IMT)

NIDS Sistemas de detección de incidentes de la red (Network Incident Detection Systems)
HIDS Sistema de detección de intrusiones de host (Host Intrusion Detection System)
SIEM Gestión de eventos de seguridad de la información (Security Information Event Management)

Una característica importante de los sistemas para la gestión de incidentes es su capacidad para dar seguimiento a un incidente durante el ciclo de vida. El seguimiento es una característica altamente eficaz que garantiza que no se pasen por alto los incidentes y que reciban la atención necesaria con base en su criticidad

El seguimiento permite a los usuarios proporcionar mayor información y recibir actualizaciones de estado a través del ciclo de vida del evento hasta que se ha cerrado el evento. El sistema se ofrece mas a menudo en un formato basado en Web para una fácil accesibilidad

Un sistema eficaz para la gestión de incidentes debe ejecutar lo siguiente:

• Consolidar y correlacionar datos provenientes de varios sistemas
• Identificar incidentes reales y posibles
• 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 practicas

Existe una serie de responsabilidades que el Responsable de Seguridad (CISO) debe llevar a cabo:

• Desarrollar planes de gestión y respuesta a incidentes de seguridad de la información
• Manejar y coordinar las actividades de respuesta a incidentes relacionados con la seguridad de la información de manera eficaz y eficiente
• Validar, verificar y reportar las soluciones de protección de contramedidas, tanto técnicas como administrativas
• Llevar a cabo la planificación, la elaboración de presupuesto y el desarrollo del programa para todos los aspectos relativos a la gestión y respuesta a incidentes
• Obtener compromiso, apoyo y respaldo de la alta dirección

El enfoque de respuesta a incidentes puede variar dependiendo de la situación; las metas incluyen:

• Contener los efectos del incidente para que el daño y las perdidas no aumenten fuera de control
• Notificar a la gente apropiada el propósito de la recuperación o proporcionar la información necesaria
• Recuperarse rápida y eficazmente de los incidentes relacionados con la seguridad
• Minimizar el impacto del incidente relacionado con la seguridad
• Responder de forma sistemática y reducir la probabilidad de que el incidente vuelva a ocurrir
• Equilibrar los procesos operativos y de seguridad
• Resolver problemas legales y relacionados con el cumplimiento de las leyes

Tal como sucede con otros aspectos de la seguridad de la información, un actor crucial para el éxito de la gestión y respuesta a incidentes es contar con el compromiso de la alta dirección. Se trata de un componente de la gestión de riesgos y aplica la misma razón y justificación

Se puede preparar un caso de negocio (business case) con el objetivo de que la gestión y respuesta a incidentes sea una opción menos costosa que intentar implementar controles para todas las posibles condiciones. La gestión y respuesta a incidentes puede formar parte de los intercambios que pueden reducir el costo de las iniciativas de gestión de riesgo al permitir niveles mayores de riesgo aceptable.

Una respuesta a incidentes adecuada, en combinación con una seguridad de la información eficaz, crea una solución de gestión de riesgos practica que a la larga, puede resultar mas rentable y podría ser la decisión de gestión de recursos mas prudente

Identifica los puntos de integración con las partes interesadas del negocio y proporciona pautas sobre cómo ponerlas en práctica de manera práctica (Hari Mukundhan, ISACA)

Un estudio del Instituto Poneman reveló que solo el 14 por ciento de las empresas encuestadas dijeron que su gestión ejecutiva participa en el proceso de respuesta a incidentes, y "como consecuencia de esta falta de participación y conciencia, los gerentes de incidentes pueden no solo tener dificultades para priorizar el manejo de incidentes , pero también puede resultarle difícil obtener los recursos del liderazgo empresarial para invertir en las habilidades y tecnologías necesarias para hacer frente a futuros incidentes de seguridad ", que se espera que aumenten significativamente. Por lo tanto, el manejo de incidentes como una función requiere una fuerte integración con los procesos de gestión de riesgos operacionales de una manera más sistemática, para que el impacto en el negocio se pueda entender mejor y la priorización de incidentes pueda ser más precisa.

Un enfoque integrado para el manejo de incidentes
La "Guía de manejo de incidentes de seguridad informática" del Instituto Nacional de Estándares y Tecnología de los Estados Unidos (NIST) se ha aprovechado para enfatizar los posibles puntos de integración entre el proceso de gestión de incidentes de seguridad y el proceso de gestión de riesgos operativos y para proporcionar un marco para gerentes de incidentes y gerentes de negocios para comprometerse entre sí de manera efectiva. Este artículo revisa cada fase de la guía de flujo del proceso NIST, identifica los puntos de integración con las partes interesadas del negocio y proporciona pautas sobre cómo ponerlas en práctica de manera práctica.
Fuente: ISACA Journal / Issues / 2015 / Volume 6 / A Business-integrated Approach to Incident Response
Author: Hari Mukundhan, CISA, CISSP, Date Published: 1, November 2015
https://www.isaca.org/resources/isaca-journal/issues/2015/volume-6/a-business-integrated-approach-to-incident-response 

Hay muchos tipos de incidentes relacionados con seguridad/ciberseguridad, y nuevos tipos de incidentes emergen frecuentemente.

US-CERT ofrece categorías de incidentes de seguridad y los plazos de presentación de informes utilizados por las agencias federales

El control de Seguridad sigue siendo un inconveniente para los responsables de Tecnología de la Información (TI) de la mayoría de las organizaciones del medio, el clásico ejemplo es cuando un virus o gusano informático infecta a los equipos de cómputo de la organización. Los profesionales de TI deben dejar todas sus actividades destinando esfuerzo para actualizar y escanear los equipos, y en algunos casos, reiniciar todo el proceso de instalación (preparar los servidores y reconfigurar servicios críticos desde el inicio, cambiar las contraseñas administrativas), lo que causa una inversión importante de tiempo y la interrupción de los servicios críticos del negocio.

ENISA: https://www.enisa.europa.eu/publications/reference-incident-classification-taxonomy 

csirt.gob.cl: https://www.csirt.gob.cl/matriz-clasificacion-incidentes/ 

Qué información se debe comunicar a qué partes interesadas y durante qué etapa del incidente

Red de comunicación de incidentes  (Hari Mukundhan, ISACA):

Un incidente de seguridad en desarrollo, dependiendo de su alcance, podría crear confusión y pánico tanto para el personal como para los clientes. Para mitigar de manera proactiva dicha confusión, los gerentes de incidentes deben proporcionar información clara, precisa, relevante y específica a diversos públicos. Para las partes interesadas del negocio, el mensaje debe ser lo menos técnico posible y debe apuntar a los posibles impactos comerciales para que las partes interesadas puedan calibrar las respuestas de su lado. El rol de administrador de incidentes en la organización de seguridad de la información tiene el mejor punto de vista para proporcionar dicha información. El gerente de incidentes debe estar preparado por adelantado con la red de comunicación, es decir, qué información se debe comunicar a qué partes interesadas del negocio y durante la etapa del ciclo de vida del incidente. Las plantillas apropiadas, las listas de distribución de correo electrónico y los árboles de llamadas deben crearse por adelantado en asociación con la empresa. Siempre que sea posible, se debe realizar una ejecución en seco para ajustar la efectividad de los canales y vehículos de comunicación.

Las personas marcan la diferencia entre un buen proceso y un gran proceso. La dotación de personal adecuado en el proceso de gestión de incidentes con habilidades adecuadas, especialmente en los puntos de integración con las empresas, ayuda a navegar la respuesta a un resultado más exitoso. Idealmente, dicho personal debería tener una buena combinación de habilidades técnicas, comerciales y de comunicación y estar igualmente cómodo tratando con los equipos técnicos y los equipos comerciales.

Para ayudar a mantener la agenda de seguridad/ciberseguridad constantemente alineada con las prioridades comerciales y proporcionar un mecanismo práctico y efectivo para priorizar incidentes, es vital un enfoque integrado para la gestión de incidentes. La respuesta y la recuperación pueden ser más específicas y más eficientes. Además, los gerentes de seguridad/continuidad/incidentes pueden encontrarse en una mejor posición para obtener recursos para invertir en habilidades y tecnologías que se requieren para enfrentar incidentes futuros.

A: Audio / V: Video Conferencia

La organización típica posee diversos recursos que deben identificarse y utilizarse en el desarrollo del plan de la gestión y respuesta a incidentes:

• Desarrollar una visión clara
• Definir los objetivos de Gestión y respuesta a Incidentes seguridad de la información
• Desarrollar una estrategia de implementación
• Definición de PNPs para respaldar el Plan de respuesta a Incidentes
• Alinear las actividades de gestión de Incidentes con la misión del IMT
• Definir los principios de seguridad C-D-I
• Entender las vulnerabilidades, deficiencias y ataques relacionados en la Seguridad

El conocimiento sobre los principios de seguridad para entender posibles problemas que pueden surgir en caso de que no se implementen correctamente las medidas de seguridad apropiadas y para entender los posibles impactos que pueda tener en los sistemas de la organización.

Para conformar un equipo de respuesta a incidentes con administradores capaces, las organizaciones requieren de personas que cuenten con una determinada serie de habilidades y conocimientos técnicos especializados, que le permitan responder a los incidentes, llevar a cabo taras de análisis y comunicarse de forma efectiva con la comunidad de usuarios y otros contactos externos. También deben ser capaces de solucionar problemas de manera competente, adaptarse al cambio rápidamente y ser eficientes en el desempeño de sus actividades diarias.

El conjunto de habilidades básicas con las que deben contar los miembros del equipo de respuesta a incidentes se puede clasificar en dos grandes grupos:

• Habilidades personales: Las partes principales de la actividad diaria del administrador de incidentes, incluyendo:

• Comunicación, Integridad, Conocimiento de si mismo
• Habilidades de liderazgo, Habilidades de presentación
• Habilidad para apegarse a las políticas y procedimientos
• Habilidades de trabajo en equipo, bajo presión (superando la tensión)
• Solución de problemas, Gestión del tiempo

• Habilidades técnicas: Las habilidades técnicas básicas que deben tener los miembros de un equipo de gestión de incidentes se clasifican en dos tipos:

• Habilidades de base técnica: se requiere de un entendimiento básico de las principales tecnologías que utiliza la organización
• Habilidades para el tratamiento de incidentes: se requiere de una comprensión de las técnicas, puntos de decisión y herramientas de soporte (software o aplicaciones) que se requieren en la ejecución de las actividades diarias

ISO 27002:2013 control A.7.2.2
“Concienciación con educación y capacitación en seguridad de la información”

Todos los empleados de la organización y, cuando sea pertinente, contratistas, deberían recibir concientización, entrenamiento y formación adecuada y actualizaciones regulares en políticas y procedimientos organizacionales, relevantes para su función laboral.

NIST PR.AT1
“Todos los usuarios se encuentran entrenados e informados”

El personal y los socios de la organización reciben educación de concienciación sobre la seguridad cibernética y son capacitados para cumplir con sus deberes y responsabilidades relacionados con la seguridad cibernética, en conformidad con las políticas, los procedimientos y los acuerdos relacionados al campo.

La norma nos da algunas indicaciones de aspectos que deben incluirse en la formación y sensibilización

• La formación debe incluir el compromiso de la dirección con la seguridad de la información en toda la organización
• La importancia del conocimiento y el cumplimiento de las obligaciones aplicables de seguridad de la información contenida en las políticas, normas, contratos, etc.
• La responsabilidad de los empleados y contratistas de sus propias acciones u omisiones en la protección de la información

Los procedimientos básicos de la seguridad de la información, por ejemplo:

• Procedimiento de notificación de incidentes de seguridad
• Procedimientos sobre uso de contraseñas seguras
• Controles sobre software malicioso
• Limpieza de escritorios, Etc.

Los recursos que disponen para obtener más información sobre cuestiones de la seguridad de la información (puntos de contacto, manuales o especificaciones etc.)

Organización de equipos de respuesta a incidentes:

Las personas que intervienen en el tratamiento de incidentes analizan los datos de los incidentes, determinan el impacto del incidente y actúan apropiadamente para limitar el daño a la organización y restaurar los servicios normales. A menudo el equipo dependerá de la participación y cooperación de grupos complementarios y de usuarios generales.

Los miembros permanentes pueden incluir administradores de incidentes, investigadores y expertos forenses y especialistas de seguridad física y de TI. Los miembros de equipos virtuales, por lo general, son representantes de negocio (gerencia media), personal jurídico, comunicaciones (relaciones publicas), recursos humanos (RR.HH), Seguridad física, gestión de riesgos, especialistas de TI y otros grupos.

Un IMT suele estar conformado por un gerente de seguridad de la información, comité directivo/consejo consultor, miembros de equipos permanentes y miembros de equipos temporales/virtuales

Por lo general, el gerente de seguridad de la información dirige el equipo. En organizaciones grandes, seria mas eficaz designar a un líder/gerente de IRT.

Antes de continuar, debe realizar la Actividad 10 – IRT, IMT.

Los objetivos de la gestión de incidentes son los siguientes:

• Manejar incidentes cuando ocurren, de tal forma que sea posible mitigar o erradicar la exposición y permitir la recuperación dentro de una ventana de interrupción aceptable (AIW)
• Prevenir que vuelva a ocurrir incidentes previos mediante la documentación y aprendizaje de incidentes pasados
• Aplicar contramedidas proactivas para prevenir/minimizar la probabilidad de que los incidentes tengan lugar

El proceso de gestión y respuesta a incidentes actúa como el cuerpo de bomberos, el servicio de ambulancia y la sala de urgencias para los activos de información de la organización

• La razón de ser de la gestión de incidentes es tratar los eventos inevitables que amenazan la operación de cualquier organización
• Funciona como la penúltima red de seguridad después de que los controle san fallado en evitar o contener un evento amenazante
• Su propósito es contener y responder a un incidente amenazante o restablecer con rapidez las operaciones normales en caso de que se haya ocasionado daño. No hacerlo ocasionara la declaración de un desastre, y las operaciones de recuperación se trasladaran a un sitio alterno para restablecer las operaciones con base en un BCP/DR
• El proceso de gestión y respuesta a incidentes debe ser eficaz para afrontar una amplia gama de posibles eventos inesperados , tanto electrónicos como físicos.
• Sera necesario contar con capacidades de monitoreo bien desarrolladas para los controles claves, ya sean técnicos o de procedimiento, para detectar posibles problemas en una etapa temprana. Deberá contar con personal capacitado en la evaluación de la situación, capa de brindar capacidades de priorización de emergencias, gestionar respuestas eficaces que maximicen la continuidad operativa y minimicen los impactos.
• Los gerentes de seguridad/incidentes establecerán previsiones para capturar toda la información que se relevante y aplicarán las lecciones aprendidas de experiencias pasadas. Sabrán cuando un desastre sea inminente y contaran con criterios bien definidos, experiencia, conocimiento y la facultad para activar los procesos de recuperación en caso de desastres que sean necesarios para mantener o recuperar el estado operativo.

Las métricas basadas en indicadores claves de desempeño (KPIs) y las metas del programa establecidas para la gestión de incidentes deben presentarse a la alta dirección como una base para justificar el soporte y financiamiento continuo:

• Número total de incidentes detectados vs reportados
• Tiempo promedio para resolver un incidente vs ventana de interrupción aceptable (AIW)
• Número total de incidentes resueltos satisfactoriamente
• Número total de empleados que recibieron concientización sobre seguridad
• Ahorros totales de los posibles daños que se hubieran generado por incidentes resueltos
• Daños totales ocasionados por incidentes reportados/detectados

Las métricas, medidas e indicadores de gestión de incidentes son los criterios que se utilizan para medir la eficacia y la eficiencia de la función de gestión de incidentes.
Permiten a la Alta dirección entender la capacidad de la gestión de incidentes de su organización y las áreas de riesgo que es necesario atender.
Las medidas y los reportes sobre la gestión de incidentes resultan de utilidad para el IMT a fin de llevar a cabo una autoevaluación y saber lo que se ha hecho satisfactoriamente y las mejoras que son necesarias hacer.

Preparar:

Preparar (mejorar/sustentar): Este proceso define todo el trabajo de preparación que se debe realizar antes de contar con alguna capacidad para responder a incidentes. Contiene subprocesos para evaluar una capacidad del tratamiento de incidentes y revisión post-mortem de incidentes para efectos de mejoras.

Definición de los Procesos de la Gestión de Incidentes (Defining Incident Management Processes) CMU/SEI adoptado por SANS Institute
Fuente: Reporte técnico del CMU/SEI (Carnegie Mellon University) / (Software Engineering Institute)

Proteger la infraestructura (Proteger):

Proteger la infraestructura (Proteger): El proceso de protección tiene la intención de proteger y asegurar los datos críticos y la infraestructura informática, así como a su comunidad de usuarios cuando se responde a un incidente.

También propone mejoras sobre un programa predeterminado mientras que se mantiene en consideración un contexto apropiado

Detectar eventos (Detectar):

Detectar eventos (Detectar): el proceso de detección identifica cualquier actividad inusual/sospechosa que pudiera comprometer las funciones de negocio criticas o la infraestructura.

Para que el IMT reciba el reporte oportunamente, se deberá contar con múltiples canales de comunicación que vayan de los usuarios finales al IMT. Estos pueden establecerse como llamadas telefónicas, faxes, mensajes de correo electrónico, reportes en formato web y sistemas de detección de intrusos (IDS) automatizados. 

Priorizar eventos:

Priorizar eventos: La priorización de eventos es un proceso que consiste en clasificar, categorizar, correlacionar, priorizar y asignar reportes/eventos entrantes. Es un elemento esencial de cualquier capacidad de gestión de incidentes. Cuando el IMT recibe varios reportes, la priorización de incidentes permite priorizar los eventos en forma apropiada, recibiendo así una respuesta oportuna. También sirve como un solo punto de entrada para la correspondencia o información del IMT.

La priorización de eventos proporciona una fotografía instantánea del estado actual de toda actividad de incidentes reportados, una ubicación central para todos los reportes entrantes para su atención posterior.

Responder:

Responder: El proceso de respuesta incluye los pasos que se toman para tratar, resolver o mitigar un incidente.  CMU/SEI define tres tipos de actividades de respuesta: Respuesta técnica, gerencial y/o legal.

Preparación:

Elementos de un plan de respuesta a incidentes: El Plan de Respuesta a Incidentes (IRP) es el componente operativo de la gestión de incidentes.

El siguiente modelo propuesto por Schultz, Brown y Longstaff en el informe técnico de la Universidad de California “Responding to Computer Security Incidents: Guidelines for Incident Handling” (UCRL-ID-104689, 23 de julio de 1990), presenta el modelo de respuesta a incidentes de seis fases que incluye: preparación, identificación, contención, erradicación, restauración y seguimiento

Identificación:

Contención:

Erradicación:

Recuperación: 

Lecciones aprendidas:

Fuente: ISACA (2015) CSX Cybersecurity Nexus, adoptado por ISACA (2016) CISM Review Manual 15th Edition, (pag. 230-231)

Procesos de Centro de Soporte (Help Desk) para identificar los incidentes relacionados con la seguridad:

• El responsable de seguridad de la información debe contar con procesos definidos para el personal de los centros de soporte (Help Desk) a fin de distinguir entre una solicitud típica de un soporte y la notificación de un posible incidente relacionado con la seguridad.
• Es probable que el centro de soporte (Help Desk) reciba el primer informe de un problema relacionado con la seguridad
• El reconocimiento inmediato de un incidente en progreso y su pronta canalización a las partes pertinentes es fundamental para minimizar el daño que se deriva de dichos incidentes

• Software de mesa de Ayuda / Tickets de Servicios
• Tableros Visuales de Seguimiento

Al definir los criterios apropiados y al mejorar la concientización del personal de soporte, el gerente de seguridad de la información desarrolla otro método importante para detectar incidentes relacionados con la seguridad. Brindar una capacitación adecuada también contribuye a reducir el riesgo de que el soporte pueda ser blanco de un ataque exitoso de ingeniería social diseñado para obtener acceso a cuentas, como cuando un atacante se hace pasar por un usuario al cual se le ha negado el acceso y requiere de acceso inmediato al sistema. Además de identificar el posible incidente relacionado con la seguridad, el personal del soporte (Help Desk) debe conocer los procedimientos apropiados para notificar y escalar un posible incidente.

Enlace de interés:
https://sourceforge.net/projects/itop/ 
iTop (IT Operations Portal): El Portal de operaciones de TI, es una herramienta de gestión de servicios basada en web, ITIL y de código abierto completa que incluye una CMDB totalmente personalizable, un sistema de servicio de asistencia y una herramienta de gestión de documentos. iTop también ofrece herramientas de importación masiva y servicios web para integrarse con el código fuente de su proyecto de TI que se trasladó a https://github.com/Combodo/iTop

Software de mesa de Ayuda y Tickets de Servicios:
https://www.manageengine.com/latam/service-desk/ 
https://www.solarwinds.com/es/service-desk 
https://freshdesk.com/latam/ 
https://freshservice.com/latam 

Tableros Visuales de Seguimiento:
https://kanbanflow.com/ 
https://trello.com/es 
https://asana.com/es

Antes de continuar, debe realizar la Actividad 11 – CERT, CSIRT, SOC, NOC.

El plan debe identificar a los equipos y definir sus responsabilidades asignadas en caso de que ocurra un incidente.

Para implementar las estrategias que hayan sido desarrolladas para la recuperación del negocio, es necesario designar y capacitar al personal clave para la toma de decisiones, del área técnica y del usuario final a fin de dirigir los equipos. Dependiendo del tamaño de la operación de negocio, el equipo puede estar conformado por una sola persona. La participación de estos equipos depende del nivel de interrupción del servicio y los tipos de activos perdidos, comprometidos, dañados o en peligro.

Se debe desarrollar una matriz que indique la correlación entre las funciones de los distintos equipos. Esto facilitara la estimación de la magnitud de las actividades y la activación de la combinación de equipos adecuada.

Se debe acordar una cantidad de decisiones importantes durante las fases de planificación, implementación y evaluación del plan de respuesta y recuperación. Estas incluyen:

• Metas/requerimientos/productos para cada fase
• Objetivo principal e indicadores de desempeño
• Factores cruciales de éxito y aspectos de ruta critica de la implementación
• Instalaciones alternas en las cuales se pueden llevar a cabo tareas y operaciones
• Recursos de información critica que se vana implementar (por ejemplo, datos y sistemas)
• Personas responsables de llevarlas a cabo
• Recursos disponibles, incluyendo los financieros, humanos y técnicos, para ayudar en el despliegue
• Programa de actividades con prioridades establecidas.

Capacitar a los equipos de respuesta es esencial; el gerente de seguridad de la información debe desarrollar escenarios de eventos y probar los planes de respuesta y recuperación para garantizar que los participantes de los equipos conozcan sus tareas y responsabilidades. A través de este proceso, los equipos identificarán también los recursos que requieren para la respuesta y la recuperación, lo que proporciona la base para dotar a los equipos con los recursos que necesitan. Uno de los valores agregados de la capacitación es que permite detectar y modificar los procedimientos ambiguos para lograr claridad y determinar los recurso de recuperación que pudieran no ser efectivos o adecuados.

Cada sistema de procesamiento de información de importancia extrema requerirá un enfoque para restaurar las operaciones en caso de interrupción. Existen varias estrategias alternativas que pueden considerarse tanto en términos de capacidad de gestión y respuesta ante desastres. Estas pueden variar desde sistemas redundantes y duplicados hasta el aseguramiento de un alto grado de robustez y capacidad de recuperación de los sistemas o procesos.

Antes de continuar, debe realizar la Actividad 12 – Estrategias para abordar riesgos en Proyectos

Antes de continuar, debe realizar la Actividad 13 – Retos en el desarrollo de un plan para la gestión de incidentes