El auditor pide una política de auditoría de seguridad para AWS: ¿qué debe contener realmente?

Para un auditor la cosa es simple: la política dice 'qué hay que hacer', el procedimiento explica 'cómo hacerlo' y la evidencia demuestra que 'se ha hecho'. Lo que os piden es el primer paso. En el documento ponéis 'nuestra empresa exige MFA por hardware o software a todos los usuarios de AWS' y luego presentáis como prueba la tabla de estado de MFA del panel de IAM.

Lo primero que buscan los auditores corporativos en el documento son estos cuatro puntos: 1) Cómo se protegen los registros de CloudTrail contra eliminación. 2) Quién accede al entorno de producción y mediante qué mecanismo de aprobación. 3) En cuántos días como máximo se aplican los parches de seguridad. 4) La cláusula que garantiza que el acceso a AWS de los ex empleados se revocará el mismo día de su salida.

El trimestre pasado pasamos por una auditoría similar para un cliente financiero con un presupuesto de 80.000 $. Preparamos un documento de política sencillo de 6 páginas. Tras leer la política, el auditor solo pidió evidencia en vivo de dos cosas: la última fecha de inicio de sesión de la cuenta Root y las alarmas de acceso no autorizado configuradas en CloudWatch. Si ambas están bien, el proceso se suele aprobar en 48 horas.

No te compliques redactando desde cero. Busca en internet el título CIS AWS Foundations Benchmark. Pasa los puntos de control de esta guía a un archivo Word y conviértelos en las reglas internas de tu empresa. Ponle el nombre de la empresa y el número de versión en el título y fírmalo en PDF.

La trampa más grande aquí es copiar y enviar plantillas corporativas de 30 páginas descargadas de internet. Si pones en el documento "se realizan escaneos de vulnerabilidades cada semana" y no lo haces, el proceso de venta se cae en cuanto el auditor pida pruebas. Escribe solo lo que puedas cumplir; que sea poco, pero real.

En nuestra primera auditoría corporativa pusimos en la política que "las claves de acceso se renuevan cada 90 días". Vino el auditor, vio que una clave de API en el sistema llevaba 410 días activa y nos puso directamente una nota de no conformidad en el informe. El trato se retrasó un mes. Por eso cada frase escrita tiene que reflejarse tal cual en el panel.

Esto es totalmente un documento Word/PDF, no es código técnico; declaras en lenguaje formal tus reglas de infraestructura y tu disciplina de registros.

Es fundamental que el texto a preparar sea compatible con los procesos de gestión de seguridad de la información de la empresa. La inclusión de la fecha de entrada en vigor, el número de revisión y la firma de aprobación de la alta dirección en el documento constituye un requisito desde el punto de vista de los estándares de auditoría.

Permíteme resumir lo que se ha dicho hasta ahora. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro. Ánimo.

Tiene razón. Todo lo que no está por escrito ambas partes lo recordarán de forma distinta en el futuro.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Muchas gracias, lo probaré hoy.

Gracias por escribir esto, es lo correcto. Si regañas las falsas alarmas, nadie volverá a reportar.

Yo seguiría por ese camino.

Lo probaré.

correcto.

Exactamente así. El tiempo que tardas en detectar un problema determina directamente su coste.

Yo pasé por esto, déjenme contarlo. Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después.

Espero que le sea útil.

exacto y encima no es tan conocido y la verdad la respuesta varía muco según el sector, no hay una regla general.

por supuesto, cambia si tu situación es diferente.