Gestión del Riesgo

La seguridad de la información es el conjunto de medidas preventivas y reactivas de las organizaciones y de los sistemas tecnológicos que permiten resguardar y proteger la entidad buscando mantener la confidencialidad, la disponibilidad e integridad de la misma.

Para ello existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a la información.

Una de las técnicas para evaluar en una entidad su nivel de Seguridad es realizar un análisis de Riesgos. El estudio puede incluir la visión de negocio, si se realiza el estudio después de la realización del Análisis de Impacto sobre el Negocio BIA (Business Impact Analysis).

La realización del análisis de riesgos proporciona a las organizaciones una visión de la situación en cuanto al nivel de protección de los sistemas de información. Por este motivo, se constituye como uno de los pilares fundamentales a la hora de conocer de manera de detallada la infraestructura y el funcionamiento interno.

Con el análisis de riesgo sobre los sistemas de la organización se conseguirán los siguientes objetivos:

• Identificar y valorar los procesos más críticos de negocio, con el propósito de identificar el nivel de protección adecuado.
• Determinar i evaluar las amenazas existentes, determinando su grado de efectividad para hacer frente a los riesgos existentes.
• Calcular el nivel de riesgo, existente, de forma que la organización conozca con detalle la probabilidad de materialización de cada una de las amenazas y el impacto que estas pueden ocasionar.

Para efectuar un análisis de riesgos con garantías, entre otras, se puede seleccionar la metodología MAGERIT, elaborada por el ‘Consejo Superior de Administración Electrónica’.

MAGERIT es el acrónimo de ‘Metodología de Análisis y Gestión del Riesgo de los Sistemas de Información’, y nace para minimizar los riesgo asociados al uso de los sistemas informáticos y telemáticos, garantizando su autenticidad, confidencialidad, integridad y disponibilidad de dichos sistemas y generando así la confianza en el usuario de los mismos.

A nivel conceptual, MAGERIT se basa en la evaluación y relación lógica de los siguientes conceptos:

Tal y como muestra el esquema, todo el análisis gira entorno de los conceptos:

• Activo: elemento que tiene un valor para la organización
• Amenaza: acontecimiento que supone un impacto negativo sobre el activo y
• Salvaguarda: medida implantada para proteger el propio activo

Los objetivos principales son:

1. Determinar los activos relevantes para la organización, su interrelación y su valor, en el sentido de qué perjuicio supondría su degradación.
2. Determinar a qué amenazas están expuestos dichos activos
3. Determinar qué salvaguardas hay dispuestas y cuán eficaces son frente al riesgo.
4. Estimar el impacto, definido como el daño sobre el activo derivado de la materialización de la amenaza.
5. Estimar el riesgo, definido como el impacto ponderado con la tasa de ocurrencia (o expectación de materialización de la amenaza).

Llegando finalmente a un concepto MEDIBLE que es el riesgo al que la entidad queda expuesta, es decir a una vulnerabilidad provocada por una amenazada.

Conviene aclarar la existencia de dos variables de riesgo diferenciadas. La primera de ellas se acostumbra a nombrar RIESGO POTENCIAL, es decir el riesgo al que estaría expuesta la organización sino existiera ningún tipo de salvaguarda implantada. Todo y ser un valor de riesgo ‘ficticio’ es un valor muy práctico en el momento de implementar nuevas salvaguardas en la entidad, ya que permite simular la evolución del nivel de riesgo a medida que se introducen nuevas medidas de seguridad. En cambio, el RIESGO RESIDUAL se ha de considerar como el nivel de riesgo actual, y por tanto la base sobre la cual se estructuraran los planes de continuidad de los servicios prestados.

Existen herramientas, como el software EAR/PILAR, diseñadas para gestionar de manera eficiente los riesgos según la metodología expuesta.   

Con esta información, juntamente con los requisitos de las normativas aplicables, la organización/entidad podrá seleccionar y priorizar aquellas medidas técnicas que permitan mejorar de manera eficiente el nivel de seguridad de sus sistemas de información. 

Código Penal (II): Elaboración de un Modelo de Prevención

Es fundamental para cumplir con los requerimientos normativos y legales y potenciar el nivel de control interno exigido, lo cual supone un mayor grado de concienciación por parte de la compañía en el impacto que supone la incorporación del área de seguridad TI como agente de articulación entre los procesos de negocio y las TIC.

Ahora bien, pero ¿Qué tipo de controles o medidas pueden ser implementados?  

Existen múltiples controles que desde el área de seguridad TI pueden ser diseñados, desarrollados y/o evaluados para responder a cada delito. A continuación se mencionan algunos de los controles a tener en cuenta:

