Los registros locales sí apoyan la evidencia SOC 2 CC7

Los registros locales de ejecución con evidencia de manipulación pueden apoyar la evidencia SOC 2 CC7, pero no cubren por sí solos CC7.1 ni CC7.2. Pueden mostrar qué proceso de agente local inició una sesión, qué llamadas con credenciales intentó, cómo terminaron y si cambió el historial almacenado. No demuestran que todos los sistemas dentro del alcance tuvieron monitoreo de vulnerabilidades ni que una persona investigó las anomalías según lo previsto.

Ese límite importa. He visto equipos entregar al auditor una exportación de registros perfectamente firmada y llamarla su control de monitoreo. La exportación probaba que existían eventos. No probaba cobertura, lógica de detección, revisión, escalamiento ni corrección. El registro local es útil cuando se trata como una fuente de evidencia dentro de un sistema de control. Si se trata como el control completo, las carencias aparecen durante el muestreo.

La prueba práctica es sencilla: conecta cada afirmación con un campo, un procedimiento, un responsable y evidencia corroborante. Si falta una de esas piezas, documenta la limitación antes de que lo haga el auditor.

CC7.1 y CC7.2 plantean preguntas distintas

CC7.1 pregunta si la entidad usa procedimientos de detección y monitoreo para identificar cambios de configuración que introducen nuevas vulnerabilidades y exposición a vulnerabilidades recién descubiertas. CC7.2 pregunta si la entidad monitorea los componentes del sistema y su operación para detectar anomalías asociadas con actos maliciosos, desastres naturales o errores, y luego analiza esas anomalías para decidir si son eventos de seguridad. El registro de una acción API o SSH de un agente puede contribuir a ambos criterios, pero de forma distinta.

Para CC7.1, un registro de ejecución suele ser evidencia de cambios. Puede mostrar que un agente modificó una regla de firewall, desplegó un paquete, cambió una configuración de identidad o ejecutó un comando en un host. Esa evidencia ayuda a relacionar una desviación de configuración o una nueva exposición con el proceso que la causó. El registro no detecta una vulnerabilidad recién publicada, salvo que otro escáner, fuente de avisos, servicio de inventario o procedimiento de revisión compare los componentes desplegados con la nueva información.

Para CC7.2, el mismo registro es telemetría operativa. Una llamada denegada, un destino inesperado, fallos repetidos de autenticación, un comando inusual o una acción fuera de una sesión aprobada pueden alimentar la detección de anomalías. Sin embargo, almacenar un evento no equivale a monitorearlo. La organización aún necesita una forma definida de seleccionar eventos, reconocer patrones sospechosos, enviarlos a un revisor y documentar la decisión.

Esta distinción evita un error frecuente: equiparar el registro con la detección. Una fuente de registros guarda observaciones. Un control de detección aplica lógica o juicio humano a esas observaciones. El auditor suele probar tanto el diseño como la operación, así que una prueba que solo demuestra la recopilación responde la mitad de la pregunta.

Los Trust Services Criteria de AICPA ofrecen puntos de atención, no una lista universal de herramientas. Eso permite que una empresa diseñe controles adecuados a sus riesgos, pero elimina la idea de un periodo mágico de conservación o una categoría de producto obligatoria. La descripción del sistema, la evaluación de riesgos, la redacción del control y el procedimiento real determinan si los datos locales de ejecución son pertinentes.

Una declaración de control limitada y defendible podría decir: «Seguridad revisa cada día hábil las acciones de producción mediadas por agentes para detectar llamadas denegadas, llamadas fallidas, destinos nuevos y comandos SSH privilegiados; el revisor registra el resultado y escala los eventos sospechosos mediante el procedimiento de incidentes». Esa declaración identifica la población, las señales, la frecuencia, el responsable y el seguimiento. «Conservamos registros con evidencia de manipulación» solo identifica una propiedad del almacenamiento.

La identidad de sesión describe un proceso, no una persona

