El Marco del Auditor: Pensar Como un Auditor de SI

A un auditor de SI no se le contrata para encontrar cada bug o misconfiguration en un sistema. El trabajo es más estrecho y, honestamente, más difícil: determinar si los controles implementados proporcionan una seguridad razonable de que los riesgos para el negocio están gestionados. Esa distinción cambia cómo abordas casi cada tarea, desde leer un conjunto de reglas de firewall hasta entrevistar a un propietario del sistema.

Riesgo primero, tecnología después

Un penetration tester pregunta "¿puedo romper esto?" Un auditor pregunta "¿importa esto, y si falla, qué le sucede al negocio?" Antes de tocar un solo control, un auditor intenta entender qué hace el sistema, qué datos toca, y qué saldría mal si la confidentiality, integrity o availability se vieran comprometidas. Por eso los programas de auditoría generalmente comienzan con una evaluación de riesgos o un walkthrough, no con un vulnerability scan.

Concretamente: si estás auditando controles de acceso en un sistema de nómina, la primera pregunta no es "¿está MFA habilitado?" Es "¿cuál es el impacto si una persona no autorizada puede cambiar datos de salario o ver PII?" Una vez que conoces el impacto, puedes juzgar si los controles existentes (MFA, workflows de aprobación, segregación de funciones) son proporcionales.

Evidencia sobre aseveración

Los propietarios del sistema te dirán que las cosas funcionan. El trabajo de un auditor es verificar, no confiar. Esto significa pedir artefactos: una captura de pantalla de una pantalla de configuración, una exportación de derechos de acceso de usuarios, un ticket de cambio con timestamps de aprobación, registros mostrando que un control realmente se activó. Si alguien dice "revisamos el acceso trimestralmente," el auditor pide ver los últimos tres registros de revisión, no solo la política que lo ordena.

Este hábito basado en evidencia es lo que separa un hallazgo de auditoría de una conversación en el pasillo. Un hallazgo necesita sobrevivir al escrutinio: qué fue probado, qué población fue muestreada, qué criterios fueron usados, y qué fue realmente observado. Declaraciones vagas como "los controles parecen adecuados" no se sostienen en un informe que la gerencia y los reguladores leerán.

Diseño vs. efectividad operativa

Una de las divisiones mentales más útiles en este campo es separar el diseño del control de la operación del control. Una política de contraseña que requiere 14 caracteres y MFA está bien diseñada sobre el papel. Pero si la última revisión de acceso fue hace 11 meses, o si las cuentas de servicio están exentas sin documentación, el control no está operando como se pretendía. Los auditores prueban ambos: ¿existe el control como se describe, y ¿realmente se está siguiendo día a día?

Por eso el muestreo importa. Probar el acceso de un usuario no te dice mucho. Extraer una muestra de 25 empleados despedidos y verificar si sus cuentas fueron deshabilitadas dentro de la ventana SLA (digamos, 24 o 48 horas) te da una base defendible para una conclusión.

Segregación de funciones como tema recurrente

Una enorme parte de los hallazgos de auditoría se remontan a segregación de funciones (SoD): la misma persona que solicita un cambio también lo aprueba, o un desarrollador tiene acceso directo a la base de datos de producción junto con derechos de deployment. Los auditores buscan estos solapamientos constantemente, porque las fallas de SoD son cómo el fraude y los errores no intencionales se cuelan sin que un segundo par de ojos los atrape.

Al revisar un entorno, pregunta: ¿quién puede iniciar una acción, quién puede aprobarla, y quién puede ejecutarla? Si una persona mantiene dos o más de esos roles sin un control compensatorio (como logging detallado revisado por alguien más), ese es un gap que vale la pena documentar.

Escribir hallazgos que se corrijan

Un hallazgo técnicamente correcto que nadie actúa es una auditoría desperdiciada. Buenos hallazgos establecen la condición (qué fue observado), los criterios (la política o estándar que viola), la causa (por qué sucedió), y el efecto (qué riesgo esto crea) — la estructura de los 4C clásica que muchos auditorios usan. Los hallazgos vagos como "los controles de acceso necesitan mejora" se ignoran. Los específicos como "14 de 25 empleados despedidos muestreados retuvieron acceso VPN por más de 5 días después de su fecha de terminación, violando el SLA de desprovisión de 24 horas en la política SEC-014" se remedian porque el propietario sabe exactamente qué corregir.

Desarrollar el hábito

Desarrollas este marco practicándolo en sistemas ordinarios, no solo en compromisos formales. Elige una aplicación que uses diariamente y pregunta: ¿cuál es el riesgo si falla, qué controles existen, y cómo probaría que funcionan? Haz esto suficientes veces y el instinto del auditor — escepticismo emparejado con una demanda de evidencia — se vuelve automático.

Si este tipo de pensamiento de control y riesgo te interesa, revisa los segmentos de Korra Studio sobre modelos de control de acceso y marcos de gobernanza de seguridad para una base técnica más profunda.