Las medidas de control de accesos de la norma ISO 27001 están orientadas a controlar y monitorizar los accesos a los medios de información de acuerdo a las políticas definidas por la organización.
Citando la norma:
Objetivo 1:
Requisitos de negocio para el control de acceso
Limitar el acceso a la información y a las instalaciones de procesamiento de información.
Controles:
- 9.1.1 Política de control de acceso
- 9.1.2 Acceso a las redes y a los servicios de red
Objetivo 2:
Gestión del acceso de usuarios
Asegurar el acceso de usuarios autorizados y prevenir el acceso no autorizado a los sistemas y servicios de información.
Controles:
- 9.2.1 Registro de usuarios y cancelación del registro
- 9.2.2 Gestión de acceso a los usuarios
- 9.2.3 Gestión de derechos de acceso privilegiados
- 9.2.4 Gestión de la información de autenticación secreta de los usuarios
- 9.2.5 Revisión de derechos de acceso de usuario
- 9.2.6 Remoción o ajuste de los derechos de acceso
Objetivo 3:
Responsabilidades del usuario
Hacer a los usuarios responsables de salvaguardar su información de autenticación.
- 9.3.1 Uso de la información de autenticación secreta
Objetivo 4:
Responsabilidades del usuario
Impedir el acceso no autorizado a los sistemas y las aplicaciones.
- 9.4.1 Restricción de acceso a la información
- 9.4.2 Procedimientos de conexión (log-on) seguros
- 9.4.3 Sistema de gestión de contraseñas
- 9.4.4 Uso de programas de utilidad privilegiados
- 9.4.5 Control de acceso al código de programas fuente
Objetivo 1: Requisitos de negocio para el control de acceso
Para este objetivo de limitar el acceso a la información únicamente personas autorizadas
Tiene los siguientes controles:
9.1.1 Política de control de acceso
Requisitos para definir las reglas de control de acceso a la información, o sea los derechos y restricciones de acceso a la información
El requisito exacto de este punto, especifica la necesidad de establecer, documentar y revisar la política de control de acceso periódicamente, lo que significa que una política documentada es obligatoria.
Los propietarios de los activos son los que deben determinar estas normas o políticas de control de acceso de acuerdo con la política de seguridad de la información y el análisis de riesgos
El principio básico para la elaboración de estas reglas es:
- La asignación de la menor cantidad de privilegios posibles para llevar a cabo una tarea dentro de un sistema de información
- La concesión de esos privilegios solamente por el tiempo que sea necesario para el desarrollo de las tareas
En otra forma de explicarlo, se deben asignar los permisos de acceso limitados solamente a la información necesaria para hacer un trabajo, tanto a nivel físico (accesos a instalaciones o soportes de información), como lógicos (Accesos a aplicaciones).
Aunque nos hemos referido tanto a permisos del tipo lógico como físico, este apartado solamente se refiere a los accesos a nivel lógico aunque ambos deben ir a la par y basarse en los mismos principios.
Otro principio a tener en cuenta en la elaboración de las políticas de control de acceso es el siguiente:
El objetivo de la política de control de acceso debería ser que todo está prohibido a menos que esté expresamente permitido y no al revés
Profundicemos un poco más en todo esto para ver como aplicamos estos principios
ASIGNACION DE ROLES
Los roles dentro de un sistema de Información nos informan de lo que un usuario está autorizado a hacer dentro de un sistema y de lo que no le está permitido
CASO PRACTICO:
Por ejemplo:
Un rol de administrador dentro de un sistema de administración de páginas web CMS puede realizar funciones de editar código, instalar aplicaciones, modificar archivos CSS etc., mientras que un rol de colaborador solamente puede editar el contenido en modo texto de sus propios artículos y un rol de usuario registrado solamente puede acceder a visualizar determinados contenidos
Como podemos ver Cada rol no solo tiene una serie de privilegios distintos sino que además existe un mayor nivel de riesgo en un Rol de administrador que en un rol de colaborador. Es por ello que el nivel de confianza juega un papel importante en los requisitos que deberemos exigir a dichas funciones en relación a la Seguridad de la Información
De esta forma aplicando los principios sobre la asignación de privilegios deberemos hacernos estas preguntas antes de asignar privilegios a un usuario de sistemas de información: a visualizar determinados contenidos
Como podemos ver Cada rol no solo tiene una serie de privilegios distintos sino que además existe un mayor nivel de riesgo en un Rol de administrador que en un rol de colaborador. Es por ello que el nivel de confianza juega un papel importante en los requisitos que deberemos exigir a dichas funciones en relación a la Seguridad de la Información
De esta forma aplicando los principios sobre la asignación de privilegios deberemos hacernos estas preguntas antes de asignar privilegios a un usuario de sistemas de información:
- ¿Cuáles son los mínimos privilegios que puedo asignar a un puesto de trabajo con tal que le permita realizar sus tareas?
- ¿Durante cuánto tiempo es necesario que tenga estos privilegios?
- ¿Resulta pactico y es posible asignar estos privilegios solamente durante el tiempo que está realizando los trabajos?
¿Qué deberíamos incluir en un documento de política de acceso?
Ya hemos visto que la política debe considerar unos principios generales. Veamos ahora como elaborar en la práctica este documento
En primer lugar deberemos especificar la postura de su organización sobre los privilegios dentro de la política de control de acceso.
CASO PRACTICO:
Por ejemplo:
Un ejemplo de política de control de acceso ISO 27001 puede ser la gestión de los derechos de acceso del usuario donde se detalla el proceso:
- Emisión de los privilegios o cuentas de usuario
- Modificación de privilegios
- Revocación de privilegios
- Determinación del ciclo de vida del ID de usuario
Esto sería la documentación de la postura de la organización dentro de esta política específica
¡Importante!
La política sobre la seguridad de la información específica la postura de las organizaciones sobre lo que se tolera y lo que no se tolera, por lo tanto, no se trata de un documento de nivel de "cómo hacerlo" sino simplemente un conjunto de requisitos que la empresa debe cumplir.
Por ejemplo:
“Las cuentas de usuario solo se emitirán después de la aprobación formal de la gerencia de TI y de Recursos Humanos.”
Otro caso típico no lo encontramos en las reglas que rigen el proceso de emisión de permisos a cuentas de usuarios con altos privilegios. Este tema debería abordarse en una política específica de control de acceso, que está respaldada por procedimientos formales que guíen a los empleados en el proceso a seguir para emitir cuentas privilegiadas.
9.2.2 Gestión de acceso a los usuarios
Se trata de un requisito para la gestionar la autorización de los usuarios que acceden a los recursos de red
Para ello se exige como requisito elaborar una política específica para el uso de los recursos de red
Aunque este requisito o control está cubierto en gran parte por el punto anterior, la política de “gestión de acceso de usuarios de red” debe determinar a qué información se puede acceder, los procedimientos de autorización, los controles de gestión para la protección de las redes, las conexiones de red permitidas (p. Ej., No mediante wifi), los requisitos de autenticación y la supervisión del uso.
Un proceso de control de acceso robusto pasa por los siguientes puntos realizados según la secuencia de:
Identificación: métodos para proporcionar un sujeto (entidad que solicita acceso) con una identidad reconocible (por ejemplo, ID usuario o cuenta de usuario, IVA, número de seguro social, pasaporte, etc.).
Autenticación: métodos para garantizar que un sujeto sea quien dice ser (por ejemplo, contraseña, token, huella digital, etc.). Autorización: métodos para controlar qué acciones puede realizar un sujeto en un objeto (entidad a la que se accede) (por ejemplo, lista de permisos de materia y lista de permisos de objetos).
Con respecto a los métodos de autenticación, los siguientes conceptos (o factores) se pueden usar, por separado o en combinación:
- Algo que sabe un sujeto: por ejemplo, contraseñas y PIN. Este es el menos costoso de implementar y el menos seguro.
- lgo que tiene un sujeto: por ejemplo, tarjetas inteligentes, fichas, llaves, etc. Caro, pero seguro.
- Algo que un sujeto es: por ejemplo, patrones de voz, retina, huella digital, etc. Este es el más costoso de implementar, y el más seguro.
Por lo tanto, cuando hablamos de autenticación de dos factores, nos referimos a utilizar dos de estos tres conceptos para garantizar que el sujeto sea quien dice ser.
Finalmente la norma nos proporciona los elementos a considerar en la definición de la política de acceso de usuarios a la red.
La política debe identificar:
- La red y servicios a los cuales se accede
- Los procedimientos de autorización
- Que controles tienen estos procedimientos
- Los medios por los cuales se accede (VPN, Wifi etc.)
- Los requisitos de autenticación
- Como se supervisa el uso de los servicios de red
Objetivo 2 Gestión del acceso de usuarios
Controles para garantizar que solamente los usuarios autorizados acceden a los sistemas y servicios
9.2.1 Registro de usuarios y cancelación del registro
Se trata de un control para el alta y baja de los usuarios
Este control exige establecer un proceso de altas y bajas que permite los derechos de acceso teniendo en cuenta:
- Un registro de IDs o cuentas de usuario donde se vincula o identifica al usuario
- Los IDs deben desactivarse automáticamente o de forma inmediata cuando el usuario abandona la organización
- Eliminación periódica de usuarios redundantes
- Los IDs redundantes nunca pueden ser asignados a otros usuarios
- El proceso de cancelación debería tener en cuenta:
- La revocación del ID del usuario
- La revocación de los permisos del ID de usuario
9.2.2 Gestión de acceso a los usuarios
Se debe establecer un proceso formal para asignar y revocar los accesos a sistemas y servicios que:
- Incluya la aprobación del propietario del servicio o sistema
- Verifique si el acceso cumple con las políticas de acceso definidas
- Se garantice que el acceso no se da hasta finalizar el proceso de autorización
- Se mantiene un registro de los accesos concedidos
- Se eliminan los accesos de usuarios que han abandonado la organización
- Se modifican los accesos de usuarios que han cambiado de función o puesto de trabajo si proceda
- Se revisan periódicamente los derechos de acceso
9.2.3 Gestión de derechos de acceso privilegiados
El control de los derechos de acceso privilegiados debe realizarse de forma independiente mediante un proceso específico que:
- Tenga en cuenta las políticas de acceso privilegiado definidas
- Se identifiquen accesos privilegiados de cada sistema o proceso
- Se tenga en cuenta las reglas generales de mínimos privilegios
- Se establezca una norma de caducidad de los permisos privilegiados
- Se definan IDs especiales o distintos para las cuentas de uso normales o no privilegiadas
- Se definan procedimientos para evitar el uso no autorizado de cuentas con derechos de acceso privilegiados
- Se verifiquen periódicamente las competencias de los usuarios
- Considerar mecanismos para mantener la confidencialidad de los datos de acceso de usuarios genéricos para los usuarios privilegiados o mecanismos para forzar el cambio de contraseñas cuando un usuario privilegiado abandona o cambia de puesto de trabajo
9.2.4 Gestión de la información de autenticación secreta de los usuarios
Control para garantizar que se mantiene la confidencialidad de la información secreta de acceso (p. ejemplo contraseñas).
Gestionar la información de autenticación supone controlar:
- Incluir cláusulas en contratos y condiciones de puesto de trabajo sobre el mantenimiento del secreto de las contraseñas o información de autenticación
- Obligación de cambiar contraseñas iniciales después de su primer uso
- Identificar al usuario antes de entregar las contraseñas y obtener acuse de recibo
- Uso de contraseñas seguras, no compartidas
- Uso de medios seguros de comunicación (Correos cifrados etc.)
- Cambiar contraseñas a personal externo después de que han realizado sus trabajos (instalaciones de software etc.)
Nota: donde hablamos de contraseñas como medios comúnmente utilizados para la autenticación, pero donde pone contraseñas podemos referirnos también a otros medios de autenticación como claves criptográficas, tarjetas inteligentes etc.
9.2.5 Revisión de derechos de acceso de usuario
Control para establecer una revisión periódica de los permisos de accesos de los usuarios
- Revisar derechos de acceso a la terminación de empleo o cambios en la organización (cambios de empleo o promociones)
- Limitar en el tiempo los derechos de acceso con privilegios especiales
- Revisar las cuentas con privilegios especiales periódicamente y registrar los cambios que se realicen
9.2.6 Remoción o ajuste de los derechos de acceso
Control para garantizar que se modifican los derechos de acceso al:
- Finalizar el empleo
- Cambiar de puesto de trabajo dentro de la organización
Objetivo 3: Responsabilidades del usuario
El objetivo de este control es que los usuarios sean responsables de mantener a salvo sus contraseñas o información de autenticación
Para ello se establece el siguiente control
9.3.1 Uso de la información de autenticación secreta
Cada organización debe establecer normas para la utilización de contraseñas basando se en:
- Asegurar que las contraseñas no se divulguen
- Evitar el uso de registros de contraseñas (papel, archivos etc.)
- Políticas para cambiar las contraseñas ante amenazas
- Políticas para la calidad de las contraseñas
- Evitar el almacenamiento de contraseñas
- Forzar cambios de contraseñas iniciales
- Evitar compartir contraseñas para distintos usos
Objetivo 4: Control de acceso al sistema y a las aplicaciones
Se trata de prevenir accesos no autorizados a sistemas y aplicaciones con los siguientes controles:
9.4.1 Restricción del acceso a la información.
Las funciones de una aplicación o sistema deben considerar las restricciones de control de acceso determinadas por la política de control definido
Este sería un ejemplo de cuestiones a considerar:
CASO PRACTICO:
- Utilice menús para controlar el acceso a las distintas funciones
- Oculte las funciones de administración a los usuarios habituales
- Determine que datos son accesibles determinando que datos pueden estar disponibles para cada ID de usuario.
- Restringa de forma selectiva derechos de lectura / escritura / eliminación / ejecución etc.
- Limite el tipo de información de salida
Por ejemplo: Utilice gráficos que eviten el acceso a todo un archivo o carpeta - Considere accesos físicos o lógicos adicionales para sistemas o información altamente clasificados.
9.4.2 Procedimientos de conexión (log-on) seguros
Control para establecer inicios de sesión seguros
El inicio de sesión seguro debe ser capaz de corroborar la identidad del usuario.
Cuando la clasificación de la información lo requiera por política, se debe considerar la autenticación sólida por encima y más allá de la simple identificación de usuario y contraseña. (Controles adicionales físicos o lógicos)
El procedimiento de inicio de sesión no debe mostrar los identificadores del sistema o de la aplicación hasta que el inicio de sesión haya tenido éxito.
Un centro de datos seguro no puede anunciar su nombre en el exterior del edificio. ¡Tiene que saber que está allí para encontrarlo!
Los sistemas deberían mostrar advertencias evitando proporcionar mensajes de ayuda que podrían dar pistas a los usuarios no deseados.
Los formularios de acceso deben validarse solo cuando se han completado evitando mensajes de error con información y tener algún sistema para proteger múltiples intentos de acceso mediante "fuerza bruta"
Su departamento de TI debería registrar intentos fallidos y hacer que los administradores conozcan esta información.
Después del inicio de sesión con éxito, debería mostrarse un mensaje de intentos fallidos que le permiten al usuario detectar cualquier inicio de sesión inusual.
Las contraseñas no se deben transmitir en un formato no encriptado por razones obvias. De lo contrario le estamos dando facilidades extra a los hackers.
Las sesiones inactivas deben ser dependientes del tiempo, cerradas después de un cierto tiempo o un cierto tiempo inactivo, lo que mejor se adapte a la política de la compañía.
También debe considerar si es aplicable limitar las horas del día para el acceso a las aplicaciones; no hay tantos empleados que trabajen fuera de horas, ¿debería la política de acceso reflejar este aspecto? Tenga en cuenta que, aunque sea electrónicamente, las aplicaciones son como su puerta de entrada. La información almacenada en las aplicaciones y el impacto en su pérdida o corrupción deberían guiarlo en cuanto a qué tan fuerte es esa puerta.
9.4.3 Sistema de gestión de contraseñas
A modo de refuerzo de lo dicho hasta ahora sobre las contraseñas, los sistemas de administración deben aplicar contraseñas de calidad, rechazar contraseñas débiles, requerir confirmación y, si se emiten con ID, forzar el cambio de las contraseñas en el primer inicio de sesión.
También se deben establecer cambios de contraseñas de forma periódica, además de registrar todas las contraseñas y rechazar contraseñas similares utilizadas anteriormente. El almacenamiento de contraseñas debe mantenerse separado de los sistemas en los que se encuentran las aplicaciones.
9.4.4 Uso de programas de utilidad privilegiados
Aquellos programas con capacidades de anulación del sistema o sus controles deben ser restringidos y supervisados de manera especial.
Los programas con funciones privilegiadas deberían requerir autenticación por separado y estar segregados de las aplicaciones del sistema. Todas las actividades deben registrarse. Se debe considerar nuevamente la segregación de funciones cuando sea posible.
9.4.5 Control de acceso al código de programas fuente
El código fuente debe estar protegido con acceso restringido mediante el uso de librerías fuente. El código fuente no debería protegerse con aplicaciones de red.
Por otro lado se establecen controles para mantener registros de la salida y de auditoría de los cambios realizados en el código. La mayoría de las herramientas de desarrollador tienen esta función.
El desarrollo debe estar sujeto a un entorno “beta” de prueba antes del lanzamiento y la migración a la red o aplicación en operación.
