martes, 9 de septiembre de 2014

Planes de Continuidad. 10 aspectos clave



Ya sea que hablemos de la continuidad de los procesos de negocio en general o de la continuidad de los servicios de TI en particular (equivalentes a los planes de contingencia de TI), hay una serie de aspectos clave a la hora de abordar estos proyectos que es necesario tener en cuenta para garantizar su éxito:




Mapa de procesos y/o catálogo de servicios de TI
Conseguir disponer de un mapa de procesos de negocio y/o un catálogo de servicios de TI suficientemente detallado.

Participación de la Dirección
Conseguir la participación y/o involucración de la Dirección en el proyecto. En caso de abordar un Plan de Continuidad de Negocio la participación debe quedar plasmada en el compromiso de involucrarse de forma continua y participativa en la ejecución del proyecto. Dicha participación es clave, por no decir absolutamente imprescindible. Un Plan de continuidad de Negocio es un proyecto estratégico para la organización.

Análisis de Impacto en el Negocio (BIA)
Conseguir que la Dirección y los interlocutores se ubiquen dentro del alcance de este tipo de proyectos y tengan claro la diferencia entre una incidencia y un desastre. Para ello es muy importante explicar el concepto de análisis de impacto en el negocio  (BIA). El BIA introduce en el análisis la variable temporal que permite evaluar, precisamente, cuando un incidente puede llegar a convertirse en un desastre si no se soluciona a tiempo.

Valoración tangible vs intangible
Poder valorar de forma tangible – económicamente - el impacto asociado a la no disponibilidad de un proceso crítico de negocio (PCN) o de un servicio de TI (PCTI).

Análisis de Riegos
Disponer de un análisis de riesgos creado con criterios homogéneos a lo largo de toda la organización. Esto puede ser complicado cuando la organización decide abordar este tipo de proyectos de forma interna y no dispone o designa a un responsable del proyecto que marque las pautas.

Plan de Tratamiento de Riesgos
Establecer el Plan de Tratamiento de Riesgos como un entregable básico del proyecto. En realidad no nos gustaría llegar a tener que activar nuestro Plan.

Estrategias de Recuperación
Conseguir que quede clara la diferencia entre lo que son las medidas de reducción, eliminación del riesgo (o del impacto asociado) con respecto a lo que son las estrategias de recuperación a implementar para conseguir cumplir con los requisitos de continuidad del negocio (RTOs).

Riesgo vs Coste
Valorar económicamente, con el nivel de detalle necesario, las medidas de reducción del riesgo y estrategias de recuperación planteadas. Los análisis de riesgo vs coste y RTO vs coste permitirán a la Dirección decidir en base a criterios de negocio. La experiencia demuestra que casi siempre, para algunos procesos de negocio o servicios de TI, la primera valoración de los RTO es demasiado restrictiva. Suele ser necesario un segundo análisis.

Escenarios de Indisponibilidad
Agrupar los riesgos residuales inaceptables para la organización en una serie de escenarios de indisponibilidad que se puedan tratar a posteriori con planes operativos de recuperación específicos para cada escenario (planes de recuperación ante desastres).

Oficina de Continuidad
La definición e implementación de una Oficina de Continuidad constituida por una estructura de roles y responsabilidades que velen en la organización por la continuidad y sean asumidas por personal capacitado (definiendo la estructura y seleccionando a las personas adecuadas para ejercer cada rol). Roles que pueden ser internos, externos o una mezcla de ambos.

jueves, 24 de julio de 2014

Cómo el CISO y el CEO pueden hablar el mismo idioma


Desde hace 10 años el CEO (Chief Executive Officer) ha comenzado a entender como la seguridad TI y los responsables de seguridad pueden convertirse en habilitadores de negocio.

Esto se debe a que los responsables de la seguridad TI han conseguido el camino para traducir los problemas de seguridad a un lenguaje de negocio que el CEO puede entender.

Tradicionalmente el negocio cuida la caída de la línea de producción (ensamblado de coches, empaquetado de productos, procesamiento de materia prima) y no cuida la caída de TI.

