Para cualquier empresa, que sus sistemas de prevención no detecten una amenaza puede suponer un drama. Que se cuele un ransomware, o un malware cualquiera, que se sustraigan unas credenciales críticas de acceso a través de phishing … tiene como consecuencia una importante pérdida económica en todos los sentidos, y además puede conllevar una pérdida de prestigio y reputación, difíciles de recuperar. En algunas ocasiones incluso, un ataque puede conllevar al desastre total, el cierre del negocio ante la imposibilidad de recuperarse del golpe.
Si las cosas se llevan bien, este impacto y pérdida económica tratarán de estar contemplados en un plan de contingencia, donde se calcula el tiempo que puedes sobrevivir sin los sistemas informáticos activos, se prevé el tiempo de recuperación de estos servicios a través de copias de seguridad, y en general se establecerán las posibilidades de recuperarse de un determinado ataque, a través de las capacidades y SLAs gestionadas. Ojo, todo lo anterior ayuda llegada la emergencia, pero el mal trago ante un incidente hay que pasarlo igualmente, además de que a pesar de los tests periódicos de disponibilidad, backups, etc, siempre surgen desagradables sorpresas en vivo, que acompañadas con las prisas y presiones soportadas por el equipo encargado del marrón, formulan más que un mal trago.
Con todo el rollo anterior, trato de exponer que si se tienen 2 dedos de frente, una persona es consciente de que es blanco de ataques, que protegerse de éstos es complicado, (ni las empresas más grandes y con más recursos se salvan), y que si uno de estos ataques tiene éxito habrá un daño importante en el negocio.
Concienciados de lo anterior, cuestión que hace 20 años era algo despreciable, y ahora es fundamental para la superviviencia en el entorno tecnológico en el que nos movemos, es importante tratar de ir más allá, y abordar todas las variables de la ecuación. En este sentido, una de esas cosas que a veces quedan en el limbo, es la correspondiente al título de la entrada: “el coste del falso positivo”.
Un falso positivo, básicamente es catalogar como malicioso un elemento que no lo es por error. Ojo, que normalmente esta categorización tiene un motivo, un correo electrónico con deficiencias en el servicio emisor, una URL lícita que en su momento estuvo categorizada como malware, un servidor incluido en una lista negra, etc.
Pero el problema aquí ya no es que haya razones para categorizar algo como no adecuado, el problema es que una vez catalogado como tal, se ha denegado el acceso a algo legítimo, y esto puede conllevar consecuencias de todo tipo, también económicas.
Los ejemplos pueden ser variopintos, imaginemos un correo de la Administración pública, el típico de notificación, en plan tienes 15 días para acceder a tu carpeta virtual y responder tal cosa, o en su defecto incurrirás en una sanción, o tendrás tal penalización. Si este correo es catalogado como SPAM, o si el sistema directamente lo corta, las consecuencias de ese inocente falso positivo, pueden ser graves.
El anterior ejemplo, pone de relieve la línea tan delgada existente entre seguridad y funcionalidad, es decir, te ves en la tesitura de configurar el sistema antivirus/antispam de la manera más óptima, para que corte lo máximo posible, pero no tanto como para incurrir en demasiados falsos positivos, y ésto en ocasiones es una tarea muy complicada, y que requiere más de experiencia y tablas con este tipo de servicios, que otra cosa.
Pero los ejemplos pueden ir mucho más allá de un simple correo. Recientemente traté otro caso relacionado a lo que hablamos, servicios de Google que no funcionaban correctamente, y la imposibilidad de utilizar bots de Telegram desde una organización. Tras evaluar el caso, me percaté de que el problema estaba relacionado a unas IPs de estos 2 servicios bloqueadas conscientemente en el firewall, que en realidad eran falsos positivos.
Y me explico, el caso está relacionado al típico SIEM (Gestión de Eventos e Información de la Seguridad), básicamente el sistema detecta una actividad anómala de unas IPs, y las categoriza como peligrosas. El técnico de turno recibe el aviso, y comprueba en un sitio de referencia como AbuseIDP (del que hablamos en: https://ciberseguridadtotal.com/protegiendo-servidores-fail2ban-abuseipdb/) que efectivamente las IPs están marcadas como peligrosas, y por tanto, decide bloquearlas.
Esto es prueba de una de las afirmaciones con las que comenzamos el artículo, normalmente un falso positivo se produce porque hay mimbres para categorizarlo como tal, pero claro… una equivocación puede conllevar un problema mayor. Para este caso concreto, hubiera bastado comprobar que la categorización en AbuseIDP era pobre, así como haber comprobado el origen de la IP en algún sitio de referencia como https://ipinfo.io/.
En todo caso, lo anterior da pie a hablar del falso positivo, y su importancia en la actividad normal de la empresa. Una importancia no obstante muy inferior a la de recibir un ataque, y que da lugar a uno de los dilemas críticos de toda empresa, la mencionada línea entre seguridad y funcionalidad.
Por último señalar otro de los problemas asociados a muchos de los sistemas de detección de amenazas, y es el tiempo dedicado a evaluar y categorizar las alertas recibidas, distinguiendo entre amenazas reales y falsos positivos, que supone una importante dedicación del personal orientado a ciberseguridad. Cada día se gestionan miles de eventos por cada servicio gestionado, y aunque los sistemas cada día mejoran más, a día de hoy sigue siendo necesario sobre todo en determinadas áreas, que una persona esté detrás de todo eso.
