Gestión de Incidentes para Operaciones

Capítulo 4. Ampliación de la respuesta a incidentes

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Respuesta a incidentes y escalada

Los pequeños incidentes de con escaso impacto suelen requerir menos personal y un marco de gestión, y quizá dependan más de la resolución de problemas por parte de individuos. Los grandes problemas con alto impacto suelen requerir más personal de respuesta a incidentes, más marco de gestión, más trabajo en equipo, más tareas que completar y seguir, más estrés y más impacto empresarial que considerar. Estos incidentes de mayor envergadura suelen requerir un marco de gestión sólido para mantenerse organizados y un Comandante de Incidentes más fuerte para que el esfuerzo siga avanzando de forma clara y decidida.

No existe una fórmula de gestión perfecta para ninguna de las dos situaciones, ni reglas rígidas. Depende de cada Comandante de Incidentes crear la mezcla adecuada de mando y marco para crear el entorno de resolución de incidentes más eficaz, que se ajuste al tamaño y alcance del incidente. Parte de ser un buen Comandante de Incidentes es la capacidad de saber mezclar con pericia los elementos de mando, marco y resolución de problemas.

En algunos casos, puede parecer innecesario atenerse a una estructura de mando formal en lo que parece un asunto menor (asunto de caja verde o amarilla), pero piénsalo de este modo: cada respuesta a un incidente refuerza el uso del proceso para todos los intervinientes, porque la habilidad y la destreza se dominan con la repetición.

Si el SGI sólo se activa para incidentes de gran envergadura (incidentes de caja roja o negra), es posible que no se disponga de esas habilidades y competencias para implementar rápida y satisfactoriamente el proceso cuando realmente importa. Así pues, quienes respondan a incidentes deben aprovechar cualquier oportunidad para practicar el cambio de tiempos de paz a tiempos de guerra y sentirse lo suficientemente cómodos como para que el uso del marco no sea tan caótico como el propio incidente.

Si siempre utilizas el SGI, por pequeño que pueda parecer un problema en un principio, el marco y el Comandante de Incidentes están preparados y listos para escalar si es necesario.

Ámbito de control

Como seres humanos, todos tenemos límites en cuanto a la cantidad de información que podemos procesar en un momento dado o la atención que podemos prestar a conversaciones o tareas que compiten entre sí, especialmente cuando estamos estresados. En tiempos de paz, la multitarea es habitual. En tiempos de guerra, los intervinientes en incidentes deben tener cuidado de no verse abrumados por demasiados datos, demasiadas conversaciones simultáneas o demasiadas tareas que completar en un plazo de tiempo reducido. Es fundamental que reconozcas tus límites y los de los demás, y que no te exijas hasta el punto de romperte, sobre todo cuando manejes a personas bajo estrés durante un incidente.

El ámbito de control es el número máximo de personas que una persona puede dirigir. Normalmente, ese número es de 5 a 7 personas. Mantener un alcance de control aceptable garantiza unidad de mando, o líneas claras de autoridad de información. Cuando 30 personas se unen a un puente de conferencias telefónicas sobre incidentes, con o sin un líder definido, la conversación puede degradarse rápidamente, volverse improductiva y perder el foco, lo que supone una pérdida de tiempo que nunca puede recuperarse.

En términos sencillos, la amplitud de control es una táctica de gestión del Comandante de Incidentes. Se utiliza cuando es necesario organizar a muchos intervinientes en el incidente de forma que se mantenga el control de las tareas asignadas y de los debates que deben tener lugar. Consiste en dividir un gran conjunto de tareas en actividades más pequeñas y manejables, y delegar el trabajo de forma que se pueda hacer un seguimiento y una gestión eficaces.

Esto no quiere decir que nunca se deba violar el ámbito de control recomendado de 5-7 subordinados directos. Recuerda que los incidentes son dinámicos y pueden cambiar, a menudo de forma bastante rápida y drástica, pero no te quedes atrapado con un ámbito de control demasiado amplio.

Repasemos el concepto de amplitud de control en acción con este ejemplo, utilizando el formato de informe CAN:

Condiciones

• El rendimiento del sistema se ha ralentizado tras un reciente cambio de software en una aplicación crítica

• Se desconoce la causa

Acciones

• El servicio de asistencia de nivel 1 ha determinado que el problema está fuera de su alcance y lo ha derivado a la IRT

Necesita

• IRT para investigar

Nota

