Ya había productos de ciberseguridad que decían utilizar la IA para protegernos antes de la explosión de la IA generativa: algunos CISOs apoyaban estas aproximaciones y otros las miraban con escepticismo. Sin embargo, ahora ya parece fuera de toda duda que la IA debe incluirse en el arsenal defensivo de cualquier empresa. En A CISO’s Guide to Vetting AI Security Vendors dan algunas recomendaciones sobre la elección de proveedores, basándose en tres pilares.

• ¿Resuelven algún problema importante?

Pillar 1: The Problem — Are You Solving Anything That Matters?

Se basa en un par de preguntas interesantes: ¿qué problema está resolviendo esta IA?

“What specific pain is your AI solving?”

Y la respuesta debería ser concreta, fácil de entender…

A vendor who can give you a concrete, understandable example of their product’s value actually understands the problem.

¿Realmente es necesaria la IA para eso?

“Why is AI necessary here? How is it superior to simpler methods?”

Esta es una pregunta que deberíamos estar haciéndonos en todos los ámbitos, claro: leí en algún sitio (y trato de seguirlo) que no deberíamos utilizar IA si lo podemos resolver con un programa ‘normal’. O, como dice en el texto, a veces un centenar de expresiones regulares puede producir mejores resultados que un modelo malo al que llaman IA.

Many times, a hundred regular expressions can produce better results than a poorly implemented model, but the vendor just calls it “AI.”

• ¿Realmente funciona?

Pillar 2: The Proof — Does It Actually Work?

En este caso, la primera pregunta sería ¿Cuáles son los datos de entrada de tu modelo? ¿Qué algoritmo utilizas?

“What are the inputs to your model? What algorithms are you using?”

Se trata de conocer cómo funciona el producto.

También sobre la calidad, ¿qué tasas de falsos positivos y falsos negativos tiene el modelo?

“What are your model’s false positive and false negative rates?”

Se trata de hablar de precisión y sensibilidad (recall): si no pueden darnos esa información es porque probablemente no la conocen, no les interesa, o no es muy buena.

Any serious AI vendor tracks precision and recall. If they can’t give you hard numbers, that’s a red flag. Ask for them in the context of a real customer deployment, not a lab test.

¿Cómo maneja el modelo las amenazas que nunca antes se han visto?

“How does your system handle a threat it has never seen before?”

No debemos olvidar que algunas IAs (LLMs, en particular) proporcionarán respuestas aleatorias en esos casos.

If you pass an LLM a complex attack with multiple TTPs it hasn’t seen before, it might have low confidence and just spit out random MITRE ATT&CK categories.

• ¿Cómo impactará esto en mi equipo?

Pillar 3: The Practicality — How Will This Impact My Team?

La primera pregunta sería ¿cuál es el verdadero coste de tener esta solución?

“What is the true cost of ownership?”

No se trata de hablar solo del coste de la licencia sino de otros aspectos (el propio funcionamiento, ¿va incluido en la suscripción o aparecerá en mi factura de operaciones en la nube?

This isn’t just the license fee. If the product is feeding massive amounts of data into an LLM, who pays the inference cost? Is it included in your subscription, or is that going to show up on my cloud bill?

Pero también el coste para las personas: ¿cuánto tiempo necesitarán para validar las alertas y resultados que ofrezca la herramienta?

Even more importantly, what is the cost of my team’s time? If my analysts have to spend their days validating the AI’s output, I haven’t saved them work; I’ve just shifted it.

Otra pregunta interesante estaría relacionada con la corrección de errores: ¿si encontramos fallos podemos hacer que la IA aprenda para que no los vuelva a cometer?

“Can my analysts correct the AI’s mistakes, and does it learn from them?”

La última pregunta tendría que ver con la explicabilidad y el cumplimiento: ¿cómo proporciona el sistema la información para los auditores?

“How does your system provide ‘explainability’ for auditors or the board? I need to see detailed decision logs, confidence scores, and visualization tools.”

Complementa el escrito con las señales de alarma (red flags) que incluyen las típicas que hemos visto en otros contextos:

• Nuestro producto es propietario y no podemos darte detalles.

“Our AI is proprietary and we can’t share details.” Transparency is non-negotiable.

• No hacemos seguimiento de la tasa de falsos positivos.

“We don’t track false positive rates.” If they don’t measure accuracy, they can’t improve.

• Funciona sin tener que tocar nada.

“It works out of the box with no tuning.” Real-world environments always require configuration.

Buena lista de recomendaciones.

Igual A Modern Approach to Preventing CSRF in Go es excesivamente técnico y sobre algo muy concreto, pero quería dejarlo guardado porque nunca se sabe qué se puede necesitar en algún momento futuro.

Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)? Can we build secure web applications without bringing in third-party packages like justinas/nosurf or gorilla/csrf?

And I think the answer now may be a cautious “yes” — so long as a few important conditions are met.

En “GPUGate” Malware Abuses Google Ads and GitHub to Deliver Advanced Malware Payload nos contaban cómo atacaban a usuarios poco vigilantes mediante anuncios y enlaces a GitHub.

1. Aparece un anuncio malicioso, que apunta a un enlace que aparentemente es de GitHub, con un producto que parece ‘interesante’ (GitHub Desktop)