1. Descubrimiento y revelación  de secretos:

•  Controles técnicos:
• Registro “centralizado” de alertas de auditoría.
• Acceso remoto a los sistemas informáticos (clientes, proveedores, etc).
• Antivirus, malware y software malicioso.
• Filtrado o detección de uso no autorizado de los recursos TIC.
• Auditorías técnicas de sistemas de información.
• Monitorización de usuarios.

• Controles organizativos:
• Revisión técnica de contratos con terceros.
• Políticas de seguridad de la información.
• Políticas de uso de los recursos TIC.
• Formación y concienciación de empleados.
• Protocolos de actuación de accesos no autorizados.
• Procedimientos de seguridad para proveedores y personal externo.

2. Daños informáticos:

• Controles técnicos:
• Revisión de autorizaciones y privilegios de los usuarios.
• Revisión de servicios, protocolos y puertos de comunicación.
• Auditorías de seguridad de la red interna y externa.

•  Controles organizativos:
• Matriz de autorizaciones de usuarios.

3. Acceso no autorizado:

• Controles técnicos:
• Gestión de identidades.
• Control de acceso basado en Role-Based Access Control.
• Validaciones automáticas en transacciones críticas.
• Medidas de autenticación robustas.
• Restricción de accesos a transacciones críticas (por ejemplo modificación de márgenes de tolerancia por encima del límite).
• Restricción del acceso a las funcionalidades de administración y configuración del sistema.

•  Controles organizativos:
• Documentación de las matriz de roles y responsabilidades de usuarios, directivos, proveedores.
• Documentación de la segregación de funciones.
• Documentación de las transacciones incompatibles.
• Definición de key users.
• Definición de flujos de autorización para el control de acceso (alta/baja de usuarios y modificación de accesos).
• Revisión de accesos de usuarios.

Entre las novedades y acciones de la nueva reforma del código penal está la obligatoriedad por parte de las empresas de definir un Modelo o Plan de Prevención del Delito. La implantación de este modelo se estima para el año 2015, por lo que las empresas tendrán un periodo de tiempo para evaluar los riesgos a los que el negocio está expuesto y en base a los riesgos deberán desarrollar e implementar, entre otros:

• Protocolos de actuación por ejemplo protocolos de evidencias, o de  acceso a los documentos de un trabajador, etc.
• Medidas de control
• Pruebas de las medidas de control
• Controles de proveedores
• Repositorio de evidencias
• Formación de los empleados

En resumen las áreas claves para elaborar el Modelo de Prevención son:

Código Penal (I): Delitos TI

En los últimos años las presiones impuestas por las normativas como Basilea II o Sarbanes-Oxley o bien los requerimientos legales de obligatorio cumplimiento como la LOPD o Blanqueo de Capitales, han supuesto que desde las áreas de Legal y/o Cumplimiento se requiera el conocimiento de los expertos de seguridad TI para incorporar las medidas de seguridad técnicas y organizativas necesarias para cumplir con los requerimientos normativos y legales exigidos.

En esta línea, desde la reforma del código penal, que entró en vigor el 23 de diciembre de 2010, se ha incorporado en el catálogo de riesgos del negocio y en el marco de cumplimiento de las compañías, los riesgos relacionados con la responsabilidad penal de personas jurídicas y su consecuente impacto en el control interno y seguridad TI de la compañía. 

En la siguiente figura se muestran algunos de los delitos definidos en el Código Penal:

Delito	Nivel de riesgo
Descubrimiento y revelación de secretos	ALTO
Delitos relativos al mercado y a los consumidores
Daños informáticos	MEDIO
Delitos relativos a la propiedad intelectual
Blanqueo de capitales
Estafa	BAJO
Pornografía infantil
Falsedades documentales

Algunas de las penas podrían establecerse en:

• Multa por cuotas o proporcional.
• Disolución de la persona jurídica.
• Suspensión de sus actividades por un plazo que no podrá exceder de cinco años.
• Clausura de sus locales y establecimientos por un plazo que no podrá exceder de cinco años.
• Prohibición de realizar en el futuro las actividades relacionadas con el delito

En lo que respecta al área de TI, los riesgos identificados son:

• Acceso no autorizado
• Descubrimiento de secretos y datos personales
• Revelación de secretos y cesión de datos personales
• Estafa informática
• Daños informáticos – Denegación de servicio
• Delito contra la propiedad intelectual – sw sin licencia
• Delitos contra la propiedad industrial – patentes tecnológicas
• Apoyo tecnológico a la comisión de otros delitos (blanqueo)

  