Es importante hacer ver al negocio que detrás de las operaciones de producción del negocio hay una serie de elementos de TI que necesitan ser reparados, cambiados y configurados de forma segura.
Los responsables de seguridad deben ser capaces de conectar el impacto actual de la caída del  negocio con los fallos de seguridad que impacten en la caída del negocio. En este punto se unen la línea de protección del negocio y la de reducción del riesgo del negocio.



El CEO debe tener claro que 1 hora de caída de TI tiene como resultado 40 coches menos ensamblados por caída de la línea de ensamblado. El problema está cuando el CEO reporta en su inventario 40 coches menos y no una caída de TI, en esta caso el CEO está preocupado por la producción del coche y no por los servicios TI.

En todo caso si se reporta una perdida en el inventario estamos hablando de un problema de negocio. Si hay un problema de negocio,  el área de TI y de seguridad deben informar las cosas que necesitan ser corregidas cada uno desde su ámbito. Al equiparar el problema de negocio con los elementos TI y de seguridad necesarios y que impactan en el problema estamos habilitando a la empresa a ser más eficiente, aumentar la producción y, como consecuencia, aumentar los beneficios.

Hay que eliminar la cultura de desconectar, que consiste en que la seguridad es un problema técnico que puede ser resuelto por TI, los problemas técnicos deben ser resueltos por los administradores u operadores de TI y los de seguridad deben ser resueltos por los responsables de seguridad TI.

Hay que direccionar dentro de la gestión del riesgo la seguridad TI, se estima que sólo el 30% por ciento de las organizaciones adoptan un enfoque basado en riesgos para la seguridad TI. En lugar de ser los defensores de la organización, los administradores de seguridad de TI están interesados ​​en ser facilitadores de ese equilibrio entre la necesidad de proteger y las necesidades para ejecutar el negocio.



Un responsable de seguridad no se preocupa de si un hacker hará un ataque a la página de la compañía, un responsable de seguridad se preocupa de preparar la compañía para afrontar riesgos mediante la implementación de medidas y prácticas.


La seguridad no es una persona al lado de un firewall, la seguridad es desarrollar programas de riesgos alineados con las necesidades del negocio.

martes, 1 de julio de 2014

“Indisponibilidad Personal Crítico” Un Escenario de Continuidad en Desarrollo

Desde hace años los profesionales de la continuidad llevamos tiempo tratando escenarios de desastre de todo tipo en las diferentes organizaciones: indisponibilidad sede, indisponibilidad sistemas TI, indisponibilidad proveedores… De todos estos escenarios y en base a la experiencia y al trabajo realizado, se ha conseguido establecer  un know how  que permite a las organizaciones no partir de cero, siendo el escenario más contemplado y trabajado en las empresas el Plan de Recuperación frente a Desastres (que aborda la indisponibilidad de los sistemas TI).


Sin embargo en relación con el personal clave de las empresas no hay mucho trabajo realizado. Son numerosos los países que en los últimos años han sufrido algún tipo de pandemia, o países en los cuales hay revueltas importantes que implican huelgas severas con duraciones prolongadas. Las personas son activos muy importantes en las empresas y en algunos casos la indisponibilidad de ciertos roles críticos puede suponer la interrupción de actividades vitales para el negocio o la pérdida de know how para la organización.


Actualmente muchas organizaciones disponen de Planes de Sucesiones en los cuales se tiene identificado el personal clave de cada departamento y donde para cada uno de ellos se ha definido un sucesor de emergencia (para bajas de hasta 6 meses) y un sucesor primario (para bajas más prolongadas en el tiempo). En estos planes de sucesión se analiza:

§  si a nivel individual se tienen identificadas las competencias que cada empleado necesita desarrollar para ejecutar el trabajo y asegurar una carrera a largo plazo
§  Si a nivel de negocio se tiene identificadas las competencias  y el diseño organizacional  para soportar los procesos requeridos por el negocio
§  Los aspectos de formación necesarios para desempeñar futuras tareas de determinados roles/cargos (críticos)
§  Identificación de las áreas con conocimiento compartido y multidisciplinar (entre roles de la misma área y entre diferentes áreas)

