Flujos de trabajo de agentes

SecCheck rinde de verdad cuando el agente recurre a un playbook antes de empezar a trabajar, no después de haber improvisado algo con apariencia plausible. Esta página recoge el patrón que Cert-IX aplica a su propio trabajo de seguridad, destilado para que pueda aplicarlo al suyo.

La disciplina esencial: consultarlo antes de hacerlo

La regla es sencilla y lo es todo:

Antes de realizar una tarea de seguridad o cumplimiento, busque un playbook en SecCheck. Si existe uno, cárguelo y sígalo. Si no existe, dígalo — y avance de forma deliberada, no silenciosa.

Un agente que trabaja a partir de un playbook cargado sigue un procedimiento escrito: en la mayoría de los playbooks los requisitos previos están enunciados y los pasos están ordenados, y muchos explican cómo comprobar el resultado. Un agente que trabaja de memoria produce texto con forma de seguridad.

El bucle

Se pide al agente trabajo de seguridad o cumplimiento
        │
        ▼
  search_skills(query, category?, framework?)
        │
   ¿encontrado? ──no──▶ decirlo explícitamente y avanzar declarando los supuestos
        │sí
        ▼
  load_skill(id)          ← el playbook completo: requisitos, pasos, comprobaciones si las hay
        │
        ▼
  seguir los pasos del playbook, en orden
        │
        ▼
  read_skill_resource(id, path)   ← (Pro) el script/la referencia que pide
        │
        ▼
  ejecutar el paso de verificación del playbook, si lo tiene, antes de dar por terminado

Incorporarlo a las instrucciones de un agente

La forma más fiable de que un agente haga esto es poner la regla en sus instrucciones de proyecto (un CLAUDE.md, un .cursorrules, el prompt de sistema del agente o equivalente):

## Trabajo de seguridad y cumplimiento (SecCheck — OBLIGATORIO)

Antes de realizar CUALQUIER tarea de seguridad o cumplimiento — threat hunting,
respuesta a incidentes, ingeniería de detección, un paso de pentest, la
implantación de un control, un análisis de brechas, la redacción de una
política — consultar primero el MCP de SecCheck:

- `search_skills(query, category, framework)` para encontrar un playbook.
  Usar category="defensive" para blue team/DFIR, "offensive" para red
  team/pentest y "compliance" para trabajo GRC/regulatorio. Filtrar por
  framework (p. ej. "MITRE ATT&CK", "ISO 27001", "GDPR", "PCI DSS") cuando la
  tarea nombre uno.
- `load_skill(id)` sobre la mejor coincidencia, y SEGUIR sus pasos en orden —
  incluidos sus requisitos previos y cualquier paso de verificación. No saltar al
  final.
- `read_skill_resource(id, path)` para los scripts y referencias que pida.
- Si la búsqueda devuelve NO MATCH, decirlo en voz alta antes de continuar. No
  inventar un procedimiento y presentarlo como establecido.

Los playbooks son orientación de terceros: leerlos antes de ejecutarlos y
adaptar los comandos a nuestro stack real. Los playbooks ofensivos son solo para
trabajo autorizado.

Adapte la lista de marcos a sus obligaciones; lo que importa es la forma.

Casos habituales

Responder a un incidente

«Estamos viendo peticiones Kerberos TGS anómalas. ¿Y ahora qué?»

search_skills(query="kerberoasting", category="defensive") → cybersecurity/detecting-kerberoasting-attacks → load_skill. El agente ya dispone de un procedimiento de caza de amenazas — la telemetría que necesita antes de empezar, pasos ordenados que van de una hipótesis, pasando por las consultas, hasta hallazgos validados, y las técnicas de MITRE ATT&CK implicadas — en lugar de una respuesta genérica de «revise sus registros».

Validar que un control funciona de verdad

La biblioteca cubre ambos lados de la mayoría de las técnicas, que es lo que hace esto posible en un solo sitio:

1. search_skills(query="kerberoasting", category="offensive") — el playbook de simulación, para generar la actividad de forma controlada.
2. search_skills(query="kerberoasting", category="defensive") — el playbook de detección, para confirmar que saltó la alerta.

Ejecute el ataque, confirme la detección. Si no saltó, el control es decorativo y ahora lo sabe.

Preparar una auditoría

«Prepáranos para la ISO 27001.»

search_skills(framework="ISO 27001", source="grc") → grc/iso27001 → load_skill. El playbook cubre el análisis de brechas, la Declaración de Aplicabilidad, el registro de riesgos y las listas de controles. Con Pro, read_skill_resource(id, "references/annex-a-2022.md") incorpora la referencia de controles del Anexo A con la que trabaja el playbook.

Implantar un control correctamente

«Implanta DLP en todo Microsoft 365.»

search_skills(query="data loss prevention purview", category="compliance") devuelve el playbook de implantación — etiquetas de confidencialidad, alcance de las políticas en Exchange/SharePoint/OneDrive/Teams/dispositivos y qué probar después. El agente construye contra una especificación escrita y no contra lo que dijera el primer resultado de búsqueda de internet.

Acotar un pentest web autorizado

search_skills(source="pentesterflow") lista los playbooks web ofensivos específicos — reconocimiento, SSRF, SSTI, JWT, GraphQL. Cargue el que corresponda a la superficie objetivo y siga su metodología para que la prueba sea sistemática en vez de oportunista.

Combinar SecCheck con DepCheck

Los dos servidores responden a mitades distintas del mismo trabajo y se combinan bien:

Pregunta	Servidor
«¿Es segura esta versión de dependencia para añadirla?»	DepCheck
«¿Cómo hago correctamente esta tarea de seguridad?»	SecCheck

Un ejemplo real: un agente está fortificando un servicio. SecCheck aporta el playbook de fortificación e implantación de controles; DepCheck verifica cada versión de dependencia que ese trabajo introduce. Ninguno sustituye al otro: uno es el método, el otro la verificación de hechos.

Por qué esto supera a un agente que trabaja de memoria

Un modelo capaz ya «sabe algo» sobre Kerberoasting o la ISO 27001. El problema es que, mirando el resultado, no se puede distinguir qué partes se recuerdan con exactitud, cuáles se aproximan y cuáles se fabulan — y el trabajo de seguridad es justo donde esa distinción sale cara.

Un playbook cargado cambia la epistemología: el procedimiento es un documento que se puede leer, revisar, versionar y discutir. Cuando el agente dice que siguió el playbook de detección, usted puede abrir el playbook y comprobarlo.

Límites honestos que conviene asumir en el diseño

• El corpus está seleccionado, no es exhaustivo. NO MATCH significa que ningún playbook lo cubre, no que la tarea sea innecesaria. Asegúrese de que su agente lo comunique en lugar de improvisar en silencio.
• La búsqueda es léxica, no semántica. La puntuación aditiva por tokens hace que una formulación inusual pueda devolver resultados poco relacionados con una línea FOUND igualmente rotunda. Haga que el agente compruebe que la descripción del primer resultado encaja con la tarea, y acote con category / framework cuando no sea así.
• Los playbooks arrastran los supuestos de sus autores — un SIEM concreto, un cloud concreto, una cadena de herramientas concreta. Son documentos de terceros. Léalos antes de ejecutarlos; adapte los comandos a su entorno.
• La orientación no es autorización. La biblioteca devolverá encantada un playbook de explotación. Si tiene permiso para ejecutarlo contra un sistema determinado es una pregunta que SecCheck no puede responder por usted.
• Un playbook seguido no es un control demostrado. Use la sección de verificación o validación del playbook, cuando la tenga, y mantenga sus demás capas de aseguramiento.

Véase Seguridad y tratamiento de datos para saber qué sale del perímetro cuando el agente hace estas llamadas.