1.1.1. Texto no estructurado

Es todo contenido cuyo significado está en lenguaje natural y no viene organizado en campos fijos (como una tabla). A diferencia de un log estructurado (e.g. JSON con claves constantes), el contenido es variable, con estilos distintos, abreviaturas, errores, y fragmentos técnicos mezclados con lenguaje común. Esto incluye comunicaciones humanas y narrativas de incidentes.

1.1.2. Tipos de texto más comunes

En un entorno real de ciberseguridad, la información relevante para la detección de amenazas no se encuentra únicamente en registros estructurados, sino principalmente en cuatro tipos de textos no estructurados que circulan dentro de la organización: correos electrónicos, tickets de soporte, logs narrativos de incidentes y mensajes en chats o foros corporativos. Cada uno de estos formatos posee características discursivas, técnicas y contextuales distintas, pero todos comparten un rasgo común: contienen indicios lingüísticos y técnicos (Forma típica) que pueden revelar comportamientos maliciosos o situaciones de riesgo (Rasgos clave).

Comprender la naturaleza de estos tipos de texto constituye el primer paso para poder representarlos computacionalmente y analizarlos mediante técnicas de PLN orientadas a la ciberseguridad.

1.1.3. Texto no estructurado es “difícil” para una máquina

Un sistema automático se enfrenta a problemas recurrentes:

• Variación léxica: “urgente”, “inmediato”, “ASAP”, “ahora”.
• Ambigüedad: “revisa esto” puede ser legítimo o malicioso.
• Ruido: firmas, disclaimers legales, cadenas de correo, HTML.
• Entidades mixtas: nombres, dominios, URLs, hashes, códigos, IPs.
• Intención oculta: el ataque puede estar “disfrazado” como solicitud normal.

Esta complejidad explica por qué el primer reto del curso inicia con comprender el texto antes de modelar.

1.1.4. Componentes internos del texto o “capas”

En un texto de incidente, conviene separarlo mentalmente en capas:

• Componentes internos del texto o “capas”
• En un texto de incidente, conviene separarlo mentalmente en capas:
• Contenido lingüístico (qué se dice): verbos de acción, tono, urgencia.
• Contenido técnico (qué referencia): URLs, dominios, IPs, adjuntos.
• Metadatos (si existen): fecha, remitente, canal, categoría, prioridad.
• Estructura discursiva: saludo → petición → justificación → llamada a acción.

1.1.5. Análisis de texto no estructurado

Demostrativamente se analiza un correo electrónico sospechoso (phishing simulado), y un ticket de soporte o legítimo (también simulado). Basado en (Jurafsky et al, 2023) y (Eiseinstein,2019). Este ejercicio permite:

• Comprender la naturaleza del texto no estructurado.
• Diferenciar lenguaje persuasivo vs. técnico.
• Preparar el terreno para limpieza y tokenización (Semana 2).
• Vincular lenguaje con riesgo operativo en un SOC.

1.2.1. Token

Es una unidad mínima de texto que el sistema puede procesar. Generalmente corresponde a palabras individuales. También pueden ser números, símbolos o URL.

En el texto original: “Hemos detectado actividad inusual en su cuenta”. Los tokens posibles son:

[“Hemos”, “detectado”, “actividad”, “inusual”, “en”, “su”, “cuenta”] Así el sistema deja de ver oraciones y comienza a ver listas de unidades manipulables. Este proceso se llama “tokenización”.

1.2.2. Corpus

Es el conjunto organizado de textos que se utilizará para analizar o entrenar modelos. En ciberseguridad, un corpus puede estar compuesto por:

• 20.000 emails (legítimos y phishing).
• Cientos o miles de tickes de soporte
• Cientos o miles de logs narrativos.

El correo de ejemplo es parte de un corpus etiquetado como “sospechoso” o “phishing”.

1.2.3. Ruido

Es todo elemento que no aporta valor a la tarea específica. Depende del objetivo del análisis. Ejemplos:

• Analizar solo patrones lingüísticos.
• La información crítica en dominios sospechosos.
• Mayúsculas excesivas.
• Firmas automáticas.
• Encabezados repetidos.
• HTML.

1.2.4. Stopwords

Son palabras frecuentes que aportan poco significado semántico, por lo que suelen eliminarse. En el ejemplo, al eliminar los stopwords queda: [“detectado”, “actividad”, “inusual”, “cuenta”].