Sin duda este Plan de Sucesión es un gran primer paso  que permite a la organización disponer de una estrategia de recuperación formalizada ante bajas puntuales de personal clave. Sin embargo este plan no cubre el escenario de una indisponibilidad de personal más generalizada  como por ejemplo la baja simultánea de varias personas clave en una misma área o en varias, o la indisponibilidad de un departamento entero… Las causas pudieran ser variopintas, una pandemia, una huelga generalizada, una sucesión de casuísticas, un accidente en un viaje corporativo… Para estos escenarios es imprescindible disponer de políticas y de controles que permitan mitigar estos riesgos (políticas sanitarias, políticas de viajes, etcétera…) pero el siguiente reto que la organización debe abordar es la elaboración de un Plan de Indisponibilidad Generalizada de Personal Crítico que garantice la existencia de una estrategia clara para un escenario de este tipo (poco probable pero con consecuencias que pudieran ser muy importantes). Debido a la alta dependencia que las organizaciones desarrollan del personal, no es sencillo definir estrategias robustas que permitan cubrir este escenario, pero en base a nuestra experiencia, los pilares sobre los que se sustenta este plan y que permiten alcanzar la resiliencia en el capital humano de una organización son:

§  Políticas y Comunicaciones: Definición de políticas específicas como baja por enfermedad, política de viajes y formalizarlas a fin de establecer canales de comunicación en caso de desastre
§ Educación de los empleados y soporte: Formar y capacitar a los empleados en la continuidad de negocio y en los planes existente que abordan escenarios.
§  Infraestructura Virtual / Teletrabajo: Establecer vías alternativas de trabajo remoto.
§  Formación Profesional: Redundar el know-how y preparar al personal para asumir roles de más responsabilidad.
§  Gestión del Talento: Plan de Sucesiones a corto y largo plazo.
§  Sistema de RRHH: preparar al departamento de RRHH para dar soporte durante una crisis y activar los procesos críticos del área, pago de nóminas, subcontratación durante la crisis…
§ Cultura de Organización: Involucrar a los empleados en la cultura de continuidad de negocio, dándoles las herramientas a los empleados para que vean que en caso de desastre es su responsabilidad ejecutar en modo degradado su trabajo. 


Sin duda, este es un escenario muy importante a contemplar y en el que todavía nos queda un largo camino que recorrer a muchas organizaciones, pero la implantación de estos pilares nos debe hacer dar un paso más hacia la resiliencia.


lunes, 23 de junio de 2014

TrueCrypt - Tus archivos podrían no estar seguros


TrueCrypt se ha convertido en la herramienta de cifrado de datos a nivel local que más usuarios y empresas ha utilizado hasta la fecha. No obstante, en los últimos meses esta herramienta se ha visto envuelta en una nube de conspiraciones que han acabado con el proyecto. Si hoy en día entramos en su página web, veremos un cartel que nos anuncia:
"WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues"

Seguido de una guía para migrar todo el contenido que tengamos en nuestro TrueCrypt hacia la plataforma de cifrado de Microsoft, BitLocker. La teoría de su caída que más peso ha tomado hasta la fecha es la existencia de backdoors en su código producidos por la N.S.A. y la auditoría realizada a dicha herramienta.

La Unidad de Auditoría y Consultoría de Seguridad TI de Abast Systems ha realizado una prueba de concepto para determinar hasta qué punto es posible acceder a datos encriptados en un ordenador ajeno. Para ello necesitaremos un ordenador en caliente (hibernado, suspendido, en funcionamiento) o una captura de la memoria ram, en caso de que el ordenador se haya apagado. Esta prueba no es posible realizarla si el ordenador se encuentra completamente apagado.

Con un análisis exhaustivo de una captura de RAM es posible detectar programas en funcionamiento, sesiones abiertas a memoria, conexiones establecidas y otro tipo de información que puede complementar o ayudar a detectar nuevas evidencias. Una de las herramientas más potentes para realizar esta tarea es el framework Volatility.

Figura 1 - Volatility descubre un TrueCrypt en uso

Figura 2 - Devicetree de Volatility muestra el contenedor