Un registro de sesión útil identifica el proceso del agente con suficiente precisión para distinguir una ejecución de otra. Como mínimo, captura un identificador único de sesión, horas de inicio y fin del proceso, ruta del ejecutable, identidad de firma de código o resumen binario, proceso padre, identificador del host, cuenta local, decisión de autorización, persona que autorizó y estado de revocación. Conserva el método usado para obtener cada campo, porque un valor declarado por el agente merece menos confianza que uno observado por el gateway de ejecución o el sistema operativo.

No conviertas en silencio la identidad del proceso en identidad humana. Una autoridad de firma de código puede indicar quién firmó un binario. Una cuenta local puede indicar el contexto del sistema operativo que lo inició. Ninguna demuestra qué empleado escribió el prompt, aprobó cada acción o pretendía ejecutar un comando concreto. Si el control exige atribución humana, une la sesión con registros de acceso del proveedor de identidad, gestión de dispositivos, aprobaciones, propiedad de tickets o asignación de estaciones controladas.

La misma cautela se aplica a las relaciones entre procesos. Un shell puede iniciar un agente, el agente puede iniciar un auxiliar y el auxiliar puede solicitar una acción SSH. Registra la cadena observada, pero define qué proceso es el sujeto del control. De otro modo, un equipo agrupará por el agente principal, otro por el auxiliar y la población de muestra cambiará a mitad de la auditoría.

Un objeto de sesión compacto puede hacer explícito el contrato de evidencia:

{"session_id":"ses_01JX...","host_id":"mac-042","started_at":"2026-07-21T14:03:18Z","ended_at":"2026-07-21T14:48:02Z","executable":"/usr/local/bin/agent","signing_authority":"Developer ID Application: Example","parent_pid":8821,"local_account":"builder","authorization":{"decision":"approved","method":"local_user_action","at":"2026-07-21T14:03:22Z"},"revoked_at":null}

Los puntos suspensivos indican que el ejemplo está abreviado, no un identificador aceptable para producción. La evidencia real necesita el valor completo y una regla de unicidad documentada. También necesita pruebas de sincronización horaria. Si las marcas de tiempo del endpoint, gateway, sistema de identidad y ticket se desvían, el auditor no puede reconstruir la secuencia con fiabilidad aunque cada fuente sea coherente internamente.

En Sallyport, el diario Sessions registra las ejecuciones de agentes, mientras que la aprobación de la primera llamada muestra primero la autoridad de firma de código del proceso y dura hasta que ese proceso termina. Es buena evidencia local de sesión, pero el equipo aún necesita registros externos si su control atribuye la acción a un empleado, dispositivo gestionado, cambio aprobado o acceso corporativo.

El resultado de una llamada necesita contexto para decidir

El registro de una llamada debe responder qué intentó el proceso, dónde lo intentó, qué referencia de credencial o clase de clave usó el gateway, si hacía falta aprobación, qué decisión ocurrió, si empezó la ejecución y cómo terminó. Captura marcas de tiempo y duración, canal, destino normalizado, tipo de acción, clase de resultado, clase de error y un identificador estable de correlación. Guarda suficiente detalle del comando o solicitud para investigar sin copiar secretos ni cuerpos de respuesta sensibles en la pista de auditoría.

El vocabulario de resultados debe ser estricto. «Denegado» significa que un control detuvo la ejecución antes de la acción externa. «Fallido» significa que la ejecución empezó, pero devolvió un error, agotó el tiempo o perdió el transporte. «Correcto» significa que la interfaz remota informó éxito según una regla documentada. «Desconocido» cubre el caso incómodo en que el cliente perdió la confirmación después de enviar la acción. Mezclar llamadas denegadas y fallidas en una sola categoría destruye la evidencia de que el control funcionó.

El estado HTTP por sí solo rara vez cuenta toda la historia. Una respuesta 200 puede contener un error de aplicación. Un 202 puede indicar que el trabajo solo quedó en cola. Un código de salida SSH cero indica que el shell remoto informó éxito, no que cambió el estado previsto del sistema. Define la normalización de resultados para cada tipo de acción y conserva el estado o código original junto al resultado normalizado.

