Organización y toma de notas

Una nota útil tiene una tarea y un lector. El diario de un laboratorio, una referencia técnica y un informe no conservan la misma información. Si los mezclas, la cronología oculta las conclusiones y los comandos pierden contexto.

El diario de laboratorio explica qué ocurrió en un caso concreto. La referencia temática recibe solo las conclusiones que hayas entendido y comprobado. Guardar una salida no la convierte en conocimiento reutilizable.

Una página técnica suele necesitar finalidad, prerrequisitos, modelo mental, procedimiento e interpretación. Añade variantes y errores habituales cuando aporten algo. No rellenes apartados por obligación.

Las instrucciones reproducibles identifican el punto de partida, los valores que debe sustituir el lector, la señal esperada y los límites. Utiliza placeholders como TARGET_IP, PORTS, USERNAME o WORDLIST. Si una versión cambia el resultado, indícalo junto al paso afectado.

La estructura debe mostrar a qué laboratorio o encargo pertenece cada archivo. Este ejemplo es un punto de partida:

WORKSPACE/
└── ENGAGEMENT_ID/
    ├── scope/
    ├── notes/
    ├── scans/
    ├── logs/
    ├── evidence/
    │   ├── screenshots/
    │   └── data/
    └── deliverables/

Separa laboratorios, evaluaciones internas y evaluaciones externas. Los nombres deben permitir atribuir cada archivo. El historial de terminal no sirve como único registro.

Los datos de cliente requieren almacenamiento cifrado, acceso limitado y el tratamiento acordado en las RoE. Antes de sincronizar una carpeta o usar notas en la nube, comprueba dónde almacena los datos y quién puede acceder. La evidencia de cliente no debe convivir con el conocimiento público.

Un transcript ayuda a reconstruir una sesión, pero no convierte todo el texto capturado en evidencia útil. Puede contener tokens, contraseñas impresas, datos personales, secuencias de control y resultados que no pertenecen al hallazgo. Trátalo como un artefacto sensible y extrae después el fragmento que justifica cada decisión.

En Linux, script abre una shell interactiva y guarda lo que aparece en la terminal. --log-out fija el archivo de salida:

script --log-out logs/session.typescript

Termina la shell con exit para que script cierre el archivo. No uses --log-in ni --log-io como configuración general. Esas opciones pueden registrar también la entrada aunque la terminal desactive el eco para una contraseña.

En PowerShell, Start-Transcript registra la sesión en la ruta literal indicada. -IncludeInvocationHeader añade la hora de invocación de los comandos y -NoClobber impide sobrescribir un archivo existente:

Start-Transcript `
  -LiteralPath '.\logs\session.txt' `
  -IncludeInvocationHeader `
  -NoClobber

Finaliza la captura explícitamente:

Stop-Transcript

Los transcripts no sustituyen las opciones de output nativas de una herramienta. Estas suelen conservar formatos estructurados, metadatos y códigos de salida que la presentación de terminal puede perder. Para un comando aislado, tee permite ver el resultado y guardarlo. -a lo añade al archivo existente, mientras que 2>&1 combina el error estándar con la salida estándar antes de pasarlos al pipeline. COMMAND representa la orden que quieres registrar:

COMMAND 2>&1 | tee -a logs/command.txt

No introduzcas secretos como argumentos solo para que el comando sea más fácil de registrar. El historial, el transcript y el listado de procesos pueden conservarlos.

Una cheatsheet guarda sintaxis para una tarea que ya entiendes. Cada entrada debe indicar qué resuelve, sus condiciones, los placeholders, la salida esperada y la página que explica el procedimiento. Una tabla de un curso sirve para revisar cobertura hasta que hayas verificado y contextualizado sus comandos.

Una checklist protege contra omisiones conocidas, por ejemplo confirmar el scope o registrar un cambio. No sustituye la enumeración ni impide volver atrás cuando aparece una superficie nueva.

Un template proporciona campos y lenguaje base para notas o informes. Hay que adaptarlo al activo, la evidencia y el riesgo observados. Una descripción genérica no debe presentarse como si correspondiera a un entorno real.

Conserva la salida completa como artefacto y copia en la nota solo el fragmento que justifica la decisión. Cada captura debe tener un propósito y cada comando, una pregunta.

Cuando un tema dependa de otro, introduce el contexto mínimo y enlaza la explicación principal. Así evitas repetir TCP, HTTP o autenticación y mantener versiones contradictorias.

La gestión de evidencias desarrolla la integridad, custodia y saneamiento durante un encargo. Documentación e informes explica cómo convertir esas notas en entregables para distintas audiencias.

La referencia de Nmap aplica este criterio a escaneos reales: conserva outputs completos, nombres atribuibles y una referencia rápida que no oculta las condiciones de cada flag.

• ¿Se entiende el propósito en el primer párrafo?
• ¿El diario, la evidencia y la referencia están separados?
• ¿Cada comando conserva condiciones, placeholders y señal esperada?
• ¿Se distingue lo observado de lo inferido?
• ¿Los transcripts y outputs se tratan como artefactos sensibles?
• ¿La ubicación de los datos corresponde a su sensibilidad?

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• Diátaxis: A systematic approach to technical documentation
• Linux man-pages: script(1)
• Microsoft Learn: Start-Transcript