El gran lío de reportar un incidente

Cuando se desea mostrar el impacto de los ciberataques en la actualidad a escala nacional o global, usualmente se recurre a estadísticas sobre todos los eventos informáticos ocurridos durante un periodo de tiempo, y hay razones de sobra para alarmarse: las cifras de registros no han cesado de aumentar, cada vez más entidades importantes han sido comprometidas y los perjuicios, tanto económicos como personales, alcanzan niveles abismales.

Sin embargo, hay un detalle igualmente preocupante en el que pocos se han detenido a pensar: estos datos corresponden a los incidentes informáticos que sí se reportaron, y en la realidad, una importante fracción de los incidentes (aprox. un 30% [1]) no se llegan a reportar, incluso entre países tecnológicamente desarrollados y a pesar de que constituye una fase conocida y necesaria en el proceso de manejo de incidentes.

En el presente artículo, con ayuda de una analogía basada en la labor de revisión de un fontanero sobre una tubería, se estudian los dos principales motivos detrás de este fenómeno: la falta de voluntad de los usuarios y la carencia de métodos adecuados, así como sus implicaciones para las organizaciones.

¿Evento o incidente? Lo ideal es reportar ambos

Antes de empezar, es preciso definir y diferenciar los términos “evento” e “incidente”: un evento es cualquier suceso que sitúa al sistema en un contexto de riesgo, donde puede hacerse tangible algún daño, o bien, no presentarse aún ningún peligro y pasar desapercibido en el momento; cuando se da el primer caso y se compromete negativamente el funcionamiento del sistema, se habla entonces de un incidente [2] (aunque, de forma errónea, es común usar para ambos casos el término “brecha de datos”, que realmente corresponde a un tipo más específico de incidente).

Para entenderlo más fácilmente, un evento en nuestra analogía podría describirse como la aparición de una grieta o una zona corroída en una tubería, que puede hacer ruidos e incluso gotear, mientras que un incidente sería una fuga de agua o gas provocada por este desperfecto que deja sin servicio a la planta de un edificio.

En ese orden de ideas, el reporte podría verse como un fontanero utilizando el boroscopio para inspeccionar y confirmar el daño en la tubería. Un evento abarca, por tanto, desde acontecimientos notorios (como el cese de operaciones de todo un datacenter) hasta acciones simples y cotidianas (como anotar una contraseña en un post-it visible), siempre que tenga el potencial de desencadenar una situación con efectos adversos en términos de seguridad para algún individuo o entidad, esto es, de convertirse en un incidente.

Indiferencia y temor, dos caras de una voluntad inexistente

Es crucial reportar un evento cuando se presenta para atenderlo y registrarlo, aún si no se convierte enseguida en un incidente. Es aquí donde encontramos un primer caso: los eventos que corresponden a sucesos triviales en apariencia o que el usuario no asocie como riesgosos se suelen omitir, pues se asume que su daño potencial es ínfimo y reportarlos no se considera un esfuerzo justificable [4]; algo así como asumir que el desperfecto en la tubería es nada más parte del diseño.

Ahora bien, existe asimismo un segundo caso, en el que un subalterno ejecutó alguna acción (abrió el enlace de un correo de phishing o ingresó credenciales a una página clonada) que, por supuesto, ocasiona un incidente: este usuario vacilará sobre si debería reportarlo, pues teme enfrentar algún tipo de sanción (multa, suspensión, revocación de permisos) o incluso el despido por su error [3]. La posición es semejante para el fontanero de nuestro ejemplo si temiera que alguien, al verlo utilizar el boroscopio, lo acusara de contaminar el interior de la tubería.

No obstante, este caso se manifiesta también en los altos directivos que representan a una empresa: aquí, la negativa a reportar los eventos o incidentes surge de la posibilidad de perder la confianza de sus clientes, además de diversas implicaciones legales, pues ante los ojos de todos, ellos son los responsables [3, 4].

En ambos escenarios, se puede evidenciar una importante ausencia de transparencia dentro de la cultura de una organización en la que sus integrantes, aún cuando en la teoría afirman que harían el deber de reportar, o no se encuentran lo suficientemente motivados o involucrados para reportar los incidentes, o consideran que al hacerlo podrían salir perjudicados.

Autosabotaje por falta de herramientas o procesos claros

Nótese que, pese a sus esfuerzos, un fontanero no podrá inspeccionar eficazmente la tubería con un boroscopio defectuoso; análogamente, están los usuarios que sí están dispuestos a reportar un incidente, pero no se les proveen las herramientas para hacerlo o las que poseen son muy confusas y engorrosas (por ejemplo, llenar un sinnúmero de formularios), por lo que muchas veces de plano desisten de hacer el reporte o cometen algún error en el proceso que lo invalida [3, 4].

