Security Art Work

Como cualquier analista sabe, la misma naturaleza del Threat Hunting conlleva la aplicación de aproximaciones lo más genéricas posible en cuanto a la detección de anomalías. Al contrario que las posiciones reactivas de la seguridad basada en reglas, el análisis proactivo delega en el analista un porcentaje importante de la detección. Esto conlleva que, del mismo modo que le ocurre a un analista de inteligencia convencional, se suela caer en errores de interpretación, debido al gran número de casuísticas que se encuentran en el día a día, y que el cerebro tiende a clasificar como legítimas o maliciosas en cuestión de centésimas de segundos.

Según Richard Heuer define en “Psicology of Intelligence Analysis”, un analista tiene límites en la interpretación de la información, determinados por su personalidad, sus creencias y sus sesgos cognitivos. Y es que, tras la identificación de la anomalía, el analista debe ser capaz de hacer una predicción. Es decir, es la interpretación de una detección y su asociación a una posible amenaza lo que concluye con una alerta de seguridad.

Ver primera y segunda parte.

¡Buenas cazadores! ¿Qué tal va la temporada de caza?

Tras lo visto en anteriores posts, en este artículo vamos a continuar entendiendo y mejorando nuestro laboratorio de Threat Hunting.

Ya hemos aprendido a introducir nuestros datos sobre ataques reales y ahora aprenderemos a explotar esos datos. Poder visualizar los datos de una manera cómoda es, junto con la selección de buenas fuentes de datos, la parte más importante de un laboratorio. Todo el tiempo que invirtamos en una visualización intuitiva y agradable será tiempo ahorrado durante el análisis.

Ahora vamos de vuelta al laboratorio, esta vez vamos a aprender a manejar algunas de las funcionalidades de HELK que aún no hemos visto.

El Laboratorio – Visualización de datos

Continuando esta serie de posts relacionados con el cloud, hoy toca hablar sobre cómo enfrentarse ante el mundo de posibilidades que la nube ofrece. Este artículo busca arrojar un poco de luz ante tan enorme empresa y mostrar diferentes aspectos a tener en cuenta. Es un camino interesante, con múltiples opciones y que puede llegar a aportar un valor enorme, tanto al negocio como a nuestra calidad de vida, siempre y cuando se plantee desde un punto de vista objetivo, realista y crítico. No hay que ser reticentes al cambio, pero tampoco afrontar el cambio por el cambio en sí.

Dejando mantras filosóficos aparte, afirmar que el cloud es la panacea tiene el mismo poco sentido que decir que el cloud no nos aporta valor.

Como siempre, y perdón por la insistencia, dependerá de cada organización y sus necesidades. Lo que es fundamental, dentro del análisis del caso de negocio y en el cálculo del retorno de inversión de la implementación de estos nuevos paradigmas tecnológicos, es que se tengan en cuenta las consecuencias, necesidades y capacidades de la seguridad. Tanto en procesos de migración a la nube, como ante cualquier cambio tecnológico.

Dicho esto, y yendo al grano, no hay ninguna duda de que migrar al cloud tiene un coste significativo. Que este coste sea mayor o menor dependerá de con lo que se compare, pero se puede afirmar que no es una decisión “barata”. Si se hace el ejercicio simple de comparar un servidor físico con un servidor en la nube, obviamente no hay color. Ahora bien, si se pone todo en contexto, y sobre todo, haciendo hincapié en la seguridad, hay muchos costes a valorar.

Los datos

Ahora que, como vimos en la anterior entrada de esta serie, ya disponemos de una plataforma para almacenar los datos, hay que conseguir datos.

Una forma sería instalar máquinas virtuales de Windows con Winlogbeat y Sysmon, pero eso lo haremos más adelante. Ahora quiero hablar de Mordor.

Mordor

Este proyecto, mantenido también por Roberto Rodríguez y José Luis Rodríguez, es un repositorio de eventos pregrabados mientras se ejecutaban técnicas ofensivas en máquinas de laboratorio.

Como es de esperar, Mordor se integra perfectamente con HELK y nos permite disponer de datos muy interesantes para empezar a cazar a nuestras amenazas. Vamos allá.

La entrada de hoy es una colaboración enviada por el equipo del CSIRT-CV, el Centro de Seguridad TIC de la Comunitat Valenciana, en relación a la detección de una vulnerabilidad en el CMS Tiki-Wiki durante el pasado diciembre.

Hace ya unos meses, concretamente en diciembre de 2019, en el CSIRT-CV descubrimos una vulnerabilidad en el CMS Tiki-Wiki, un sistema de gestión de contenidos del estilo de WordPress, Joomla o Drupal.

Esta vulnerabilidad se publicó meses más tarde, en abril de 2020, con el código CVE-2020-8966, como se puede comprobar en nuestra página de alertas, dando el suficiente margen de tiempo a los desarrolladores para corregir el problema detectado en la aplicación. Todo esto se canalizó a través de INCIBE-CERT, que intermedió con la empresa desarrolladora. Una vez corregida, publicada y tras los problemas derivados de la Covid-19 hemos sacado un rato para contaros los detalles de la misma.

Durante un test de intrusión realizado a una página web interna que usaba este CMS, se detectaron varios fallos de seguridad Cross-Site Scripting (XSS) Reflected sobre la versión 18.3, pero cuya explotación seguía siendo efectiva en la última versión disponible, la v.20.0 por aquel entonces.

Muchas veces, hablando con amigos que se dedican a otras profesiones, les comento la gran suerte que tenemos los que nos dedicamos a la informática. Nosotros, a diferencia del 99% de las profesiones, podemos crear entornos realistas para hacer pruebas, aprender, practicar… y cuando terminamos con esos entornos podemos destruirlos y el gasto de material habrá sido cero. ¡Cuánta suerte tenemos!

A los que nos apasiona la seguridad informática aún tenemos más suerte; desde sus inicios la comunidad de la ciberseguridad se ha caracterizado por su defensa de la libertad de la información, el software libre y el aprendizaje colectivo, lo que ha hecho que estemos en el mejor momento de la historia para aprender sobre ciberseguridad.

En este caso, quiero hacer una guía para poder construir un laboratorio de Threat Hunting desde casa y a coste cero (sin contar en la inversión de nuestro equipo).

Antes de ponernos manos a la obra, vamos a hacer una breve introducción sobre el Threat Hunting, es importante asentar bien los cimientos de nuestro laboratorio.

En las últimas semanas (y meses) las aplicaciones móviles de apoyo a la lucha contra el virus se han erigido en uno de los múltiples prismas desde los que analizar la pandemia ocasionada por COVID-19; como otros tantos, en medio de este escenario repleto de riesgos e incertidumbre, esta perspectiva ha emergido acompañada de una importante dosis de polémica y controversia.

Por un lado, están las aplicaciones focalizadas en las funcionalidades de geolocalización de los ciudadanos; por otra parte, las aplicaciones de autodiagnóstico; y como punto en común a todas ellas, las potenciales limitaciones al derecho fundamental de protección de datos personales. En el ámbito europeo, diferentes interesados han saltado a la arena de una u otra forma: desde la propia Unión Europea, emitiendo sus recomendaciones; pasando por los proveedores de las propias aplicaciones, con Apple y Google como actores más renombrados; hasta las autoridades nacionales, las regionales u otros estamentos públicos reguladores, como es el caso de la Agencia Española de Protección de Datos.