De nuevo, en problemas de bajo impacto, puede ser tan básico como que un Comandante de Incidentes dirija un pequeño grupo de sólo dos o tres respondedores a incidentes, como se ve en la Figura 4-1. En esta ilustración, el organigrama representa a un pequeño grupo de primeros intervinientes (PYMES) que llegan a un puente de conferencia telefónica sobre incidentes: un DBA, un ingeniero de redes, un ingeniero de SAN/Almacenamiento y el Comandante de Incidentes.

Como en cualquier incidente, la función de Comandante del Incidente la desempeña inicialmente el primer CI cualificado que se encuentre en el puente. Sin embargo, ten en cuenta que la función de Mando puede transferirse en cualquier momento a cualquier persona por cualquier motivo, siempre que esa persona esté cualificada para desempeñar el papel de Comandante del Incidente.

Incluso para esta respuesta a un incidente aparentemente simple (de baja gravedad, no complejo), debe establecerse el cargo de Comandante del Incidente. De nuevo, mirando hacia el servicio de bomberos como guía, podrías oír algo como esta transmisión de radio de forma habitual, incluso en lo que podría considerarse un incidente rutinario: "Motor 2 en escena de un accidente de tráfico de dos vehículos. Parece que todas las partes han salido de los vehículos. Motor 2 estableciendo mando en la calle Oak". Sin duda hay variaciones en las palabras utilizadas, pero la cuestión es que, aunque este incidente parezca un pequeño asunto de caja verde-amarilla, el servicio de bomberos lo hace así porque es la forma, y cuando ese mismo camión de bomberos llega a un incidente grande, el proceso de establecer el mando es familiar y automático.

Figura 4-1. Estructura de mando simple para un problema de baja gravedad

También observarás en la Figura 4-1 que las casillas no se identifican con el nombre de la persona que ocupa el puesto, sino que sólo se nombran las funciones del puesto: CI, Base de Datos, Red y SAN/Almacenamiento. Volviendo al ejemplo que acabamos de dar sobre el servicio de bomberos, el oficial de la compañía (jefe del equipo) del Motor 2 no dijo: "Frank, Pete, Bill y Kathy están en la escena". Se identificaron por su función, que en este caso es una función de equipo llamada Motor 2. Como otro ejemplo, los grandes camiones escalera que ves en un incendio representan una función específica, del mismo modo que la unidad de respuesta a materiales peligrosos es una función, y también lo es un equipo de rescate técnico. Llegados a este punto, el proceso de establecer el mando y dirigir los recursos por función laboral (PYMES) en lugar de por nombre de persona permite que el organigrama crezca con rapidez y claridad, aunque la persona que ocupe la función cambie por algún motivo. La función es la constante. La persona concreta que la desempeña puede variar día a día, e incluso durante un incidente.

Si en el ejemplo de la Figura 4-1 se necesita más de un DBA, se puede crear un grupo de base de datos y el Comandante del Incidente sólo tendrá que comunicarse con el líder de la función de base de datos (Líder del Grupo de Base de Datos, o DGL), sin tener que llevar la cuenta de los múltiples individuos asignados a ella. Si tu organización es pequeña y todo el mundo se conoce, esto puede parecer ridículo, pero cuando el grupo de PYMES es grande o está repartido por todo el mundo, es mucho más claro hacer un seguimiento de tus PYMES por función en lugar de por nombre.

Para continuar con el ejemplo de la Figura 4-1, supongamos que tras unos minutos de discusión, otros tres DBA de otra zona horaria se unen al puente de la multiconferencia de incidentes. El Comandante del Incidente reconoce a los nuevos intervinientes que se han unido al puente y la conversación subsiguiente podría sonar así:

PYME: "Hola, soy Allen, de la base de datos".

SME: "Kelly también acaba de incorporarse".

Comandante de Incidentes: "Hola, Allen. Soy Ben. Soy el Comandante de Incidentes y estamos trabajando en un SEV 1. Gracias por unirte. También he oído que se ha unido Kelly".

PYME Kelly: "Sí, soy DBA en Sydney, Australia. También estoy aquí con James".

Comandante de Incidentes: "Recibido, siento despertarte a estas horas, pero necesitamos tu ayuda. Estoy en medio de una conversación con el ingeniero de SAN/Almacenamiento y en breve te daré un informe de CAN. Espera por ahora".

SME: "Recibido. Preparado".

SME Kelly con James: "De acuerdo".