En las imágenes superiores se puede apreciar la existencia de la herramienta de encriptación de unidades TrueCryp. El alto nivel de seguridad que conlleva esta herramienta está reconocido internacionalmente. No obstante, el hecho de tener una captura de la memoria RAM puede ayudar a descifrar o, al menos identificar qué unidad es la que se encuentra cifrada.

Con el módulo volshell de Volatility abre una consola y se miran las propiedades del Device_object situado en la dirección de memoria 0x856f37a0, que es la que se ha devuelto en la imagen anterior.

Figura 3 - Propiedades del objeto situado en 0x856f37a0

Con estos datos ahora es posible mostrar todo lo que hay en esta parte de la memoria. Se mostrará 1416 (size) unidades de memoria, a partir del offset 0x856f37a0.

Figura 4 - Obtención del "container"/archivo encriptado: Mine

Ahora se intentará obtener la clave de desencriptación del archivo. El próximo paso necesitará de la ayuda del Driver_object del TrueCrypt, mostrado previamente a la imagen de las propiedades del Device_object.

Figura 5 - Información del driver_object

Para realizar esta tarea expulsaremos toda la memoria que hay desde la posición DriverStart hasta DriverStart + DriverSize. El problema de esto es que nos devuelve un trozo demasiado grande como para hacer búsquedas manualmente. Así que, automatizar el proceso restante usando herramientas como CryptoScan (con Volatily1.3), aeskeyfind o alguna más "user-friendly" como Elcomsoft Forensic Disk Decryptor.

Figura 6 - Ejemplo de extracción de keys AES

Con estas claves se permite descifrar el archivo previamente comentado (mine) y montarlo. De esta manera se puede acceder a su interior, y ver toda la información que creíamos tener guardada de manera segura.

jueves, 12 de junio de 2014

Cómo resolver el problema de la ejecución


Uno de los grandes problemas de los CIOs, sino el más importante, consiste en ser capaces de generar cambios en el comportamiento y forma de trabajar de su equipo. Muchas veces, la Dirección de TI se encuentra con la necesidad o el objetivo de implementar metodologías, mejores prácticas que “profesionalicen” el funcionamiento del departamento y permitan hacer un uso más eficaz y eficiente de los recursos de TI.


Estamos hablando, por ejemplo, de proyectos encaminados a mejorar el gobierno y gestión de los servicios de TI que soporta y ofrece el Departamento de TI, o de proyectos asociados a la mejora, también, del gobierno y gestión de la seguridad de TI tanto en el ámbito de riesgos como en el de cumplimiento.

Algunas veces la escasez de personal, otras la exigente operativa diaria y muchas veces la propia resistencia al cambio de las organizaciones, hacen muy difícil la puesta en marcha de estos proyectos de mejora. En estos casos el reto está en la ejecución, es decir, en cómo ejecutar estos proyectos de manera que puedan convivir con el día a día y obtener, a su vez, los resultados esperados.

Al ser este un problema más común de lo habitual he querido compartir con vosotros una aproximación que descubrí hace tiempo y que recuperé últimamente. Se trata de “The 4 Disciplines of Execution” (4DX) de Chris McChesney, Sean Covey y Jim Huling. Al final os dejo un par de enlaces donde podréis encontrar información.

Básicamente 4DX trata de explicar cómo conseguir alcanzar objetivos importantes efectuando el cambio necesario en el comportamiento del personal que permita su consecución. Las 4 disciplinas son:
  1. Focalizarse en lo realmente importante.
  2. Actuar sobre los indicadores de rendimiento (KPIs).
  3. Utilizar un cuadro de mando que garantice el compromiso contínuo.
  4. Crear una cadencia de rendición de cuentas.

http://www.franklincovey.com/tc/solutions/business-execution-solutions

miércoles, 28 de mayo de 2014

Análisis de Riesgo TIC


La provisión de servicios TIC pasa por el correcto funcionamiento de una serie de activos, cada uno de ellos con su función específica. Si alguno de estos activos se ve comprometido por la materialización de una determinada amenaza, el propio servicio se verá afectado. Para determinar el nivel de riesgo real de una entidad hay que realizar un análisis de riesgo.

La primera actividad a realizar en un análisis de riesgos es identificar cuáles son los activos que soportan los sistemas de información de la organización.