Matriz ejemplo de identificación de riesgos 

La participación del área de seguridad TI en todas las fases del Modelo de Prevención es fundamental para integrar: Procesos de Negocio->Procedimientos de Control Interno->Tecnología -> Seguridad TI.

A grandes rasgos, los principales pasos para el desarrollo del Modelo de Prevención son:

• Análisis global del Riesgo que supone cada delito.
• Recopilación de los controles y evidencias existentes.
• Valoración de la consistencia de los controles y detección de gaps.
• Elaboración del Modelo de Prevención de Delitos.

Externalizar las TIC: Hoja de ruta

Actualmente son múltiples los servicios, procesos, infraestructuras e inclusive gestión técnica que desde el Departamento de Sistemas pueden externalizarse. Desde la realización de la copia de seguridad, gestión del help desk, alojamiento de páginas web, soporte técnico del host, entre otros servicios y/o procesos propios de un Departamento de Sistemas. 

Las actividades relacionadas con la decisión de externalizar y posteriormente depender de un tercero, deben ser cuidadosamente evaluadas en todas las vertientes que tienen impacto en el negocio, como por ejemplo, el impacto financiero, la imagen, la seguridad, el cumplimiento legal y normativo, y demás aspectos que sean identificados, según el tipo de organización, como un impacto negativo. 

Existen cuatro pasos fundamentales a considerar al momento de externalizar. Estos pasos que deben ser evaluados por separado:

• Estrategia
• Selección
• Implementación y
• Gestión 

• La estrategia es el proceso de determinar si es o no necesario externalizar y, si es así, ¿qué externalizar?
• La selección es el proceso de búsqueda y evaluación de posibles socios de outsourcing.
• La implementación es cuando la relación entre los socios de outsourcing está definida y establecida.
• La gestión es el control y la evolución de la relación continuada del servicio de outsourcing.

Cada paso tiene su propio conjunto único de actividades relacionadas para hacer frente a los riesgos que pueden surgir al momento de externalizar.

A continuación se describen las actividades para cada uno de los pasos antes mencionados:

Actividades relacionadas con la Estrategia

• Definir la externalización de funciones “no deseadas” contra la externalización de funciones que proporcionan mayor “ventaja competitiva”.
• Definir claramente las metas y objetivos antes de comenzar el proceso de externalización.
• Establecer una línea de base eficaz para medir los proveedores a nivel de costos, servicio y valor agregado.
• Desarrollar  casos de negocios ajustados a la realidad para la tomar la decisión de externalizar.
• Tomar la decisión de externalizar con la información completa de los costos y de los procesos internos.
• Tener en cuenta el impacto de la externalización y áreas de riesgo, como por ejemplo regulación y cumplimiento normativo.
• Realizar un análisis de riesgos y la planificación de la evaluación de riesgos.
• Considerar los aspectos de mantenimiento, soporte de aplicaciones y operaciones de infraestructura en el outsourcing.
• Definir en los SLAs (basados en contratos), y tomar en cuenta los aspectos de tiempo y recursos para los servicios de outsourcing de desarrollo de aplicaciones o programas.
• Definir un programa para la gestión del outsourcing en términos de evaluación continua, entrega de resultados, cumplimiento de indicadores, notificación de incidentes de seguridad, auditorías internas/externas.

Actividades relacionadas con la Selección

• Incluir los recursos suficientes para gestionar con eficacia el proceso de selección del servicio de  outsourcing.
• Identificar las capacidades internas apropiadas para gestionar eficazmente el proceso de selección.
• Entender o aprovechar los beneficios de una Solicitud de Información (Request For Information - RFI) puede impactar en la reducción del campo potencial del outsourcing antes de entrar en el proceso de Solicitud de Propuesta (Request For Proposal - RFP).
• Recopilar de forma apropiada, amplia y suficiente información de proveedores potenciales del servicio.
• Implicar a todos los responsables para obtener una variedad de perspectivas en el proceso de selección.
• Documentar las especificaciones del servicio o producto que se quiere externalizar.
• Obtener conocimiento de las limitaciones técnicas, de escalabilidad y de seguridad de los proveedores de servicios de outsourcing.
• Hacer que el proceso de selección sea una decisión de negocio y no una decisión personal.

Actividades relacionadas con la Implementación

• Establecer una relación de externalización con suficiente flexibilidad para hacer frente a los cambios del negocio.
• Definir un periodo de tiempo real para cada uno de los pasos del proceso de externalización, incluyendo el inicio.
• Definir a tiempo los Acuerdos de Servicio (SLAs) y solucionar los aspectos operativos y legales.
• Definir el plan de transición con todos los pasos a seguir y aspectos a considerar.
• Planificar las tareas relacionadas con los sistemas de información y la interconexión (interfaces) con el proveedor de servicios.
• Informar al proveedor de los elementos críticos del negocio y de las expectativas del servicio.