En este rápido intercambio, el Comandante de Incidentes ha establecido las normas de participación para que las PYMES se unan al puente, y luego debe decidir el momento de dar actualizaciones y/o participar a las PYMES. Si se está manteniendo una conversación importante y se incorpora una nueva persona, el Comandante de Incidentes puede esperar para reconocer a la PYME con el fin de no romper el flujo de la conversación. No hay normas establecidas al respecto. Depende del Comandante de Incidentes cómo gestionar el flujo de intervinientes que llegan al puente de la multiconferencia de incidentes.

Además, algunos IRT utilizan una página de estado o alguna otra forma de capturar electrónicamente los sucesos y poner la información a disposición de todos los intervinientes en el incidente. Es una forma eficaz de proporcionar actualizaciones de estado e información actualizada sobre la respuesta al incidente. Sin embargo, a falta de ello, el Comandante del Incidente puede proporcionar informes CAN a intervalos regulares para mantener a todos informados.

Avancemos rápidamente y supongamos que nuestro ejemplo de un escenario de respuesta a un incidente está aumentando rápidamente en gravedad y el número de intervinientes en el incidente ha aumentado a nueve. Para evitar el caos en el puente, el Comandante de Incidentes tendría que mantener la amplitud del control. Supongamos que el incidente se identifica como un problema de la base de datos y que hay una conversación sólida entre los DBA. Como ahora hay cinco DBA en la llamada, y dependiendo de lo que se esté discutiendo en el puente, podría tener sentido que el Comandante de Incidentes

1. Crea un grupo de bases de datos.

2. Asigna a uno de los DBA el papel de Líder del Grupo de Bases de Datos (DGL).

3. Indícales que establezcan otro puente de conferencia de incidentes y trasladen sus conversaciones a ese puente.

4. Pide que sólo el DGL informe al Comandante del Incidente y/o responda por el grupo.

El DGL puede ser o no un gestor de bases de datos en tiempos de paz, o incluso el DBA más experimentado. De hecho, es totalmente decisión del Comandante del Incidente (con la aportación del DBA y lo que sea adecuado para la situación), pero los DBA tienen que apoyar a su DGL.

El DGL recién nombrado debe tomar las siguientes medidas:

1. Mueve el grupo de base de datos del puente de multiconferencia del incidente principal a un puente de grupo de base de datos.

2. Dirige las discusiones sobre el puente base de datos-grupo.

3. Asigna tareas a los DBA del grupo de bases de datos y facilita los debates.

4. Informa al Comandante del Incidente en el puente principal de la conferencia telefónica del incidente.

La Figura 4-2 ilustra el organigrama que representa al grupo de bases de datos recién formado. Puedes ver que el Comandante de Incidentes tiene en cuenta el alcance del control agrupando a los DBA.

Nota

El Comandante del Incidente puede ser creativo con la estructura de mando, pero la idea es delegar o trocear las tareas de forma que mantenga el número de personas que dependen de cualquier otra persona dentro del rango de control de 5-7.

Es conveniente que el DGL informe al Comandante de Incidente de los resultados del trabajo del grupo de base de datos y/o de las recomendaciones/acciones. En esa discusión, el Comandante de Incidente debe dirigir las preguntas al DGL. Es importante que el DGL sea la única persona que hable en nombre del grupo de base de datos. Si el grupo de base de datos se disuelve una vez finalizadas las tareas, todos los miembros del grupo de base de datos, incluido el DGL, están disponibles para otra serie de tareas.

Esto es una simple ilustración del punto, pero con la naturaleza modular del SGI, un Comandante de Incidente puede construir una estructura para agilizar y monitorizar/controlar la respuesta más eficazmente. Agrupando los recursos, nombrando líderes de grupo (GL) y asignando tareas por funciones, la comunicación es directa y más fácil de seguir. Si se necesitara otro grupo de expertos, el Comandante del Incidente podría crear otro grupo con otro nombre, nombrar un líder, esbozar las tareas con un calendario, y esperar un informe del GL en el puente de conferencias telefónicas del incidente.

Figura 4-2. Organigrama de un incidente ampliado

