En resumen: una lista de contactos de emergencia de TI indica, para cada rol, una persona con suplente, su localización también fuera del horario laboral, el motivo por el que se le avisa y los datos que hay que tener a mano durante la llamada. Está disponible impresa y en un dispositivo aparte, se prueba con regularidad e incluye también a las autoridades con plazos de notificación. Así no se pierde tiempo buscando en una emergencia.
El número que nadie tiene
Un viernes por la tarde, la tienda muestra redirecciones extrañas y el administrador sospecha algo. ¿Y ahora qué? Llamar al proveedor de alojamiento, pero ¿qué número vale fuera del horario laboral y qué número de cliente hace falta? La agencia, pero ¿quién allí tiene acceso al servidor? El seguro, pero ¿dónde está el número de póliza? ¿Y quién decide si la tienda se desconecta?
Muchas empresas conocen estos momentos, y la semana de PHP2Shell los ha multiplicado. En el mejor de los casos existe el plan de emergencia, pero la lista de contactos que contiene suele ser el eslabón más débil: anticuada, incompleta o guardada solo en formato digital precisamente en el sistema que en ese momento no está disponible. Cómo se estructura el plan en su conjunto lo describe Crear un plan de emergencia TI para servidores web. Aquí se trata de la lista en sí.
¿Quién debe figurar en la lista de contactos de emergencia?
La tabla siguiente ordena los contactos típicos según el motivo por el que se les avisa e indica qué conviene tener a mano en el primer contacto.
| Contacto | Cuándo informar | Qué tener a mano |
|---|---|---|
| Dirección de emergencia (a menudo la dirección general) | ante cualquier sospecha de incidente | breve descripción de la situación, primera valoración |
| Responsables de TI y administradores | de inmediato, para la comprobación técnica | sistemas afectados según el inventario |
| Proveedor de alojamiento (canal de emergencia) | ante sospecha en el servidor, para desconexión o registros | número de cliente, número de contrato, contraseña de soporte |
| Agencia o desarrollador | cuando la aplicación está afectada | nombre del proyecto, accesos, interlocutores |
| Proveedor de servicios de ciberseguridad | ante intrusión confirmada o probable | observaciones hechas hasta ahora, momentos |
| Delegado de protección de datos | en cuanto puedan estar afectados datos personales | tipos de datos, periodo, sistemas |
| Ciberseguro | según las condiciones de la póliza, normalmente pronto | número de póliza, vía de comunicación del siniestro |
| Asesoramiento jurídico | ante obligaciones de notificación, extorsión, cuestiones de responsabilidad | situación de los hechos, pasos dados |
| Autoridad de control de protección de datos | ante una brecha de datos notificable, si es posible en 72 horas | datos conforme al art. 33, apdo. 3, del RGPD |
| Punto de contacto central de cibercrimen (ZAC) | al denunciar un delito | pruebas, cronología |
| BSI | ante obligación de notificación según NIS2 | según las indicaciones del BSI |
| Comunicación | antes de cualquier información al exterior | hechos acordados |
El ZAC (Zentrale Ansprechstelle Cybercrime) competente se encuentra a través de la policía de su estado federado alemán; cómo transcurre la denuncia se explica en Presentar una denuncia: puntos de contacto centrales de cibercrimen. Qué plazos y obligaciones suelen fijar los seguros lo describe Ciberseguro: qué cuenta en caso de siniestro.
Qué debe contener cada entrada
Un nombre y un número de teléfono no bastan. Una entrada completa responde a seis preguntas:
- Rol: ¿de qué se encarga la persona, qué puede decidir?
- Nombre y suplente: ¿quién la sustituye si no se localiza a la primera persona?
- Localización: teléfono, también móvil, y una segunda vía. ¿Vale el número también de noche y en fin de semana?
- Detonante: ¿ante qué suceso se avisa a esta persona?
- Legitimación: número de cliente, número de contrato, contraseña de soporte, para que la llamada no se atasque en la verificación de identidad.
- Estado: ¿cuándo se revisó la entrada por última vez?
Sobre todo el punto 5 suele subestimarse. Los proveedores de alojamiento y los registradores comprueban por teléfono si quien llama está autorizado, y con razón. Quien primero tiene que buscar la contraseña de cliente pierde un tiempo valioso. Guarde estos datos de forma segura, pero de modo que la dirección de emergencia pueda acceder a ellos en caso de necesidad.
Tome los números de teléfono de los proveedores del contrato o del sitio web oficial, nunca de un correo electrónico. Los estafadores aprovechan con gusto las situaciones de seguridad conocidas para enviar mensajes falsos con «números de emergencia».
El orden en caso de emergencia
No todos los contactos se necesitan a la vez. Ha dado buen resultado un procedimiento escalonado: primero la dirección de emergencia y el equipo técnico, para obtener una primera valoración y decidir sobre la contención. Después, el proveedor de alojamiento, la agencia y el proveedor de ciberseguridad para el trabajo técnico. En cuanto puedan estar afectados datos personales, el delegado de protección de datos, pues desde que se conoce una brecha de datos corre el plazo del art. 33 del RGPD. El seguro y el asesoramiento jurídico siguen pronto, antes de que se tomen decisiones importantes. La comunicación al exterior va en último lugar y solo con hechos acordados.
Qué pasos siguen tras la primera alerta lo resume la lista de comprobación tras un hackeo. Esta página ofrece indicaciones generales; las obligaciones de notificación y las cuestiones jurídicas se aclaran con el delegado de protección de datos y un abogado.
Prevea además una segunda vía de comunicación. Si el servidor de correo está afectado o existe la sospecha de que un atacante lee buzones internos, la coordinación debería pasar por un canal separado, por ejemplo por teléfono o a través de un grupo creado de antemano en otro servicio. Defina este canal con antelación e inclúyalo en la lista. Buscar una vía nueva en plena emergencia cuesta tiempo y genera incertidumbre sobre qué mensaje es auténtico.
Mantener viva la lista
Las listas de contactos se quedan obsoletas en silencio. El personal cambia, los proveedores modifican los números de emergencia, los contratos vencen. Planifique por ello dos fechas fijas de revisión al año y una fecha extraordinaria con cada cambio. Una breve llamada de prueba fuera del horario laboral es la forma más fiable de comprobar si un canal de emergencia funciona de verdad. Pregunte también si la persona sabe que figura en la lista y qué se espera de ella en caso de emergencia.
¿Cómo ayuda PHP SOS en concreto?
- Elaboramos con usted la lista de contactos técnicos de emergencia y comprobamos si los proveedores de alojamiento y las agencias tienen realmente un canal de emergencia.
- Determinamos qué datos deben estar a mano para cada contacto, de modo que una llamada surta efecto de inmediato.
- Acompañamos una prueba de la alerta e incorporamos las lagunas a su documentación.
- En caso de emergencia, figuramos en su lista como interlocutor técnico mediante la respuesta a incidentes.
Conclusión: una buena lista de contactos es corta, completa y probada. Decide si las primeras horas de un incidente se dedican a actuar o a buscar.
Preguntas frecuentes
¿Quién debe figurar en una lista de contactos de emergencia de TI?
Internamente, la dirección, TI, el delegado de protección de datos y comunicación; externamente, el proveedor de alojamiento, la agencia, el proveedor de servicios de ciberseguridad, el ciberseguro, el asesoramiento jurídico, la autoridad de control de protección de datos competente y el Punto de contacto central de cibercrimen (ZAC) de su estado federado alemán; si rige la obligación de NIS2, además el BSI (Oficina Federal alemana para la Seguridad de la Información).
¿Dónde guardo los contactos de emergencia?
En al menos dos lugares, uno de ellos accesible sin la propia TI, por ejemplo impreso en la carpeta de emergencia y en un dispositivo aparte. Una lista que solo está en el buzón de correo o en el servidor afectado no está disponible en caso de emergencia.
¿Con qué frecuencia debe revisarse la lista?
Al menos dos veces al año y tras cada cambio de personal o de proveedor. Una breve llamada de prueba muestra si los números son correctos y si las personas saben que figuran en la lista.
¿Hay que informar siempre a la autoridad de control de protección de datos?
No en todos los incidentes. El art. 33 del RGPD exige una notificación en caso de violación de la seguridad de los datos personales, si es posible en un plazo de 72 horas, salvo que sea improbable que suponga un riesgo para los afectados. La valoración la hace usted con el delegado de protección de datos; esta página no constituye asesoramiento jurídico.