Actividades relacionadas con la Gestión

• Tener en cuenta el impacto de un acuerdo de outsourcing en la situación financiera de la organización.
• Definir canales de comunicación interna.
• Definir una estrategia de incentivos al proveedor para la mejora continua.
• Establecer múltiples puntos de contacto entre la empresa y el proveedor.
• Definir un plan de contingencia para las interrupciones en el servicio del proveedor.
• Establecer un plan de comunicación donde se incluyan los procesos de escalamiento, reuniones programadas, periodos de revisión y comunicación con el personal.
• Identificar los "gaps" que impacten en la evolución de los requisitos de externalización.
• Formalizar o documentar las "lecciones aprendidas" sobre la contratación externa y, en concreto, con cada proveedor.

En resumen, a la hora de poner sobre la mesa la opción de externalizar un proceso TI o infraestructura técnica, se debe considerar ejecutar las siguientes actividades o tareas dentro de un programa de trabajo general, a fin de mitigar los riesgos relacionados con la externalización:

• Llevar a cabo una evaluación exhaustiva de las opciones que ofrece el mercado y seleccionar el proveedor que cumpla con todos los requerimientos de seguridad, de servicio, de cumplimiento legal y normativo, técnico,  definidos por el negocio.
• Analizar la estrategia de outsourcing actual, su eficacia e incidentes solucionados para el éxito del servicio.
• Revisar y hacer un benchmark del modelo de entrega de TI actual,  de los servicios y capacidades y crear un mapa de ruta mejorado.
• Diseñar una estrategia de servicios TI de negocio, con un caso de negocio y  el modelo de entrega deseado.
• Rediseñar el modelo operativo de TI y el modelo de contratación de proveedores.
• Implementar el modelo de contratación de proveedores y optimizar los procesos compartidos con los proveedores.

Los 20 controles de seguridad críticos

La prevención es lo ideal pero la detección es una necesidad

Para protegerse contra los ataques, las organizaciones deben:

• Defender sus redes y sistemas de una variedad de amenazas internas y externas
• Estar preparados para detectar e impedir daños en el interior de su organización una vez ésta se ha visto comprometida

Principios fundamentales de un sistema de defensa

• El ataque informa a la defensa. Usar el conocimiento de los ataques reales que han comprometido sistemas para construir defensas prácticas y eficaces. Utilizar los controles que detengan los ataques conocidos del mundo real.
• Priorización. Invertir primero en aquellos controles que supongan la mayor reducción de riesgo y protección contra las amenazas más peligrosas y que se puedan implementar de forma factible en el entorno de TI actual.
• Métricas. Implementar sistemas de medición comunes y acordados que permitan identificar e implementar rápidamente los ajustes necesarios.
• Monitorización. Llevar a cabo un seguimiento continuo que permita probar y validar la eficacia de los controles de seguridad implementados.
• Automatización. Automatizar, en la medida de lo posible, las defensas de manera que las organizaciones puedan obtener mediciones continuas, fiables y escalables del comportamiento de los controles y las métricas relacionadas

Los 20 controles críticos

Los 20 controles críticos de seguridad son un conjunto recomendado de acciones para la ciberseguridad que proporcionan formas concretas y viables de frustrar los ataques más generalizados http://www.cpni.gov.uk/advice/cyber/Critical-controls/

1. Inventario de dispositivos autorizados y no autorizados
2. Inventario de software autorizado y no autorizado
3. Configuraciones seguras del hardware y software en dispositivos móviles, PCs, servidores.
4. Análisis continuo y eliminación de vulnerabilidades
5. Protección anti-malware
6. Seguridad del software de aplicación
7. Control de dispositivos wireless
8. Capacidades de recuperación de datos
9. Análisis de habilidades de seguridad y programas de formación adecuados
10. Configuraciones seguras para dispositivos de red como firewalls, routers y switches
11. Limitación y control de los puertos de red, protocolos y servicios
12. Uso controlado de los privilegios administrativos
13. Defensa del perímetro
14. Mantenimiento, monitorización y análisis de los logs de auditoría
15. Control de acceso basado en la necesidad de conocimiento
16. Control y monitorización de las cuentas
17. Prevención de pérdida de datos
18. Gestión y respuesta a incidencias
19. Ingeniería de red segura
20. Realización de tests de penetración

El objetivo de los controles críticos