Además, ves que se añade al organigrama el puesto de escribiente (SitStat). También se llama SitStat porque es la función que mantiene el estado de la situación en todo momento durante el incidente. Un escriba (tanto si es una persona que realiza la tarea como si está automatizado de algún modo) es útil para ayudar al Comandante del Incidente a documentar: los intervinientes en el incidente; la cronología del incidente; las asignaciones realizadas por función con plazos de tiempo; y las acciones realizadas. No todas las organizaciones tienen el lujo de contar con un gran IRT o un gran grupo de PYMES, por lo que puede que este puesto no sea realista para tu IRT. Si no es así, se debe seguir escribiendo, pero lo hace el Comandante del Incidente. Puede que documentes la respuesta electrónicamente, lo que sin duda es útil, pero ten en cuenta que el puesto de escriba es una forma estupenda de que los miembros junior del IRT adquieran experiencia y observen a un miembro más veterano manejando la respuesta a un incidente. Además, escribir puede considerarse una tarea mundana, cuando en realidad es muy importante para mantener una cronología precisa del incidente y se convierte en la base de una Revisión Posterior a la Acción (RPA).

Nota

El puesto de escribiente (SitStat) se muestra aquí como una función a desempeñar y no cuenta en el ámbito de control del Comandante de Incidentes. Es una función de apoyo y no activa en el esfuerzo de resolución de problemas.

La Figura 4-3 representa una posible forma en que el ejemplo de la Figura 4-2 podría intensificarse con un número aún mayor de intervinientes en el incidente, manteniendo aún un ámbito de control adecuado.

Llegados a este punto, conviene definir el término escalar. En TI, escalar tiene dos significados distintos, pero interrelacionados: 1) llevar un asunto a un responsable de rango superior para que tome una decisión; 2) en caso de que una persona identificada como recurso primario de guardia no responda en un plazo determinado, llamar al recurso secundario o terciario. He aquí un diálogo típico para la primera definición: "Esta es una decisión de red que no tengo autoridad para tomar, así que voy a escalar a mi gestor de red para que haga la llamada". He aquí un diálogo típico para la segunda definición: "Han llamado a la red principal de guardia hace 15 minutos y no se ha unido al puente de conferencias telefónicas sobre incidentes, así que voy a pasar a la red secundaria de guardia para que alguien de la red se una al puente".

En el servicio de bomberos, escalar tiene una definición muy diferente: solicitar más o diferentes recursos a medida que cambian las condiciones de un incidente. He aquí un diálogo típico en el servicio de bomberos del Comandante de Incidentes: "El fuego se ha extendido al segundo piso, envía una segunda alarma y dos ambulancias más".

Recomendamos utilizar la definición del servicio de bomberos de escalar en TI. Como hemos descrito antes, la MTTA es la única parte de la respuesta al incidente que el IRT puede controlar realmente. En la segunda definición de escalar en TI, un interviniente principal de guardia no responde, lo que impide al IRT avanzar en la resolución del incidente y supone una pérdida de tiempo valiosa. Como hemos comentado antes, si un interviniente en incidentes está disponible, se encuentra en una posición de disponibilidad operativa, se unirá a un puente telefónico de incidentes con un sentido de urgencia y llegará capaz de completar las asignaciones del Comandante de Incidentes.

Un cliente nos preguntó: "¿Cómo actúa el cuerpo de bomberos cuando se envía un camión de bomberos al lugar de los hechos y no se presenta? La pregunta nos dejó atónitos, ¡porque esa situación nunca se da en el cuerpo de bomberos! Sin duda, los camiones de bomberos pinchan o se averían y no pueden responder, pero si están disponibles para responder a un incidente, están en una posición de disponibilidad operativa, responderán con un sentido de urgencia y llegarán en condiciones de completar las tareas asignadas por el Comandante de Incidentes. El problema de que el principal de guardia no responda debe discutirse con su responsable fuera del puente de conferencia telefónica del incidente para evitar que vuelva a ocurrir.

Volvamos a nuestro ejemplo: El incidente se expandió rápidamente y el Comandante de Incidentes optó por aumentar el nivel SEV y llamar a los distintos recursos: "Voy a escalar esto a un SEV 1. Activemos al equipo de Recuperación de Desastres (DR)".

Figura 4-3. El organigrama del incidente muestra una mayor expansión en el incidente

Cuando el equipo de DR llegara al puente, el organigrama cambiaría en consecuencia. De nuevo, se incorporarían más intervinientes en el incidente, pero el ámbito de control del Comandante del Incidente se mantendría dentro de un rango aceptable. La figura 4-4 representa una nueva ampliación del marco IMS. No te preocupes por comprender las funciones de los puestos en términos de sus obligaciones específicas para este escenario. Concéntrate más bien en el organigrama y en cómo un incidente en expansión puede dar cabida a un gran número de intervinientes mediante la asignación de grupos. Las funciones como planes, oficial de enlace y escribiente se denominan funciones del personal de mando (asignadas para ayudar directamente al Comandante del Incidente) y no se contabilizan en el ámbito de control. Una vez más, el Comandante del Incidente puede configurar el organigrama para mantener el control sobre el conjunto de recursos y mantener un alcance de control efectivo.