Un activo es cualquier elemento que tenga valor para la entidad, desde un PC concreto, a un recurso de red o una persona física necesaria para el desarrollo de una actividad.

Con el objetivo de estructurar la información de forma coherente, los activos han de estar clasificados en función de su naturaleza, intentado usar un modelo por capas. Esto permitirá clasificar los sistemas diferenciando la funcionalidad de los activos entre sí, y además facilitará próximos pasos, como definir sus dependencias.

El análisis puede empezar a estructurarse según necesidades específicas, los activos pueden ser des del tipo proceso de negocio, pasando por el personal que trabaja y hasta una ubicación física. Por ejemplo, en el siguiente grafico se representa cada tipo de activo según su tipo y funcionalidad:

Se ha de desglosar el análisis bajando hasta los niveles más básico de la estructura, es decir dentro de Sistemas de Información en el apartado de Comunicaciones se debería profundizar mucho más, por ejemplo separando los activos de hardware necesario para soportar el sistema de comunicaciones, de los propios servicios de redes que puedan existir en la entidad.

Con la creación de dichas dependencias el cálculo del nivel de ruido tendrá en consideración que en el caso de materializarse una amenaza sobre un determinado activo, todos los elementos que dependan de él también sufrirán sus consecuencias.

Un ejemplo de dependencias de un proceso genérico podría ser el siguiente:

De esta forma se introducen una a una todas las dependencias entre los elementos que soportan los sistemas de información, obteniendo como resultado una base de datos de configuración de tipo relacional de los servicios TIC de la entidad.

A nivel conceptual es fácilmente apreciable que no todos los elementos son igual de críticos. No supondrá el mismo impacto la indisponibilidad de un servicio crítico para la actividad diaria que la de un entorno de pruebas, por ejemplo.

La anterior lógica se aplica a todas las dimensiones de un mismo servicio. La indisponibilidad temporal de un servicio puede no tener consecuencias graves, y sin embargo, un escape de la información que se trata pudiera suponer un impacto enorme para la organización.

Cuando se habla de valorar los activos, intuitivamente se piensa en el coste de sustitución de un determinado elemento físico, pero esta es solo una de las variables que se han de considerar cuando se han de valorar los activos informáticos, y normalmente no acostumbra a ser más significativa. En este sentido la valoración de activos trata de mostrar cual sería el impacto global en una organización en caso de que alguna de las dimensiones de seguridad se viera comprometida. 

Un ejemplo sería, si un servicio automatizado no se encuentra disponible para la operativa diaria, en este caso se tendrá que valorar cual es el impacta económico que genera la paralización (tiempo de parada del personal, esfuerzo necesario para recuperar el tiempo perdido, posible pérdida de producto generada por la incapacidad logística, penalizaciones debidas a incumplimientos de compromisos contractuales…) pero también hay que medir aspectos intangibles, como por ejemplo los daños en la imagen de la organización. La suma de todas estas variables da como resultado la valoración del activo en cuestión.

Utilizando estos criterios para valorar los activos identificados, el resultado es una matriz con todos los servicios de la organización y una valoración de estos para cada una de las dimensiones de seguridad.
  • D: Disponibilidad
  • I: Integridad
  • C: Confidencialidad
  • A: Autenticidad
  • T: Trazabilidad

Una vez identificados y valorados los activos, el siguiente paso es identificar cuáles son las amenazas que, es caso de materializarse, pudieran comprometer la seguridad.

Bajo este concepto está el análisis de las particularidades de la organización, es decir, quienes pueden ser los posibles atacantes y su interés, como trabajan los usuarios, cual es el entorno físico y lógico donde se encuentran los sistemas, etc. Con esta información será posible identificar como es de probable que una determinada amenaza acabe materializándose sobre un servicio.

Algunos ejemplos de amenazas que pueden afectar a  un CPD o componente electrónico son:
Una vez analizados todos estos aspectos es el momento de analizar qué protecciones hay aplicadas de cara a reducir el riesgo potencial existente. Estas  medidas de protección son las conocidas como salvaguardas.
En términos generales, las salvaguardas se caracterizan, además de por su existencia, por su eficacia delante del riesgo que han de mitigar. De manera ideal, la salvaguarda es 100% eficaz, ya que combina dos factores:

·         Des del punto de vista técnico:
ü  Es técnicamente idónea para afrontar el riesgo que protege.
ü  Se utiliza siempre.

·         Des del punto de vista de operación de salvaguarda:
ü  Esta perfectamente desplegada, configurada i mantenida.
ü  Existen procedimientos de uso normal.
ü  Los usuarios están formados y concienciados
ü  Existen controles de aviso para posibles fallos.

Identificadas todas las salvaguardas que resultan de aplicación en función del tipo de activos existentes, es el momento de valorar qué medidas de protección se encuentran implementadas  i que nivel de madurez tienen.

Para realizar este último proceso de medidas de protección es recomendable valorar los controles de la ISO 27002.

La norma incluye 114 controles divididos en  35 objetivos de control y en 14 dominios. Lo que se pretende es obtener el nivel de madurez  de la organización con respecto a cada uno de los dominios de seguridad. Entre ellos, por ejemplo, el de políticas de seguridad establecidas, o la organización de la seguridad de la información en la compañía, la protección de los recursos humanos, también sobre  continuidad de negocio o el  cumplimiento normativo, entre otros aspectos.



Una vez analizados todos los puntos expuestos ya se puede extraer como conclusión el valor de riesgo real al que la organización está expuesta. Este siempre es mitigable con unas buenas estrategias de recuperación en caso de desastre.

martes, 20 de mayo de 2014

Aspectos a tener en cuenta en proyectos de Gestión de Identidades


El acceso a la información es de primordial importancia. Tras muchos años intentando facilitar y automatizar el acceso a la información, también se han generado otra clase de problemas:
  • Accesos no permitidos a información confidencial.
  • Usuarios activos eternamente en los sistemas.
Los sistemas aumentan y el número de usuarios también. Pero no solo aumentan en número sino también en diversidad.
  • Se diversifican los sistemas de control de privilegios de accesos, mecanismos de seguridad, repositorios e interfaces.
  • La diversificación de usuarios y sistemas provoca, entre otros:
    •  un aumento en la plantilla de IT para la administración y mantenimiento de los sistemas,
    • experiencias poco satisfactorias de los usuarios al tener credenciales distintas en sistemas distintos.
  • Se tiene que conseguir homogeneizar los mecanismos de control de acceso a la información.
En la actualidad las entidades, ante los nuevos avances y requisitos de interconexión, se encuentran con:
  • Sus usuarios necesitan múltiples contraseñas para acceder a sus aplicaciones.
  • Otros proveedores deben permitir el acceso a los usuarios de las entidades.
  • El tiempo medio para que un empleado empiece a trabajar con los sistemas internos es 5 días. (en el mejor de los casos).
  • La información de los usuarios está distribuida en multitud de repositorios.
  • Los sistemas se vuelven complejos y heterogéneos.
  • Aumentan los costes de los departamentos de IT.



Problemática a resolver:
  • Disminución de costes de administración IT.
  • Mejora de la visión de seguridad de nuestros sistemas.
  • Flexibilidad en la interacción con otros proveedores.
  • Mejora de la satisfacción de los usuarios/clientes al interactuar en nuestros sistemas.
  • Robustez en la arquitectura de seguridad.
  • Disminución de los costes de desarrollo de nuevas aplicaciones de negocio.
Los objetivos de un marco de gestión de identidades deben estar basados en un enfoque de seguridad centrado en los procesos que identifican, crean, capturan y mantienen el valor de la seguridad en la compañía.

Ahora el objetivo de un sistema de gestión de identidades es cubrir:
  • Autenticación
  • Control de acceso
  • Gestión de usuarios
  • Repositorio central de usuarios 
Este marco da respuesta a la siguiente ecuación: Usuarios + Gestión de Identidades + Aplicaciones
  • Usuarios= Externos, Proveedores, Empleados
  • Gestión de identidades= Autenticación, Control de acceso, Gestión de Usuarios, repositorio de usuarios
  • Aplicaciones= ERP, WEB, CRM, Legacy, Correo electrónico