El objetivo de los controles críticos es:

• Proteger los activos críticos, la infraestructura y la organización mediante una protección continua y automatizada.
• Reducir los niveles de compromiso, minimizar la necesidad de esfuerzos de recuperación y reducir los costes asociados mediante la monitorización de la infraestructura de tecnología de la información.

Estructura de los controles críticos

Cada control crítico incluye:

• Una explicación de cómo los atacantes explotan activamente la ausencia de este control.
• Un listado de las acciones específicas que las organizaciones están realizando para implementar, automatizar y medir la efectividad de este control:
• Quick wins que proporcionen una sólida reducción del riesgo sin realizar grandes cambios técnicos, en la arquitectura o a nivel de procedimientos y que proporcionen una reducción sustancial y rápida del riesgo en base a los ataques más comunes que sufren la mayoría de las organizaciones.
• Medidas de visibilidad y atribución que mejoren los procesos, la arquitectura y las capacidades técnicas de la organización para monitorizar las redes y sistemas, detectar intentos de ataques, localizar puntos de entrada, identificar máquinas ya comprometidas, interrumpir las actividades de los atacantes infiltrados y conseguir información sobre las fuentes de los ataques.
• Configuración de la seguridad de la información mejorada para reducir el número o magnitud de las vulnerabilidades de seguridad y mejorar las operaciones de los sistemas informáticos con un enfoque en la protección contra prácticas de seguridad pobres por parte de los administradores de los sistemas y de los usuarios
• Sub controles avanzados que utilizan las nuevas tecnologías para proporcionar una máxima seguridad pero que son difíciles de implementar o son más caros que soluciones de seguridad más estándar.

¿Cómo aplicar los controles?

1. Realizar una evaluación inicial que analice lo ya implementado en la organización y detecte áreas de mejora o carencias respecto a los controles.
2. Desarrollar un plan de trabajo donde se establezcan diferentes fases de implementación, los controles específicos que se aplicaran en cada fase y la programación de las mismas en función de consideraciones de riesgo empresarial.
3. Implementar la primera fase. Identificar las herramientas existentes que puedan ser reutilizadas o utilizadas mejor, nuevas herramientas a adquirir, procesos a mejorar y habilidades a desarrollar mediante formación.
4. Integrar los controles en las operaciones. Focalizarse en el seguimiento continuo, mitigación e integración de nuevos procesos en los sistemas de adquisición y gestión de operaciones.
5. Revisar el plan de trabajo definido en el paso 2 y actualizar, repetir las fases 3. 4 y 5.

Riesgos y Auditoría en SAP ERP

En la actualidad factores como la globalización, alta productividad, minimización de tiempos en los procesos de negocio y las cambiantes condiciones del mercado y por ende del negocio, hace que muchas empresas de diferentes sectores y tamaño se planteen la implementación de un sistema que soporte los procesos del negocio y la operativa transaccional de una forma integrada.

Entre muchas de las opciones que hoy día ofrece la industria del software de las aplicaciones y sistemas informáticos, está SAP. SAP ERP es un sistema integrado que puede proporcionar a las empresas herramientas para gestionar la planificación estratégica, controlar sus objetivos y analizar las operaciones. En la siguiente imagen se resumen de forma general las funcionalidades del sistema SAP:

Todas estas funcionalidades suenan muy bien de cara al negocio, sin embargo hay que añadir algunos elementos claves que impactan de forma directa en la integridad, confidencialidad y disponibilidad de la información y transacciones que se procesa en SAP, estos elementos son “riesgo”, “controles”, “Seguridad”.

SAP no escapa a los riesgos tradicionales que afectan a las tecnologías de la información por ejemplo:

• Acceso no autorizado a datos que pueda resultar en la eliminación o alteración de información.
• Ejecución no autorizada de transacciones sensibles que pueden tener impacto en el sistema.
• Errores en el funcionamiento de los programas, como consecuencia de cambios deficientemente probados.
• Cambios no autorizados a tablas de SAP en el entorno de producción que puedan afectar a la integridad de los datos.
• Pérdida potencial de información como consecuencia de errores en la ejecución
• de interfases y procesos.
• Pérdida de información por accesos no autorizados, uso de perfiles con privilegios o deficiencias en copias de seguridad.

Las empresas demandan cada vez más “confianza” sobre la fiabilidad de la información y transacciones del negocio bien se desde el punto de vista contable y/o de gestión para la toma de decisiones. Es por ello que es necesario mitigar los riesgos que puedan impactar en el sistema principal del negocio y en la infraestructura que lo soporta. Mitigar estos riesgos implica un trabajo continuo y basado en el conocimiento de los procesos del negocio, funciones de cada cargo (rol de usuario) y de los objetos y transacciones de SAP.

