4. Control de acceso a sistemas y aplicaciones
4.2 Procedimientos de log-on seguro
4.2.1 Definición ISO
El acceso a aplicaciones y servicios debería estar controlado por un proceso de conexión seguro, cuando así sea requerido por la política de control accesos38.
4.2.2 Guía de implementación ISO
Se debe elegir una técnica de autenticación adecuada para corroborar la identidad declarada por los usuarios.
Cuando se requiera autenticación y verificación de la identidad robusta se deben utilizar mecanismos alternativos a las contraseñas, con medios criptográficos, como smartcards, tokens o de reconocimiento biométrico.
Análisis del dominio de Control de Accesos de la ISO/IEC 27002 y métricas para cuadros de mando
75 de 130
El procedimiento para iniciar sesión en un sistema o aplicación debe ser diseñado para minimizar la posibilidad de tener accesos no autorizados. El procedimiento de inicio de sesión debe minimizar la información que muestra del sistema o aplicación, de cara a evitar proporcionar a los usuarios no autorizados asistencia innecesaria.
Un buen procedimiento de inicio de sesión debe:
No mostrar identificación de la aplicación o del sistema hasta que el proceso de inicio de sesión no haya finalizado correctamente.
Mostrar mensaje o aviso de que el sistema u ordenador sólo puede ser accedido por usuarios autorizados.
No ofrecer mensajes de ayuda durante proceso de conexión que puedan ayudar o dar pistas a un usuario no autorizado.
Validar la información de autenticación sólo cuando se hayan introducido todos los datos necesarios. Si se produce un error de autenticación, el sistema no debe indicar qué parte de los datos es el erróneo.
Proteger contra intentos de autenticación por fuerza bruta.
Dejar registro de los intentos de inicios de sesión correctos y también fallidos.
Lanzar o enviar un aviso o alerta de seguridad cuando se detecte una potencial brecha en el control del inicio de sesión.
Mostrar la siguiente información tras completar conexión con éxito: o Fecha y hora de la anterior conexión con éxito
o Detalles sobre cuando intento de inicio de sesión fallido desde la última conexión correcta realizada.
No mostrar por pantalla la contraseña que se escribe.
No transmitir en claro ninguna contraseña por red.
Finalizar las sesiones que estén inactivas tras un periodo definido de inactividad, especialmente en ubicaciones de alto riesgo como pueden ser áreas públicas o externas a la organización o en dispositivos móviles.
Restringir los tiempos de conexión para proporcionar seguridad adicional en aplicaciones de alto riesgo y reducir las ventanas de oportunidad para accesos no autorizados.
4.2.3 Riesgos de seguridad
No utilizar procedimientos de log-on seguros debilita todo intento de control del proceso de autenticación y su consecuente acceso, por lo que debilita la confidencialidad, integridad e incluso disponibilidad de la información o servicio accedido.
Control de acceso a sistemas y aplicaciones
Análisis del dominio de Control de Accesos de la ISO/IEC 27002 y métricas para cuadros de mando
76 de 130
4.2.4 Recomendaciones y Buenas prácticas
Por el hecho de ser un elemento accesible y punto de entra a un sistema, aplicación o información, el proceso de autenticación es el componente más vulnerable para la seguridad de un sistema, aplicación o información.
La robustez que un proceso de autenticación necesita obviamente depende de la criticidad de los datos gestionados. Las recomendaciones que propone el estándar son muy indicadas para cualquier proceso de autenticación y con frecuencia aplicadas en las organizaciones puesto que previenen de ataques de fuerza bruta entre otras vulnerabilidades que el proceso puede tener.
Los mecanismos de autenticación considerados robustos en comparación con el uso de contraseñas como los certificados o los tokens, proporcionan un mayor nivel de seguridad, pero en contextos de servicios o aplicaciones orientados a clientes, el uso de contraseñas sigue siendo el principal mecanismo utilizado.
En esta situación, en función de la naturaleza de la aplicación y del contexto alrededor de su tipo de usuario, a veces se pueden producir situaciones de ataque extraordinarias que deben contemplarse de manera especial y que las medidas sugeridas por el estándar no previenen ni necesariamente alertan convenientemente. Por ejemplo, las aplicaciones de banca online. Actualmente han evolucionado mucho y los niveles de protección y seguridad aplicados son muy altos. Se debe a la detección y tratamiento de situaciones extraordinarias de ataques a las que se tuvieron que enfrentar en el pasado y que a día de hoy son un buen ejemplo para remarcar que se debe analizar el contexto de uso personal y no sólo técnico que se hace de ciertas aplicaciones y sistemas.
Es frecuente que el acceso a una cuenta bancaria sea realizado por el propietario de una cuenta o por alguno de sus autorizados (habitualmente la pareja o conyugue del propietario). Pero, ¿qué sucede en los casos en que hay separaciones? Pues en ocasiones ocurría que se producían intentos de acceso a cuentas bancarias por parte de las exparejas. Los ataques de fuerza bruta de estas situaciones para tratar de acceder a una cuenta a la que ahora ya no tenían acceso, se caracterizaba porque en los logs se veía el campo correspondiente al número de cuenta siempre fijo y la variable cambiante era únicamente la contraseña. Coincidía además, que los “ataques” provenían siempre desde la misma IP, por no tratarse de un ataque profesional.
Cuando los ataques a las aplicaciones bancarias eran profesionales, solían tener otra caracterización. Trataban de explotar el hecho de que los usuarios utilizaban contraseñas débiles y predecibles, por lo que los ataques solían consistir en que la contraseña se fijaba (por ejemplo a “password”, o a “123456”) y lo que variaba era el número de cuenta bancaria.
Detectar estos ataques diferentes, permitió en su momento aplicar medidas específicas y evolucionar los procesos de autenticación hasta el punto en que se encuentran hoy en día, en base a un PIN largo, con posiciones diferentes en cada acceso e incluso con
Análisis del dominio de Control de Accesos de la ISO/IEC 27002 y métricas para cuadros de mando
77 de 130
teclado en la propia página para eliminar posibles detecciones de contraseñas por lectura del teclado físico.
4.2.5 Tecnologías aplicables
Existen muchas tecnologías que proporcionan mecanismos de logon más seguros que los procesos de autenticación habituales basados en contraseñas. Algunos de ellos son:
Autenticación con certificados en tarjetas inteligentes (smartcards). o Gemalto eToken PRO SmartCard39
o FNMT-CERES. Tarjeta criptográfica FNMT-RCM40
Autenticación con token. Reemplaza la autenticación con usuario y contraseña por la necesidad de autenticarse mediante la inserción de un hardware (una llave USB especial, una smartcard, una etiqueta RFID, etc):
o Rohos logon key41
Autenticación con one time password. Sistemas que generan una contraseña única válida por períodos de tiempo muy breves, conocidas como contraseñas de un solo uso.
o McAfee One Time Password42
o Gemalto eToken PASS43
Autenticación biométrica. Consiste en autenticarse ante un sistema por lo que uno es. Mediante técnicas matemáticas y estadísticas se es capaz de identificar a una persona por un rasgo físico, como su huella dactilar, el iris de su ojo, su rostro, su voz o la geometría de la mano, por ejemplo.
o Kimaldi Suprema Face Station, para reconocimiento facial44
o ElevenPaths, SmartID para huella dactilar45
39 http://www.safenet-inc.com/multi-factor-authentication/authenticators/pki-smart-cards/etoken- pro-smart-card-security/ 40https://www.cert.fnmt.es/catalogo-de-servicios/tarjetas-criptograficas 41http://www.rohos-es.com/productos/rohos-logon-key/ 42http://www.mcafee.com/es/products/one-time-password.aspx 43 http://www.safenet-inc.com/multi-factor-authentication/authenticators/one-time-password- otp/etoken-pass/ 44 http://www.kimaldi.com/productos/sistemas_biometricos/huella_vascular_y_facial/biometria_facial 45https://www.elevenpaths.com/es/tecnologia/smartid/index.html
Control de acceso a sistemas y aplicaciones
Análisis del dominio de Control de Accesos de la ISO/IEC 27002 y métricas para cuadros de mando
78 de 130
o Nuance Voice Biometrics46
4.2.6 Métricas para el cuadro de mando
Evaluar el cumplimiento de las recomendaciones proporcionadas por el estándar para obtener un proceso de logon seguro es más un proceso de revisión y auditoría de que se cumplen los requerimientos técnicos en los procesos de las diferentes aplicaciones.
A una organización en realidad la métrica que le interesará será conocer el resultado de esa auditoría evaluando que lo cumplen. Por tanto, las métricas para este control serían:
¿En cuántos sistemas de la organización el proceso de logon cumple las directrices del estándar? ¿qué porcentaje supone respecto al total?
¿En cuántos sistemas de la organización el proceso de logon no cumple las directrices del estándar? ¿qué porcentaje supone respecto al total?
¿Cuántos sistemas de la organización están pendientes de evaluar?
Ahora bien, en función del mecanismo de autenticación utilizado por las aplicaciones, puede ser interesante evaluar su grado de precisión y por tanto de seguridad que ofrece a la organización. Es decir:
Si se utiliza como mecanismo de autenticación el basado en “Usuario y Contraseña”, la efectividad del control ya se repasó en anteriores apartados.
Si se utilizan sistemas de autenticación biométricos, quizás las métricas más importantes serían:
¿Cuántas llamadas al servicio de atención al usuario/empleado se han recibido indicando que no han podido autenticarse con el sistema biométrico? Este volumen proporcionará un indicador sobre cuántos falsos negativos se han producido y por tanto el impacto que está teniendo el sistema de autenticación por falta de precisión.
¿Cuántos accesos indebidos es capaz de identificar un responsable de una aplicación tras revisar un log de accesos? Este dato, bastante complejo de identificar con precisión, sería el que proporcionaría un indicador sobre posibles accesos fraudulentos que se han sufrido. La organización no puede hacer nada por evitar ese acceso concreto, puesto que ya ocurrió, pero un volumen alto sería un indicador de que el sistema de autenticación está fallando.
Si se utilizan certificados, métricas interesantes para la organización sería identificar:
Análisis del dominio de Control de Accesos de la ISO/IEC 27002 y métricas para cuadros de mando
79 de 130
¿Cuántos inicios de intentos de acceso se han producido que luego se han abandonado? Esto proporcionaría una idea a la organización de cuantos usuarios deciden no acceder a la aplicación precisamente por utilizar certificados o que por problemas de complejidad de uso del certificado por parte de los usuarios, han decidido abandonar el acceso.