Elementos de la ecuación:

    1. Autenticación: Algo que sé, algo que tengo, algo que son
  • Autenticación de factor único:
    • Identificador de usuario y contraseña.
    • Contraseñas robustas.
    • PINs.
  • Autenticación multi-factor (autenticación fuerte):
    • Contraseñas de un sólo uso.
    • Dispositivos hardware de autenticación (smartcards, tokens).
    • Certificados Digitales (PKI).
    • Sistemas desafío-respuesta.
    • Dispositivos Biométricos (de reconocimiento de huella dactilar, reconocimiento de retina e iris, reconocimiento de voz, escáner facial, escáner de la palma de la mano, escáner de firma).
    • Combinaciones de los anteriores.
  •  Enfoque tradicional:
    • Cada aplicación ha de contemplar mecanismos de autenticación
    • Los controles sobre contraseñas no son homogéneos entre aplicaciones
    • La definición del concepto usuario no corresponde con el de identidad
    • Soporta un único esquema de autenticación
  • Gestión de identidades:
    • Proporciona capacidades de Single-Sign-On (web)
    • El nivel de autenticación varía en función de la criticidad de la información
    • Soporta múltiples esquemas de autenticación
    • Los accesos se gestionan entorno al concepto identidad
   2. Control de acceso:
  • Una Infraestructura que posibilita un enfoque común para la autenticación y autorización entre múltiples plataformas.
  • Proporciona Single Sign-On para aplicaciones Web (y otras aplicaciones).
  • Permite varias aproximaciones de control de acceso: basadas en usuarios (ACLs, control de acceso por reglas o de niveles de seguridad jerárquicos), en roles y en políticas.
  • Reduce los costes de operación asociados con el control de acceso de usuario.
  • Reduce los costes de desarrollo de nuevas aplicaciones y agiliza su implantación.
  •  Enfoque tradicional:
    • La definición del control de acceso es propio de cada aplicación
    • Existen múltiples herramientas de control de acceso
    • Nivel de acceso no homogéneo
    • Altos costes de administración
  • Gestión de Identidades:
    • El control de acceso se independiza de las aplicaciones
    • Se reduce el tiempo y coste necesario para la incorporación de nuevas aplicaciones
    • Los controles y perfiles definidos son aplicables a múltiples aplicaciones
   3. Gestión de Usuarios
  • Workflows automatizados para la creación y modificación de usuarios y perfiles con los derechos de acceso a los usuarios y aprovisionamiento de los elementos necesarios
  • Eliminación automática de los derechos de acceso cuando un usuario deja la organización o cambia de funciones
  • Posibilita el uso de capacidades de autoservicio (autoregistro de usuarios, modificación de información de identidad e inicialización de contraseñas) y administración delegada
  • Enfoque tradicional:
    • Costes aumentan más que proporcionalmente
    • El modelo no escala bien al aumentar el número de aplicaciones o usuarios
    • Se acumulan usuarios en desuso
    • No responde ante cambios organizativos o de funciones
  • Gestión de identidades:
    • Aprovisionamiento de usuarios
    • Automatización del proceso a través de workflow
   4. Repositorio de Usuarios
  • Repositorio centralizado, seguro y fiable para los perfiles de usuario
  • Capacidad de escalabilidad a millones de usuarios
  • Posibilidad de integración mediante el uso de estándares con gran número de aplicaciones
  • Se consiguen tiempos de respuesta razonables con peticiones concurrentes




Hoja de ruta de la Gestión de Identidades:
  • Repositorio corporativo de identidades
  • Definición e integración de fuentes autoritativas
  • Definición de roles y políticas
  • Establecimiento de mecanismos de control de acceso
  • Automatización del aprovisionamiento de cuentas
  • Implementación de mecanismos de autenticación robusta
  • Portal del empleado (Self-provisioning)
  • Federación de identidades
  • Seguridad integrada (física y lógica)
Beneficios:
  • Reducción de Costes
  • Incremento de la Seguridad
  • Cumplimiento Legal
  • Mejoras para usuario final
  • Incremento de Productividad
  • Escalabilidad y Flexibilidad