La identificación de los riesgos debe realizarse a todos los niveles que componen el entorno del sistema SAP, es decir se deben identificar los riesgos a nivel de los procesos, las personas, las instalaciones físicas y de la infraestructura que soporta el sistema SAP. Una visión general de las capas que pueden conformar el entorno del sistema SAP se presenta en la siguiente imagen:

Como se puede observar principalmente son tres capas en las que hay que aplicar medidas para mitigar los riesgos.

Actualmente existen numerosas herramientas para evaluar la seguridad de un sistema SAP y así mitigar los riesgos, un ejemplo es la herramienta de Control, riesgo y cumplimiento regulatorio (Governance Risk and Compliance) propia de SAP. GRC es una solución que puede ayudar a automatizar los procesos de GRC, entre los que se incluyen la supervisión automática de los indicadores de riesgo clave para la eficacia del cumplimiento.

En este punto, digamos que hemos realizado el análisis de riesgos a todos los niveles del entorno SAP y posteriormente hemos definido e implementado los controles para mitigar los riesgos identificados.

El siguiente paso sería auditar los controles implementados para evaluar su funcionamiento y si el control cumple el objetivo que hemos definido. Para esto una vez se define el alcance de la auditoría, por ejemplo revisar la seguridad general del sistema SAP, procedemos a definir las pruebas que ejecutaremos para validar que los parámetros del sistema que componen la seguridad general están en funcionamiento.

Entre algunos de los ámbitos que podemos revisar en el sistema SAP están:

• El control de acceso a programas y datos
• La gestión de cambios a programas y
• Las operaciones de explotación del sistema

En este sentido algunos de los controles implementados son:

• Control de acceso a programas y datos
• Parámetros de configuración de las contraseñas
• Caducidad de la clave de acceso
• Complejidad de la clave de acceso (longitud mínima, caracteres especiales, dígitos, etc.)
• Intentos fallidos de acceso
• Historial de contraseñas
• Bloqueo de sesiones
• Acceso a los objetos críticos de SAP (S_PROGRAM, S_TRANSPRT, S_DEVELOP, S_QUERY, etc.).
• Acceso de ejecutar transacciones críticas (SU10, SU20, SU21, SE16, …).
• Revisión de los perfiles de seguridad como SAP_ALL.
• Revisión de la configuración de los perfiles nativos de SAP (SAP*, …).
• Gestión y revisión de perfiles de usuarios y usuarios genéricos.
• Gestión de cambios a programas
• Listado de Key Users para la aprobación de peticiones de cambio.
• Monitorización y restricción de la capacidad para desbloquear el ambiente de producción y realizar cambios de forma directa (incluido los cambios a las tablas y diccionario de SAP).
• Segregación de funciones en la gestión de cambios incluyendo desarrollo, customización y aprobación de cambio y transporte.
• Usuarios de programación en producción.
• Operaciones informáticas
• Controles de acceso de modificación de trabajos por lotes e interfaces.
• Controles de acceso de trabajos por lotes ejecutados en nombre de otro (ANOTHER).
• Controles de acceso de trabajos por lotes ejecutados por cualquier (ANY).
• Controles de acceso a la gestión de la base de datos.  

Si bien entendemos que el sistema SAP como ERP, es un sistema que puede aportar un alto grado de seguridad en las operaciones, y posee un buen número de controles embebidos en el mismo, tanto configurables como inherentes. También debemos tener en cuenta que esta seguridad tiene que ser configurada, para que sea efectiva.

Y también es importante destacar una característica particular de SAP a la hora de auditarlo, y es que en el mismo no solo se configuran y por consiguiente, se revisan, los controles de aplicación (controles internos del negocio, validaciones de datos, etc) sino que también un gran número de controles de base o generales deben efectuarse en el mismo, ya que desde dentro de un sistema SAP es posible acceder directamente a las tablas de base de datos, ejecutar programas, ver código fuente, ejecutar comandos de sistema operativo, apagar el servicio, realizar debugging, y un largo etc de actividades que en otros sistemas deben controlarse “por fuera de la aplicación” y en el caso de SAP deben controlarse en “ambos niveles”. Y resaltamos “ambos niveles” porque incluso en muchas revisiones de seguridad se pierde el foco y se controlan los permisos dentro del sistema con el fin de verificar controles generales y de aplicación, abandonando un poco el control sobre los otros niveles que conforman el entorno del sistema como por ejemplo los servidores de base de datos.

