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


lunes, 12 de mayo de 2014

Marco de seguridad de datos accedidos por terceros en 5 pasos

La seguridad de los datos ha estado entre las tareas prioritarias del responsable de seguridad. En la actualidad esta tarea ha cobrado mayor importancia debido a los siguientes factores:

  • Incremento de los requerimientos de cumplimiento de la legislación vigente sobre protección de datos personales, protección de datos de tarjetas de debido y crédito, blanqueo de capitales, entre otros requerimientos regulatorios.
  • Los datos del negocio son accedidos desde distintos puntos, distintos repositorios y por diferentes tipos de usuario empleados, operadores/administradores/programadores de las compañías de servicios TI contratadas.
  • La creciente externalización de servicios a proveedores de TI (comunicaciones, alojamiento de servidores, explotación de sistemas, etc).
  • Incidentes de pérdida de datos,  sanciones e investigaciones de  organismos reguladores locales y Europeos.



Para construir un Marco de gestión de la seguridad de datos accedidos por terceros, aconsejamos seguir los siguientes pasos:

1. Definir el enfoque global para la identificación y categorización de proveedores:
  • Crear un inventario de proveedores.
  • Evaluar el riesgo de seguridad de datos.
  • Priorizar y clasificar los proveedores por el nivel de seguridad de datos.
  • Desarrollar e implementar un programa para mitigar los riesgos identificados.

2. Estandarizar el procesos de gestión de la seguridad del acceso a datos por terceros:
  • Revisión anual de contratos.
  • Definición obligaciones contractuales basadas en requerimientos de seguridad.
  • Desarrollar e implementar indicadores de seguimiento y revisar de forma periódica dichos indicadores.
  • Definir reuniones de seguimiento de los requerimientos de seguridad con los proveedores.
  • Definir un calendario de visitas anuales/regulares según el tipo de proveedor.
  • Realizar auditorias a las operaciones del proveedor.
  • Establecer requerimientos adicionales de seguridad a los proveedores de riesgo alto.

3. Definir el marco de seguridad de datos:
  • Desarrollar e implementar las políticas y procedimientos con los requerimientos de seguridad dirigidos a terceros que acceden datos personales y del negocio.
  • Definir controles técnicos para el control de accesos, caducidad de conexiones remotas, registros de auditoria para la descarga de datos, traspaso de programas al entorno de producción, etc.
  • Definición de roles de usuario con accesos específicos, asignación de privilegios basados en funciones específicas.
  • Revisión mensual de accesos asignados, supervisar la rotación de personal del proveedor
  • Establecer un programa de concienciación del personal interno y del proveedor.

4. Definir roles y responsabilidades:
  • Establecer el rol de responsable del servicio en ambas partes (tanto en la compañía como en el proveedor).
  • Establecer responsabilidades a los responsables.
  • Definir una matriz RACI incluyendo a todos los niveles que intervienen en la prestación del servicio.
  • Establecer el proceso de revisión de los roles cuando se realicen cambios en el servicio.

5. Monitorizar la ejecución del marco de gestión:
  • Revisión de la ejecución de indicadores de seguimiento.
  • Revisión de la ejecución de los controles técnicos, registros de auditoria, cambios de claves de acceso, etc.
  • Revisión de la aplicación de las políticas y procedimientos definidos, revisiones de accesos, autorizaciones, actas de reuniones con el proveedor.