Un registro práctico de llamada puede verse así:

{"call_id":"call_01JX...","session_id":"ses_01JX...","occurred_at":"2026-07-21T14:17:09Z","channel":"ssh","destination":"prod-web-03","action":"systemctl restart api","credential_ref":"ssh-prod-ops","approval":{"required":true,"decision":"approved","method":"touch_id"},"execution":{"started":true,"result":"failed","exit_code":1,"error_class":"remote_command_error","duration_ms":842},"ticket_ref":"CHG-1842"}

No registres un bearer token, una clave privada, el encabezado completo de autorización o una respuesta sin procesar solo para que la evidencia parezca completa. Un registro de auditoría que filtra secretos crea otro fallo de control. Usa una referencia estable de credencial y registra el método de inyección, manteniendo el material secreto fuera del agente y de la evidencia exportada.

Para CC7.1, los revisores pueden correlacionar llamadas capaces de cambiar configuración con desviaciones, despliegues y hallazgos de vulnerabilidad. Para CC7.2, pueden seleccionar acciones denegadas, fallidas, desconocidas, con destinos inusuales o de alto riesgo. El registro solo respalda esos procedimientos si la organización puede enumerar toda la población. Una captura de cinco eventos interesantes demuestra que existieron cinco eventos, no que se consideraron todos los relevantes.

Las verificaciones de integridad prueban coherencia, no verdad

Una cadena de hashes puede detectar eliminación, inserción, reordenamiento o modificación después de que los registros entran en la cadena, siempre que el verificador parta de un formato y ancla confiables. No demuestra que la fuente capturara todas las acciones, que cada campo fuera correcto al escribirse ni que un atacante nunca eludiera el registrador. Esta es la distinción más importante: la integridad de los registros no equivale a la integridad de la recopilación.

El almacenamiento cifrado de escritura ciega reduce la posibilidad de que un lector o una ruta de análisis comprometida reescriba entradas anteriores. El cifrado protege la confidencialidad. El encadenamiento protege una continuidad verificable. Las claves respaldadas por hardware pueden reforzar el control de acceso. Estos mecanismos responden preguntas de auditoría distintas, así que documéntalos por separado en vez de llamar «inmutable» al diseño completo.

Un procedimiento de integridad necesita entradas repetibles y resultados conservados. Con Sallyport, un revisor puede verificar la cadena cifrada sin conexión y sin una clave:

$ sp audit verify /evidence/agent-audit-2026-07.splog
verified: 18432 records
first: 2026-07-01T00:01:44Z
last: 2026-07-31T23:58:10Z
chain: valid

La salida exacta debe proceder de la versión instalada. La forma anterior define qué debe guardar el paquete: comando, versión de la herramienta, identificador o resumen del archivo, cantidad de registros, límites de tiempo, resultado, hora de ejecución y operador. Si el comando real emite otras etiquetas, conserva su salida en lugar de reescribirla para que coincida con el ejemplo.

Ejecuta una prueba negativa antes de confiar en el procedimiento. Copia una exportación que no sea de producción, modifica o elimina un registro con una prueba preparada por ingeniería y confirma que la verificación falla. Conserva el método, el fallo esperado, la salida real, la versión y la aprobación del revisor. Una verificación correcta muestra que un archivo pasó; una prueba negativa controlada muestra que el verificador detecta la alteración que afirmas detectar.

También reconcilia los límites. Compara el último recuento y el ancla de una exportación con el estado inicial esperado de la siguiente. Investiga huecos, reinicios, reinstalaciones, saltos de reloj y sustituciones de hosts. Si los administradores locales pueden borrar todo el registro y su ancla, la cadena puede validar fielmente solo el historial sustituto. Envía anclas, resúmenes o recibos firmados a una ubicación con control separado con la frecuencia que exija el riesgo.

NIST Special Publication 800-92 recomienda proteger la integridad de los registros archivados y verificar los registros transferidos, normalmente comparando resúmenes. Ese consejo sigue siendo válido, pero un resumen o cadena no reemplaza el monitoreo de cobertura de fuentes. Úsalo para hacer visibles los fallos de transferencia y conservación, y después prueba que todas las fuentes dentro del alcance reportan.

