La gobernanza es la forma en que una organización decide qué debe lograr la seguridad, quién rinde cuentas y cómo sabrá si está funcionando. En el nivel de SecurityX se espera que pienses como la persona que diseña esa estructura, no solo como quien la sigue. Las partes escritas de la gobernanza forman una jerarquía, y las preguntas del examen a menudo dependen de ubicar un requisito en el nivel correcto.
Una política (policy) es una declaración breve, de alto nivel y obligatoria de la intención de la dirección, aprobada por la alta gerencia o la junta directiva. Por ejemplo: 'Todos los datos sensibles deben cifrarse en reposo y en tránsito'. Las políticas cambian pocas veces porque requieren aprobación ejecutiva. Un estándar (standard) hace que la política sea medible y específica, por ejemplo: 'Usa AES-256 para datos en reposo y TLS 1.2 o posterior para datos en tránsito'. Los estándares también son obligatorios, pero el equipo de seguridad puede actualizarlos a medida que cambia la tecnología sin volver a la junta directiva.
Un procedimiento (procedure) es la instrucción paso a paso para realizar una tarea de forma consistente, como la manera de solicitar y aprobar un cambio en el firewall o de rotar la clave de una cuenta de servicio. Una guía (guideline) es un consejo recomendado y opcional, por ejemplo, formas sugeridas de crear una frase de contraseña robusta. Una línea base (baseline) es una configuración mínima para una clase de sistemas, a menudo derivada de un benchmark como un CIS Benchmark.
Los marcos de gobernanza vinculan estos documentos con un programa. Definen órganos de supervisión (un comité directivo de seguridad, un comité de riesgos de la junta), estatutos que otorgan autoridad a la función de seguridad y un ciclo de establecer objetivos, medir y revisar. Marcos como ISO/IEC 27001, el NIST Cybersecurity Framework y COBIT dan una estructura para que no tengas que inventar el programa desde cero.
Los buenos documentos de gobernanza tienen un responsable, un ciclo de revisión (normalmente anual), control de versiones, un proceso de excepciones con fechas de vencimiento y controles compensatorios, y un vínculo claro con los riesgos o regulaciones que atienden. Sin un proceso de excepciones, las personas esquivan la política de manera informal y pierdes visibilidad del riesgo real.
Términos clave
- Policy (política)
- Declaración de alto nivel y obligatoria de la intención de la dirección, aprobada por la alta gerencia.
- Standard (estándar)
- Requisito obligatorio, específico y medible que respalda una política, como un algoritmo o una configuración requerida.
- Procedure (procedimiento)
- Instrucciones paso a paso para realizar una tarea de forma consistente.
- Guideline (guía)
- Consejo recomendado pero opcional que ayuda a las personas a cumplir una política.
- Policy exception (excepción a la política)
- Aprobación documentada y con límite de tiempo para desviarse de un requisito, normalmente con controles compensatorios.
La junta directiva de un banco aprueba una política que exige autenticación robusta para el acceso remoto. El equipo de seguridad publica un estándar que requiere MFA resistente al phishing (FIDO2) para los administradores y MFA basada en app para el resto del personal, además de un procedimiento para registrar nuevas llaves de seguridad. Cuando una aplicación heredada no puede soportar MFA, su responsable presenta una excepción que vence en seis meses y agrega restricciones por IP como control compensatorio.
Comprueba lo que sabes
¿Dónde debe documentarse el requisito 'TLS 1.2 o posterior'?
En un estándar, porque es un requisito específico y medible que respalda una política de cifrado de mayor nivel y puede cambiar con el tiempo.
¿Por qué importa un proceso de excepciones a la política?
Permite desviaciones controladas, documentadas y con límite de tiempo, con controles compensatorios, de modo que el riesgo sea visible en lugar de que las personas eludan la política de manera informal.