Subtécnicas y cuándo bajar al detalle

Las subtécnicas separan variantes de una misma idea. Una técnica padre como «ejecución programada» se divide según el mecanismo: cada sistema operativo y cada orquestador tiene el suyo. Bajar a la subtécnica sirve cuando la evidencia nombra el mecanismo: entonces la ficha concreta tiene detección, plataformas y mitigaciones propias.

Cuando la fuente solo dice «una tarea programada» y no se sabe en qué planificador, elegir una subtécnica es adivinar. Lo honesto es registrar el padre, y subir de nivel solo si aparece la evidencia que falta.

En la consola, familia_de_tecnicas lista una técnica padre y sus subtécnicas con el mecanismo de cada una, y observaciones_del_mes trae seis observaciones. La que viene del servidor Linux de archivos nombra un mecanismo concreto: el planificador clásico de Linux con sus tablas de usuario.

Otra observación viene de un nodo Linux de reparto y habla de una unidad nueva que lanza un script. En Linux hay más de un planificador; que el mecanismo sea otro cambia la subtécnica, y con ella lo que se mira para detectarlo y lo que se endurece para evitarlo.

De las seis observaciones, unas traen evidencia del mecanismo y otras no: un informe externo muy general y una alerta que dice «ejecución programada sospechosa» sin decir qué planificador. Registrarlas todas a nivel de subtécnica daría un mapa más fino y menos cierto.

La columna dice_el_mecanismo de la tabla de observaciones lo resume con «si» o «no».

Un compañero propone registrar todo a nivel de subtécnica «para que el informe quede más profesional». Un mapa más fino parece más trabajado, pero lo que dice debe sostenerse en lo que se vio. Una subtécnica mal elegida manda a otro equipo a buscar en el planificador equivocado, y pesa en cualquier comparación posterior con otros mapas.