1.2.5. n-gramas

Es una secuencia de n tokens consecutivos.

• Unigramas (1 palabra): ["urgente", "verificación"]
• Biogramas (2 palabras): ["verificación inmediata", "actividad inusual"]. En phishing estos biogramas se pueden convertir en patrones detectables por el modelo.
• Trigramas (3 palabras): ["suspensión inmediata confirme"]

El objetivo del PLN en ciberseguridad es identificar la dimensión discursiva del ataque. Muchas amenazas textuales no se distinguen únicamente por contenido técnico, sino por estrategias discursivas. Los atacantes diseñan el lenguaje para activar respuestas automáticas en el usuario, explotando atajos cognitivos (ver Ilustración 1):

• Miedo → términos como “suspensión”, “actividad inusual”, “riesgo de pérdida” reducen el pensamiento analítico.
• Obediencia / autoridad → referencias a “Seguridad TI”, “Administración”, “Soporte” inducen cumplimiento.
• Urgencia → expresiones como “inmediato”, “último aviso”, “24 horas” presionan a actuar sin verificar.

En PLN aplicado a ciberseguridad, estas estrategias se traducen en señales lingüísticas (imperativos, marcadores temporales, suplantación institucional) que pueden modelarse y detectarse: ya sea como tokens (urgente, verifique, [URL]), n-gramas (“suspensión inmediata”), o features semánticas (intención, presión emocional).

Estas estrategias pueden clasificarse en tres categorías:

• Urgencia artificial
• Suplantación de autoridad
• Persuasión emocional o coercitiva

1.3.1. Urgencia artificial

La urgencia busa reducir el tiempo de reflexión crítica del usuario, favoreciendo decisiones impulsivas. En informática, palabras asociadas a urgencia pueden convertirse en: features léxicas, n-gramas relevantes, indicadores semánticos.

En el ejemplo, los n-gramas asociados con urgencia son: “URGENTE”, “suspensión inmediata”, “verificación inmediata”. Se puede observar:

• Uso de mayúsculas
• Adverbios de inmediatez
• Plazos implícitos o amenazas

1.3.2. Suplantación de autoridad

La suplantación se detecta lingüísticamente cuando: el dominio del enlace no coincide con la institución, la firma es genérica, y no hay personalización real del destinatario. Aquí se combinan análisis lingüístico + análisis técnico.

En el ejemplo “Departamento de seguridad de TI”, combina estrategias de:

• Referencia a una entidad institucional
• Uso de términos corporativos formales
• Construcción de legitimidad aparente.

1.3.3. Lenguaje persuasivo y manipulación emocional

El verbo en imperativo (e.g. “confirme”) es clave. En PLN, los verbos de acción pueden convertirse en: Indicadores de intención, marcadores pragmáticos, señales de ingeniería social.

“Hemos detectado actividad inusual en su cuenta”, demuestra las siguientes estrategias:

• Introducción de un problema ambiguo
• Generación de incertidumbre
• Llamada directa a la acción (“confirme”).

1.3.4. Síntesis conceptual

Basado en Eisenstein (2019), la Tabla 1 sintetiza las estrategias respecto del objetivo del atacante, resaltando la señal lingüística y la característica PLN.

1.3.5. Comparación con texto legítimo: ejemplificación

En el ticket legítimo simulado “Desde ayer no puedo conectarme a la VPN corporativa”, se observa: tono descriptivo, ausencia de presión, e información verificable. Ilustración 2 muestra diferencias entre texto amenazante y legítimo.

1.3.6. Formalización para PLN

Estas características pueden convertirse en variables computables:

• Conteo de términos de urgencia
• Detección de imperativos
• Análisis de polaridad emocional
• Identificación de estructuras persuasivas

En etapas posteriores relacionadas con el Reto 3, estas señales pasarán de ser solo léxicas a ser semánticas y contextuales. Ilustración 3 conecta psicología humana, lenguaje y procesamiento computacional, miestra el puente conceptual entre Semana 1 (comprensión del lenguaje en ataques), Semana 2 (preparación del texto), Reto 3 (análisis semántico) y reto 4 (sistema inteligente de alerta).

Contextualmente:

• SOC (Security Operations Center): Unidad encargada de monitorear, detectar y responder a incidentes de seguridad en tiempo real.
• CSIRT (Computer Security Incident Response Team): Equipo especializado en la gestión, análisis y resolución de incidentes de seguridad.
• CERT: Equipo de respuesta de seguridad informática.

