El viejo adagio "Si no planificas, estás planeando fracasar" es cierto en muchos ámbitos; la seguridad de la información y la respuesta a la violación de datos no son excepciones. La información es un activo valioso de toda empresa, y cuando se vulnera la seguridad de esa información, las organizaciones se enfrentan a un campo minado de posibles responsabilidades y daños a la reputación.
Después de ayudar a nuestros asegurados a responder a más de 30.000 incidentes de seguridad de datos, el equipo de Servicios Cibernéticos de Beazley sabe que las organizaciones con un plan de respuesta a incidentes bien diseñado suelen sortear este campo minado mucho mejor que las organizaciones sin un plan en marcha. Una respuesta desordenada suele empeorar mucho las consecuencias de una violación de datos.
Un plan de respuesta a incidentes (IRP) es una hoja de ruta escrita mediante la cual las organizaciones captan, evalúan y responden a una violación presunta o real de los sistemas informáticos o al robo, pérdida o revelación no autorizada de información personal. Un IRP es distinto de un plan de continuidad de negocio o de recuperación ante desastres. A diferencia de esos documentos, el objetivo principal de un IRP es gestionar los incidentes de privacidad o seguridad de forma que se limiten los daños, aumente la confianza de las partes interesadas externas, se cumplan las obligaciones legales y se reduzcan los costes.
Los IRP más eficaces también se redactan para que se activen ante sospechas de filtraciones de datos en toda la organización y sus sistemas, independientemente del departamento o la ubicación de los datos; los datos de recursos humanos, los datos del plan de salud de los empleados y los datos mantenidos por los proveedores deben estar todos cubiertos por el IRP. El IRP también debe cubrir los datos de la organización en dispositivos móviles y personales, los datos en cualquier dispositivo médico y los datos almacenados en fotocopiadoras, faxes o escáneres.
Creemos que la razón principal para desarrollar un IRP es el enorme valor que proporciona cuando se responde a un incidente real de seguridad de la información; pero tener un IRP no es sólo una buena gestión del riesgo, sino que también lo exigen varias leyes, reglamentos y normas del sector. Tanto si tu organización acepta tarjetas de pago¹, como si es una entidad cubierta por la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA)², una empresa de servicios financieros regulada³, o simplemente opera en determinados estados⁴, algún tipo de IRP es una necesidad.
Normalmente, las organizaciones comienzan el proceso de redacción del IRP designando primero un equipo de respuesta a incidentes (IRT), es decir, las personas que realmente realizarán las tareas sustantivas que tienen entre manos. Reconociendo que no hay dos organizaciones iguales, recomendamos designar un representante principal y otro secundario de al menos cada una de las siguientes partes interesadas:
Ciertamente, se puede recurrir a otras personas ajenas al núcleo del IRT cuando sea necesario; sin embargo, los departamentos antes mencionados suelen ser los más implicados en los escenarios de respuesta a incidentes. Un buen plan de respuesta a incidentes no sólo identifica a las partes interesadas clave, sino que también establece procesos sobre cuándo un departamento se relaciona con otro. El IRP debe esbozar las funciones y responsabilidades respectivas del IRT, proporcionar información de contacto para ellos a través de varios canales (correo electrónico, marcación directa, móvil y fuera de banda en caso de que las comunicaciones corporativas no funcionen), y hablar de cuándo los miembros permanentes del IRT recurren a otros miembros internos y externos para que les ayuden.
El departamento de TI descubre una bandera roja y decide investigar internamente antes de notificárselo a nadie. La investigación dura 32 días y desvela que se ha puesto en peligro información personal confidencial. A continuación, el departamento de TI notifica la situación al departamento jurídico, sólo para enterarse de que el plazo establecido por la ley estatal para notificar a las personas afectadas era de 30 días desde el momento del descubrimiento. El plazo se ha sobrepasado, y los organismos reguladores se preguntarán por qué.
La siguiente área clave en la que hay que centrarse es la clasificación de los incidentes. Cuando se trata de incidentes de seguridad de la información, no hay dos totalmente iguales, y cada uno requerirá mecanismos de respuesta y participación de los miembros del IRT diferentes. Un buen IRP prevé esto y clasifica los tipos de incidentes basándose en un conjunto de criterios fáciles de utilizar. He aquí, por ejemplo, tres sencillos niveles de amenaza:
Los niveles de amenaza no pretenden ser excesivamente rígidos. Es imposible abarcar todos los tipos de incidentes potenciales, y dedicar demasiado tiempo a determinar en qué nivel se encuentra un incidente concreto sólo hace perder un tiempo muy necesario. Además, la respuesta a los incidentes es fluida: un incidente puede empezar en el nivel 1 y, tras cierto análisis, ascender al nivel 2. La principal ventaja de los niveles de amenaza definidos es la orientación que proporcionan para los siguientes pasos en cada fase de la respuesta.
Por ejemplo, un buen IRP que utilice los criterios anteriores indicaría que, al descubrirse un incidente de nivel 2, los primeros en responder convocarían inmediatamente al IRT, notificarían a su aseguradora y empezarían a preparar la red y los sistemas afectados para un análisis forense.
Preservar las pruebas para el análisis forense puede ser crucial en la respuesta a incidentes, y un buen IRP reconoce que, en determinadas situaciones, el deseo de restablecer las operaciones debe pasar a un segundo plano frente a la preservación del entorno para el análisis forense.
TI/SI identifica un servidor que ha sido infectado con malware. El malware parece capaz de exfiltrar datos, y el equipo trabaja rápidamente para erradicar el malware y reconstruir el servidor afectado a partir de una copia de seguridad reciente. Pocos días después, se contrata a una empresa forense externa para que ayude a determinar lo ocurrido. Por desgracia, el equipo informático no tomó una imagen forense del servidor antes de reconstruirlo. Además, ya no se dispone de registros importantes que habrían aportado más visibilidad sobre el ataque, ya que la empresa sólo los conserva durante 48 horas. Las pruebas que podrían haber demostrado que sólo se había visto afectado un pequeño número de registros o que no se había filtrado ningún dato han desaparecido para siempre.
Sin embargo, un IRP bien pensado no se detiene sólo en el componente técnico de la investigación⁵. Sigue proporcionando una hoja de ruta sobre cómo avanzar una vez que la investigación técnica ha confirmado el robo, la pérdida o el acceso no autorizado a información personal identificable. Para ello, un IRP bien diseñado habla de la metodología real que hay detrás de la respuesta a una "violación de datos" confirmada, tal como se define ese término en las leyes que se aplican a la organización y al tipo de datos.
El IRP no pretende sustituir al análisis jurídico real ni a las directrices de relaciones públicas, pero debe esbozar lo que la organización necesita llevar a cabo una vez que parezca que una violación de datos puede requerir la notificación a las personas afectadas, a los reguladores o a los medios de comunicación. Sin unas directrices fijas en el IRP, las organizaciones tienen dificultades para saber qué decir, cómo decirlo y cuándo decirlo. Muy a menudo, incluso las intenciones bienintencionadas no filtradas a través del IRP resultan en daños innecesarios para la organización.
Tu empresa descubre un malware en los dispositivos de punto de venta de una de tus tiendas. Antes de que el IRT tenga la oportunidad de terminar de analizar las capacidades del malware o de revisar las leyes de notificación de violación de datos operativas, tu director general decide que la empresa debe emitir un comunicado de prensa al día siguiente, declarando que las tarjetas de 200.000 clientes pueden haberse visto afectadas.
El comunicado de prensa enlaza con el sitio web de la empresa, con un mensaje de vídeo del director general en el que se disculpa por la "violación". Tras contactar con tu compañía de seguros y contactar con un experto forense externo, determinas que el malware de tu entorno de punto de venta no robó realmente ningún dato de tarjeta, y que este asunto no fue un suceso, y no requería notificación pública. Mientras tanto, la cotización se ha resentido y muchos clientes tardarán meses en volver⁶.
Si te encuentras en las primeras fases del montaje de un IRP para tu organización, no hay necesidad de reinventar la rueda. Pero tanto si acabas de empezar como si ya tienes un plan desarrollado, te recomendamos que te mantengas alejado de las siguientes cuestiones que vemos que plantean problemas a las organizaciones una y otra vez.
La palabra "B
El IRP es un plan de respuesta a "incidentes", no un plan de "violación de datos". "Violación de datos" es un término legal con un significado específico. Un buen IRP evita por completo el uso de ese término. Los miembros del IRT no deben referirse a un incidente como "violación" por escrito ni durante la investigación. Dejar un rastro de referencias a la "violación" en el correo electrónico o en papel podría ser especialmente problemático si la investigación concluye que no es necesaria la notificación porque no hay violación según la legislación pertinente. No proporciones munición a los reguladores ni a los abogados de los demandantes.
"Debe" o "deberá
El IRP debe evitar un lenguaje que sugiera que los pasos del proceso son obligatorios. Cada incidente es diferente, y puede que necesites seguir pasos distintos según la situación. Permite flexibilidad y no te pongas en una situación en la que un regulador o un abogado puedan cuestionar por qué no se siguió un determinado paso.
Demasiado largo
El PIR debe ser fácil de utilizar en una crisis. Si es demasiado largo o detallado, es menos probable que los miembros del IRT se familiaricen con él.
Demasiado corto
Por otra parte, el PIR debe contener suficiente información para ser útil, de modo que todos los miembros del equipo comprendan su papel y quede claro cómo recurrir a recursos externos a la organización cuando sea necesario.
"Es sólo papel"
Aunque las organizaciones suelen centrarse en los incidentes electrónicos, los registros en papel están protegidos por una serie de leyes estatales, así como por leyes federales como la HIPAA para la información sanitaria y la Ley de Privacidad y Derechos Educativos de la Familia (FERPA) para los registros de estudiantes. El IRP debe cubrir los datos independientemente del formato en que estén almacenados, para que puedas reaccionar con la misma rapidez.
"A pescar"
Está garantizado que los incidentes se descubren en el momento menos conveniente: un viernes por la tarde o un fin de semana, o cuando una persona esencial está de viaje. Asegúrate de incluir las formas de contactar con los miembros del equipo las 24 horas del día y de tener copias de seguridad para los miembros en caso de que no estén disponibles.
La realidad de la seguridad de la información hoy en día es que la idea de un perímetro de red "inexpugnable", capaz de mantener a raya a los intrusos, hace tiempo que pasó a la historia. Tanto si se debe a un hacker decidido y hábil como a un simple error humano, una violación de datos ya no es un "si", sino un "cuándo" Asumir lo contrario, y no prepararse para el campo de minas, perjudicará enormemente a la marca, el balance y el negocio de tu organización. Pero con un IRP bien pensado que siga los principios descritos anteriormente, un plan que pruebes y actualices regularmente, tu organización estará mejor equipada para convertir una crisis potencial en un bache manejable en el camino.
¹ Estándar de seguridad de datos de la industria de tarjetas de pago (PCI), Requisitos y procedimientos de evaluación de la seguridad § 12.10.1 (ver. 4.0.1 junio 2024), https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf
² 45 C.F.R. § 164.308(a)(6), tratado en U.S Dep't of Health & Hum. Svcs., HIPAA Security Series no. 2, Normas de seguridad: Administrative Safeguards, http://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/ securityrule/adminsafeguards.pdf
orientación interinstitucional sobre programas de respuesta al acceso no autorizado a la información del cliente y aviso al cliente I.A.2(c), 70 Fed. Reg. 15.736 (29 de marzo de 2005), https://www.gpo.gov/fdsys/pkg/FR-2005-03-29/pdf/05-5980.pdf
⁴ Véanse, por ejemplo, las Normas de Protección de Datos Personales de Residentes de la Commonwealth, 201 Code Mass. Regs.§ 17
⁵ De hecho, para la información conservada en determinados formatos (por ejemplo, en papel) o que implique divulgaciones simples e inadvertidas, los miembros técnicos del IRT pueden ser totalmente innecesarios
⁶ Según KPMG, el 19% de los compradores minoristas no volverían tras un hackeo que comprometiera información personal, y casi el 50% del resto tardaría entre tres y seis meses en volver. KPMG, Barómetro de pérdidas de consumidores (julio de 2016), disponible en https://info.kpmg.us/consumer-loss-barometer.html