Incidentes de seguridad: divulgar o no, ese es el dilema

El 30 de marzo de 2018 recibí un correo del Chief Digital Officer de MyFitnessPal, servicio al que me había suscrito hace algunos años, en el que me notificaban que un mes antes habían sufrido un acceso no autorizado a datos de cuentas de usuarios. La información afectada incluía nombres de usuarios, correos y los hashes de las contraseñas. Asimismo, me hacían saber que habían tomado acciones inmediatas para determinar la naturaleza y alcance del problema, y que estaban trabajando con firmas líderes en el ámbito de la seguridad para que los asistieran en la atención al incidente. Finalmente comentaban que el evento ya había sido notificado a las autoridades, con quienes estaban trabajando de forma coordinada, y me daban una serie de recomendaciones a llevar a cabo.

En noviembre de 2017 Uber reconoció públicamente que un año antes había sido víctima de un hackeo que había involucrado al menos 25 millones de nombres de usuarios y sus correos, 22 millones de números de dispositivos móviles y 600 mil licencias de conductores. Esta situación la ocultó a las autoridades, pues estaba bajo investigación por otro incidente producido en 2014. Uber también dio a conocer que había realizado el pago de la módica cantidad de cien mil dólares a un “investigador” para destruir la información a la que había tenido acceso a través del hackeo, y el pago lo realizó utilizando un mecanismo llamado “bug bounty” (programa de incentivos que algunas empresas ofrecen abiertamente a aquellos que logren descubrir una vulnerabilidad en un sistema o aplicación y lo reporten a la empresa con el fin de mejorar la seguridad).

Yo soy usuario de ambos servicios. En el primer caso me hizo sentir que aun cuando había un problema y cierta información había sido comprometida, estaban tomando con seriedad el asunto y lo estaban abordando de manera frontal y abierta ante los usuarios. En el segundo caso, no supe si mis datos podrían haber estado en los afectados, no tuve noticias de algún comunicado y, desde mi punto de vista, claramente hubo un manejo inadecuado e inoportuno de la situación.

El incremento en la sofisticación y número de ciberataques obliga a las organizaciones a estar preparadas para los peores escenarios. Las estrategias de seguridad han adoptado un enfoque de proteger, detectar y responder, pues se sabe que no es cuestión de si nos atacarán o no, es cuestión de cuándo sucederá y de si estaremos listos para responder adecuadamente.

En este contexto resulta indispensable crear las capacidades organizacionales para el manejo de incidentes de seguridad de la información y para el manejo de cibercrisis. Dentro de estas competencias a desarrollar, un tema central a discutir es la estrategia de comunicación y divulgación, es decir, cuándo sí se deberá notificar la situación, cómo, y cuándo no.

Los tres objetivos principales que se deberán perseguir con la definición de una estrategia de comunicación y divulgación son:

  • Limitar el daño reputacional y recuperar la confianza de las partes interesadas (clientes, accionistas, aliados, empleados y entidades regulatorias).
  • Resolver y manejar el incidente de la mejor forma, ya que una estrategia de divulgación oportuna puede ayudar a mejorar la efectividad y oportunidad de las actividades de respuesta.
  • Cumplir con los requerimientos legales.

 

En general podemos identificar dos fuentes de detección de incidentes: la primera es la interna, que se da a través del monitoreo continuo de seguridad; la segunda es la externa, cuando el incidente se identifica por terceras partes, como por ejemplo un cliente, un aliado o algún organismo encargado de la aplicación de la ley.

Cuando la detección es interna, se puede presentar el dilema de si se debe o no divulgar, excepto cuando exista la obligación o requerimiento legal para sí hacerlo (ahí no debería haber dilema), como puede ser el caso de la Ley Federal de Protección de Datos Personales en Posesión de Particulares o la normativa europea GDPR (General Data Protection Regulation), por mencionar un par de ejemplos.

Cuando el incidente es identificado por una fuente externa, resulta muy difícil “esconderlo”, y entonces, además de atender el incidente en la parte operativa y técnica, se debe ejecutar un plan de comunicación y divulgación.

Ante la decisión o necesidad de notificar un incidente, es vital controlar el flujo de información asociada con él para asegurar que la información correcta es comunicada en el momento correcto por la persona correcta a la audiencia correcta.

No tener establecido, documentado y probado el proceso de comunicación puede provocar que las consecuencias sean aún mayores. Una buena comunicación ayuda a rápidamente involucrar a la gente adecuada, tanto interna como externa, así como a tomar mejores y más rápidas decisiones.