Es más grave cuando no se establecen roles definidos y, por ende, no se entiende a quién le corresponde qué acciones tomar: sin una figura específica a cargo de recibir los incidentes reportados, los usuarios recurren a su figura de autoridad más accesible, que a su vez improvisa para registrar y controlar el incidente o solicita ayuda a los roles que más probablemente podrían intentar manejar la situación. Piénselo: si no sabe lo que hace realmente un fontanero, podrá acabar pidiéndole el favor de examinar la tubería a un soldador [3].

De modo similar a la primera causal, también puede ocurrir el caso en que, al no haber precisamente unas funciones claramente establecidas, algunos miembros de menor rango en una organización suponen erradamente que les corresponde a los altos directivos (CEO, CTO, CISO) y a las áreas de Auditoría y Seguridad, pero no a ellos, reportar los eventos que se presenten, por lo que, una vez más, dejan pasar eventos deliberadamente sin actuar al respecto [4].

Todo lo anterior crea una primera falsa sensación de que está respondiendo para salvaguardar la seguridad de las entidades, pero eventualmente ocasiona un caos en la cadena de acciones que sus integrantes están tratando de realizar y, en el largo plazo, se pierde la confianza en el proceso de reporte y se abandona, dejando al final a los individuos todavía más vulnerables.

Pero, ¿no reportar un incidente es así de grave?

Dados los argumentos expuestos anteriormente, el acto de reportar un incidente pareciera traer consigo una serie de inconvenientes, pero debe tener por seguro que, primero, muchas de esas complicaciones son solo percibidas y totalmente resolubles, y segundo y más importante, no reportar siempre acaba siendo mucho peor, así como el daño a toda una planta del edificio que necesitará 1 semana para arreglarse es peor que una revisión de 1 hora en un cuarto para evitar dicho daño.

Por una parte, cuando se trata de eventos con efecto limitado, éstos la mayoría de las veces anteceden a eventos con mayor alcance y potencial de daño, de modo que actúan como señales de advertencia que dan cuenta del tipo de incidente que se avecina.

No reportarlos significa perder la oportunidad de comprender el riesgo que el sistema enfrentará próximamente y prepararlo para entonces [5]. De otro lado, si se habla de incidentes que ya causaron importantes estragos, no reportarlos efectivamente condena a la organización a permanecer vulnerable y terminar nuevamente damnificada, en igual o peor grado, por la misma clase de incidente cada vez que se presenten, pues se la priva de recuperar las lecciones aprendidas durante la identificación y resolución de aquellos eventos [5].

Conclusiones

Para empezar, todo evento e incidente, por mínimo que parezca, merece ser reportado, pues aunque la sola acción de reportar no va a solucionar el problema, siempre ayuda a descubrir un nuevo aspecto del sistema que estamos obviando o malinterpretando, como una vulnerabilidad reciente u otro tipo de amenaza.

Aunado a lo anterior, se debe lograr que cada usuario vea el reporte como una fuente de soluciones y no de problemas, y si tiene alguna responsabilidad en el incidente, conciliar la forma en que corregirá su error: luego, se requiere revisar la cultura que los usuarios ponen en práctica y determinar hacia dónde se orientará.

Además, hay que recordar esto siempre: todos los usuarios están en la capacidad y obligación de alertar, informar y reportar cuando algo no se encuentra bien o se hace de forma incorrecta; esta es una labor que los individuos y departamentos especialmente enfocados, por más grandes y activos que sean, no pueden ni tienen que desempeñar solos, pero en la que ejercen un rol decisivo.

Resulta entonces imperativo construir una serie de mecanismos y lineamientos que permitan a todos reconocer qué posición asumir y de qué forma contribuir en el proceso de reportar. Al final, lo único que se consigue al esperar a que alguien más reporte un evento es darle tiempo para que se pierda su rastro y/o, a futuro, provoque daños irreversibles.

Si deseas tener siempre a la mano el artículo escrito por nuestro ingeniero Zharet Bautista, te invitamos a descargarlo, compartirlo y comentarnos qué opinas al respecto.

Cyte_El_Gran_Lío_de_Reportar_un_Incidente.pdf

Descargar PDF • 1.47MB

Referencias

[1]https://www.ituser.es/seguridad/2023/04/mas-de-un-22-de-los-profesionales-de-ci berseguridad-espanoles-no-ha-reportado-brechas-de-datos

[2]https://www.escuelaeuropeaexcelencia.com/2020/04/definiciones-de-evento-incid encia-o-no-conformidad-en-iso-27001/

[3]https://securityintelligence.com/articles/why-security-incidents-often-go-underrepor ted/

[4]https://www.lepide.com/blog/the-importance-of-security-incident-reporting/

[5]https://www.upguard.com/blog/cyber-incident-reporting