El CIO como broker de servicios: gestionando entornos híbridos

IDC, en colaboración con HP y ABAST SYSTEMS, organizó el pasado 27 de Junio un encuentro con directivos de empresas y entidades públicas catalanas para debatir sobre el papel de CIO como broker de servicios. Éste es el resumen que Fernando Maldonado, el consultor de IDC que dirigió y moderó la reunión, nos hace sobre las conclusiones del evento.

---------------------------------------------

Los servicios Cloud no sólo están cambiando la forma en la que las empresas evalúan, adquirieren y despliegan tecnología, sino que también trasladan el foco de los departamentos TI hacia la entrega del servicio y la innovación.

Una organización centrada en servicios podrá favorecer el rendimiento de las aplicaciones, conseguir una mayor eficiencia de costes, mejorar la productividad del departamento TI y servir de impulso a la innovación en los procesos de la empresa.

A medida que las empresas vayan intensificando su adopción cloud y evolucione su estado de madurez mediante el desarrollo de una estrategia que abarque a toda la empresa, estas conseguirán separar la capa de servicio del modelo de despliegue y los servicios serán prestados en un entorno híbrido que será a través de cloud privada, pública o modelo tradicional en función del valor aportado y del riesgo asumido por la organización.

El papel que desempeñan los departamentos de sistemas es el de convertirse en un agente de cambio dentro de las organizaciones para lo que es necesario que se produzca un cambio de enfoque, de uno reactivo, vinculado a la actividad de soporte, a otro proactivo vinculado a detectar nuevos servicios no solo TI sino también de negocio.

Con este contexto de fondo, IDC plateó a los asistentes al almuerzo debate: ¿Cómo les afectaba esta transformación como CIOs y qué se exige de ellos?

Contexto.-

Durante el almuerzo, IDC contextualizó la adopción de Cloud y su impacto dentro de las organizaciones en torno a cinco puntos:

• La trasformación de la industria TI está provocando que el departamento de sistemas pase de la periferia al “core” del negocio: resulta difícil encontrar un sector de actividad donde las tecnologías de información no jueguen un papel cada vez más importante en la prestación de un servicio a los clientes o un cambio de modelo de negocio. En otras palabras, es necesario que el papel que desempeñan los departamentos de sistemas pasen de una actividad de mero soporte, enfoque reactivo, a otra de impulsor del cambio, enfoque proactivo.

• La adopción de Cloud Pública se acelera. Hasta ahora el despliegue ha estado marcado por modelos de despliegue que el mercado identifica como privados, pero son los modelos públicos los que en el corto plazo experimentan un mayor crecimiento. Esta evolución desembocará irremediablemente en la convivencia de distintos entornos dentro de la organización y la complejidad de gestionar estos entornos híbridos irán en aumento.

• No existe un único camino a Cloud, cada empresa debe encontrar su propia vía. Las empresas encuentran dificultades en la identificación de qué cargas deben subir a Cloud pública, cuáles a Cloud privada y cuáles mantener en un modelo tradicional. La decisión sobre qué opción elegir depende fundamentalmente de factores endógenos a la empresa (ej. Criticidad de la carga, coste de entrega del servicio, valor aportado, etc.) por lo que no existen referentes claros ni sobre el modelo a utilizar ni sobre el ritmo de adopción.

• Pasar de una aproximación táctica en Cloud a otra estratégica implica cambios en tecnología, procesos y personas. En una primera aproximación a Cloud, lo que las empresas buscan es alcanzar unos menores costes a través de una mayor eficiencia en la gestión de sus activos TI al mismo tiempo que van ganado en agilidad en la provisión de servicios TI. Una visión estratégica debe contemplar una visión trasversal de la empresa y no como un conjunto de soluciones puntuales inconexas para resolver problemas específicos.

• A partir de ahora el foco pasa a la entrega del servicio. Los servicios Cloud están cambiando no sólo la forma en la que las empresas evalúan, adquirieren y despliegan tecnología sino que también trasladan el foco de los departamentos TI hacia la entrega del servicio. Se trata en definitiva de que los departamentos TI se orienten a servicios y para ello van a ser necesarios cambios no sólo tecnológicos sino también organizativos y culturales. Un hito imprescindible en esta reorientación a servicios es la utilización de un catálogo de servicio dinámico que incorpore conceptos de autoprovisión por parte de los usuarios.

Debate.-

Cloud promete una mayor trasparencia en costes, un servicio eficiente y un mejor soporte; pero el debate se centró en la complejidad de llevar esto a la práctica:

• Gestión del riesgo. La evaluación de los servicios Cloud puede ser más confusa y complicada que entender unos KPIs y unos niveles de servicio dados y esto se debe a la necesidad de ir más allá, gestionando el riesgo de negocio detrás de los contratos. De este modo durante el debate las empresas se cuestionaron aspectos como:

• ¿Existe flexibilidad en la negociación de los SLAs que permitan una mayor personalización? Las empresas consultadas por IDC señalaron que actualmente existe escasa flexibilidad y que la mayoría había llegado a acuerdos de adhesión con sus proveedores actuales de cloud, acuerdos que admiten una escasa personalización.
• ¿Cuáles son los mecanismos que permiten verificar que los SLAs se están cumpliendo? El debate respecto a la verificación de SLAs puso de manifiesto la necesidad establecer alguna metodología que permita verificar que los acuerdos se cumplen. Además, también se trató del incremento del coste de ejercer el derecho a auditorías en el data center del proveedor por efecto de la deslocalización.
• ¿Cuáles son los límites de las indemnizaciones cuando el proveedor no cumple con el servicio prometido? Actualmente, las empresas participantes en el debate, destacaron los limites en la responsabilidad de los proveedores, y más concretamente las indemnizaciones, eran un impedimento para subir cargas críticas a entornos Cloud. En casos de incumplimiento grave del servicio, la compensación representa en general un porcentaje del valor del contrato anual lo que es percibido como alto riesgo para su negocio.
• ¿Cuáles son los costes de salida? Pese a que los proveedores están trabajando en una mayor estandarización que permita a los clientes moverse de una cloud a otra, los riesgos asociados actualmente a la reversibilidad del modelo siguen estando presentes y debe ser un aspecto que necesariamente debe ser negociado de antemano.

• Cada empresa debe encontrar su propio camino a cloud. Las empresas representadas en el debate, empresas medianas y grandes, han llegado a Cloud Privada por evolución y una vez ahí comienzan…

• Cloud por evolución. Las empresas consultadas por IDC admiten que a Cloud Privada llegan como evolución natural: primero consolidando sus data center, luego virtualizando, incorporando herramientas de automatización, orquestadores y finalmente portales de autoservicio. Estas mismas empresas destacan la necesidad de cubrir todas las etapas antes de estar en condiciones de dar el salto a Cloud, si bien algunas reconocen que la automatización y orquestación son todavía asignaturas pendientes.

• Aprendiendo a compartir. La creciente madurez de la oferta se refleja en que las empresas tienen cada vez una mayor capacidad de elección en torno a los modelos de despliegue de Cloud. De este modo, durante los últimos años han aparecido distintos tipo de Cloud privada que van desde la Cloud privada gestionada a Cloud privada dedicada (en el segundo se comparte más que en el primero). Actualmente la demanda se está produciendo en Cloud privada gestionada donde la infraestructura es, y se ubica en instalaciones, del cliente y el proveedor se encarga de su gestión.

• Broker de servicios. A medida que las empresas vayan intensificando su adopción Cloud, las empresas tendrán que coexistir en un entorno híbrido donde cada carga se adapte de forma dinámica al mejor modelo de despliegue en función del valor aportado y del riesgo asumido por la organización. La complejidad de gestión de estos entornos se convertirá en una de las principales prioridades de los departamentos de sistemas que tendrán que llevar a cabo una gestión del cambio en tanto que afectará no sólo a sus capacidades tecnológicas sino también a los procesos y las habilidades de las personas que componen el departamento.

• Seguridad del dato. El principal inhibidor en la adopción del modelo Cloud sigue siendo la seguridad, entendida como seguridad del dato. Si bien, durante el debate se identificaron algunos aspectos que hacen que la sensibilidad de una empresa sea mayor o menor. Así por ejemplo, para el sector financiero, bufetes de abogados o entidades públicas la seguridad del dato resulta más crítica que para otros sectores. Detrás de esta distinción sectorial se encuentran aspectos de carácter regulatorio.

Opinión de IDC

En opinión de IDC el resumen del debate originado en torno a adopción de Cloud refleja la creciente madurez de las empresas que a pesar de reconocer tener una aproximación eminentemente táctica a Cloud apuntan a la necesidad de definir una estrategia global de empresa en un contexto en el que se están reorientando a servicios.

Que gran parte del debate se produjera en torno a la gestión de los contratos del servicio y de los riesgos y beneficios para el negocio es buena prueba de ello. Así como las contantes referencias a la necesidad de realizar una gestión del cambio que incluya tecnología, procesos y personas.

Tal y como apuntó un asistente al debate "Cloud está aquí para quedarse" y ahora es el momento de definir una estrategia en torno a su adopción.