The attack begins with malicious advertising, where attackers place a sponsored ad at the top of Google search results for terms like “GitHub Desktop.” This ad directs users to what appears to be a legitimate GitHub page.

1. El enlace lleva a un página de GitHub dentro de un repositorio, todo parece legítimo, pero allí hay enlaces de descarga alterados.

In reality, the link leads to a specific, manipulated “commit” page within a repository. This page looks authentic, retaining the repository’s name and metadata, but contains altered download links that point to an attacker-controlled domain.

1. Para evitar los filtros de contenido el tamaño del instalador es muy grande (para aprovecharse de que muchos mecanismos de seguridad que tienen limitación de tamaño).

What makes GPUGate particularly notable is its unique evasion method. The initial installer is a large 128 MB file, designed to bypass security sandboxes that often have file size limits.

1. Finalmente, y para evadir la vigilancia mejor, solo se activa en caso de que haya disponible una GPU.

Its most innovative feature is a GPU-gated decryption routine. The malware will only decrypt its malicious payload if it detects a real, physical GPU with a device name longer than ten characters, Arctic Wolf said.

En este caso se está abusando de la confianza en los anuncios de Google, y en las páginas de GitHub. Pero eso es un problema, claro.

This “trust bridge” exploits the user’s confidence in both Google and GitHub to deliver the malicious payload.

Además, se implantan algunas medidas que son habituales en las máquinas de vigilancia y de los analistas, lo que haría más difícil la detección y análisis.

Curioso.

Ya hace unos cuantos años que se ofrecían inteligencias artificiales para la ciberseguridad: lo penúltimo era la detección de comportamientos anómalos a partir de la actividad de la red, los registros de actividad, etc. Pero, en los últimos años, las IAs se han ganado por derecho propio la entrada a todos los niveles. Casi me da apuro hablar de este caso porque la entrada tiene más de un año y todo cambia demasiado rápido, pero en Hallucinations, Hidden Costs & Human-in-the-Loop Realities nos hablaban de varios problemas y limitaciones que siguen estando de plena actualidad.

Nos podrían ayudar, nos dicen, en diversos aspectos:

• La fatiga por alertas: Ante la avalancha de avisos y textos largos, la IA permite examinarlos y resumirlos en segundos (aunque el problema de fondo sigue siendo que necesitan un buen entrenamiento con datos de calidad para ser confiables).

LLM Solution: Summarises the log avalanche in seconds

• Construcción de consultas: Ayuda a redactar queries complejas sin necesidad de ser un DBA especialista en esa sintaxis específica.

Pain Point: Query Kung-fu — SPL/KQL syntax

• Estructura y borrador de informes: Prepara la plantilla base (boilerplate) y aligera la carga de redacción.

Pain Point: Playbook boilerplate

• Apoyo a los perfiles junior: Delegar en la IA la explicación de conceptos o eventos relevantes (manteniendo siempre la precaución frente a posibles alucinaciones).

Pain Point: Junior mentoring

También se señalan inconvenientes claros:

• Completado de patrones: Como sabemos, los LLM completan secuencias de texto; no «saben» hechos. Si les alimentamos con datos de seguridad ambiguos o parciales, se inventan la respuesta con total soltura.

LLMs complete patterns; they don’t know facts. Feed them ambiguous or partial security data and they happily invent:

• Costes ocultos: El precio de los tokens, el coste de conectar e integrar nuestros datos (Retrieval Engineering), la desviación de instrucciones (Prompt Drift), el optimismo del vendedor frente a los resultados reales y las zonas grises en materia de cumplimiento normativo.

Token Tax Retrieval Engineering Prompt Drift Oversell, Underdeliver Compliance Grey-zones

¿Dónde quedan los humanos? Una cosa es que realmente podamos auditar y supervisar las respuestas de nuestras IAs y otra muy diferente lo que terminemos haciendo en el día a día.

Marketing slides imply analysts are promoted to “decision-makers”. In reality: they become prompt engineers, prompt auditors and bug-report shepherds. Without clear HITL checkpoints, a hallucinating agent can spray false positives, or worse, false negatives, at machine speed.

Para no olvidarlo.

Forma parte del folclore cómo algunos empleados ‘previsores’ insertan código en las plataformas que gestionan ‘por si acaso’. En Dev gets 4 years for creating kill switch on ex-employer’s systems nos contaban uno de estos casos y cómo el empleado fue condenado a cuatro años de cárcel por hacerlo.

A software developer has been sentenced to four years in prison for sabotaging his ex-employer’s Windows network with custom malware and a kill switch that locked out employees when his account was disabled.

Por lo visto, había sido degradado en una reestructuración de la empresa y trató de vengarse preparando código malicioso.

After a corporate restructuring and subsequent demotion in 2018, the DOJ says that Lu retaliated by embedding malicious code throughout the company’s Windows production environment.

Algo tan simple como un programita en Java que lanza un bucle infinito, sobrecarga y termina dejando inutilizables los servidores.

The malicious code included an infinite Java thread loop designed to overwhelm servers and crash production systems.

No parece que sea la mejor forma de afrontar un despido o una degradación, justificados o no.