Hay una parte del trabajo defensivo que casi nunca queda documentada.
No suele aparecer en los manuales del fabricante ni cabe en una captura de una alerta: las hipótesis que se descartan, las búsquedas que no devuelven resultados, los falsos positivos, las configuraciones que fallan y las pequeñas decisiones que terminan marcando la diferencia durante una investigación.
Defensive Ops nace para documentar esa parte del trabajo.
La idea es publicar, cada semana, una pieza técnica sobre operaciones defensivas: investigaciones, laboratorios, herramientas, detecciones, automatizaciones y procedimientos construidos desde la práctica.
No se trata de publicar por cumplir una cadencia. Se trata de convertir el trabajo operativo en conocimiento que pueda revisarse, reproducirse y reutilizarse.
Aprender haciendo, documentar el proceso y extraer criterio operativo.
Por qué Defensive Ops
El nombre resume el enfoque del proyecto: operaciones defensivas.
Una herramienta, una regla o una alerta solo tienen valor cuando encajan dentro de un proceso más amplio:
- detectar actividad relevante
- realizar un triage inicial
- analizar telemetría
- formular y validar hipótesis
- reconstruir una secuencia de ejecución
- identificar el alcance
- documentar los hallazgos
- responder con la menor pérdida de información posible
La parte importante no es ejecutar un comando o instalar una plataforma. La parte importante es entender cuándo utilizarla, qué evidencia esperar, qué limitaciones tiene y qué decisión permite tomar.
Por eso, cada publicación intentará responder a una pregunta concreta:
¿Qué valor aporta esto durante una investigación o una operación defensiva real?
Una publicación técnica cada semana
Defensive Ops tendrá una cadencia semanal.
El formato podrá cambiar según el contenido. Algunas semanas habrá un laboratorio completo; otras, el análisis de una detección, una herramienta, un falso positivo, una automatización o un hallazgo operativo.
Las principales líneas de contenido serán:
- EDR y telemetría de endpoint
- Incident Response y DFIR
- Detection Engineering
- análisis de alertas
- Windows y Linux
- laboratorios controlados
- automatización aplicada a Blue Team
- revisión de herramientas defensivas
- playbooks y procedimientos
- análisis técnico de comportamientos sospechosos
- errores, limitaciones y lecciones aprendidas
Linux tendrá un peso especial. Gran parte del contenido defensivo se concentra en Windows, pero los servidores Linux, sus procesos, servicios, agentes EDR y fuentes de telemetría también necesitan procedimientos específicos.
Cómo será cada publicación
Cada entrada partirá de un problema operativo, no de una herramienta elegida al azar.
La estructura habitual será:
- Contexto: qué problema queremos resolver.
- Objetivo: qué capacidad queremos construir, validar o mejorar.
- Entorno: qué sistemas, versiones y configuraciones intervienen.
- Ejecución: qué acciones o pruebas controladas se realizan.
- Telemetría: qué evidencias aparecen y dónde.
- Análisis: cómo interpretamos los resultados.
- Limitaciones: qué no hemos podido observar, validar o detectar.
- Aplicación real: cómo trasladaríamos lo aprendido a una investigación.
- Conclusiones: qué funciona, qué no y qué mejoraríamos.
Cuando algo falle, también quedará documentado.
Los errores de configuración, las hipótesis descartadas y las detecciones ruidosas forman parte del trabajo. Ocultarlos produciría un tutorial más limpio, pero una publicación menos útil.
Cómo irá evolucionando el proyecto
Esta web es el punto de partida, pero no será el único formato.
La evolución prevista es sencilla:
Web → documentación técnica y referencia
X → avances, hallazgos y nuevas publicaciones
YouTube → demostración visual de laboratorios e investigaciones
GitHub → código, configuraciones y artefactos reproducibles
La web seguirá siendo la fuente principal. Aquí quedarán los pasos, las evidencias, los comandos, las decisiones y las conclusiones.
X servirá para compartir avances, observaciones breves y nuevos contenidos. YouTube permitirá mostrar procesos que se entienden mejor viendo la ejecución completa. GitHub recogerá los artefactos que puedan reutilizarse de forma segura.
El objetivo no es crear contenido diferente para cada plataforma, sino documentar un mismo trabajo desde distintos niveles de profundidad.
El primer recorrido
El proyecto comienza apoyándose en una referencia conocida dentro de la comunidad de Incident Response y DFIR: el repositorio awesome-incident-response.
No se utilizará como una lista para copiar ni como un catálogo de herramientas.
La idea será seleccionar recursos, probarlos en entornos controlados y evaluar:
- qué problema resuelven
- qué requisitos tienen
- qué telemetría generan o consumen
- qué limitaciones presentan
- cuándo aportan valor
- cómo encajan dentro de una investigación real
A partir de ahí, el proyecto irá creciendo hacia laboratorios más completos, detecciones propias, análisis de telemetría y procedimientos reproducibles.
Qué no es Defensive Ops
Defensive Ops no pretende ser:
- una academia generalista
- una colección de tutoriales reciclados
- una lista infinita de herramientas
- un resumen automático de noticias
- un escaparate comercial de productos
Tampoco se publicarán datos corporativos, evidencias reales de clientes, credenciales, tokens ni información sensible.
Todo el contenido se desarrollará en entornos controlados y con finalidad defensiva, educativa y profesional.
El criterio de éxito
El éxito del proyecto no se medirá por la cantidad de herramientas instaladas ni por el número de comandos publicados.
Se medirá por la capacidad de responder preguntas con evidencia:
- qué ocurrió
- cómo ocurrió
- qué telemetría lo demuestra
- qué detectó la plataforma
- qué información faltó
- qué decisión defensiva podemos tomar
- qué debemos mejorar para la próxima vez
Esta entrada funciona como punto de partida. A medida que Defensive Ops avance, los artículos, laboratorios y notas irán dando forma al proyecto.
Puedes consultar los primeros trabajos en la sección de laboratorios y seguir las novedades en X.
Detect · Analyze · Respond.