En ambos entornos, una parte significativa de la información crítica está contenida en texto no estructurado, que debe ser analizado para apoyar la toma de decisiones. El texto en ciberseguridad proviene de múltiples canales. Cada fuente tiene rasgos lingüísticos propios. La preparación del dataset depende de la fuente.

1.4.1. Principales fuentes textuales en un entorno real

En un SOC/CSIRT, los textos provienen de múltiples canales. Las más relevantes para PLN se encuentran en Tabla 2.

1.4.2. Diferencias estructurales entre fuentes

Cada fuente tiene características particulares (Ilustración 5). Estas diferencias afectan: El tipo de preprocesamiento necesario, la presencia de ruido, el tipo de patrones lingüísticos detectables. El análisis PLN se enfoca dependiendo las particularidades.

El texto no estructurado debe convertirse en un dataset organizado para poder ser procesado por modelos de PLN. Esto implica transformar documentos individuales en registros estructurados que contengan: el texto, información contextual, una posible etiqueta de clase. Sin esta estructura, el modelo no puede entrenarse ni evaluarse adecuadamente.

1.5.1. Campos principales de un dataset

Para que un conjunto de datos pueda ser identificado y analizado debe contener mínimo:

• id: identificador único
• Fuente: tipo de texto (correo, ticket, log, chat)
• Texto: Contenido textual limpio o crudo
• Fecha: Fecha del evento
• Canal: Medio de recepción (email, sistema, ITSM, chat)

1.5.2. Metadatos

Aportan información valiosa para el analásis, como: Dominio del remitente, nivel de prioridad del ticket, departamento afectado, severidad asignada, usuario reportante. Estos elementos pueden ser variables adicionales en modelos posteriores.

1.5.3. Etiquetas (labels)

Las etiquetas son fundamentales cuando se trabaja con aprendizaje supervisado (Reto 2). Los tipos de etiquetas posibles son:

• phishing
• malware
• ingenieria_social
• legitimo
• incidente_tecnico

1.5.4. Buenas prácticas de estructuración

• Mantener formato consistente (CSV o JSON).
• Evitar celdas vacías innecesarias.
• Documentar criterios de etiquetado.
• Versionar el dataset.
• Registrar fecha de creación y modificaciones.

Texto no estructurado à Registro Estructurado à Dataset analizable

1.5.5. Herramientas para PLN

Rubrix es un framework de Python listo para producción que permite explorar, anotar y gestionar datos en proyectos de PLN. Rubrix es código abierto, compatible con las principales bibliotecas de PLN (Transformers, Hugging Face, spaCy, Stanford Stanza, entre otros). Es recomendable usar Rubrix como apoyo automático al etiquetado manual. escárguela en: https://rubrix.readthedocs.io/en/v0.4.1/.

Las fuentes textuales pueden contener datos sensibles, por lo tanto se debe tomar precauciones. Los datos reales pueden ser: nombres, correos electrónicos, direcciones IP, datos sensibles que identifican personas o aspectos de la organización. Por ello, es obligatorio anonimizar, respetar las políticas institucionales, y documentar el tratamiento del dato.

1.6.1. Riesgos al trabajar con textos reales

• Exposición de datos personales: Un correo de phishing puede incluir nombres reales, cargos, teléfonos o direcciones internas.
• Fuga de información sensible: Logs narrativos pueden describir vulnerabilidades o configuraciones internas.
• Reidentificación: Incluso si se elimina el nombre, puede identificarse a una persona por contexto (cargo, departamento, incidente específico).
• Uso indebido del corpus: El dataset podría ser reutilizado fuera del propósito académico o sin autorización.

1.6.2. Anonimización

Consiste en eliminar o transformar datos personales para impedir la identificación de individuos, como en Ilustración 8.

1.6.3. Minimización del dato

Implica que el dataset debe contener solo la información necesaria para el objetivo del análisis. Ejemplo: Para detectar phishing no es necesario almacenar el nombre completo del remitente, puede bastar con almacenar el dominio.

1.6.4. Documentación ética del dataset

Un dataset académico responsable incluye un archivo README o una ficha técnica del corpus, detallando:

• Fuente de los datos.
• Procedimiento de anonimización.
• Fecha de recopilación.
• Restricciones de uso.
• Responsable del tratamiento.