Al lío…
Como indicábamos en el anterior post, implementar la ISO 27001, se va a fijar en el trato de los datos que maneja la empresa mediante documentación y evidencias de que la documentación se cumple.
La normativa se divide en temáticas, que contienen controles más o menos concretos.
Se cubre tanto la parte legal y operativa de la empresa, como la técnica, sin ser ninguna de las partes menos importante que la otra.
A continuación destacamos algunos controles críticos a nivel técnico de la ISO 27001 con preguntas que debemos ser capaces de responder para superar la auditoría:
Plan de acción en caso de desastre, también conocido como DRP (Disaster Recovery Plan) o plan de contingencia
- ¿Cada cuánto se realizan simulaciones de caída del CPD?
- ¿Cuánto se tarda en restablecer el servicio?
- ¿Qué aplicaciones/servicios se prueban en estas simulaciones?
- ¿Se registran los resultados obtenidos en estos simulacros especificando la fecha y servicios testeados?
Gestión de usuarios
- ¿Cuál es el flujo de alta/baja de usuarios?
- ¿Qué criterio se sigue para otorgar permisos a un usuario?
- ¿Hay segregación de roles?
- ¿Se comprueba periódicamente que los usuarios mantienen o cambian su nivel de permisos?
Documentación interna
- ¿Están los procesos productivos correctamente documentados?
- ¿La documentación está a disposición de los usuarios que la necesiten y saben dónde encontrarla?
Incidencias de seguridad
- ¿Hay un procedimiento técnico y legal que recoja qué es una incidencia de seguridad
- ¿Cómo se gestiona a ambos niveles y qué pasos se deben dar para notificarla?
- ¿Se ha producido alguna incidencia de seguridad?
- Si es así ¿Qué se ha aplicado para evitar que se vuelva a producir?
Securización de la plataforma
Este punto es muy amplio, ya que abarcaría el desarrollo, los servidores, las comunicaciones, los backups, el intercambio de información… Cubriendo ligeramente estos aspectos, tendríamos las siguientes preguntas:
- ¿Se subcontrata el desarrollo de software?
- ¿Es el entorno de desarrollo seguro (herramientas, equipos, instalaciones)?
- ¿Qué pruebas se hacen a nivel de desarrollo previas al despliegue?
- ¿Quién puede desplegar software en producción?
- ¿Cuál es el procedimiento de control de cambios?
- ¿Hay separación total de entornos (producción y desarrollo)?
- ¿Son entornos completamente independientes a todos los niveles?
- ¿Se actualizan periódicamente los sistemas/servicios para corregir vulnerabilidades?
- ¿Cada cuánto se hacen?
- ¿De qué mecanismos se dispone para estar informado de vulnerabilidades?
- ¿Cómo se intercambia información en la empresa? (por correo electrónico, por USB, por Dropbox, etc?
- ¿Los medios utilizados para el intercambio de información son considerados seguros?
Por lo tanto, antes de empezar a documentar como locos (porque esto de lo que va es de tener todo planificado en forma de políticas y procedimientos):
Tener claro qué es lo que se está haciendo ya y revisar qué hay documentado.
Primero y, bajo mi punto de vista, crucial. Antes de buscar una manera nueva de hacerlo, veamos si lo que tenemos sirve. Y si es así, pues documentemos lo que hay, si no está hecho ya.
Una cosa muy simple, pero que no siempre es evidente, es que los controles son bastante concisos.
No nos empecemos a liar haciendo más de lo que se especifica, ya que nos cargamos de trabajo que puede ser innecesario, si hay una base que no es correcta.
Redactar, lo que no esté documentado, teniendo en mente el control que queremos evidenciar.
Por lógica, sería el siguiente paso. En algún punto serán necesarios registros que acrediten que estamos haciendo algo de esa manera.
Para ello es importante apoyarnos en un sistema de tickets y registrar altas/bajas/modificaciones de usuarios o cambios de contraseña, por ejemplo.
Aunque pueda parecer que tardamos más en crear un ticket que en hacer la tarea en sí, es muy beneficioso de cara a evidenciar los cambios que se han hecho en el entorno.
Definir controles, aplicarlos y evidenciarlos
Ahora nos queda lo más difícil. Lo que nos queda son, en mayor medida, controles que no sabíamos ni que existían. Y tenemos que definirlos, aplicarlos y evidenciarlos.
En este punto, vamos a introducir un documento básico en la ISO 27001, la declaración de aplicabilidad (SOA).
En la declaración de aplicabilidad vamos a tener, para cada control, el documento vinculado que lo detalla (en caso de que aplique), en qué estado está (si está o no implantado) y su responsable.
De esta manera tenemos, a simple vista, un cuadro con todo lo que tenemos hecho y qué nos queda por hacer.
Después de toda esta información… ¿Cómo empezar?
De una manera similar a como plantearíamos un examen.
Primero, lo que sabemos que está bien, documentarlo si no está, retocarlo y ampliarlo (sólo si vemos que no cumple con todo lo que indica el control).
Posteriormente, si tenemos que definir un control de 0, aplicar lo que sea más cercano a nuestra plataforma, ciñéndonos a lo que pide el control, sin documentar nada que no seamos capaces de hacer.
Recordemos que todas las empresas no tienen el mismo nivel de recursos y, sin embargo, pueden implementar la ISO 27001 tanto un banco como una pyme, por lo que no nos compliquemos la vida sin motivo.
Lo que es importante aquí es que las políticas y procedimientos que entreguemos se lleven a cabo y puedan ser evidenciadas, no vale de nada documentar algo que no se va a poder aplicar.
En el siguiente post sobre “cómo implementar la ISO 27001” hablaremos de la última fase, la preparación de la auditoría y la auditoría en sí.