La conservación parte del periodo y la investigación

SOC 2 no asigna una cantidad universal de días a la evidencia CC7.1 o CC7.2. Define la conservación a partir del periodo de auditoría, obligaciones contractuales y legales, necesidades de investigación, demora de detección, sensibilidad del almacenamiento y tiempo para producir una muestra. La política debe nombrar clases de eventos, ubicación, responsable, restricciones de acceso, eliminación y proceso de excepciones.

En un examen Type 2, el auditor prueba la operación durante un periodo. Si el equipo conserva solo una parte reciente del historial local, quizá no pueda respaldar muestras del inicio ni mostrar continuidad. Conserva evidencia durante todo el periodo, la preparación, el trabajo de campo y un margen razonable para seguimiento. Pide al área legal o al responsable de cumplimiento que determine obligaciones más largas, en vez de copiar la duración del informe de otra empresa.

La conservación únicamente local tiene un fallo previsible. Se sustituye un portátil en abril, desaparece su diario y la muestra de octubre incluye febrero. El equipo tiene una cadena perfecta para el nuevo dispositivo y ninguna evidencia de la fecha elegida. Exporta registros y anclas a almacenamiento controlado por la organización según un calendario definido, y conserva prueba de que las exportaciones programadas se ejecutaron.

Prueba la recuperación, no solo la configuración. Elige una fecha temprana, localiza la población de sesiones, recupera las llamadas, verifica la integridad y conecta un evento con su resolución de revisión. Registra el tiempo y los fallos. Una captura de configuración muestra diseño. Recuperar con éxito un periodo antiguo demuestra operación.

La privacidad y la seguridad siguen aplicándose. Comandos, destinos, cuentas locales y errores pueden contener datos personales o detalles sensibles. Restringe el acceso, redacta copias exportadas según una regla documentada y conserva una fuente sin redactar solo cuando esté autorizado. La redacción no debe alterar el orden ni invalidar la ruta de verificación sin preservar un original verificable de forma independiente.

La frecuencia de revisión debe dejar pruebas

Un control de revisión funciona cuando un rol designado examina una población definida con una frecuencia declarada, aplica criterios escritos y registra el resultado. «Los registros se revisan periódicamente» no se puede muestrear con confianza porque nadie sabe qué significa periódicamente ni qué registros cuentan. Una revisión diaria en días hábiles puede encajar con acciones en producción. La aprobación por llamada puede servir para unas pocas claves potentes. Una revisión semanal de tendencias puede encajar con destinos de desarrollo de menor riesgo. La evaluación de riesgos debe explicar la elección.

Separa la aprobación preventiva de la revisión de detección. La aprobación decide si una acción puede avanzar. La revisión pregunta si las acciones permitidas, denegadas, fallidas y eludidas indican una anomalía o un problema de control. Aprobar una llamada arriesgada no demuestra que alguien revisara luego el resultado, correlacionara llamadas relacionadas o reconociera una sesión comprometida.

Define los selectores de revisión en lenguaje claro antes de elegir la herramienta. Un procedimiento puede seleccionar todos los result iguales a failed o unknown, todas las aprobaciones denegadas, cada destino nuevo, todos los usos de credenciales de producción designadas, sesiones iniciadas por una autoridad de firma desconocida y cualquier fallo de integridad. El revisor marca cada elemento como esperado, problema operativo, desviación de política o posible evento de seguridad. Los eventos sospechosos reciben un identificador y una hora de escalamiento.

Conserva evidencia de resultados cero. En un día tranquilo, la consulta guardada, ventana cubierta, hora de ejecución, identidad del revisor y recuento cero demuestran que se ejecutó el procedimiento. Un mes con tickets solo para hallazgos positivos genera dudas sobre los días sin tickets. Los auditores muestrean la ejecución del control, no solo los casos llamativos.

La evidencia de revisión debe incluir:

• La consulta de población o criterios de exportación y su versión.
• Las horas inicial y final, zona horaria y cantidad de registros.
• La identidad del revisor, hora de finalización y explicación de retrasos.
• Cada anomalía elegida, su resultado y justificación.
• Referencias a tickets de incidente, cambio o problema si hubo escalamiento.

No dejes que quien produce los eventos sea el único que revise su historial. Un equipo pequeño quizá no tenga separación completa, pero puede aplicar una revisión compensatoria por otra persona, inspección periódica de dirección y exportaciones bajo control separado. Describe la situación real. Una segregación inventada es peor que una limitación honesta con un control compensatorio razonable.

La frecuencia también se aplica a la salud del control. Confirma en intervalos definidos que los hosts esperados produjeron registros, las exportaciones terminaron, los relojes siguieron sincronizados, las verificaciones pasaron, los selectores aún coinciden con el esquema y los revisores cerraron sus colas. Un cambio de esquema puede romper en silencio una consulta que parece sana. Incluye un evento de prueba conocido o un límite de recuento para advertir cuando la canalización deja de seleccionar elementos.

CC7.2 exige analizar las anomalías para decidir si son eventos de seguridad. Cerrar un ticket como «falso positivo» sin explicar por qué no demuestra análisis. El registro debe decir qué ocurrió, por qué amenazó o no los objetivos, qué evidencia apoyó la decisión, quién la tomó y si el seguimiento cambió un detector o procedimiento.

Organiza el paquete según afirmaciones y muestras

Un auditor suele pedir primero evidencia de diseño y luego evidencia operativa de fechas o eventos seleccionados. Organiza los registros locales de modo que cada artefacto responda una afirmación de control. No entregues un archivo bruto esperando que el auditor descubra tu control dentro.

Usa este mapa como índice de trabajo:

Para cada control, mantén una definición de una página con redacción, responsable, frecuencia, población de sistemas y eventos, procedimiento, artefactos esperados, ubicación y excepciones. Añade un diccionario para cada columna exportada. El auditor no debe adivinar si actor significa empleado, cuenta local, proceso o autoridad de firma.

Prepara dos rutas de muestra. La primera empieza con una fecha al azar y demuestra que la revisión completa se ejecutó a tiempo. La segunda empieza con una llamada de alto riesgo y retrocede a la autorización de sesión, luego avanza al resultado remoto, revisión y cualquier ticket. Una muestra de fecha prueba la operación recurrente; una muestra de evento prueba trazabilidad.

Reconcilia totales en cada transferencia. El recuento del diario Sessions debe coincidir con la exportación bajo los filtros documentados. Los recuentos de llamadas deben coincidir antes y después del traslado. Las entradas de revisión deben cuadrar con elementos seleccionados, excluidos y pendientes. Explica diferencias legítimas como entornos de prueba, exclusiones aprobadas, reintentos duplicados o registros fuera de la ventana.

Un informe Type 1 evalúa el diseño en un momento concreto. Un Type 2 también evalúa si los controles operaron durante el periodo declarado. Una captura actual, una verificación reciente o un procedimiento recién escrito pueden apoyar el diseño Type 1, pero no recrean meses de operación Type 2 faltante. Si no existe el historial, declara la carencia y ajusta el calendario en lugar de crear firmas retrospectivas.

Antes del trabajo de campo, pregunta cómo quiere el auditor recibir evidencia cifrada o sensible, qué atributos espera y si elegirá fechas, sesiones, llamadas o alertas. Esa conversación cambia el empaquetado, no el control. El control debe operar de forma coherente antes de recibir la muestra.

Recopila cobertura y respuesta en otros sistemas

Los registros locales solo cubren acciones que pasan por la ruta local. No prueban que todos los cambios de producción usen esa ruta. Los administradores pueden usar consolas en la nube, SSH directo, credenciales CI/CD, canales de soporte, cuentas de emergencia, tareas programadas u otra estación. Haz un inventario de rutas de cambio y acceso, y llévalas al control o recopila sus registros por separado.

CC7.1 necesita evidencia adicional:

• Inventario actual de activos y software ligado al alcance.
• Normas de configuración y versiones base aprobadas.
• Configuración, cobertura, resultados y salud del análisis de vulnerabilidades.
• Un proceso para avisos nuevos y correspondencia de componentes afectados.
• Tickets de corrección, aceptaciones de riesgo, plazos, nuevas pruebas y excepciones.

Una llamada de agente que instala la versión X es evidencia útil del cambio. No informa que X se volvió vulnerable tres semanas después. El sistema de vulnerabilidades, la entrada de avisos, el inventario y la corrección deben aportar esa historia.

CC7.2 también necesita fuentes más amplias. Recopila telemetría de endpoint, identidad, red, plano de control de nube, aplicaciones, bases de datos y disponibilidad según los riesgos. Conserva definiciones de detección, inventarios de fuentes activas, pruebas de rutas de alertas, turnos o revisores, historial de alertas, resoluciones, incidentes y acciones posteriores. La cobertura de desastres naturales y errores puede necesitar alarmas de disponibilidad y continuidad que un gateway de acciones no ve.

Prueba la integridad mediante reconciliación. Compara dispositivos gestionados con los que exportan registros, credenciales de producción con las disponibles en el gateway y cambios de nube con llamadas y automatización aprobada. Investiga discordancias en ambos sentidos: un cambio remoto sin llamada puede indicar una evasión; una llamada correcta sin el cambio esperado puede indicar mala normalización o reversión.

Recopila también evidencia de gobierno. La evaluación de riesgos debe explicar por qué las acciones de agentes importan para CC7.1 y CC7.2. Las políticas asignan responsabilidades de registros, vulnerabilidades, monitoreo, revisión, incidentes y conservación. La capacitación cubre a quienes aprueban y revisan. Las revisiones de acceso muestran quién puede leer, exportar, administrar o borrar evidencia y quién puede cambiar la lógica de detección.

NIST Special Publication 800-92 trata la gestión de registros como generación, transmisión, almacenamiento, análisis y eliminación. Ese ciclo pone a prueba el pensamiento exclusivamente local. Si el diseño resuelve generación y almacenamiento pero omite transmisión, análisis y eliminación, sigue incompleto aunque la criptografía sea sólida.

Mantén un registro explícito de carencias con sistema sin cobertura, periodo faltante, control afectado, riesgo, procedimiento provisional, responsable y fecha objetivo. Los auditores no esperan que un pequeño registro observe toda la empresa. Sí esperan que la dirección conozca el alcance y no haga afirmaciones que la evidencia no sostiene.

Usa los registros como componente limitado y comprobable

Los registros locales merecen usarse cuando la declaración coincide con lo que observan. Pueden dar evidencia detallada de sesiones y llamadas, conservar intentos denegados que el sistema remoto nunca recibe y hacer detectables los cambios posteriores. Son especialmente útiles para agentes de IA porque las API remotas suelen ver una identidad de servicio compartida y perder el contexto del proceso local.

Se debilitan cuando el equipo exagera la identidad, ignora rutas alternativas, conserva datos solo en endpoints sustituibles o confunde una cadena válida con monitoreo completo. La solución no es otro adjetivo criptográfico. Es una afirmación menor, una población documentada, revisión recurrente, resultados de verificación conservados por separado y uniones con sistemas autoritativos.

Antes de confiar en los registros, ejecuta una prueba integral con un evento sembrado. Inicia una sesión identificable, intenta una acción aprobada y otra denegada, confirma ambos resultados, exporta el periodo, verifica la cadena, ejecuta el selector, registra la resolución y reconcilia el evento remoto. Repite luego la recuperación para un periodo antiguo. Cada ruptura es una carencia real.

Entrega al auditor el resultado de la cadena, pero también el inventario de fuentes, selector, prueba de revisión, excepciones y corroboración externa. Ese paquete respalda un control CC7.1 o CC7.2 defendible. La cadena sola respalda únicamente la afirmación modesta de que el historial local suministrado conserva la estructura que esperaba el verificador.