Figura 4-4. Organigrama del IMS para un incidente de escalada. Este nivel de respuesta puede estar indicado para incidentes de caja roja.

Transferencia de mando

Si los incidentes se prolongan, el mando (así como cualquiera de las otras funciones) puede transferirse a otro miembro cualificado del IRT. La transferencia debe ser un proceso ordenado y anunciarse en el puente de conferencia del incidente. Entonces, ¿cuándo se hace esto? La transferencia del mando o de cualquier otra función de trabajo puede ocurrir en cualquier momento durante la respuesta a un incidente, pero lo más habitual es que ocurra cuando:

• Hay una interrupción natural en un periodo de trabajo, como cambios de turno o traspasos globales entre equipos.

• Un Comandante de Incidente está fatigado y lo mejor para el incidente es que ocupe el puesto una persona bien descansada.

• Un Comandante de Incidente puede estar luchando y una persona más cualificada está disponible.

• Por razones empresariales, una persona de mayor rango o rango en tiempos de paz debe dirigir la respuesta al incidente.

Como ya se ha dicho, el Comandante de Incidente saliente debe anunciar al grupo que se va a transferir el mando y presentar al grupo al nuevo Comandante de Incidente entrante. Antes de eso, el Comandante de Incidentes saliente debe proporcionar un informe CAN al Comandante de Incidentes entrante fuera del puente de conferencia telefónica sobre incidentes para ponerle al corriente de las condiciones y actividades actuales en el puente. El motivo por el que esto se hace fuera del puente de conferencia telefónica sobre incidentes es que los dos Comandantes de Incidentes pueden mantener una conversación sincera sobre los esfuerzos de respuesta al incidente. Si hay un problema con una PYME que el Comandante de Incidentes saliente no haya podido resolver, pueden discutir una estrategia para hacer frente a esta situación. El Comandante de Incidentes saliente puede haber querido ir en otra dirección, pero el equipo se resistió. El nuevo Comandante de Incidentes puede entrar y presentar el nuevo plan y hacerlo avanzar. Cuando se necesita una nueva dirección, un cambio de Comandante de Incidentes puede facilitar esta reorientación.

Resumen

En el mundo de la seguridad pública, algunos incidentes son grandes y complejos y requieren la coordinación y gestión de muchas personas, como el incidente del World Trade Center del 11-S. Algunos incidentes son relativamente pequeños y pueden ser gestionados en la mayoría de los casos por un pequeño equipo de respuesta a incidentes, como un pequeño incendio doméstico. Una llamada médica rutinaria requiere una respuesta a incidentes menor y normalmente la gestionaría un equipo más pequeño de personal médico y de bomberos.

En TI, el IRT puede ser llamado para resolver y recuperarse de incidentes grandes y complejos, como un ataque DDoS generalizado y persistente. Los incidentes de gran SEV pueden requerir las habilidades colectivas de resolución de problemas de ingenieros de red, DBA, ejecutivos clave en tiempos de paz, proveedores externos y quizá incluso un equipo de recuperación de desastres, lo que puede dar lugar a docenas de personas entrando y saliendo de un puente de conferencia telefónica sobre incidentes. A la inversa, un puñado de ingenieros puede estar trabajando en un problema con un solo cliente que tenga un problema con una aplicación.

• La mejor forma de adquirir destreza y competencia en la gestión de incidentes es utilizar regularmente el SGI para los problemas de caja verde y amarilla, no sólo en los incidentes grandes y complejos de caja roja y negra.

• Cada Comandante de Incidente debe esforzarse por encontrar la mezcla adecuada de mando, marco y esfuerzo en la resolución de problemas para crear el entorno de resolución de incidentes más eficaz, adaptado al tamaño y alcance del incidente.

• El ámbito de control es el número máximo de personas que una persona puede dirigir. Normalmente, ese número es de 5-7 personas.

• La función de Mando (o cualquier otra función de trabajo en una respuesta) puede transferirse en cualquier momento a cualquier persona por cualquier motivo, siempre que esa persona esté cualificada para desempeñar la función.

• Las funciones del puesto durante la respuesta a un incidente son constantes. Las personas que desempeñan la función pueden variar.