El plan de divulgación deberá considerar, al menos: ¿qué notificar (contenido)?, ¿cómo notificar (medios y métodos)?, ¿cuándo notificar? y ¿a quién notificar (clientes, proveedores, aliados, accionistas, entidades regulatorias, proveedores de servicios de respuesta a incidentes, prensa, público en general)?

La naturaleza del incidente y el impacto potencial definen el tipo de comunicación que se requiere; algunos otros aspectos a tomar en cuenta son la sensibilidad de la información comprometida o afectada; número de usuarios, clientes, áreas y procesos afectados; número de dispositivos y servidores afectados y la causa del incidente (error humano, brecha de seguridad, etc.).

A continuación, muestro una tabla ejemplo de qué y a quién notificar1:

 

Comunicación interna
Audiencia Qué se les debe notificar
Alta dirección Activos que fueron impactados por el incidente

Cuál es el plan de respuesta

Cuáles son los resultados esperados

Cuándo volverá a la normalidad la operación

Áreas de negocio afectadas Cuándo volverá a la normalidad la operación
Empleados Qué deberán hacer los empleados

Cuánto tiempo se estima que durará la situación

Comunicación externa
Audiencia Qué notificar
Prensa Es mejor si se puede evitar, pero si es necesario se deberá dar un comunicado sobre el incidente y su impacto.
Clientes Avisar si el cliente fue potencialmente impactado por el incidente

Avisar si sus datos personales fueron robados.

Proveedores Avisar si el proveedor fue potencialmente impactado por el incidente.

Avisar si podría ser un proveedor el objetivo primario del ciberataque.

Proveedor de servicios para respuesta a incidentes Detalles técnicos para recibir asistencia en la atención del incidente.
Entidades regulatorias Avisar si se trató de una brecha de seguridad.

Qué tipo de datos se vieron involucrados.

Detalles técnicos que sean requeridos.

Policía/otras autoridades Si se quiere levantar una denuncia habrá que dar todos los detalles necesarios.

 

En el siguiente diagrama se presenta una línea de tiempo de notificación propuesta en el artículo Cyber Crisis Management2, en la que se puede observar que, conforme va evolucionando el ciclo de vida del incidente, los aspectos a comunicar tanto de forma interna como externa van variando.

Marcos Polanco - Fig 1

 

Conclusiones

Hoy existen casos en los que se debe notificar si se es víctima de un incidente de seguridad, pero ¿es suficiente?, ¿debería existir una obligación de notificar cualquier incidente de seguridad?, para el caso de México, ¿se discutirá esto en las mesas de trabajo en las que se está conformando la Estrategia Nacional de Ciberseguridad?

Independientemente de las respuestas a las preguntas anteriores, yo considero que las organizaciones deben contar con procesos formales y sólidos de manejo de incidentes y cibercrisis e incluir en ellos una estrategia de comunicación y divulgación que responda claramente qué se deberá notificar, a quién, cuándo y cómo.

 

[email protected]

 

Fuentes:

1 Cyber Security Incident Management Guide, Centre for Cyber Security, Belguim.

2 Cyber Crisis Management: A decision-support framework for disclosing security incident information. Olga Kulikova, Ronald Heil, Jan van den Berg, Wolter Pieters

 

Otras referencias:

The Cyber Risk Handbook, creating and measuring effective cybersecurity capabilities. Domenic Antonucci

Cyber Security Incident Reponse Guide, CREST

Cyber Incident Response, Are business Leader ready?, The Economist Intelligence Unit

Marcos Polanco. ITIL, CISSP, CISA y CISM

Ingeniero en Cibernética y Sistemas Computacionales por la Universidad La Salle, cuenta con un Diplomado en Dirección Estratégica por parte del Instituto Tecnológico Autónomo de México (ITAM) y una especialización en Alta Dirección en Innovación y Tecnología por el Instituto Panamericano de Alta Dirección de Empresas (IPADE). Cuenta con más de 17 años de experiencia en el área de gestión y monitorización de seguridad, redes y sistemas, temas sobre los cuales ha escrito diversos artículos en revistas especializadas. Actualmente es Director de Nuevos Servicios en Scitum, anteriormente se ha desempeñado como director general de Ironwall, empresa Española dedicada a la seguridad de la información y como director de servicios administrados para Scitum. 

Tags:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.