Controles de Acceso y Criptografía en ISO 27001

A9 Control de acceso
A9.1 Requisitos de negocio para el control de acceso
A9.1.1 Política de control de acceso
A9.1.2 Acceso a las redes y a los servicios de red
A9.2 Gestión de acceso de usuario
A9.2.1 Registro y baja de usuario
A9.2.2 Provisión de acceso de usuario
A9.2.3 Gestión de privilegios de acceso
A9.2.4 Gestión de la información secreta de autenticación de los usuarios
A9.2.5 Revisión de los derechos de acceso de usuario
A9.2.6 Retirada o reasignación de los derechos de acceso
A9.3 Responsabilidades del usuario
A9.3.1 Uso de la información secreta de autenticación
A9.4 Control de acceso a sistemas y aplicaciones
A9.4.1 Restricción del acceso a la información
A9.4.2 Procedimientos seguros de inicio de sesión
A9.4.3 Sistema de gestión de contraseñas
A9.4.4 Uso de utilidades con privilegios del sistema
A9.4.5 Control de acceso al código fuente de los programas

A10 Criptografía
A10.1 Controles criptográficos
A10.1.1 Política de uso de los controles criptográficos
A10.1.2 Gestión de claves

![](

Sin duda los grupos de mayor trabajo se enmarcarían en:
A.8 Gestión de Activos
A.9 Control de acceso.

Son dos grandes grupos que demandan tiempo en la recopilación de información clasificación y ponderación de la misma.

Para el caso de los administradores, es fundamental que tengan un sucesor debidamente capacitado en el manejo informático de la organización, los roles y responsabilidades deberán ser divididos en dos roles:

1. Super administrador
2. Administrador

Donde el segundo tendrá atributos de admin con limitaciones y restricciones, cuando el super admin salga a vacaciones deberá ser remplazado por el admin. Los Usuarios y Claves de del super, estarán con antelación bajo llave preferiblemente en caja fuerte para que sea custodiada por la alta directiva de donde dependa el área IT, conjuntamente con seguridad de la información se autoriza la rotura del sobre sellado para acceder a estas claves dependiendo el estado de la necesidad y/o su criticidad.

Objetivos de control y controles de referencia:

A.9.Control de acceso

A.9.1 Requisitos de negocio para el control de acceso

	A.9.1.1 Política de control de acceso (Tipos de conexión para un usuario, periodicidad de revisión de los permisos para los usuarios, horarios donde se permite o no su acceso)

	A.9.1.2 Acceso a las redes y a los servicios de red ()

A.9.2 Gestión de acceso de usuario

	A.9.2.1 Registro y baja de usuario (Dar de baja a los usuarios que ya no pertenecen a la compañía) 
	A.9.2.2 Provisión de acceso de usuario (Que tanto se demora un usuario para poder tener acceso al sistema dependiendo de su rol, entrega pronta)
	A.9.2.3 Gestión de privilegios de acceso (Definir matriz de roles, funcionalidades y permisos para cada sistema de información, que roles tienen acceso a determinadas funcionalidades)
	A.9.2.4 Gestión de la información secreta de autenticación de los usuarios (Va de la mano con la responsabilidad del usuario ya que es lo que tiene que hacer el usuario con la custodia o manejo de su información privada o de accesos, es información confidencial)
	A.9.2.5 Revisión de los derechos de acceso de usuario (Periódicamente implementar indicador que diga que está pasando con el usuario , quienes están accediendo a que y con qué periodicidad , monitorear que a los usuarios se les está entregando pocos o solo los permisos necesarios)

	A.9.2.6 Retirada o reasignación de los derechos de acceso (Retirar permisos innecesarios a los usuarios, solo los que necesita y va usar en su actividad diaria)

A.9.3 Responsabilidades del usuario
	
	A.9.3.1 Uso de la información secreta de autenticación (Capacitación adecuada de que sus acceso son para el empleado y no debe de compartirla con nadie más ya que es solo para su uso, si está en vacaciones debe de desactivarse se usuario temporalmente)


A.9.4 Control de acceso a sistemas y aplicaciones

	A.9.4.1 Restricción del acceso a la información (Restringir que puede ver o no determinado usuario)

	A.9.4.2 Procedimientos seguros de inicio de sesión (Tener en cuenta accesos concurrentes, restringir en el desarrollo para que no se permiten sesiones concurrentes …no es permitido en la ISO 27001 que el mismo usuario esté logueado en varios equipos o sesiones al mismo tiempo)

	A.9.4.3 Sistema de gestión de contraseñas (Validar periodicidad de la contraseña, restricciones fuertes en contraseña,8 caracteres, caracteres alfanuméricos  y caracteres especiales, que no se pueda repetir la misma contraseña , que tenga que cambiara unas 4 o 5 veces antes de poder poner una contraseña antigua)

	A.9.4.4 Uso de utilidades con privilegios del sistema (No es permitido que el usuario pueda escalar privilegios)

	A.9.4.5 Control de acceso al código fuente de los programas (Información altamente confidencial en su mayoría cuando se desarrolla software)

A.10. Criptografía

A.10.1 Controles criptográficos
	
	A.10.1.1 Política de uso de los controles criptográficos (Definir lineamiento de cómo definirla, quien las custodia, oficial de seguridad que las guarda en un sistema de información o si es algo impreso se guarda en una caja fuerte, etc)

	A.10.1.2 Gestión de claves (Quién tiene las claves de acceso o criptográficas con las que se hace intercambio de acceso entre entidades)

Se debe tener por escrito en un acta o documento especificando los permisos de accesos a los diferentes sistemas de información por cada funcionario?

Un caso de filtracion de codigo fuente grave, seria el de la empresa CD PROJEKT, el cual luego de un ataque de ramsonware y HABER PAGADO el rescate, filtaron de igual manera el codigo de juegos como The Witcher 3 o el infame Cyberpunk 2077.
Esto nos deja claro que aunque paguemos el rescate de un ransomware, no hay una seguridad que nos devolveran nuestra informacion.
Aqui les dejo mas datos
https://hipertextual.com/2021/06/cyberpunk-2077-codigo-fuente-filtrado

Existe algun formato para realizar las policitas?

en mi trabajo esta resuelto asi
un root, para todo
un administrator solo con permisos de cambiar pass
cado uno con su usuario y cuando se necesita el root o el administrator, se lo pide y un jefe o gerente lo aprueba.
asi tenes el acceso al usuario de root
extra hay un usuario mas, que solo lo tiene el gestor y solo se usa por fallo critico de los otros dos.

En la empresa que trabajo no llevan un adecuado control de acceso, ya que un usuario de red puede estar logueado en diferentes equipos y trabajando en simultaneo sin ninguna restricción.

Muy completa la explicación de esta segunda parte de los controles.

Todas las reglas para prevenir un error humano

Quien controla el acceso al administrador cuando este de vacaciones?

Gracias a la información aprendida aquí, he comprendido que no se puede divorciar a ninguna área para la implementación de un SGSI.

Creo que los mas complicados es delinear que privilegios tienen ciertos usuarios.
Pero uno claro que yo si creo que se deben hacer es entender que políticas necesito aplicar, que se de manera coordinado y de manera que se este evaluando, capacitando, y automatizando de manera constante.

En lo personal estos son los controles mas complejos para implementar:
A9.1.1 Política de control de acceso
A9.3.1 Uso de la información secreta de autenticación
A9.4.1 Restricción del acceso a la información
A9.4.2 Procedimientos seguros de inicio de sesión

Las credenciales de un usuario son únicas e intransferibles 🔑

Maravillosas Clases, amo platzi!

Control de Acceso Lógico y llevaría a cabo una Certificación de Accesos Semestral para ratificar los permisos que necesitan los usuarios.

Lo mas difícil seria responsabilidades de usuario a mi parecer, ya que se puede desconocer como funciona el sistema, por eso las capacitaciones de los funcionarios son importantes.

A.9.2.4 Gestión de la información secreta de autenticación de los usuarios

Empezaria por el control de acceso.

A9.1.1 Política de control de acceso
A9.1.2 Acceso a las redes y a los servicios de red
A9.2 Gestión de acceso de usuario

estos son los que implementaría.

A9.4.5 Control de acceso al código fuente de los programas
este seria muy difícil de implementar.