SUPERINTENDENCIA DE BANCOS Y ENTIDADES FINANCIERAS “Consultoría en Auditoría de Sistemas a la Unidad de Sistemas de Información” Trabajo Adicional Enero de 2002
SUPERINTENDENCIA DE BANCOS Y ENTIDADES FINANCIERAS PROYECTO DE CONSULTORIA EN AUDITORIA DE SISTEMA A LA UNIDAD DE SISTEMAS DE INFORMACION INDICE I.
OBJETIVO
II.
ALCANCE
III. RESUMEN EJECUTIVO III.1
Conclusión general
III.2
Conclusiones específicas
IV.
RECOMENDACIONES
IV.1. Resumen de recomendaciones IV.2 V.
Detalle de recomendaciones RESULTADOS OBTENIDOS
I.
OBJETIVO El objetivo de nuestro trabajo fue evaluar la adecuada administración de los recursos tecnológicos y humanos del área de sistemas, así como la estructura de control existente en los sistemas que soportan los procesos de negocio para emitir una opinión respecto al ambiente de control existente en el procesamiento electrónico de datos.
II.
ALCANCE Si bien el alcance del trabajo efectuado se basa en los términos de referencia definidos en nuestra propuesta, hemos querido dar un valor agregado adicional en cuanto a la visión de los aspectos notados desde un punto de vista de la función informática a nivel de toda la organización. De este modo la Superintendencia de Bancos y Entidades Financieras (SBEF) dispondrá de mejor información para tomar acciones de mejora más efectivas y de forma mas focalizada.
II.1 INTRODUCCION De acuerdo a lo relevado en el transcurso de nuestro trabajo, la SBEF nos ha trasmitido su preocupación por lograr la optimización de la efectividad y eficiencia de su función informática, apuntando al logro de sus objetivos institucionales. Queremos hacer notar que cuando nos referimos a la función informática, lo hacemos como a una función general de toda la organización, y no debe ser confundida con el área informática, que si bien es una parte importante de esta función, no es la única que la compone. Nuestra intención es plantear las medidas requeridas por la función informática, basándonos en los hallazgos surgidos de la ejecución de nuestro programa de trabajo detallado. De este modo, la SBEF obtendrá una visión clara de su problemática general, comprendiendo las relaciones causa-efecto existentes entre los hallazgos obtenidos. Estas relaciones a las que nos referimos, difíciles de identificar sin un estudio profundo del entorno general en el que se opera, son parte importante del valor agregado adicional que obtendrá la SBEF de nuestro trabajo. Enfoque de las conclusiones generales Como ya mencionamos anteriormente, hemos estructurado los resultados obtenidos en torno a tres niveles, referidos a la función informática de la SBEF:
Gestión informática (planificación estratégica de la Institución y de sistemas)
Desarrollo y adquisición de aplicaciones (planificación táctica y entrega) Operación y soporte de sistemas (soporte a las aplicaciones existentes)
2
Analizando estas áreas en un contexto más amplio, podemos representarlas dentro del siguiente gráfico.
Modelo de administración de sistemas
Planificación estratégica de la institución
Necesidades del negocio
Administración del Negocio
Planificación estratégica de sistemas
Soporte a las aplicaciones existentes
Proyectos prioritarios
Planificación táctica de sistemas
Nuevos Cambios
Entrega de Aplicaciones
Conjunto de aplicaciones nuevas
Administración de Sistemas
Cultura Informática
Este modelo contiene seis componentes operación de los servicios informáticos. informática provienen de aspectos que aplicando este modelo de alto nivel. Los
básicos asociados con la provisión y Muchos de los problemas del área pueden ser fácilmente identificados seis componentes del modelo son:
Planificación estratégica de la institución. El máximo órgano ejecutivo de la institución debe determinar los requerimientos que tienen los sistemas, si es que los hay, para el soporte de los planes del negocio. Tradicionalmente los sistemas de información no han sido vistos como una ventaja competitiva potencial y por lo tanto pocas organizaciones tienen procesos o capacidades para examinar el uso estratégico de la informática para maximizar sus beneficios para el negocio. El resultado de este proceso tiende a ser un conjunto de requerimientos del negocio o pedidos de proyectos;
Planificación estratégica de sistemas. La gerencia de sistemas debe cubrir dos actividades básicas: el soporte permanente del conjunto de aplicaciones existentes y el desarrollo de nuevas aplicaciones (o mejoradas). El proceso de planeamiento estratégico atiende estas necesidades por medio de la asignación de los limitados recursos de sistemas al soporte y desarrollo, identificando una arquitectura de sistemas y conjunto de herramientas que facilitará las tareas de desarrollo y operación, y estableciendo procesos de priorización para la atención de requerimientos. El proceso involucra a la gerencia del negocio y a la de sistemas, el resultado de este proceso tiene
3
dos contenidos principales: una lista de proyectos priorizados y la asignación de recursos;
Planificación táctica de sistemas. Una vez que el proceso de priorización ha identificado que proyectos se van a iniciar, el proceso de planificación táctica identifica la forma en que los proyectos serán estructurados y gerenciados. Esto incluye aspectos como la asignación de un gerente de proyecto, determinación de las herramientas de gerenciamiento que serán utilizadas, establecimiento de la estructura del proyecto, organización de adecuados vínculos y definición de las responsabilidades de los diversos participantes. Mientras que este proceso puede ser llevado adelante por la gerencia de sistemas, el gerente del proyecto asignado puede a menudo provenir de la gerencia del negocio. El resultado de este proceso deben ser proyectos para nuevas aplicaciones o para la realización de cambios a los actuales sistemas;
Entrega de aplicaciones. Una vez que los proyectos de han estructurado y los recursos se han asignado, un proceso separado se lleva a cabo para entregar el proyecto terminado, ya sea en la forma de una nueva aplicación o de un cambio a una ya existente. Este proceso esta relacionado con los aspectos del día a día del gerenciamiento de proyectos y la calidad de integración entre el personal de sistemas y del negocio para asegurar la entrega exitosa del proyecto. La salida de este proceso debe ser el nuevo conjunto de aplicaciones existentes;
Soporte a las aplicaciones existentes. Este proceso se relaciona con el gerenciamiento y soporte del conjunto de aplicaciones existentes. Esto incluye a las aplicaciones en sí mismas, el grado de cobertura que proveen a las necesidades del negocio, el mantenimiento y soporte de estas aplicaciones y las operaciones del computador relacionadas. La información acerca del conjunto de aplicaciones existentes es utilizada como insumo para proceso de planeamiento estratégico de sistemas, para determinar la mejor forma de cumplir con los requerimientos del negocio;
Cultura informática. Este proceso provee una visión de alto nivel sobre la información provista en el análisis que procede y ayuda a la gerencia a identificar necesidades de cambio de la postura de la organización en general con respecto a los sistemas de información, con el fin de emprender el desarrollo de nuevos productos o servicios.
4
III.
RESUMEN EJECUTIVO Con el objeto de facilitar la lectura del presente informe, a continuación presentamos un resumen ejecutivo, de los aspectos más relevantes que han surgido como resultado de nuestro trabajo.
III.1 Conclusión general Confiabilidad, integridad y adecuación a normas vigentes.
-
Como resultado de nuestro trabajo, hemos detectado aspectos que afectan la confiabilidad, integridad y adecuación a normas vigentes de los sistemas y su información, entre los que se destacan los siguientes: los ambientes de desarrollo y producción no se encuentran separados, los roles y responsabilidades del personal involucrado en el ciclo de vida de desarrollo de sistemas (programadores, usuarios, operadores, gerencia, etc.) no están claramente definidos, las tareas de desarrollo e implantación en el ambiente de producción no están segregadas, y no se cuenta con normas ni procedimientos para realizar pruebas de los nuevos desarrollos, con participación del usuario final en su ejecución y constancia formal de su conformidad con el producto final. Confidencialidad
-
Dentro del diseño general del ambiente de seguridad hemos visto aspectos que afectan la confidencialidad de la información, y deben ser mejorados en cuanto a: segregación inadecuada de las funciones de administración de seguridad, segregación inadecuada de otras funciones técnicas de sistemas (por ejemplo: desarrollo e implantación en el ambiente de producción) el mecanismo de asignación, modificación y construcción de contraseñas no cumple con las mejores prácticas, no se cuenta con funciones de auditoría interna de sistemas, no se cuenta con una clasificación de la información en cuanto a su criticidad (que incluye el concepto de confidencialidad) y por lo tanto tampoco con medidas de protección asociadas a cada categoría. existen oportunidades de mejora en la seguridad física (piso falso, paredes de vidrio, alarmas de incendio, detectores de humo, etc.) Asimismo, es necesario contar con una mayor formalización y estandarización de los procedimientos relacionados con la administración de seguridad. Eficacia, eficiencia y oportunidad.
5
-
Consideramos que la Unidad de Sistemas de Información tiene una serie de debilidades que afectan la administración de los recursos tecnológicos y humanos del área. Entre los aspectos más importantes podemos mencionar: falta de formalización de procedimientos, la estructura organizacional de la USI no refleja su realidad actual, falta de áreas de apoyo (O&M y Auditoría Interna de Sistemas), inadecuado proceso de elaboración del plan estratégico de sistemas y planificación de tareas, falta de mecanismos claros de priorización de trabajos, falta de definición de roles y responsabilidades dentro de la unidad y para las áreas usuarias. Disponibilidad Hemos detectado que existen una serie de debilidades en esta área, entre las que podemos mencionar:
respaldo
no existe Plan de Contingencia del negocio no existe uniformidad en la obtención y custodia de copias de
III.2 Conclusiones específicas a. Cultura Informática Uno de los aspectos clave que se deben tener en cuenta en el diseño de la función informática es su marco de funcionamiento, fijado por la cultura de la organización en cuanto a los sistemas. La medida de esta evaluación es un componente fundamental que fija la dirección y el orden de magnitud de las acciones a tomar para la mejora de la eficacia y eficiencia de la gestión informática de la Institución. Para realizar nuestra evaluación hemos utilizado los criterios de niveles de madurez en el uso de la tecnología, y en el proceso de incorporación de software. Nivel de madurez en el uso de la tecnología Hemos realizado la evaluación del nivel de madurez aplicando los conceptos de Gibson y Nolan (1974 y 1979) que identifican entre cuatro y seis niveles de madurez:
Inicio: la aplicación de la tecnología es incipiente, hay pocos ejemplos aislados y los sistemas tienen orientación operativa
6
Contagio: conocidos los beneficios de la aplicación de sistemas, se desarrollan múltiples aplicaciones para distintas áreas de la organización mayormente no integradas entre si.
Control: la organización es consciente del poder de la información contenida en los sistemas y la usa para controlar su negocio.
Integración: las aplicaciones comienzan a integrarse mas fuertemente, para lograr visiones integrales de los procesos y del negocio.
Estratégico: la organización comprende la importancia de los sistemas y los utiliza como herramientas para lograr ventajas en sus áreas estratégicas
Creación de conocimiento: se usan herramientas especiales para el relacionamiento de datos a niveles superiores a los de las transacciones (p.ej: data mining, CRM, etc.) Basados en esta clasificación, podemos estimar un nivel de madurez de la SBEF cercano al estado de control. Nivel de madurez en el proceso de incorporación de software Hemos realizado la evaluación del nivel de madurez aplicando el modelo de madurez de software de Watts Humphrey's, que identifica cinco niveles:
1. Inicial o ad hoc: caótico, costos plazos y calidad impredecibles 2. Repetible: intuitivo, costos y calidad ampliamente variables, control razonable de plazos, procedimientos y metodologías informales y ad hoc 3. Definido: cualitativo, costos y plazos confiables, en proceso de mejora de la calidad pero impredecible. 4. Gerenciado: cuantitativo, razonable control sobre la calidad del producto 5. Optimizado: bases cuantitativas para la inversión continua en procesos de automatización y mejora. Como resultado de los procedimientos aplicados y basados en esta clasificación, podemos estimar que el nivel de madurez en el cual se encuentra la SBEF es 3. De acuerdo a nuestra evaluación, podemos estimar que la SBEF se encuentra en niveles medios de madurez de su cultura informática. La mejora de este indicador no se logrará con medidas o acciones puntuales, sino que requerirá un proceso continuo, liderado por los niveles más altos de la Institución. En líneas generales este proceso deberá formalizar y estandarizar los procesos informáticos en mayor medida, enfatizando que son procesos que involucran a toda la organización.
7
b. Planificación estratégica Hemos apreciado la existencia de un proceso de planificación estratégica a nivel del negocio, cuya metodología se encuentra delineada en el documento “Reglamento Específico del Sistema de Programación de Operaciones”. Durante el presente año la SBEF ha seguido los lineamientos definidos en dicho documento y realizado un proceso que culminó en la formulación de una serie de objetivos institucionales de la SBEF y los planes operativos anuales (POAs) a nivel de cada una de sus distintas áreas. Metodológicamente, estos POAs a nivel de área se han alineado sobre la base de los objetivos institucionales planteados y llevados a un nivel mas operativo en las llamadas “fichas técnicas”. Si bien la metodología de planificación estratégica que se aplica en su definición cumple con las mejores prácticas, sus resultados en cuanto a la previsión de los trabajos del área informática no se ven cumplidos, ya que hemos observado un alto porcentaje de tareas no planificadas que habitualmente realiza la USI. De acuerdo al trabajo realizado, observamos que esta situación tiene su origen en la falta de una definición formal de los requerimientos de las áreas usuarias en sus fichas técnicas, identificando claramente los objetivos, productos y plazos. Asimismo, el proceso de los POAs de las distintas áreas debería contar con la participación de la USI, que las asesoraría en cuanto a posibles proyectos de automatización y definiría los lineamientos generales de los proyectos a llevar a cabo por la USI. Asimismo, es importante incorporar políticas orientadas a establecer que este procedimiento es el canal formalmente establecido para la incorporación de requerimientos al área de sistemas y que solamente los requerimientos definidos en esta instancia serán incorporados en el POA de la USI. Excepcionalmente, un requerimiento adicional, solicitado en forma posterior, podrá ser evaluado, priorizado y aprobado por el comité de sistemas para su incorporación en el POA de la USI. En este proceso, las distintas áreas también asignarían prioridades a los requerimientos realizados a la USI. Una vez terminado el proceso de elaboración de los POAs, e identificados todos los proyectos requeridos a la USI, esta realizaría una estimación primaria del esfuerzo requerido para su cumplimiento. En base a esta información, el comité de informática definiría el conjunto de proyectos a llevar a cabo en la gestión, sus prioridades, y opciones preliminares de implantación. Con esta información la USI elaboraría su POA, que en los hechos se consolidaría como el plan informático anual de la superintendencia. Cada ficha técnica así definida debería incluir los datos básicos de definición de un proyecto: plazos, recursos, tareas, responsables, dependencias externas e internas, servicios subcontratados, presupuesto, etc.
8
El comité de informática aprobaría el POA de la USI, junto con su presupuesto, y posteriormente sería el encargado de su seguimiento y de la aprobación de sus cambios. Este mecanismo permitiría asignar los recursos informáticos a las áreas más importantes. Con el proceso arriba descripto, la superintendencia podría definir indicadores asociados al cumplimiento de los objetivos específicos planteados, que permitieran medir la performance de la USI y de las otras áreas involucradas en los procesos informáticos. Este proceso tal como lo hemos descripto, debe estar enmarcado en la estrategia informática de la USI en cuanto a aplicaciones, equipamiento y dotación. c. Estructura organizacional y segregación de funciones Existen varios aspectos que deben ser mencionados. En primer lugar, como tema estructural más relevante, la estructura organizativa de la USI no contempla la asignación real de funciones, existiendo por ejemplo personas que desempeñan funciones de supervisión sobre personal que jerárquicamente es su par, lo que dificulta el establecimiento de efectivos procedimientos de control y supervisión. Asimismo, existen casos de funciones que no están debidamente segregadas, como por ejemplo desarrollo e implantación de sistemas de soporte a usuarios y seguridad de operación, lo que afecta a la integridad, confiabilidad y confidencialidad de la información procesada por los sistemas. Actualmente el servicio está estructurado en base a una asignación de personas a aplicaciones o áreas, que en los hechos se traduce en que las funciones de “help desk” son desempeñadas por los técnicos asignados a los sistemas en dónde se originan los incidentes. Esta función en la que todo el personal de sistemas se encuentra en la primera línea de atención a usuarios, le resta eficiencia, al tener que atender todo tipo de consultas (se ha estimado en un 13% del tiempo total de la unidad como dedicado a esta función), desde las más sencillas hasta las técnicamente más complejas. Creemos que se debería crear formalmente la función de “help desk”, responsable de la recepción y atención primaria de los incidentes. Sólo los incidentes que no pudieran ser resueltos en esta primera instancia, deberían ser derivados a los técnicos responsables. Este proceso debería ser apoyado por un software que automatizara el proceso de atención, y a la vez realizara estadísticas acerca del origen y tipo de incidentes, tiempo de respuesta y resolución, etc. Un aspecto importante que debe ser notado en la estructura de funciones vinculadas a la función informática es la debida asignación de roles y
9
responsabilidades que le competen a las áreas usuarias, que deben ser desarrollados bajo la premisa de que el usuario es el dueño final de los datos, y que el área informática en este proceso desempeña una función de servicio (disponibilizar los sistemas para el procesamiento de la información). En relación al párrafo anterior, actualmente existe un comité integrado por todas las intendencias, que se encarga de la definición y seguimiento de los proyectos informáticos. Sugerimos enmarcar las actividades, roles y responsabilidades de dicho comité en cuanto a las necesidades de control y monitoreo del plan de sistemas (tal como mencionáramos en la sección “planificación estratégica”). La Institución no cuenta con la función de auditoria interna de sistemas, responsable natural del control del cumplimiento de las directivas emanadas de su órgano director. Consideramos de gran importancia la incorporación de esta función, como parte de un proceso de mayor formalización y control de las actividades informáticas. La Institución tampoco cuenta con una función, formalmente establecida, de Organización y Métodos, que sea encargada de la implantación de las políticas definidas por la Gerencia dentro del vínculo entre los sistemas y los procedimientos de usuario. Esta función podría tener a su cargo las tareas de confección de normas de documentación de los sistemas para el usuario, eventualmente elaboraría la documentación de sistemas de desarrollo interno, controlaría la documentación entregada por proveedores externos, asesoraría a las Intendencias en cuanto a cambios en los procesos y eventualmente sería la encargada de atender los incidentes no técnicos de los sistemas referidos por la función de “help desk” (p.ej. los originados en desconocimiento de los sistemas). Si bien la Unidad de Desarrollo Operativo desempeña actividades para normar los procedimientos de la SBEF, no se le ha designado formalmente la responsabilidad y las funciones equivalentes a las de O&M. d. Normas y procedimientos Si bien en general hemos comprobado la existencia de normas y procedimientos del área informática, las mismas registran diferentes grados de formalización. La mayor formalización se puede encontrar en las áreas más técnicas, como ser desarrollo de aplicaciones y configuración de equipos, mientras que en otras (ej: pruebas de sistemas, pasajes a producción, administración de seguridad) la formalización es menor. Esta falta de documentación de los procedimientos no permite evaluar su cumplimiento, adecuación y estabilidad.
10
Dentro del proceso de formalización de los procedimiento informáticos se debería prestar atención a los aspectos de: custodia de programas fuente, prueba y aprobación de programas por parte de los usuarios, y pasajes a producción. Asimismo se deberían definir para todos los ambientes de procesamiento, sus correspondientes ambientes separados de desarrollo y prueba, aspecto que hoy no se cumple totalmente para todas las plataformas. e. Desarrollo y adquisición de aplicaciones Hemos observado que existen ocasiones en las que la USI no participa en la definición de los proyectos que involucran la incorporación de software o hardware. Esta modalidad de trabajo dificulta la planificación de la USI, a la vez que no permite mantener estándares tecnológicos y de calidad de los sistemas (cada proyecto externo es realizado con su propia metodología y enfoque), todo lo cual termina impactando en el costo final de operación. Dentro de los aspectos mencionados en la sección de “Planificación estratégica de la Institución”, se incluyen aspectos que propician la elaboración en forma más oportuna del POA de sistemas y su interrelación con los POAs de las otras áreas. Estos aspectos deben ser la base que asegure la participación adecuada de la USI en los proyectos de desarrollo y adquisición de aplicaciones. Dentro de los principales aspectos a ser considerados por la Institución para su implantación se encuentran:
Definición de roles y responsabilidades de áreas usuarias y de sistemas Implementación de estándares mínimos a exigir (participación de áreas técnicas, tecnología, documentación, capacitación, etc.) Establecer mecanismos de aprobación y seguimiento de proyectos Implementar normas y procedimientos formalmente establecidos para la definición, control y gestión de proyectos de desarrollo e implantación de aplicaciones. De acuerdo a lo relevado, una parte importante de los desarrollos realizados por la USI se orientan a la generación de información especial para las áreas usuarias. Estimamos conveniente que la Institución considere la adquisición de herramientas de usuario final orientadas a la extracción y análisis de información (ej: generadores de reportes, como también herramientas de datawarehousing que podrían contribuir a la obtención de información estadística o consolidada).
f. Operación y soporte de sistemas
11
Seguridad física De acuerdo al trabajo realizado, hemos visto que la sala del computador no cuenta con los siguientes dispositivos o medidas de protección: detectores de humo, alarma contra incendios, alarma contra intrusos. Asimismo, estimamos conveniente mejorar las medidas de protección física, sellando las ventanas y sustituyendo las divisiones de vidrio por paredes. Estas medidas deberían ser extendidas en la medida de lo aplicable al resto de las áreas de sistemas, donde también residen equipamiento, documentación e información. -
Asimismo, hemos observado que: Existen ocasiones en que las puertas de acceso al ambiente de sistemas permanecen abiertas, Personal ajeno a sistemas accede a la sala del computador sin la real necesidad. No se poseen armarios ignífugos para el almacenamiento de las cintas de respaldo. Por otro lado, es importante mencionar que las actuales instalaciones físicas de la USI no han sido diseñadas específicamente para tal fin, lo cual no contribuye a la solución de los aspectos antes mencionados. Estos aspectos inciden directamente en la disponibilidad y confidencialidad de la información. Seguridad lógica Existen varios aspectos a mejorar en cuanto a la seguridad lógica:
La función de administración de seguridad no esta formalmente asignada y segregada de funciones incompatibles. No se cuenta con políticas, normas y procedimientos formalmente establecidas. Los mecanismos de administración de usuarios y contraseñas no cumple con las mejores prácticas ni con las normas internas. Por ejemplo: otorgamiento de autorizaciones de acceso basado en la premisa necesidad de conocer, necesidad de hacer, autorizaciones formales para alta o modificación de usuarios, reglas para la construcción de claves (longitud mínima, caducidad, reglas de construcción, etc.) No se cuenta con mecanismos de control y supervisión de las actividades de seguridad.
12
No se cuenta con una clasificación de la información en cuanto a su criticidad y por lo tanto tampoco con medidas de protección asociadas a cada categoría definida. Operación
-
De acuerdo al trabajo realizado, hemos notado los siguientes aspectos relacionadas a esta área: Como ya lo mencionáramos, los operadores desempeñan funciones vinculadas a la administración de seguridad. No se cuenta con procedimientos formales de control de los trabajos de operación (revisión de bitácoras, logs), ni se deja evidencia de las revisiones. No existen cronogramas de operación formalmente documentados. No existen normas para la ejecución de tareas de mantenimiento y limpieza de los discos de los sistemas. Existen deficiencias en la administración de copias de respaldo (backups) Queremos mencionar que las tareas de operación relacionadas con el procesamiento de datos no tienen un alto grado de complejidad, por lo que la implantación de estos aspectos no debería ser costosa. Plan de contingencia La SBEF no cuenta con plan de contingencias del negocio, sólo se cuenta con un plan de recuperación operativo de sistemas. Asimismo, tampoco se han definido los procedimientos formales para la capacitación del personal de sistemas en los procedimientos definidos en el plan de contingencias.
13
IV.
RECOMENDACIONES
IV.1 RESUMEN DE RECOMENDACIONES A continuación presentamos un resumen de los hallazgos que surgieron como resultado de la aplicación de los procedimientos previamente definidos. Dichos hallazgos han sido clasificados en función a la prioridad que consideramos se le debería dar para la implementación de las soluciones sugeridas. A: A.
Alta
M:
Media
B:
Baja
GESTION DE LA UNIDAD 1. 2. 3. 4. 5. 6. 7. 8. 9. 10 . 11 . 12 .
B.
Hallazgo Reestructurar la participación de la USI en el proceso de elaboración de los POA´s de las áreas usuarias Planificación estratégica de Sistemas Consolidar el Comité de Sistemas Adecuar la Estructura organizacional Consolidar las funciones de apoyo de Auditoría de Sistemas y Organización & Métodos Definir mecanismos para la rotación de personal Planificar la carrera para el personal de la USI Implantar un sistema de control presupuestario Normar la adquisición de sistemas y/o servicios de desarrollo de sistemas Definir normas y procedimientos de derechos de autor
A A A A M M B M M B
Reestructurar el plan de capacitación
B
Definir normas e implantar procedimientos para la Administración de la calidad
M
DESARROLLO, ADQUISICION E IMPLANTACION DE SISTEMAS 1. 2. 3. 4.
Definir módulos de seguridad y de auditoria para los sistemas Definir estándares formales para la codificación de los sistemas Definir una metodología formal para realizar pruebas a los sistemas Establecer un ambiente de pruebas para los sistemas basados en
M M A A
14
5. 6. 7. 8. 9. 10 . 11 . 12 . 13 . C.
informix Definir procedimientos para la custodia de código fuente Definir procedimientos formales para realizar pases a producción Definir procedimientos para la implantación de los sistemas Definir la participación de auditoría interna en la implantación de los sistemas Definir un plan de contingencias para la continuidad del negocio Definir procedimientos formales para el monitoreo continuo del hardware Definir acuerdos de nivel de servicio entre la USI y las áreas usuarias Definir una metodología para la administración de proyectos Definir procedimientos proyectos externos
para
administrar
la
calidad
de
A A M M A M B A
los
M
Restringir el conocimiento de claves de usuario por parte de la USI Modificar la parametrización de los passwords Parametrizar el control de algunas características de los passwords Aplicar las normas y procedimientos para el alta de usuarios Definir un documento específico para el acceso de usuarios a la red. Separar las áreas de desarrollo y producción Definir normas y procedimientos para la clasificación de datos Definir normas y procedimientos para el manejo de incidentes Definir la elaboración de reportes de violación Definir una política para el uso de Internet
A
Mejorar la seguridad física
A
Completar la documentación de las configuraciones
M
Mejorar la administración de los backups
A
Documentar las operaciones
M
Definir procedimientos para la protección de los datos
M
Mejorar los parámetros de seguridad del sistema Unix
B
Mejorar los parámetros de seguridad de los sistemas Windows NT
M
OPERACION Y SOPORTE DE SISTEMAS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17
A A A M A M M M M
15
.
y Windows 2000
16
IV.2 DETALLE DE RECOMENDACIONES I.
GESTION DE LA UNIDAD
1.
Reestructurar la participación de la USI en el proceso de elaboración de los POA´s de las áreas usuarias Como resultado de la revisión de las fichas técnicas hemos observado que las mismas no reflejan en forma clara y específica las necesidades de apoyo que las áreas de la SBEF requerirán de la USI, lo cual dificulta, entre otros, los siguientes aspectos:
Identificación de necesidades de información de las áreas usuarias. Identificación de nuevos desarrollos. Mantenimiento de estándares de hardware y software de base. Mantenimiento de estándares de desarrollo. Identificación de oportunidades de proyectos no mencionados como tales. Priorización de proyectos. Previsión de esfuerzos de desarrollo y mantenimiento. Establecimiento de estrategias de hardware y software.
Por todo lo mencionado anteriormente y de acuerdo a las mejores prácticas de la industria es recomendable que las fichas técnicas especifiquen claramente las tareas a ser desarrolladas por cada intendencia de forma tal que cada ficha técnica refleje un proyecto específico, en el cual se debe mencionar claramente el tipo de apoyo que se requiere de la USI para dicho proyecto. Dentro de este proceso, la metodología debería ser complementada con las definiciones mínimas que deben ser proporcionadas para la definición de un proyecto de la USI en esta etapa de elaboración de los POAs. El desempeño por parte de la USI del rol de asesor interno será de gran beneficio a las áreas usuarias en el proceso de generación de sus fichas técnicas ya que permitirá utilizar su experiencia en la definición de proyectos que cuenten con el soporte tecnológico y proponer nuevos mecanismos de automatización de procesos y/o implementación de nuevos sistemas. De este modo, una vez elaboradas las fichas técnicas de las áreas usuarias, la USI deberá tomar los proyectos en ellas incluidos como base para elaborar sus propias fichas técnicas. 2.
Planificación Estratégica de Sistemas
17
Como resultado del trabajo realizado, observamos que la función informática no está plenamente integrada al proceso de planificación estratégica de la SBEF de forma tal que se pueda elaborar en forma oportuna y eficaz el plan estratégico de sistemas. La elaboración de un Plan Estratégico de Sistemas (Strategic Information Systems Planning – SISP) incluye el proceso de desarrollo de un plan del uso de la tecnología de la Información dentro de la organización, el cual debe estar alineado con las necesidades operativas y con las prioridades gerenciales desde el punto de vista del costo/beneficio. Un SISP debe reflejar claramente los siguientes aspectos: a) Identificación de posibles implantaciones b) Definición de los estándares de hardware y software de base que serán adoptados. c) Identificación de necesidades de información de las áreas usuarias d) Identificación de oportunidades de proyectos. e) Priorización de proyectos f) Definir las estrategias de desarrollo g) Cuantificar los esfuerzos de desarrollo y mantenimiento. h) Definición de las estrategias de HW y SW. La implantación de las medidas mencionadas en la recomendación 1 (Reestructuración de las “Fichas Técnicas”) abordaría los aspectos a), c) y d). El control y monitoreo llevado a cabo por el comité de informática (descripto tanto en el resumen ejecutivo como en la siguiente recomendación) abordaría el aspecto e). Como elementos restantes, la USI debería definir los aspectos b), f), g) y h). Si bien hemos observado que la USI cuenta con un Plan Estratégico, el cual incluye las tareas a ser desarrolladas a fin de contribuir al logro de los objetivos estratégicos de la SBEF, es importante considerar los aspectos anteriormente mencionados. 3.
Consolidación del Comité de Sistemas Como resultado de los procedimientos aplicados observamos que si bien se ha designado un comité de sistemas, el mismo no ha tenido las reuniones con la periodicidad inicialmente establecida y los resultados obtenidos no han sido los inicialmente establecidos. Consideramos que la situación anteriormente planteada es totalmente explicable considerando que el área de sistemas no cuenta con un plan de trabajo que muestre claramente las tareas que serán desarrolladas y que un
18
porcentaje muy importante de sus actividades son tareas no planificadas, aproximadamente más del 60%. Bajo esta situación es evidente que las reuniones del comité de sistemas pueden llegar a ser repetitivas e ineficientes debido a que constantemente la USI recibe requerimientos que no estaban previamente contemplados. Sin embargo, es importante que la función del comité de sistemas sea plenamente establecida en la SBEF ya que su rol es de suma importancia para la toma de decisiones en lo que a la planificación, priorización, aprobación, monitoreo y control de trabajos se refiere. Asimismo, es importante mencionar que es este comité es la instancia adecuada y recomendable para tomar decisiones relacionadas, entre otras, con:
Gastos no planificados, Contratación de personal adicional, Contratación de consultorías, Coordinación de los trabajos de desarrollo y/o modificación de sistemas a fin de posibilitar la participación oportuna y adecuada de las áreas usuarias. De esta forma las decisiones de priorización para la ejecución de los trabajos pasa a ser una responsabilidad del comité, dónde se tiene la visión global de la situación de la organización y se está informado sobre los cambios de acción o decisiones que se toman en los niveles ejecutivos. Por todo lo mencionado anteriormente, consideramos de vital importancia consolidar la función del comité de sistemas, el cual deberá mantener reuniones en forma periódica, tomando como base de referencia la planificación de tareas de acuerdo a lo mencionado en el punto 1, “Reestructuración de las fichas técnicas”, de este documento.
4.
Adecuación de la Estructura organizacional Hemos observado que la estructura organizacional de la USI no refleja las jerarquías ni los niveles de mando que en la práctica existen, esta situación crea problemas en la segregación de funciones y designación de responsabilidades, y dificulta las tareas de supervisión y control de los trabajos. De acuerdo a las mejores prácticas la estructura organizacional de un área de sistemas debe estar alineada a las tareas y responsabilidades existentes dentro de esta.
19
De acuerdo a lo observado el área de sistemas realiza tareas en las siguientes áreas de trabajo: 1. 2. 3. 4. 5.
Desarrollo y mantenimiento de sistemas Soporte a usuarios, internos y externos Operación de los sistemas en producción Administración y Soporte en equipos, redes y comunicaciones Seguridad de los sistemas Sin embargo, como resultado de nuestro trabajo observamos que las funciones de responsable de seguridad y soporte a usuarios no están formalmente definidas. Asimismo, observamos que las funciones de los responsables de las áreas de desarrollo y producción no han sido formalmente designadas por los niveles correspondientes de la SBEF. En tal sentido, es recomendable que el área de sistemas sea reestructurada a fin de contar con una mejor organización interna de la Unidad y mejorar los niveles de servicio que actualmente brinda a las áreas usuarias. Por todo lo mencionados anteriormente, consideramos que existen ciertas funciones que son claves para mejorar la calidad de servicio y mejorar la eficiencia de los recursos existentes: Help Desk, esta función permitiría contar con un único canal de comunicación para hacer los requerimientos de soporte, lo cual le permitiría a la USI contar con una primera instancia de apoyo, que debería atender los aspectos más simples de forma tal que solamente los casos más complejos sean dirigidos a las personas correspondientes. Asimismo, esta instancia debería contar con herramientas que le permitan realizar un registro de los requerimientos realizados por los usuarios a fin de contar con un historial de los problemas y sus resoluciones, para atender futuras consultas. De esta forma se realizaría un uso más eficiente de recursos, asignando las tareas más complejas al personal mas capacitado. Oficial de seguridad, esta función permitiría concentrar en una persona las funciones de seguridad de los sistemas, ya sean relacionadas con aplicaciones, administración de base de datos, administración del correo electrónico, sistemas operativos, etc. Esta persona debería ser la única que tenga acceso simultáneo a las áreas de desarrollo y producción y debería ser el responsable de la supervisón de los pases a producción de los nuevos sistemas o de los cambios que son realizados por los analistas / programadores.
20
Asimismo, y en base a una planificación previamente definida, se debería contar con una segunda persona capacitada para asumir dichas funciones y responsabilidades ante cualquier contingencia, lo cual no implica que la persona de reemplazo tenga conocimiento de las claves de acceso del oficial de seguridad titular. Dichas claves de acceso deben estar adecuadamente custodiadas en sobre lacrado, accesibles en caso de emergencia y deberían ser informadas al oficial de seguridad suplente solamente en caso de contingencia. Es importante definir canales de comunicación formales para que las áreas usuarias realicen sus requerimientos cotidianos, de forma tal de minimizar la posibilidad de que interactúen en forma directa con el personal de la USI, lo cual puede afectar significativamente la planificación de los trabajos y aumentar el riesgo de que los productos entregados no cuenten con el control de calidad necesario, antes de ser entregados a los usuarios. 5.
Consolidar las funciones de apoyo de Auditoría de Sistemas y Organización & Métodos Hemos observado que la función de O&M no está claramente definida ni establecida en la SBEF, si bien en los últimos meses la Unidad de Desarrollo Operativo desempeña actividades para normar los procedimientos de la SBEF, no se le ha designado formalmente la responsabilidad y las funciones equivalentes a las de O&M. Asimismo, hemos observado que tampoco se cuenta con la función de Auditoría interna de Sistemas. Consideramos importante la consolidación de dichas funciones dentro de la SBEF, para lo cual es necesario designar formalmente las responsabilidades de O&M para que el trabajo de dicha función sea permanente dentro de la estructura de la organización. En relación a la Auditoría Interna de Sistemas y debido a las características de la SBEF, consideramos que dicha función no debe implicar necesariamente la designación a tiempo completo de un funcionario de la Unidad de Auditoría Interna. Dicha función, podría ser designada a terceras partes de forma tal que los trabajos puedan ser realizados periódicamente en función a las necesidades de la organización.
6.
Definir mecanismos para la rotación de personal La estructura de la USI, en el área de desarrollo, se basa en la designación de responsables por aplicaciones, lo cual ocasiona que cada analista sea un experto en los sistemas que están a su cargo. Sin embargo, esta forma de estructurar las funciones y responsabilidades de los analistas, ocasiona la creación, en cierta medida, de personal indispensable sin el cual no es posible atender oportunamente requerimientos de los usuarios.
21
Actualmente la USI trata de minimizar esta situación asignando varias personas para los proyectos, de forma de que varias personas compartan el conocimiento. Las mejores prácticas indican que uno de los mecanismos más comunes que utilizan las organizaciones para contrarrestar esta situación es la creación de planes de rotación de personal. De esta forma las personas son asignadas periódicamente a distintas aplicaciones, con lo cual se logra la especialización de varias personas en cada aplicación, se cuenta con personal entrenado ante cualquier contingencia y se reduce el riesgo de depender de una determinada persona. Consideramos que la USI debe definir planes de rotación para contar con personal preparado y entrenado a fin de contar con personal de recambio en caso de contingencia.
7.
Planes de carrera para el personal de la USI Como resultado de los procedimientos aplicados observamos que la formación académica de las personas del área de desarrollo es adecuada, existiendo varias personas que cuentan con estudios de maestría. Si bien esta situación le permite a la SBEF contar con personal altamente capacitado que puede poner a disposición de la organización todo su potencial académico, es importante considerar que existen algunos aspectos que deben ser considerados en relación a este personal:
Personal que tiene bastante experiencia y al mismo tiempo tienen una buena formación académica, por naturaleza es personal caro que ocasiona que los costos de la USI se incrementen en forma significativa.
Es importante administrar adecuadamente las expectativas laborales de estas personas porque no siempre existe la posibilidad de que todos puedan crecer dentro de la organización. Esto podría ocasionar que algunos funcionarios dejen la organización y no se cuente con reemplazos, lo que pone en riesgo la calidad de servicio de la Unidad. Por todo lo mencionado anteriormente, es importante que la SBEF defina planes de carrera para el personal de la USI a fin de tomar las acciones necesarias en forma oportuna y minimizar los riesgos anteriormente expuestos.
8.
Implantación de un sistema de control presupuestario
22
Hemos observado que el área de administración de la SBEF no cuenta con un sistema que cubra sus necesidades funcionales ni de información para el control presupuestario de sus actividades. Es necesario implementar un sistema computadorizado para el control presupuestario de las actividades que cubra las necesidades funcionales y de información de los usuarios. Asimismo, el sistema a ser implementado debería contribuir a la generación de información para efectuar análisis de costo/beneficio de las distintas actividades, incluidas las de la USI, para lo cual sería importante adoptar modelos de costeo basado en centros de costo y/o por actividades. De este modo, una vez aprobado el plan de sistemas por el comité de informática, la USI podría por ejemplo controlar los gastos originados en el rubro de informática, impidiendo que se realicen adquisiciones de bienes o servicios informáticos por fuera de los procedimientos establecidos.
9.
Normar la adquisición de sistemas y/o servicios de desarrollo de sistemas Como resultado del trabajo realizado observamos que existen casos en los cuales las áreas usuarias inician proyectos de desarrollo e implantación de sistemas computadorizados sin la intervención de la USI. Consideramos que este tipo de acciones pueden llegar a ser contraproducentes para la SBEF pues se corre el riesgo de no contar con una contraparte idónea al momento de definir los requerimientos y responsabilidades de los proveedores, firmar contratos que no sean favorables a los intereses de la SBEF y otros. Consideramos necesario que este tipo de procedimientos sean eliminados en la SBEF y cualquier tipo de servicio, sea este de desarrollo de sistemas y/o de adquisición de bienes tecnológicos sean iniciados con la participación activa de la USI.
10. Definición de normas y procedimientos de derechos de autor Como resultado de los procedimientos aplicado observamos que la SBEF no cuenta con mecanismos que le permitan salvaguardar los derechos de autor sobre los sistemas computadorizados que han sido desarrollados y/o adquiridos por la misma. Asimismo, y de acuerdo a las indagaciones y pruebas realizadas observamos que esta situación se repite para la otras áreas de la SBEF.
23
De acuerdo a las mejores prácticas es recomendable que se definan normas y procedimientos orientados a la inclusión de cláusulas específicas de derechos de autor en los contratos de trabajo que los empleados contraen con la organización. 11. Reestructurar el plan de capacitación Hemos observado que la USI cuenta con un plan de capacitación el cuales definido a principio de cada gestión, el cual es formalmente documentado y aprobado a través del área de recursos humanos. Asimismo y de acuerdo a los resultados obtenido, observamos que el mismo no ha sido cumplido en su totalidad, a la fecha de nuestra revisión y que muy difícilmente se llegará a cumplirlo. Sin embargo, consideramos que es importante que el Plan de Capacitación cuente con mayor precisión en su información, esto es:
Alinear el plan hacia los proyectos planificados y estrategias tecnológicas definidas. Definir quiénes serán las personas del área de sistemas que participarán en cada curso. Hacer una estimación de costos detallada. Definir las fechas en las cuales sería recomendable realizar la capacitación. Para los cursos internos, se debería incluir horas estimadas, fechas y lugares designados para cada uno de estos. De esta forma el seguimiento al avance del plan y el nivel de cumplimiento sería más eficiente y cuantificable.
12. Definir normas e implantar procedimientos para la Administración de la calidad Observamos que no se aplican procedimientos para asegurar la calidad de los productos y servicios que son ofrecidos por la USI. Normalmente esta función tiene como responsabilidad la aplicación de pruebas y verificación para evaluar si los sistemas, los cambios realizados a los programas y la documentación cuenten con los requisitos mínimos de calidad antes de que los mismos sean puestos en producción. Es importante que esta función sea incorporada dentro de la SBEF a fin de que los productos entregados por la USI tengan el menor índice de errores y que los mismos sean oportunamente identificados y corregidos.
24
La responsabilidad de esta función recae tanto en el área de sistemas, en cuanto a aspectos técnicos, como en las áreas usuarios, en cuanto a la funcionalidad hacia el usuario final. II.
DESARROLLO, ADQUISICION E IMPLANTACION DE SISTEMAS
1.
Definir módulos de seguridad y de auditoria para los sistemas No existen procedimientos formales que permitan definir módulos de seguridad y auditoría para los sistemas. No se contempla durante las etapas del desarrollo de sistemas la definición de los módulos de seguridad y de auditoria. De acuerdo a las mejores prácticas de la industria, el ciclo de desarrollo de los sistemas debería asegurar que se consideren mecanismos para definir módulos específicos de rastros de auditoría y que se evalúen los mecanismos de seguridad que proporcionará el sistema para proteger los datos e información sensible. Los aspectos más importantes a tomar en cuenta durante la definición de estos módulos son:
2.
Acceso a los datos Administración de privilegios Acceso a funciones especiales Definición de rastros de auditoría Definición de procedimientos para la revisión de los incidentes de seguridad Definición de procedimientos para la revisión de auditoría Definir estándares formales para la codificación de los sistemas Durante nuestra revisión no encontramos estándares para la codificación de los sistemas, que permitan que la misma se realice de manera uniforme, facilitando el mantenimiento y soporte de los sistemas. De acuerdo a las mejores prácticas de la industria, deberían existir estándares y acuerdos para la programación de los sistemas. Estos estándares de codificación deberían incluir a lenguajes de consulta (querys), lenguajes de 4ta generación, generadores de reportes, generadores de pantallas y generadores de código. Los estándares y acuerdos de programación deberían cubrir los siguientes aspectos:
Guías de formato para el código fuente, incluyendo aspectos tales como identificación del código fuente, formato de los programas fuente en párrafos separados, comentarios, descripción del programa/módulo/subrutina/función, datos recibidos y valores retornados y otros aspectos que permitan comprender el flujo del programa durante la depuración de errores.
25
3.
Acuerdos sobre el estilo de programación identificando entradas y salidas, composición y formato de los almacenamientos de los datos y arreglos, acuerdos de numeración de párrafos y otros que proporciones un estilo de escritura fácil y predecible que pueda ayudar en una inspección inicial de los programas y su posterior mantenimiento. Lineamientos enfocados a promover una mayor eficiencia en lo concerniente a la representación de elementos de datos, definiciones de conjuntos de datos, rutinas de acceso y ubicación de subrutinas dentro de un módulo. Definir una metodología formal para realizar pruebas a los sistemas Durante nuestra revisión no encontramos una metodología para la realización de pruebas a los sistemas, que permita realizar las mismas según estándares de aceptación de pruebas y corrección de errores, minimizando el riesgo de que los sistemas presenten fallas importantes que no hayan sido identificadas. Las pruebas que realiza la USI no se basan en una metodología de pruebas y no existe documentación formal que respalde la realización de las mismas. De acuerdo a las mejores prácticas de la industria, la documentación de pruebas debería realizarse como parte integral del proceso de desarrollo de sistemas. Deberían existir estándares para la elaboración de pruebas que detallen la documentación a generarse, la cual debería incluir:
Estrategia de pruebas: El desarrollo de una estrategia de pruebas es el primer paso para identificar que probar y como se realizar las mismas. Específicamente, una estrategia de pruebas incluye: Los objetivos funcionales de las pruebas al sistema. Describe los ciclos de pruebas a ser llevados a cabo para cumplir con los objetivos (incluyendo pruebas a las interfases automáticas con otros sistemas) Especifica los miembros y responsables del equipo de pruebas Especifica el plan de trabajo para el desarrollo y ejecución del Plan de Pruebas Define los recursos a ser requeridos para la realización de las pruebas
Plan de Pruebas: Para poder elaborar un plan de pruebas es necesario contar con documentación del sistema y contar con un adecuado entendimiento del diseño del mismo, ya que el Plan de Pruebas se elabora en función a la documentación existente, la calidad y nivel de detalle de la documentación afectará la calidad y nivel de detalle del Plan de Pruebas. Un Plan de pruebas incluye:
26
Una definición de los procesos elementales y el objetivo de cada una de las pruebas Las condiciones de prueba Los ciclos de prueba Los pasos detallados de las pruebas La definición de los datos de prueba La descripción de los resultados esperados 4.
Establecer un ambiente de pruebas para los sistemas basados en Informix Durante nuestra revisión no encontramos un ambiente separado de pruebas para los sistemas basados en Informix. Debido a la complejidad de los ambientes computacionales, es importante contar con un ambiente separado de pruebas que permita la corrección de errores, prueba de actualizaciones recibidas de proveedores, pruebas de cambios a programas y otros. De acuerdo a las mejores prácticas de la industria, un ambiente de pruebas requiere de la selección, adquisición, instalación e integración del hardware, sistemas de software, redes y herramientas que permitan contar con una replica del ambiente productivo. Actualmente, la USI utiliza el servidor de producción para realizar las pruebas de cambios al sistema. Para los sistemas basados en SQL Server no se cuenta con un ambiente de pruebas especifico. Sin embargo, cada una de las estaciones de trabajo de los analistas puede iniciar una instancia de la Base de datos para realizar pruebas.
5.
Definir procedimientos para la custodia de código fuente No existen procedimientos formales para la custodia de código fuente, el código fuente de los sistemas basados en SQL Server y Visual Basic se administra a través de un directorio de código fuente al cual tienen acceso todas las personas de sistemas. Los desarrolladores encargados del mantenimiento de los sistemas son las personas autorizadas para actualizar los mismos (acceso de escritura según la persona que modifica el sistema). De acuerdo a las mejores prácticas de la industria, deberían existir procedimientos que permitan controlar la custodia de código fuente, la administración de versiones y el control de los cambios al código. Estos procedimientos podrían basarse en mecanismos de control, tales como:
Software de administración de librerías, que permita el control de las versiones, el control del código fuente y su estado, permitiendo el control de la modificación simultanea del mismo. Custodia de las librerías a través de copias de respaldo.
27
Procedimientos de entrega y recepción de librerías. Herramientas de comparación de código fuente que permitan asegurar que todos los cambios en el código se encuentran identificados. El código fuente de Informix está custodiado por el administrador de la Base de Datos, el cual aplica las modificaciones al mismo.
6.
Definir procedimientos formales para realizar pases a producción Durante nuestra revisión no encontramos procedimientos formales para realizar los pases a producción de los cambios a los sistemas, por lo cual existe el riesgo de que se puedan implantar en el ambiente de producción cambios no autorizados a los programas. Adicionalmente, para los sistemas basados en SQL Server los mismos programadores son los encargados de actualizar las modificaciones tanto en la base de datos como en los programas cliente. De acuerdo a las mejores prácticas de la industria, deberían existir procedimientos que permitan realizar los pases a producción de manera controlada y totalmente documentada. La secuencia para realizar los pases a producción debería contemplar:
Transferencias al ambiente de producción basadas en requerimientos autorizados. Transferencias entre ambientes realizadas por una función independiente de la de desarrollo. Existencia de software de administración de librerías para el control de movimientos de software. Que sólo códigos fuente sean transferidos entre el ambiente de desarrollo, pruebas y producción. Que los códigos fuente sean recompilados en el ambiente de producción para crear los programas ejecutables. Que se realicen comparaciones entre las versiones modificadas y versiones anteriores para identificar los cambios. Los pases a producción de los sistemas basados en Informix se realizan copiando las modificaciones en el ambiente de producción donde, el administrador de la base de datos reemplaza las modificaciones y recompila los programas.
7.
Definir procedimientos para la implantación de los sistemas No se consideran algunos procedimientos de aceptación antes de la implantación del sistema: entrega de documentación de usuario, documentación de operación del sistema, documentación para el
28
entrenamiento del personal, documentación documentación de las pruebas piloto/paralelas.
de
ajuste
de
despeño,
De acuerdo a las mejores prácticas de la industria, deberían existir procedimientos para la implantación de los sistemas que permitan controlar:
Documentación de usuario. Documentación de entrenamiento. Documentación para la operación. Estándares para la conversión de datos. Pruebas de aceptación. Procedimientos para la recepción y corrección de errores para las aplicaciones externas. Garantías y acuerdos de mantenimiento. Documentación formal de finalización del proyecto. La SBEF cuenta con procedimientos para la aceptación de los sistemas por parte de los usuarios.
8.
Definir la participación de auditoría interna en la implantación de los sistemas No se han definido procedimientos formales que permitan la participación del área de Auditoría Interna en los proyectos de desarrollo de sistemas. De acuerdo a las mejores prácticas de la industria, el departamento de Auditoría Interna debería participar en los proyectos de desarrollo de sistemas a través de la ejecución de procedimientos de control. Se recomienda la participación del área de Auditoría Interna en los siguientes aspectos del desarrollo de aplicaciones:
Controlar la adecuación de los objetivos planteados contra los resultados obtenidos. Controlar la participación de las áreas implicadas. Revisar la adecuación de la documentación y el cumplimiento de políticas, normas, procedimientos y estándares definidos. Participar en la definición de controles. Participar en el diseño de pistas de auditoría y módulos de control. Evaluar los procedimientos de pruebas, pase a producción, conversión y generación de copias de respaldo Seguimiento post implantación.
29
9.
Definir un plan de contingencias para la continuidad del negocio Durante nuestra revisión no encontramos procedimientos que permitan la recuperación del negocio en caso de contingencia, el plan de contingencias existente no contempla los aspectos críticos de negocio, tales como:
Análisis de impacto para el negocio. Medidas formalmente definidas para minimizar los riesgos identificados. Definición de tiempos máximos y mínimos para la recuperación de los procesos. Priorización de los procesos críticos de negocio (secuencia de recuperación) Lista de distribución del plan de contingencias. Aprobación formal de los procedimientos definidos en el plan de contingencias. Procedimientos para la recuperación de los procesos críticos del negocio (actualmente el plan de contingencias sólo contempla procedimientos para la recuperación de los sistemas). Detalle de requerimientos mínimos de insumos necesarios para operar en caso de contingencia. Detalle de los requerimientos mínimos de hardware, software y comunicaciones para recuperar el negocio. Lista de contactos telefónicos (proveedores y terceros) críticos para la recuperación del negocio. Lista de contactos telefónicos del personal responsable de administrar y participar en los procedimientos definidos. Definición formal de los componentes de los equipos de contingencia (responsables, equipos de contingencia, personal de seguridad y de procesamiento de datos). Definición de las responsabilidades especificas para cada uno de los equipos de contingencia. Definición de procedimientos para el respaldo de documentación sensible (copias de contratos, acuerdos firmados, etc.). Procedimientos formales para realizar pruebas al plan de contingencias (planes detallados para las pruebas, alcance de las pruebas cubriendo los desastres tanto en períodos pico y normales e, procedimientos de notificación, líneas de comunicación, medición del rendimiento de las pruebas previstas y no previstas, etc.). Mecanismos para registrar los resultados de las pruebas y realizar la actualización de los procedimientos. De acuerdo a las mejores prácticas de la industria, se debería contar con un Plan de Contingencias que permita proteger la continuidad operativa del negocio, el mismo debería identificar los procesos críticos del negocio y los recursos requeridos para mantener un nivel aceptable de operación, para lo
30
cual se deberían preparar y probar procedimientos que aseguren la continuidad de la entidad en caso de contingencia. Un Plan de Contingencias debería tomar en cuenta las siguientes etapas: Análisis de impacto: Que permite identificar y evaluar los procesos críticos del negocio, las aplicaciones que los soportan, la posibilidad de interrupción, la cuantificación de costos de negocio y escalas de tiempo de recuperación. Estrategia para la continuidad del negocio: Que proporciona un análisis comparativo de las soluciones que permitirán la continuidad del negocio, basados en los requerimientos identificados durante el análisis. Desarrollo del Plan de Contingencias: El cual define los procedimientos para una adecuada administración de las interrupciones en el negocio. Mantenimiento y Pruebas al Plan de Contingencias: Permite la validación de las estrategias de recuperación, y la elaboración de procedimientos para el mantenimiento del mismo. 10. Definir procedimientos formales para el monitoreo continuo del hardware Durante nuestra revisión no encontramos procedimientos formales que permitan monitorear de manera continua el rendimiento de los equipos de hardware. De acuerdo a las mejores prácticas de la industria, se debería contar con procedimientos que permitan el monitoreo continuo de los componentes de hardware, entre los aspectos a tomar en cuenta para realizar este monitoreo se debe considerar:
Definición de los requerimientos de disponibilidad y desempeño de los servicios informáticos. Plan de disponibilidad que permita monitorear y controlar la disponibilidad de los servicios informáticos. Procedimientos para monitorear de forma continua los recursos tecnológicos y para elaborar informes periódicos de hallazgos. Herramientas de modelaje que permitan ajustar los sistemas en función a la previsión de la capacidad, el rendimiento y la disponibilidad de los componentes.
11. Definir acuerdos de nivel de servicio entre la USI y las áreas usuarias No existen acuerdos formales entre la USI y las áreas usuarias que definan el nivel de servicio necesario para los sistemas existentes.
31
Un Acuerdo de Nivel de Servicio se define como un mecanismo que nos permite controlar una relación de tercerización, la adecuada definición del mismo es la clave para el éxito de la tercerización. Existen varios aspectos a tomar en cuenta cuando se negocia un Acuerdo de Nivel de Servicio. Sin embargo, no todos son aplicables para la SBEF, debido a que la USI es una unidad interna y no tercerizada. Los aspectos más importantes a considerar son:
Definir claramente los servicios: La definición de los servicios que debe brindar la USI a los usuarios es el punto de partida para definir de manera adecuada un Acuerdo de Nivel de Servicio. Esta definición de servicios debe además definir las responsabilidades de la USI y de las áreas usuarias para cada uno de los servicios.
Tener un periodo de medición para los componentes: Debido a que la USI deberá contar con una cantidad especifica de recursos para poder brindar los servicios esperados, es importante tener un periodo de medición que permita determinar el nivel de normal de servicio a ser brindado.
Definir métricas de nivel de servicio: Las métricas permiten medir la calidad del servicio que se brinda, pueden utilizarse métricas tales como: tiempo de resolución de problemas, cantidad de solicitudes de requerimiento de cambios, horas de programación ejecutadas, porcentaje de disponibilidad de la aplicación, grado de satisfacción de los usuarios, etc. Se recomienda que las métricas que se apliquen se basen en un procedimiento de medición tipo “Scorecard”, donde deberían contemplarse 3 dimensiones de medición:
Mediciones tecnológicas: Como por ejemplo, tiempo de disponibilidad del sistema, tiempo de disponibilidad de la red, horas de programación. Mediciones de calidad de servicio: Como por ejemplo, tiempo de respuesta del Help Desk, tiempos de resolución de problemas, cronogramas de proyectos y otros. Satisfacción del usuario: Debido a que un presupuesto de tecnología es generalmente restringido y se tienen varios proyectos prioritarios, que no se pueden ejecutar al mismo tiempo, es importante medir la satisfacción del usuario final para poder analizar los aspectos estratégicos referidos a la tecnología.
Definir la elaboración informes: No sólo es necesario definir las métricas que permitirán medir la calidad de servicio, sino también definir que informes se generarán para monitorear el nivel de servicio.
Determinar el porcentaje de crecimiento: Un Acuerdo de Nivel de Servicio debería definir un porcentaje de crecimiento razonable de los servicios ofrecidos, el cual podría estar basado por ejemplo: en el crecimiento
32
de las transacciones en el sistema o en el crecimiento de los requerimientos de cambio. 12. Definir una metodología para la administración de proyectos No se cuenta con un marco referencial general que permita administrar los proyectos de sistemas que defina procedimientos para la planificación de los proyectos, administración y medición del avance de proyectos, administración de los aspectos administrativos e implantación y operación del sistema. De acuerdo a las mejores prácticas de la industria, se debería contar con procedimientos formales para la administración de proyectos de sistemas que contemplen:
Administración de los recursos tecnológicos del proyecto. Administración tiempos y cronogramas del proyecto. Administración y monitoreo de aspectos financieros y presupuestarios. Administración de proveedores. Migración e implantación.
13. Definir procedimientos para administrar la calidad de los proyectos externos No se cuenta con procedimientos que permitan administrar y controlar la calidad de los proyectos de sistemas desarrollados por terceros. De acuerdo a las mejores prácticas de la industria, se debería contar con procedimientos formales que permitan la administración y control de los proyectos externos de sistemas, que contemplen:
Un plan de calidad de proyectos Estándares de calidad definidos para cada una de las fases de desarrollo del proyecto Definición de productos a entregar Definición de responsabilidades
III. OPERACION Y SOPORTE DE SISTEMAS 1.
Restringir el conocimiento de claves de usuario por parte de la USI La generación de claves (passwords) para todos los usuarios de la SBEF y para los usuarios externos (Entidades Financieras) es realizado mediante un programa generador de claves, el cual esta conformado por cuatro letras,
33
tres números y un carácter especial. Por este proceso el área de producción de la USI tiene conocimiento de todas las claves de usuarios. De acuerdo a normas internacionales de seguridad lógica, cada usuario debería ser responsable de su clave y debe ser la única persona que conozca la misma. El sistema debería permitir el cambio de clave al usuario el momento de ingresar por primera vez al sistema. Además se deberían tomar en cuenta los siguientes aspectos:
2.
Cada usuario debería contar con una clave distinta para cada uno de los sistemas. Permitir la misma clave para todos los sistemas solamente con autorización expresa Cambio de clave por parte del usuario el momento de la sospecha de conocimiento de la clave por parte de alguna otra persona Las claves no deben ser escritas y dejadas al alcance de otras personas Prohibición de la utilización de claves comunes
Modificar la parametrización de las claves Actualmente, ninguno de los sistemas en producción solicita (obliga) al usuario el cambio periódico de claves. Normas de seguridad generalmente utilizadas, señalan que deberían configurarse los sistemas operativos y las aplicaciones para que se posibilite el cambio periódico de claves y que todos los usuarios realicen el cambio de sus claves teniendo como máximo un lapso de 90 días.
3.
Parametrizar el control de algunas características de las claves Los sistemas no controlan algunas características de las claves que son importantes para incrementar la seguridad y la confidencialidad de la información. Las características que debería tener la administración de claves son:
Los sistemas deben guardar al menos las últimas tres claves para que las mismas no puedan repetirse.
No debe ser posible repetir el mismo carácter varias veces en la construcción de la clave.
34
Debe existir al menos un dígito numérico en la clave. Estas son algunas de las características de las mejores prácticas en cuanto a la seguridad lógica de los sistemas de información.
4.
Aplicar las normas y procedimientos para el alta de usuarios en todos los casos Mediante la aplicación de pruebas de cumplimiento, se evidenció que no en todos los casos se cuenta con el formulario firmado para dar de alta un usuario en el sistema. Uno de cinco usuarios revisados de la gestión 2001 no cuenta con la autorización para su alta. De las gestiones anteriores, de los 10 usuarios seleccionados, ninguno de los mismos cuenta con la autorización respectiva. Debería cumplirse con lo establecido en todos los casos.
5.
Definir un documento específico para el requerimiento de acceso de alta de usuarios a la red No se cuenta con un formulario específico para el requerimiento de acceso de los usuarios. El formulario SB91 es utilizado para todo tipo de requerimientos de las áreas usuarias. Debería existir un formulario específico para la solicitud de acceso de los usuarios a la red y a los sistemas. De esta manera podría tenerse un archivo separado de todas las solicitudes de los usuarios y posibilitar un mejor control de las mismas.
6.
Separar las áreas de desarrollo y producción No existe una separación entre los ambientes de desarrollo y producción, por lo que los programadores podrían tener acceso a modificar programas y datos en el ambiente de producción, pudiendo ocasionar la degradación en el rendimiento del sistema y del servidor por un mal proceso, cortando de esa manera el servicio tanto a los usuarios internos como externos. Normas internacionales señalan que el momento de realizar modificaciones a los sistemas, los desarrolladores no deberían contar con la posibilidad al acceso a datos en línea. Debería existir para ello un servidor específicamente dedicado al desarrollo y mantenimiento de las aplicaciones.
7.
Definir normas y procedimientos para la clasificación de datos
35
No se cuenta con una clasificación de los datos manejados por la Unidad de Sistemas de la Superintendencia de Bancos y Entidades Financieras. Normas internacionales de seguridad mencionan que los datos deberían ser separados en cuatro clases de información con requerimientos separados de manipulación para cada caso: Secretos, Confidenciales, Privados y No Clasificados. Esta clasificación estándar de datos podría ser usada dentro de la Superintendencia. La clasificación es definida de la siguiente manera: Secretos: Esta clase es aplicada a la información más sensitiva del negocio cuyo uso es permitido estrictamente sólo a personal de la Superintendencia. El uso no autorizado de esta información puede causar un impacto muy fuerte para la Superintendencia, las Entidades Financieras y los clientes. Confidenciales: Esta clase es aplicada a la información menos sensitiva del negocio, cuyo uso es permitido sólo a personal de la Superintendencia. El uso no autorizado de esta información puede causar un impacto para la Superintendencia, las Entidades Financieras y los clientes. Privados: Esta clase es aplicada a información personal cuyo uso es permitido dentro de la Superintendencia. El uso no autorizado de esta información puede causar un impacto fuerte a la Superintendencia o a sus empleados. No Clasificados: Esta clase es aplicada a toda la demás información que no se encuentre claramente definida dentro de las tres anteriores clases. El uso no autorizado de esta información no supone un impacto para la Superintendencia, las Entidades Financieras o los clientes. En la medida de lo aplicable los aspectos anteriormente mencionados deberían ser considerados en el caso de los mensajes enviados y recibidos mediante correo electrónico y otros medios. 8.
Definir normas y procedimientos para el manejo de incidentes No se cuenta con normas ni procedimientos formalmente establecidos para el manejo de incidentes. Según las mejores prácticas de seguridad, deberían existir normas y procedimientos establecidos para asegurar que todos los eventos de operación que no sean comunes (incidentes, errores o problemas) sean correctamente registrados, analizados y resueltos en un tiempo prudente. Además se debería consolidar la información generada por todos los operadores para realizar luego un análisis y emitir estadísticas sobre el tipo de incidentes que se producen y los usuarios que más soporte requieren.
36
Asimismo el análisis gerencial permitirá tomar decisiones para solucionar los principales problemas en forma definitiva. Actualmente se cuenta, en el área de producción, con una planilla Excel, en la cual deben registrarse todos los requerimientos de soporte de los usuarios. 9.
Definir la generación de reportes de violación Actualmente no se cuenta con reportes de violación a la red de la Superintendencia de Bancos y Entidades Financieras. Tampoco existen reportes de violación a la página web de la SBEF. Deberían existir normas y procedimientos que detallen la manera de realizar el monitoreo a la red para la detección, reporte y revisión de los intentos de violación. Las mejores prácticas de seguridad mencionan que deben existir estos documentos así como debe realizarse el monitoreo a todas las actividades de seguridad.
10.
Definir una política para el uso de Internet No existe una política de Internet formalmente definida. Las mejores prácticas relacionadas con la seguridad señalan que el uso de Internet presenta nuevos y serios potenciales problemas de seguridad, es por este motivo que debería contarse en principio, con una política claramente definida de las posibilidades y las responsabilidades de los usuarios, así como el detalle de los riesgos incluidos en la navegación y descarga de información.
11.
Mejorar la seguridad física Actualmente no se cuenta con algunos aspectos importantes para la administración de la seguridad física:
No existen normas y procedimientos formalmente establecidos para esta tarea No existen alarmas contra incendio ni detectores de humo en el Centro de Cómputo No existen alarmas contra intrusos Las paredes del Centro de Cómputo son de vidrio (posibilidad de acceso no autorizado) No se cuenta con un registro de los visitantes al Centro de Cómputo y el motivo de la visita
37
Existen tomas de corriente en el piso del Centro de Cómputo. No existe piso falso. No se realiza el mantenimiento periódico del sistema eléctrico del Centro de Cómputo, luces de emergencia ni aire acondicionado. Las ventanas que dan al exterior no se encuentran selladas. No se poseen armarios ignífugos para el almacenamiento de copias de respaldo. Las mejores prácticas de seguridad mencionan que deberían existir los aspectos mencionados para incrementar la seguridad física. Asimismo, es importante mencionar que las actuales instalaciones físicas de la USI no fueron diseñadas específicamente para tal efecto, lo cual no contribuye a la solución de los aspectos anteriormente mencionados. Adicionalmente, si bien existen procedimientos de control manuales de ingreso y salida de equipos de las instalaciones de la SBEF, es conveniente que se analice la adquisición de un mecanismo automatizado de control el cual permita a través de sensores identificar si una persona está ingresando y saliendo con un dispositivo de propiedad de la SBEF y permita registrar información como código de equipo, hora, fecha, etc. Este tipo de mecanismos fortalecería el ambiente de control y permitiría que dicho proceso sea más eficaz y eficiente.
12.
Completar la documentación de las configuraciones No se cuenta con el registro de configuraciones para todos los recursos tecnológicos. Debería existir el registro de configuraciones de CPU, impresoras, periféricos, etc. Además deberían existir procedimientos formalmente establecidos para realizar esta tarea, con el objetivo de permitir restituir todo el sistema (configuración) en caso de falla del equipo o alguna otra contingencia. Actualmente se cuenta con registro de las configuraciones de los siguientes recursos:
13.
Equipos de comunicación Configuración de la red Discos duros (Unix) Base de datos (Informix) Mejorar la administración de Backups
38
Como resultado de los procedimientos aplicados, encontramos que no se cuenta, en todos los casos, con las copias de respaldo de los servidores. Tampoco se cuenta con un cronograma de operaciones o una bitácora para la obtención de copias de respaldo. Debería llevarse un control detallado de todas las copias obtenidas para que, en caso de ser necesario, se tenga a mano toda la información de los meses y gestiones anteriores. Debería existir un cronograma de operación para que el operador conozca exactamente el orden de la obtención de las copias de respaldo. Además debería existir una bitácora en la cual se detalle las copias de respaldo diarias obtenidas, si es que existió algún problema el momento de realizar esta tarea y alguna observación especial sobre el proceso para cada uno de los servidores. Actualmente se cuenta con un cuaderno en el cual se registra el número de la cinta y el servidor del cual se obtuvo la información. Adicionalmente deberían considerarse aspectos tales como:
14.
Definir la vida útil de las cintas para la obtención de respaldo, de acuerdo a la información del proveedor para evitar fallas inesperadas de estos medios. Adquisición de un dispositivo para la obtención automática de copias de respaldo que posibilite la programación de esta tarea.
Documentar las operaciones Actualmente no se cuenta con documentación de operaciones que detalle las tareas a ser realizadas para:
Proceso de inicio y otras operaciones Programación de tareas Desviaciones de la programación estándar de tareas Normas internacionales de seguridad mencionan que el personal de operaciones debe estar familiarizado con el proceso de inicio y otras tareas de operación contando con documentación, periódicamente revisada y actualizada cuando es necesario. Además, la programación de trabajos, procesos y tareas debería estar organizada de la forma más eficiente de manera de maximizar la utilización
39
de los recursos, alcanzar los objetivos y brindar un buen servicio. Los cambios a estas tareas deberían encontrarse formalmente aprobados. Los procesos de inicio deberían encontrarse establecidas de manera de permitir identificar y registrar las desviaciones de la programación estándar de tareas. 15.
Definir procedimientos para la protección de los datos Actualmente no se cuenta con ningún procedimiento de encripción para los datos que son enviados desde la Entidades Financieras. Las mejores prácticas de seguridad mencionan que la transferencia de datos sensitivos debería ser realizado sólo a través de una ruta confiable. Información sensitiva incluye información de administración de seguridad, transacciones de datos sensitivos, claves y llaves criptográficas. Para llegar a tener una ruta confiable debería contarse con procedimientos de encripción en las líneas de comunicación: entre usuarios, entre usuarios y sistemas y entre sistemas.
16.
Mejorar los parámetros de seguridad del sistema Unix Servidor Digital Alpha – S.O. Unix Tru64 (CIRC) Usuarios con claves deshabilitadas
Estos usuarios no pueden acceder al sistema debido a que su clave se encuentra deshabilitada. Sin embargo, si el usuario tiene acceso remoto a una máquina que esté clasificada como un “Huésped Confiable”, el mismo no requerirá una clave de entrada y podrá iniciar una sesión sin problemas en la misma. Si estas cuentas nos son requeridas, deberían ser borradas del sistema. Se recomienda no borrar las siguientes cuentas pertenecientes al sistema: root, bin, sys, uucp, nobody o daemon. Los siguientes 12 usuarios tienen passwords deshabilitados: Nobody Uucp Lp
NobodyV Uucpa Tcb
Daemon Auth Ris
Bin Cron Wnn
Usuarios con GID = 0
40
Todo grupo que presente GID = 0, generalmente es conocido como el grupo “sistema” o grupo “wheel”. En la mayoría de los sistemas Unix solamente los usuarios pertenecientes a este grupo tienen la posibilidad de utilizar el comando su. Por consiguiente, estos usuarios podrían llegar a convertirse en superusuarios. Se recomienda revisar los usuarios descritos a continuación para asegurar que no se presentarán excepciones si llegaran a ser superusuarios. Se tienen los siguientes 5 usuarios “secundarios” que tiene GID=0: root jcibieta
Usuarios escritura
cuyo
Circ Ggemio directorio
“home”
mflores
permite
acceso
a
Si el directorio “home” de un usuario permite acceso a escritura, cualquier persona podría modificar sus archivos. Esta es una manera fácil para que un ’hacker’ obtenga la clave de un usuario insertando dentro de su directorio “home” un programa de captura de claves, por ejemplo que simule el funcionamiento del comando ‘ls’. Se recomienda eliminar el permiso de escritura del directorio. Los permisos sugeridos son: owner: rwx group:r – x world: – – – Se encontraron 11 usuarios: Usuario Circ Circsrc Mflores Jcibieta Ggemio Cquinta Adips Asivila Kguzman Rsalazar Jcandia
Permiso Rwxrwx--Rwxrwxr-x Rwxrwxr-x Rwxrwxr-x Rwxrwxr-x Rwxrwx--Rwxrwx--Rwxrwx--Rwxrwx--Rwxrwx--Rwxrwxr-x
Directorio Home /home/datos1/circ/ /users/usrdes/circsrc/ /users/usrdes/mflores/ /users/usrdes/jcibieta/ /users/usrdes/ggemio/ /users/usrcom/cquinta/ /users/usrcom/adips/ /users/usrcom/asivila/ /users/usrcom/kguzman/ /users/usrcom/rsalazar/ /users/usrdes/jcandia/
41
Grupos con Nombre Duplicado en el Archivo de Grupo Esto podría confundir al sistema y existe la posibilidad de que se presenten errores. Los problemas podrían incrementarse cuando se adicionan o eliminan nombres desde un grupo. Se recomienda asignar un nombre adecuado a los grupos que se encuentren duplicados y solamente mantener el correcto. Se encontraron en total 2 grupos. Grupo Informix Circ
Cantidad 2 2
Grupos sin usuarios Los siguientes grupos no cuentan con ningún usuario “válido” asignado. Si estos grupos no cuentan con usuario alguno no deberían existir. Se recomienda borrar los grupos que no son utilizados y reasignar los archivos y directorios a grupos conformados por usuarios que cuenten con el apropiado perfil de acceso. Los siguientes 7 grupos no cuentan con ningún usuario válido: Men Backup
Sec Tape
Mail Operator
Terminal
18. Mejorar los parámetros de seguridad de los sistemas Windows NT Y Windows 2000
Usuarios con cuentas inactivas Las cuentas inactivas deberían ser deshabilitadas para minimizar el riesgo de que las mismas sean utilizadas por usuarios maliciosos que intenten ganar acceso al sistema y a sus recursos. Las mejores prácticas de la industria nos muestran que las cuentas que no son utilizadas durante un periodo de 60 días o mayor deberían considerarse inactivas y deshabilitarse. Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server
42
Identificador
Nombre Usuario
Csantacruz
Cecicilia Santa Secretaria de Normas Cruz Holbin Roca Usuario Regional Santa 137 Cruz PC Portátil volante solicitado por Conzuelo 66 INB Prado Superintendencia de Bancos 115
Hroca Portinb1 Supban
del Descripción
Ultimo ingreso (días) 123
Servidor DNS_LPZ – Servidor de Recepción Identificador
Nombre Usuario
Aalmaraz
Amalia Almaraz CAJA DE AHORRO Delgadillo PRESTAMO LOS ANDES Alvaro Bazan CITIBANK S.A. 559 Adolfo Berkhan Caja los Andes 66 Alfredo Catari Caja Los Andes 613 Compania 525 Internacional Almacenara S.A. Angel Davila Cooperativa San José de 177 Punata Almacenes 820 Generales de Deposito AGEDESA Adrián Herrera Banco Nación Argentina 471 Alberto Mocobono Cooperativa Trapetro 556 Oriente Adrian Morales Cooperativa San Martín de 79 Porres Ana Karina Moreno FONDO FINANCIERO 704 Parejas PRIVADO FASSIL Alvaro Muñoz BANCO SOLIDARIO 531 Poveda Alex Nuñez FONDO FINANCIERO 624 Justiniano PRIVADO FASSIL. Asteria Ortiz Cooperativa San Jose de 332 Punata Alejandra Ribero BANCO GANADERO S.A. 819 Urquieta Abel Rojas Banco Union 628
Abazan Aberkhan Acatari Aci Adavila Agd Aherrera Amocobono Amorales Amoreno Amunoz Anunez Aortiz Aribero Arojas
del Descripción
Ultimo ingreso (días) Y 701
43
Identificador
Nombre Usuario
Asolano
Alejandro Solano Coop. Pio X Condor Alberto Suarez COOPERATIVA LA MERCED 820 Mendez Armando Taborga Cooperativa San Luis 643 Adalid de la Torre Banco Mercantil 861 Warrant Santa 896 Cruz S.A. Arturo Zabala CITIBANK 805 Banco Boliviano 668 Venta Banco Agricola de 128 Bolivia Bruno Alarcon Citibank S.A. 338 Arrieta ABM Amro Bank Ex- Banco Real. 133 N.V. Banco Boliviano 457 Americano BBA RECOMPRA BANCO BOLIVIANO 673 AMERICANO 696 Benjamin Heredia Cooperativa Hospicio Ltda. 322 Bonos NFB 468 Banco Real 598 Betty Vaca COOPERATIVA LA MERCED 340 Calderon Carlos Cordova Banco Industrial (Cheques 163 Rechazados) Cecilia Alvarado CAJA DE AHORRO Y 825 PRESTAMO LOS ANDES Carlos Michel Cooperativa PIO X 622 Clemencia Artero BANCO GANADERO S.A. 745 Velasco Carlos Eric MUTUAL GUAPAY 674 Zambrana Cristina Bernal BANCO UNION 693 Carmen Bustillo BANCO ECONOMICO S.A. 504 Zamorano (COCHABAMBA) Carla Cevasco CITIBANK 679 Carlos Chavez Banco Ganadero 63
Asuarez Ataborga Atorre Awc Azabala Baa Bab Balarcon Bam Bba Bbr Bbv Bheredia Bonosnfb Bre Bvaca Cacordova Calvarado Camichel Cartero Cazambrana Cbernal Cbustillo Ccevasco Cchavez
del Descripción
Ultimo ingreso (días) 451
44
Identificador Cheredia Cjustiniano Cluisaga Cmichel Cpereira Cpoveda Crivera Csaavedra Csanchez Csj Csl Cvacaflor Cvb Dbarahona Dcasapia Dflores Dperedo Dsaric Ebocapine Ecalcina Econdori Edcordero Eescobar Efabiani Efargo Eguzman Elramos Emartinez Eortiz Epatroni Eperalta
Nombre Usuario
del Descripción
Ultimo ingreso (días) Coral Heredia Fondo Financiero FIE 464 Claudia Justiniano BANCO MERCANTIL S.A 821 Clover Luisaga COOPERATIVA JESUS 159 Galarza NAZARENO Carlos Michel Cooperativa San Antonio 793 Carlos Pereira Banco Nación Argentina 764 Cinthia Poveda Caja de Ahorro y Préstamo 489 Los Andes Carlos rivera Citibank 157 Claudia Saavedra CITIBANK S.A 819 Ciro Sanchez BNA 65 Cooperativa San 724 Jose Obrero Cooperativa San 209 Luis César Vacaflor Cooperativa Catedral 763 Cooperativa de Vivienda Bermejo (Bermejo - 661 Tarija) Daniel Barahona Cooperativa San Roque 63 Dirza Casapia CITIBANK S.A. 365 Dante Flores Citibank 288 Danitza Peredo Coop. San Pedro Ltda. 136 Davor Saric Mutual La Paz 178 Erika Paola FONDO FINANCIERO FASSIL 583 Bocapine Ardaya Emilio Calcina Cooperativa San Martin 533 Eugenio Condori Banco Sol 427 Edgar Cordero Banco Sol 429 Eduardo Escobar Banco Union - Santa Cruz 657 Edwin fabiani BANCO SOLIDARIO S.A. 437 Edgar Fargo Banco Económico 171 (Cheques Rechazados) Elvira Guzmán CVooperativa San José de 618 Bermejo Eliott Ramos FFP FIE 300 Enrique Martínez CITIBANK S.A. 611 Edwin Ortiz Banco Union 66 Esteban Patroni FONDO DE DESARROLLO 134 CAMPESINO Edwin Peralta MUTUAL GUAPAY 496
45
Identificador
Eramos Erivero Esalas Esiles Fal Falopez Fandrade Fcl
Fcolque Fcory Fdc Fesoliz Fgutierrez Flandivar Flaura Fmamani Fmunoz Fochoa Frios Fyaveta Gburnett Gespino Ggemio Ggomez Gmachaca Gmontano Gosinaga
Nombre Usuario
del Descripción
Ultimo ingreso (días)
Salcedo Edwin Damaso FONDO FINANCIERO FASSIL 692 Ramos Miranda Eduardo Rivero Mutual Guapay 884 Edwin Salas 329 Edgar Siles Banco Sol 359 Financiera Acceso 904 La Paz Fabiola Lopez BANCO SANTA CRUZ DE LA 828 SIERRA Fatima Andrade BANCO GANADERO S.A. 532 Hieller FONDO CAJA LOS ANDES 794 FINANCIERO PRIVADO LOS ANDES Fernando Colque Banco Sol 440 Franz Cory COOPERATIVA SAN LUIS 608 Camacho Fondo de 128 Desarrollo Campesino Fernando Soliz Cooperativa Pio X 709 Freddy Gutierrez Cooperativa San Mateo 241 Freddy Landivar ISB 366 Fidel Laura Banco Sol 374 Freddy Mamami Banco Sol 391 Federico Munoz 158 Federico Ochoa BANCO DO BRASIL S.A. 496 Iturri Freddy Rios Cooperativa San Luis 211 Fernand Yaveta BANCO DE LA UNION S.A 177 Guillermo Burnett MUTUAL LA PAZ 470 Mancilla Gabriel Espino Banco Sol 415 Gerson Gemio 827 Miranda. Gustavo Gomez Banco Solidario 445 Gabier Machaca Banco Sol 424 Gimara Montano Banco CITIBANK 560 Grevy Adalid COOPERATIVA HOSPICIO 628
46
Identificador
Grjustiniano Gsanchez Halcocer Hhidalgo Hmoreno Htoledo Hvillarroel Hvonborries Iberdeja Ivguzman Jacordova Janez Jarnez Jasalinas Jbenancio Jbhurtado Jborda Jdelascasas Jdelgado Jherbas Jhurtado Jjimenez Jjustiniano Jlopez Jmalvarez Jmfernandez Jmiranda Jmollinedo Jmorales Jortiz
Nombre Usuario
del Descripción
Ultimo ingreso (días)
Osinaga Arispe GRACIELA CITIBANK S.A 335 JUSTINIANO German Sanchez BANCOS SOLIDARIO 530 Hilda Alcócer Mutual Progreso 700 Henry Hidalgo Banco Solidario 253 Humbert Moreno Banco Económico 769 Hugo Toledo Roca BANCO GANADERO S.A. 533 Heber Villarroel Citibank 303 Henry Walter Von MUTUAL GUAPAY 542 Borries Caballero Ivan Berdeja Mutual La Paz 413 Ivan Guzman Cooperativa San Joaquín 421 José Antonio ASOBAN 224 Cordova Jorge Anez Cooperativa Jesús 640 Nazareno José Arnez Cooperativa San Antonio 210 José Antonio Mutual La Plata 454 Salinas José Benancio Cooperativa Hospicio Ltda. 105 Julia Betty Hurtado Banco Santa Cruz 69 Juan Carlos Borda CITIBANK S.A. 745 Jorge de las BANCO GANADERO S.A. 588 Casasa Samoje Jerry Delgado Uria CITIBANK S.A 371 Julio Herbas BANCO DE CREDITO 650 Jose Luis Hurtado BANCO DE LA UNION S.A. 891 Rosales José Fernando Banco Central de Bolivia 97 Jiménez Arturo Justiniano COOPERATIVA JESUS 822 NAZARENO Jenny López Mutual Paitití 524 José Alvarez Banco Sol 414 Juan Fernández Banco Sol 440 José Miranda Caja los Andes 91 Juan Mollinedo CITIBANK 206 José Morales CITIBANK S.A. 133 Julio Ortiz Cooperativa Hospicio 631
47
Identificador
Nombre Usuario
Jquintela
Jhenny Quintela CAJA LOS ANDES Huiza Julio Rocha Unidad de Sistemas 521 Carrasco Josefa Rodo Fondo Financiero FIE 339 Jorge Sanchez BANCO ECONOMICO 356 Soliz Juan Saucedo Banco Ganadero 630 Jhonny Ugarte BANCO SOLIDARIO 528 Juan Vega CITIBANK 626 Jorge Velasco BISA Leasing 823 Juan Pedro FINANCIACOOP 177 Villarroel Julio Zambrana BANCO DE LA UNION S.A 863 Kenneth CITIBANK S.A. 610 Armstrong Katerina FFP – FIE 569 Bernasconi Limberg Arauz Mutual Guapay 402 Liliana Chale Perez Secretaria de INB 799 Leslie Roxana Fondo de la Comunidad 829 Delgado Lavadenz Leo Escobar Mutual Potosí 554 Liliana Favot BANCO DE LA NACION 139 Carbonari ARGENTINA Lileth Flores Fondo de la Comunidad 330 Montiel Luis Goytia Cooperativa Catedral 361 Potosí Lidia Gutierrez BANCO SOLIDARIO 615 Limberth Camacho BANCO DE LA UNION S.A 862 Luis Oliva Coop. Jesús de Nazareno 135 Luis Perez Cooperativa Financiacoop 532 Liliana Salvatierra Mutual Pando 162 Loren Vidangos CITIBANK S.A. 811 Marco Arteaga Banco Sol 441 Maya Barbery CITIBANCK 430 Marioly Abasto Fondo de la Comunidad 233 Marco Aldayuz Banco Ganadero 835 Mirtha Alvarez INB 350
Jrocha Jrodo Jsanchez Jsaucedo Jugarte Juvega Jvelasco Jvillarroel Jzambrana Karmstrong Kbernasconi Larauz Lchale Ldelgado Lescobar Lfavot Lflores Lgoytia Lgutierrez Licamacho Loliva Lperez Lsalvatierra Lvidangos maarteaga mabarbery mabasto maldayuz malvarez
del Descripción
Ultimo ingreso (días) 94
48
Identificador
Nombre Usuario
mandia
Miguel Andia Operaciones de Sistemas Maldonado Marcelo Vargas CITIBANK S.A. 560 Marisol Viscarra Cooperativa 421 Marvin Barbery Cooperativa Fátima 792 Miguel Barrios FONDO FINANCIERO FASSIL 105 Cabero Matilde Beltran CITIBANK S.A 280 Maria Cecilia Caro Mutual La Paz 223 Velázquez Mario Fortún Banco Do Brasil 463 Marisol Gamboa CAJA DE AHORRO Y 361 PRESTAMO LOS ANDES Mirtha Glasinovic 157 Mauricio Gumiel Banco Ganadero 469 Mery Jimenez BANCO GANADERO 546 Marcos Miranda Cooperativa San Antonio 570 Margot Mostajo Mutual La Promotora 161 Martha Beatriz MUTUAL GUAPAY 393 Negrete Vaca Miguel Angel 596 Navia de Pruebas Mauricio Paz CITIBANK S.A 707 Marcelo Rodriguez Mutual la Primera 692 Magda Sandi Caja de Ahorro y Préstamo 350 Los Andes Monica Saucedo Cooperativa Jisunu 458 Mabel Zamora COOPERATIVA CATEDRAL 512 Cuenca Nestor Alcocer Fondo de Desarrollo 399 Campesino Nadie Crespo CAJA LOS ANDES 94 Noraly Cruz FONDO FINANCIERO 786 Sanguino PRIVADO FASSIL Nelda Analia FONDO FINANCIERO FASSIL 584 Garcia Nancy Inturias Mutual Guapay 430 Nelson Revilla FONDO DE DESARROLLO 891 CAMPESINO Oswaldo Huanca Banco Sol 434 Oscar Mur Cooperativa Trapetrol 626
mavargas maviscarra mbarbery mbarrios mbeltran mcaro mfortun mgamboa mglasino mgumiel mjimenez mmiranda mmostajo mnegrete mnr mpaz mrodriguez msandi msaucedo mzamora Nalcocer Ncrespo Ncruz Ngarcia Ninturias Nrevilla Ohuanca Omur
del Descripción
Ultimo ingreso (días) 91
49
Identificador
Parnez Pbaldellon Pbravo Pcarrasco Pdavalos Perodriguez Pgutierrez Phoyos Phurtado Pjerez Rarias Rcamacho Rcamargo Rcoriza Rdeiraola Rhavivi Rherrera Rhoyos Rhuanca Rjemio Rlafuente Rledezma Rlozano Rmartorell Rmuriel Rotazo Rpiedras Rribera Rsantos Rsheider
Nombre Usuario
del Descripción
Ultimo ingreso (días)
Oriente Patricia Arnez Cooperativa Hospicio 624 Patricia Baldellon Cooperativa Inca Huasi 604 Patricia Bravo Banco Ganadero 538 Patricia Carrasco MUTUAL GUAPAY 499 Banegas Patricia Paz FONDO FINANCIERO 570 Davalos PRIVADO FASSIL Pedro Rodríguez Mutual Pando 570 Paola Gutiérrez Banco Económico 142 (Cheques Rechazados) Patricia Hoyos CITIBANK S.A 181 Patricia Hurtado Fondo de Desarrollo 484 Campesino Petroz Jerez Banco do Brasil 396 Ramiro Arias Cooperativa Hospicio Ltda. 78 Raúl Camacho Mutual La Promotora 423 Ruth Camargo Mutual La Plata 423 Roberto Coriza COOPERATIVA 652 Llanos FINANCIACOOP Roberto de Irahola Banco Económico 623 Ronald Havivi BANCO SOLIDARIO 366 Ricardo Herrera CITIBANK S.A 287 Lobo Renán Hoyos FINANCIA COOP. 191 René Huanca FPP Los Andes 114 Roger Jemio MUTUAL LA PAZ 619 Vargas Rolando Lafuente Cooperativa Quillacollo 878 Romer Ledezma CITIBANK 336 Rocío Lozano MUTUAL LA PAZ 659 Morales Ronald Martorell Banco Ganadero 906 Ric Muriel CITIBANK S.A 387 Ruth Otazo Banco Ganadero 521 Rubens Piedras 883 Roni Ribera Fondo Fassil 653 Raul Alberto Coop. San Antonio Cbba. 477 Santos Hurtado Rafael Sheider Banco Unión 186
50
Identificador
Nombre Usuario
Rsoria Rticona Rtorrez Rurquiza Salcoba
Rodolfo Soria Roxana Ticona Rene Torrez Rafael Urquiza Salomé Alcoba
del Descripción INB FFP - FIE Banco de la Unión Banco Ganadero Cooperativa Fátima
Ultimo ingreso (días) 349 399 311 527 820
51
Sbalboa Scahuaza Scoehlo Senape Sguillen Sgutierrez Sguzman Smendez Smontes Srios Stanacio Svillarroel Szamora Tsubieta Vayala Vgonzales Vmedinacelli Vsalazar Vvega Wecornejo Wgarcia Xbarragan Xinchausti Xjauregui
Silverio Balboa
Caja de Ahorro y Préstamo 378 Los Andes Simon Cahuaza Banco Sol 438 Sandra Coehlo CITIBANK 440 Servicio Nal. de SENAPE 121 Patrimonio del Estado Sergio Guillen Banco Mercantil 864 Sergio Gutierrez BANCO MERCANTIL S.A 863 Sandra Guzman BANCO SOLIDARIO 813 Sebastian Mendez COOPERATIVA SAN 295 ANTONIO Sandro Montes Banco SOL 505 SNYDHER RIOS FFP PRODEM 605 Silvestre Atanacio Mutual La Paz 563 Sonia Villarroel Cooperativa Feliz Gainza 631 Sergio Zamora BANCO GANADERO S.A. 687 Bascope Teresa Subieta Mutual La Promotora 154 Victor Ayala MUTUAL LA PAZ 885 Fuentes Veronica Gonzales BANCO BISA 807 Viven Patricia BANCO ECONOMICO S.A. 496 Medinacelli Rico Virginia Salazar FINANCIACOOP 178 Vania Vega Banco Nacion Argentina 436 Willy Cornejo Banco Sol 455 Walter García BANCO GANADERO S.A 467 Rocha Ximena Barragan Cooperativa la Merced 155 XIMENA FFP PRODEM 603 INCHAUSTI Ximena Jauregui FPP Los Andes 700
Servidor SERVERUSR4 – Servidor SIF
Renombramiento de cuentas Debido a que las cuentas “Administrator” y “Guest” son cuentas estándar del sistema operativo Windows NT/2000, las mismas son frecuentemente blanco de ataques por usuarios maliciosos que intentan ganar acceso al sistema.
52
Se recomienda renombrar estas cuentas con valores desconocidos. Las mejores prácticas de la industria nos muestran que la cuenta “Administrator” es renombrada con un valor desconocido, y la cuenta “Guest” es renombrada con el valor “Administrator” y se asignan claves de construcción compleja a las dos cuentas. Bloqueo automático de las cuentas
El bloqueo automático de cuentas después de un número definido de intentos fallidos de ingreso minimiza el riesgo de que las cuentas de los usuarios se vean comprometidas a través de ataques. Las mejores prácticas de la industria, nos muestran que se utilizan los siguientes parámetros: Lockout: después de 3-5 intentos fallidos de ingreso. Reset counter: después de [1440] minutos. Lockout duration: se parametriza a [Forever (until admin unlocks)] Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server Lockout: después de 3 intentos fallidos de ingreso. Reset counter: después de [5] minutos. Lockout duration: se parametriza a [5] minutos. Servidor DNS_LPZ – Servidor de Recepción Parámetros deshabilitados. Servidor SERVERUSR4 – Servidor SIF Parámetros deshabilitados.
Restricción de acceso a directorios sensitivos
El acceso irrestricto a directorios del sistema operativo puede comprometer la seguridad del servidor. Por ejemplo, si usuarios no autorizados ganan acceso a archivos del sistema operativo, podrían corromper el mismo, ejecutar programas maliciosos (Trojan horse) o crear ataques de negación de servicio (denial of service) contra el servidor. Las mejores prácticas de la industria muestran que los siguientes directorios deben ser protegidos: C:\winnt\ C:\winnt\system32
53
C:\winnt\system32\drivers Se recomienda los siguientes permisos: Administradores – Full Control Operadores del servidor (si existen) – Change Usuarios – Read Propietarios - Full Control Sistema - Full Control
Acceso al servidor a través de la red El parámetro de “Accesar a esta computadora desde la red” debe ser restringido para ciertos usuarios, por ejemplo, si la cuenta de administrador se viera comprometida y este parámetro estuviera deshabilitado no sería posible ingresar al servidor desde la red (login) por lo que el servidor no se vería comprometido. Adicionalmente, usuarios no autorizados no tendrían acceso a la red. Las mejores prácticas de la industria nos muestran que sólo los siguientes tipos de usuarios deberían contar con este privilegio: Users Server Operators Account Operators Print Operators Backup Operators Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server Todos los usuarios tienen habilitado este privilegio. Servidor DNS_LPZ – Servidor de Recepción Todos los usuarios tienen habilitado este privilegio. Servidor SERVERUSR4 – Servidor SIF Todos los usuarios tienen habilitado este privilegio.
Acceso irrestricto a los archivos El parámetro de “Realizar copias de respaldo de archivos y directorios” debe ser restringido para ciertos usuarios, si este privilegio se otorga innecesariamente existe el riesgo de que usuarios no autorizados ganen acceso a datos sensitivos del servidor.
54
Las mejores prácticas de la industria nos muestran que sólo los siguientes tipos de usuarios deberían contar con este privilegio: Backup Operators Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server Los usuarios “BUILTIN\Backup Operators”, “BUILTIN\Server Operators” y “BUILTIN\Administrators” tienen este privilegio. Servidor DNS_LPZ – Servidor de Recepción Los usuarios “BUILTIN\Backup Operators”, “BUILTIN\Server Operators” y “BUILTIN\Administrators” tienen este privilegio. Servidor SERVERUSR4 – Servidor SIF Los usuarios “BUILTIN\Backup Operators” y “BUILTIN\Administrators” tienen este privilegio.
Acceso a los logs de auditoría El parámetro de “Administrar el registro de auditoría y seguridad” debe ser restringido para ciertos usuarios, si este privilegio se otorga innecesariamente existe el riesgo de que las pistas de auditoría se vean comprometidas por usuarios que ataquen el sistema y luego borren el registro de auditoría. Las mejores prácticas de la industria nos muestran que sólo usuarios como “Oficiales de Seguridad” o “Auditores” deberían tener estos privilegios. Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server Los usuarios “BUILTIN\Administrators” tienen este privilegio. Servidor DNS_LPZ – Servidor de Recepción Los usuarios “BUILTIN\Administrators” tienen este privilegio. Servidor SERVERUSR4 – Servidor SIF Los usuarios “BUILTIN\Administrators” tienen este privilegio.
Privilegios de restauración de directorios y archivos
55
El parámetro de “Restaurar archivos y directorios” debe ser restringido para ciertos usuarios, si este privilegio se otorga innecesariamente existe el riesgo de que usuarios no autorizados modifiquen datos o programas en el servidor. Las mejores prácticas de la industria nos muestran que sólo los siguientes tipos de usuarios deberían tener este privilegio: Backup Operators Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server Los usuarios “BUILTIN\Administrators”, “BUILTIN\Backup “BUILTIN\Server Operators” tienen este privilegio.
Operators”,
Servidor DNS_LPZ – Servidor de Recepción Los usuarios “BUILTIN\Administrators”, “BUILTIN\Backup Operators”, “BUILTIN\Server Operators”, “SUPERNET\Administrator” tienen este privilegio. Servidor SERVERUSR4 – Servidor SIF Los usuarios “BUILTIN\Administrators”, “BUILTIN\Backup Operators” tienen este privilegio.
Privilegios para apagar el sistema El parámetro de “Apagar el sistema” debe ser restringido para ciertos usuarios, si este privilegio se otorga innecesariamente existe el riesgo de que el servidor no se encuentre disponible debido que el mismo podría ser apagado repentinamente. Las mejores prácticas de la industria nos muestran que sólo los siguientes tipos de usuarios deberían tener este privilegio: Administrators Server Operators Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server Los usuarios “BUILTIN\Administrators”, “BUILTIN\Backup Operators”, “BUILTIN\Server Operators”, “BUILTIN\Print Operators”, “BUILTIN\Account Operators”, “SUPERBANK\Administrators”, “SUPERBANK\SMSCliToknAcct&” tienen este privilegio. Servidor DNS_LPZ – Servidor de Recepción
56
Los usuarios “BUILTIN\Administrators”, “BUILTIN\Backup Operators”, “BUILTIN\Server Operators”, “BUILTIN\Print Operators”, “BUILTIN\Account Operators” tienen este privilegio. Servidor SERVERUSR4 – Servidor SIF Los usuarios “BUILTIN\Administrators”, “BUILTIN\Backup Operators” tienen este privilegio.
Privilegios para tomar control de los archivos El parámetro de “Tomar control sobre archivos u objetos” debe ser restringido para ciertos usuarios, si este privilegio se otorga innecesariamente existe el riesgo de que usuarios no autorizados puedan ganar acceso a datos sensitivos o recursos del sistema. Las mejores prácticas de la industria nos muestran que ninguno de los usuarios deberían tener este privilegio. Sin embargo, en algunos ambientes sería recomendable que el Administrador del sistema tenga este privilegio. Servidor SERVERUSR3 – Principal Domain Controller y Proxy Server Los usuarios “BUILTIN\Administrators” tienen este privilegio. Servidor DNS_LPZ – Servidor de Recepción Los usuarios “BUILTIN\Administrators” tienen este privilegio. Servidor SERVERUSR4 – Servidor SIF Los usuarios “BUILTIN\Administrators” tienen este privilegio.
57
V. RESULTADOS OBTENIDOS Gestión informática 1. Evaluación de la gestión informática de la Unidad de Sistemas (USI). Procedimiento aplicado 2. Verificaremos la existencia de normas y procedimientos para la administración de las funciones estratégicas del área de sistemas que permitan controlar la consistencia, orientación tecnológica y el efectivo enfoque tecnológico del Plan Estratégico de Sistemas. Adicionalmente verificaremos que el plan estratégico de sistemas esté alineado a los objetivos definidos en el plan estratégico de la SBEF. Resultados obtenidos Como resultado del análisis del documento “Plan estratégico de la SBEF para el período 2001 – 2007”, obtuvimos los siguientes resultados: El documento incluye los siguientes aspectos: 1. 2. 3. 4.
Misión de la USI Funciones Análisis FODA Estrategias generales de gestión, donde se definen los objetivos. Asimismo, observamos que el procedimiento utilizado para la planificación estratégica y operativa de las distintas áreas consideró las siguientes etapas:
1. 2. 3. 4. 5. 6.
Taller de planificación, donde se definieron los objetivos estratégicos (PES). Elaboración de los POA´s Definición de las fichas técnicas. Priorización de los trabajos a cargo del comité de sistemas. Nuevos requerimientos. Asignación de los trabajos en la USI. Como resultado de la revisión de las fichas técnicas hemos observado que las mismas no reflejan en forma clara y específica las necesidades de apoyo que las áreas de la SBEF requerirán de la USI, lo cual dificulta, entre otros, los siguientes aspectos:
1. Identificación de posibles implantaciones 2. Definición de los estándares de hardware y software de base que serán adoptados. 3. Identificación de necesidades de información de las áreas usuarias 4. Identificación de oportunidades de proyectos.
58
5. 6. 7. 8.
Priorización de proyectos Definir las estrategias de desarrollo Cuantificar los esfuerzos de desarrollo y mantenimiento. Definición de las estrategias de HW y SW. Asimismo, como resultado del análisis del documento “Planificación estratégica de la USI gestión 2001 – 2007”, observamos lo siguiente:
Se definió y documentó el entendimiento de lo que es el “IT Governance”, donde se definieron los siguientes aspectos:
Qué es el “IT Governance” Qué cubre Alineamiento estratégico de IT (Tecnología de la Información) Desarrollo de valor IT (Tecnología de la Información) Administración del riesgo Medidas de performance
Funciones de la Unidad de Sistemas Planificación estratégica Análisis FODA Estrategias a partir del análisis FODA En relación a las estrategias observamos que dicho documento incluye acciones estratégicas de la USI directamente relacionadas con las estrategias generales del Plan Estratégico de la SBEF. Sin embargo, los objetivos definidos en el POA no reflejan tareas específicas, lo cual ocasiona que el trabajo de seguimiento y evaluación sobre el logro de los mismos, cuente un grado de subjetividad. Por otro lado, la falta de objetivos y tareas concretas en los POA´s de las intendencias, dificulta la definición de objetivos claros y cuantificables en la USI. Por todo lo mencionado anteriormente, observamos que a nivel general, las acciones definidas en el POA de sistemas, están alineadas con los objetivos estratégicos definidos en el PES. Ver detalle de acciones estratégicas en Anexo 1. Procedimiento aplicado
3. Revisaremos los procedimientos utilizados para el seguimiento a los proyectos y revisaremos los informes de seguimiento al plan operativo anual.
59
Resultados obtenidos Como resultado de los procedimientos aplicados observamos que el seguimiento que se realiza sobre los proyectos no siempre sigue los mismos procedimientos o estándares, lo cual puede ocasionar que los resultados obtenidos tengan distintos niveles de seguimiento. Por otro lado, observamos que no se aplican procedimientos formales y estandarizados para el seguimiento al Plan operativo anual. Sin embargo, es importante mencionar que debido a la falta de una adecuada especificación de los requerimientos a la Unidad de Sistemas de Información, por parte de las áreas usuarias, no es posible mantener un adecuado procedimiento de seguimiento al Plan Operativos de la USI, esto principalmente porque los requerimientos específicos son recibidos por la USI en forma posterior a la definición del POA. Asimismo, observamos los siguientes aspectos:
Observamos que el comité de sistemas realiza trabajos de seguimiento a los proyectos y que la Jefatura de la unidad cuenta con mecanismos de seguimiento a los proyectos los cuales son publicados periódicamente en la intranet. Sin embargo, es importante controlar que la actualización de dicha información sea realizada correctamente para que esté permanentemente actualizada. Por otro lado, observamos que la carga de trabajo relacionada con proyectos de desarrollo de sistemas es bajo, lo cual tiene una relación directa con las características de la Superintendencia (Ente regulador). Se realizan revisiones del POA en forma semestral, las cuales son documentadas formalmente por la Unidad de Desarrollo Operativo. Las reuniones de comité de sistemas deben ser realizadas en forma mensual. Sin embargo, el nivel de cumplimiento de dicha disposición no es el adecuado. No se emiten informes específicos de seguimiento al POA de sistemas. Procedimiento aplicado
4. Revisaremos los procedimientos aplicados para la evaluación periódica de los sistemas. Resultados obtenidos Como resultado de los procedimientos aplicados no encontramos evidencia relacionada con la aplicación de procedimientos periódicos formales, orientados a medir el desempeño de los sistemas ni de los recursos tecnológicos de hardware.
60
Procedimiento aplicado 5. Evaluaremos los procedimientos establecidos para realizar estudios de factibilidad y verificaremos el cumplimiento de los procedimientos de adquisición de bienes y servicios definidos SBEF. Resultados obtenidos Como resultado de los procedimientos aplicados no hemos identificado evidencia de la aplicación de procedimientos formalmente documentados para realizar estudios de factibilidad de hardware ni de software. En relación a la adquisición de bienes y servicios, observamos que se aplican los procedimientos definidos por la Contraloría General de la Nación y por los organismos financiadores, cuando los bienes o servicios son adquiridos utilizando fondos de estos. Asimismo y como resultado de las pruebas realizadas, observamos que se aplicaron los procedimientos establecidos para la compra de: Bien adquirido 61 computadoras portátiles 46 computadoras personales 7 impresoras 1 impresora a color 7 workstations 7 Monitores Flat 2 Proyectores
Tipo de recurso Recursos propios Recursos Banco Mundial Recursos Banco Mundial Recursos Banco Mundial Recursos Banco Mundial Recursos Banco Mundial Recursos Banco Mundial
Tareas Adicionales Propuestas Procedimientos aplicados
Evaluaremos que existan procedimientos para planificar las estrategias de sistemas. Evaluaremos que existan procedimientos para presupuestar las actividades.
61
Evaluaremos que existan procedimientos para identificar las necesidades o requerimientos específicos de los proyectos. Realizaremos pruebas sobre una muestra de proyectos de la USI, que nos permitan verificar si los proyectos de sistemas son manejados según los procedimientos definidos. Resultados obtenidos Se adoptó la metodología del “Reglamento específico del sistema de programación de operaciones”, la cual incluye información relacionada con:
Presupuesto de tiempo de las actividades Requerimientos generales de las áreas usuarias. Sin embargo, el documento “Plan Estratégico de la USI”, no incluye los aspectos específicos de un plan estratégico de Sistemas, el cual de acuerdo a las mejores prácticas de la industria debería contemplar, entre otros, los siguientes aspectos.
I. II. III. IV.
Definición de las necesidades de la organización y de información Definición de los objetivos tecnológicos Definir y seleccionar una estrategia de sistemas Desarrollo del plan de implementación de la estrategia de sistemas En relación a las pruebas realizadas para verificar el cumplimiento de los procedimientos para la administración de proyectos, estas fueron documentadas en el punto 30, 32 y 33. Procedimiento aplicado
7. Realizaremos una evaluación general del ambiente de la Base de Datos DBMS, revisando el ambiente de ejecución de la misma: para lo cual revisaremos la estructura general de seguridad del sistema operativo, privilegios de acceso a la base de datos, los procedimientos aplicados para el mantenimiento y actualización de la Base de Datos y los procedimientos aplicados para la recuperación y respaldo de la misma. Resultados obtenidos
Estructura de seguridad del sistema operativo: Se revisaron los parámetros generales de seguridad del sistema operativo Digital Unix Tru64 y del sistema operativo Windows 2000, los cuales soportan los motores de base de datos Informix y SQL Server respectivamente, nuestra revisión contemplo los siguientes aspectos:
62
Evaluación de parámetros de usuarios. Evaluación de parámetros de grupos Evaluación de parámetros de directorios Las observaciones que surgieron de la revisión de los parámetros de seguridad del sistema operativo, se encuentran detalladas en las recomendaciones del presente informe.
Privilegios de acceso: Los privilegios de acceso se encuentran definidos por la administración de passwords y el alta, baja y modificación de usuarios. Estos aspectos se encuentran detallados en el punto 41. Los principales aspectos son los siguientes:
No existencia de políticas y normas formalmente establecidas y aprobadas Administración de passwords por parte del Administrador del Sistema Generación de passwords por parte de la USI mediante un programa generador de claves Existencia de autorización de jefatura o intendencia para el alta de usuarios No existe la posibilidad de cambio de clave inicial por parte del usuario No existe la renovación automática de claves No existe la posibilidad de cambio de clave por parte del usuario, a excepción del sistema SIF. Bloqueo de permiso de acceso luego de tres intentos fallidos. Habilitación a las 24 horas sin necesidad de requerimiento del usuario dueño de la cuenta. Mantenimiento y actualización: No existen procedimientos formales para el mantenimiento y actualización de las bases de datos. Sin embargo, para la base de datos Informix se ejecuta periódicamente el procedimiento “update statistics”, para la base de datos SQL Server se monitorea periódicamente la cantidad de registros existentes y su crecimiento.
Recuperación y respaldo: La recuperación y respaldo de la información se encuentra detallada en el punto 61. Los principales aspectos son los siguientes:
Se obtienen copias de respaldo diarias y mensuales
63
Las copias mensuales se obtienen en dos copias, la primera queda en la USI y la segunda es enviada a la bóveda de un banco. Se utilizan cintas de 4mm y cintas DLT para los backups No se tiene identificado el ciclo de vida de las cintas No se cuenta con una bitácora de operación para la obtención de las copias de respaldo Se cuenta con un registro de las copias mensuales en la cintoteca Procedimiento aplicado
8. Se verificará la existencia de políticas, normas y procedimientos, para la supervisión general de las funciones del personal de la USI. Para lo cual aplicaremos los siguientes procedimientos: 9. Evaluaremos si la Estructura Organizacional es adecuada y puede apoyar los planes, proyectos y tareas emprendidas por la USI. Verificaremos que los manuales de funciones estén adecuados a la estructura organizacional. Resultados obtenidos De acuerdo al trabajo realizado observamos la existencia de dos áreas de trabajo, desarrollo y operaciones, dichas áreas cuentan con sus respectivos responsables. Sin embargo, dichos encargados no están formalmente designados dentro de la estructura organizacional de la Unidad, consecuentemente la estructura de la USI es totalmente horizontal, lo cual significa que todos los funcionarios de dependen en forma directa de la Jefatura de la Unidad. El personal de la USI está organizado en las siguientes funciones:
Analista programador Encargado de soporte técnico Encargado técnico en comunicaciones Operador de sistemas Asimismo, observamos que el personal de sistemas está agrupado en las siguientes categorías: CATEGORIA Jefe de División B S–I–B S – II – A
CANTIDAD DE PERSONAL 1 1 3
% 42%
64
S S S S
– – – –
V–A VII – C VIII – C IX – B
T–I–B T–I–C T – IV – A TOTAL
1 1 1 1 1 1 1 12
33%
25% 100%
Como se puede observar en la matriz, aproximadamente el 50% del personal esta concentrado en los niveles más altos de la estructura. Asimismo, observamos que las áreas de desarrollo y producción no están adecuadamente segregadas ya que los analistas/programadores tienen acceso tanto a las herramientas de desarrollo, programas fuente, como a los programas en producción y datos en línea. Por otro lado, observamos que los manuales de funciones están alineados con los cargos actuales, excepto por la falta de la designación formal de los responsables de las áreas de desarrollo y producción. Asimismo, observamos que no se ha definido formalmente la función de oficial de seguridad de los sistemas. Por todo lo mencionado anteriormente, consideramos que el organigrama no refleja la estructura jerárquica real. Adicionalmente, observamos que no se cuenta con la función de auditoría de sistemas, si bien esta función no forma parte de la estructura organizativa de la USI, es recomendable la definición de dicha función como parte de la Unidad de auditoría interna. Por otro lado, observamos que si bien se ha definido la función de un comité de sistemas, dicha instancia no ha mantenido regularidad en sus funciones, debido principalmente por la falta de una planificación detallada de las tareas del área de sistemas. Este aspecto ocasiona que las funciones del comité de sistemas, que son entre otros, la de ser una instancia de planificación, decisión y supervisión de los recursos IT (Tecnología de la Información). Asimismo, y en atención a una expectativa manifestada por la Intendencia General y la líder del equipo de contraparte, hemos realizado un análisis de la cantidad de personal en la USI, para lo cual se consideraron encuestas internacionales realizadas durante el año 2001, las cuales muestran estadísticas porcentuales de la dotación de empleados en las áreas de
65
sistemas, respecto del total de empleados existentes en las distintas instituciones, por segmento de industria, a nivel mundial. Resultados Obtenidos Como resultado información:
del
trabajo
realizado
Aspecto analizado Porcentaje de personal en el área de sistema en relación al total de empleados de la organización 1 Porcentaje de distribución de personal por tareas Soporte/Mantenimiento Producción/Operaciones Desarrollo Administración de los sistemas Otras tareas
hemos
obtenido
la
Métrica internacional 5.5 %
Situación actual 7.6 %
35.9 % 27.9 % 21.0 % 14.0 % 1.2 %
35.0 % 24.8 % 33.7 % 4.1 % 2.4 %
siguiente
- 2001 IT Spending and Staffing Survey Results, Gartner Group, Strategic Analysis Report, September 19, 2001. - The Ratio of IT Employees to Total Enterprise Employees, Gartner Advisory, Tactical Guidelines, January, 4, 1999. - http://www.cio.com/forums/executive (CIO executives research centre)
Sin embargo, es importante mencionar que este tipo de métrica por si sola, no proporciona una visión completa, por lo que es necesario considerar adicionalmente, aspectos tales como:
Presupuesto de sistemas como porcentaje del total presupuestado. Presupuesto de tecnología por empleado. Costo tecnológico por usuario. Costo de operación de los sistemas. Inversiones tecnológicas. Costo de mantenimiento de los sistemas. Costo del personal de sistemas. Aspecto analizado Porcentaje del presupuesto tecnología con relación presupuesto total.
de al
Métrica internacio nal 6.08 %
Situación actual 7.2 %
66
Porcentaje de gastos de tecnología por tipo de recurso. Costo de personal Costo de Hardware Costo de Software Costo de proveedores externos Costo de comunicaciones de voz Costo de comunicación de datos Otros
33.9 % 22.3 % 17.8 % 12.4 % 4.0 % 5.2 % 4.5 %
34.4 % * * * * * *
* Estos aspectos que no han sido cuantificados debido a que la información disponible no cuenta con el nivel de desagregación necesaria. Procedimientos aplicado 10. Verificaremos los procedimientos aplicados para supervisar los trabajos en ejecución, así como la utilización de los recursos de manera apropiada. Resultados obtenidos Como resultado del trabajo realizado observamos que no existen procedimientos formales para supervisar los trabajos en ejecución, sean estos de desarrollo, modificación o soporte a usuarios. Sin embargo, observamos que se aplican procedimientos de seguimiento y control sobre los trabajos de desarrollo. Los cambios a los programas no cuentan con mecanismos estándar para la supervisión de los trabajos en ejecución, los trabajos de apoyo a usuarios, como ser, reportes, requerimientos especiales y otros, tienen un bajo nivel de seguimiento. Por otro lado, observamos que existen casos en los cuales los requerimientos de apoyo de los usuarios son realizados directamente a los analistas, los cuales hacen entrega de los resultados directamente a los usuarios, sin tener el seguimiento ni control de calidad correspondiente. Procedimiento aplicado 11. Verificaremos que el personal de la USI está calificado para la realización de sus funciones, a través de un análisis de cumplimiento de los requerimientos definidos en los perfiles de cargo, para lo cual tomaremos como base la currícula de los empleados. Resultados obtenidos
67
Como resultado de las pruebas realizadas sobre el nivel de cumplimiento de los requerimientos definidos en los perfiles de cargo de los funcionarios de la USI, obtuvimos los siguientes resultados:
Cuatro personas cumplen con el 100% de los requisitos (Jefe de Unidad y Analistas programadores, en el caso de estos últimos, su formación formal excede a los requerimientos del perfil de cargo definido ya que los mismos cuentan con maestría). Seis personas presentan un nivel de cumplimiento entre 75 y 83% de los requisitos. Cuatro personas tienen un nivel de cumplimiento por debajo del 75%. Los aspectos de incumplimiento están relacionados con la formación académica y experiencia. A continuación presentamos un cuadro resumen de los porcentajes de cumplimiento alcanzados para cada uno de los aspectos evaluados, de acuerdo a los perfiles de cargo definidos para los funcionarios de la USI. Cargo
Educaci ón Formal Jefe de Unidad 100 Analista Programador 76 Encargado de Soporte Técnico 0 Encargado de Soporte Técnico 0 de Comunicaciones Operador 67 PROMEDIO 48,6
Formación Complementa ria 100 81 100 100
Experien Inglés cia técnic o 100 100 67 100 100 100 100 100
78 91,8
33 80
67 93,4
Procedimiento aplicado 12. En base a los resultados de los puntos 2, 8, 9, 10 y 11 evaluaremos al personal de la USI a fin de identificar al personal clave. Resultados obtenidos Como resultado del trabajo realizado observamos que las funciones y responsabilidades del personal de la Unidad de Sistemas está basada en responsables por sistema, lo cual muestra que los Analistas/Programadores están especializados en las aplicaciones que están a su cargo y en caso de vacación y ausencia, no se cuenta con personal de remplazo que tenga el nivel de conocimiento necesario para brindar el soporte a las mismas.
68
APLICACION
XR JCI C M CL GG M CQ CA BC EZ RA M F N de 1
Central de Información Riesgo crediticio Sistema de Información Financiera Sistema de Acuotaciones Clausura y Rehabilitación de Cuentas Corrientes Operaciones Interbancarias Bolsín Unix Bolsín SQL Evolutivo Central de Información de Riesgo crediticio Microcrédito Sistema de Apoyo a Supervisión CAEDEC Sistema Recursos Humanos Sistema de Accionistas Camel Perlas Sistemas Administrativos Sistema de Control Documentario Sistema de Multas y Sanciones Mesa de Entrada/Multas Sistema de asignación de passwords Entidades Financieras Informe confidencial Boletín CIRC Sistema de asignación de passwords SBEF SIPOA TOTAL 0
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 3
3
8
2
4
1
1
0
1
0
1
Como se puede observar en el cuadro existen cuatro personas que tienen asignado la responsabilidad de tres o más sistemas, entre los cuales se encuentran los más importantes para la operación de la Superintendencia. Tareas Adicionales Propuestas
69
Procedimiento aplicado 13.
Realizaremos una evaluación general de todas las funciones existentes en la USI y no solamente las requeridas en el punto 9. Evaluaremos el perfil psicológico a través de pruebas generales psicosométricas orientadas a evaluar: inteligencia, habilidad verbal, habilidad numérica, habilidad espacial, nivel de concentración y atención, resolución de problemas simples y complejos, rasgos de personalidad. Resultados Obtenidos Como resultado de las pruebas psicosométricas, aplicadas al personal de la USI, obtuvimos los siguientes resultados generales: Aspecto evaluado Capacidad intelectual Trabajo bajo presión Razonamiento verbal
Razonamiento espacial Razonamiento numérico
Resolución simples
de
problemas
Atención a los detalles Resolución complejos
de
Concentración
problemas
Resultado obtenido Nivel de inteligencia general superior a los parámetros normales Desempeño bajo presión dentro de los parámetros normales Adecuados niveles de razonamiento verbal, los cuales muestran ser ligeramente superiores a los normales Razonamiento espacial entro de los parámetros normales. Adecuados niveles de razonamiento numérico, los cueles muestran estar ligeramente superiores a los parámetros normales. Capacidad de resolución de problemas simples dentro de los parámetros normales. Capacidad de atención a detalles dentro de los parámetros normales. Capacidad de resolución de problemas complejos dentro de los niveles normales. Niveles de concentración dentro de los niveles normales.
70
80
75
60
63
59
53
60 46
40
51
57
54
20 0 Capacidad
Trabajo bajo
Razonamiento
Razonamiento
Razonamiento
Resolución de
Atención a
Resolución de
Intelectual
P resión
Verbal
Espacial
Numérico
P roblemas
Detalles
P roblemas
Simples
Concentración
Complejos
Como se puede observar en el gráfico la capacidad intelectual es el parámetro evaluado con mayor puntaje y no existe ningún aspecto que se encuentre por debajo de los parámetros normales. Procedimiento aplicado 14.
Verificaremos los procedimientos aplicados para el seguimiento al presupuesto anual de tecnología, y los procedimientos para el monitoreo del costo y del beneficio. Asimismo, verificaremos el cumplimiento de los procedimientos de adquisición de bienes y servicios definidos. No emitiremos una opinión en relación a los precios de compra excepto que identifiquemos precios significativamente inusuales. Resultados obtenidos Como resultado de los procedimientos aplicados, observamos que no se realiza un seguimiento periódico al presupuesto anual de tecnología ni se monitorea la relación costo beneficio. Por otro lado, como resultado de las pruebas realizadas, para una muestra de adquisiciones, obtuvimos los siguientes resultados: Cantida Compra d 61 Computadoras portátiles 54 46 computadoras 7 printers 1 color 7
Workstations
Costo Precio (US$) Unitario 277,306,0 4,546,00 0 116,582,2 2,158,93 0
Comentarios Sin excepciones.
El acta de recepción definitivo y el informe al UEP, están en proceso. 70,854,4 10,122,07 El acta de recepción 8 definitivo y el informe
71
al UEP, proceso.
están
en
Asimismo y como resultado de los procedimientos aplicados observamos que existen sistemas que fueron adquiridos y/o iniciados por las áreas usuarias sin la participación de la Unidad de Sistemas, tales como:
Sistema CIRC de Microcrédito A de Juan Spyral
15. Para la evaluación de la administración del área, se aplicaron los siguientes procedimientos: Para la evaluación de la administración del área, se aplicaron los siguientes procedimientos: Procedimiento aplicado 16. Verificaremos si las políticas y normas de seguridad establecidas por la USI están claramente definidas, documentadas y aprobadas. Verificaremos si las políticas y normas son periódicamente revisadas y actualizadas. Verificaremos que las funciones y responsabilidades del Área de Administración de la Seguridad de los Sistemas de Información se encuentran formalmente definidas y documentadas. Resultados obtenidos Como resultado de los procedimientos aplicados observamos que se cuenta con normas para seguridad como ser: obtención de copias de respaldo, protección contra virus, control de ingreso al área de sistemas, control de ingreso para limpieza, uso de software, actualización de passwords, y otros. Sin embargo, de acuerdo con las mejores prácticas no se cuenta con la totalidad de las normas que se consideran mínimas necesarias para la administración de la seguridad. Este aspecto está más ampliamente evaluado en el punto 40. Procedimiento aplicado 17. Verificaremos la existencia de políticas y procedimientos para proteger los derechos de propiedad intelectual de los productos desarrollados en la USI.
72
Resultados obtenidos Como resultado de los procedimientos aplicados observamos que los contratos de trabajo no incluyen ningún tipo de cláusula específica orientada a proteger los derechos de propiedad intelectual de la SBEF. Procedimiento aplicado 18. Verificaremos la existencia de políticas referentes a la administración del personal, para lo cual revisaremos la existencia de:
Políticas formales para la contratación de personal. Procedimientos implantados y documentados relacionados con empleados despedidos, transferidos y/o promovidos. Resultados obtenidos Como resultado de los procedimientos aplicados observamos que el área de recursos humanos de la SBEF, cuenta con normas formalmente establecidas para la contratación de personal, el cual incluye una serie de tareas las cuales deben ser seguidas cuando se contrata personal, surge una nueva convocatoria o se despide a un empleado. El personal de la Unidad de sistemas se rige a dichas normas y procedimientos. Asimismo, observamos que se cuenta con un plan de capacitación el cual es preparado a inicios de año con la colaboración del área de RRHH quién es responsable por la planificación y seguimiento de los mismos. Procedimiento aplicado
19. Verificaremos la existencia de un plan de capacitación que esté formalmente definido y presupuestado. Resultados obtenidos Como resultado de las pruebas realizadas obtuvimos los siguientes resultados
Curso Planificado Realizado Programación en tres capas 0 Generalidades sobre supervisión de entidades Financieras 1° 0 Programación avanzada en Lotus Notes 1
73
Programación avanzada en SQL Curso avanzado de CISCO Programa de Post Grado Inglés
0 1 1 1
De los siete cursos planificados cuatro fueron realizados lo cual muestra un 57% de cumplimiento. Adicionalmente, se realizó un curso de cableado estructurado, que no estaba inicialmente planificado, con lo cual el nivel de cumplimiento sería de 62,5%. Procedimiento aplicado 20. Que existan planes de capacitación adecuados para el personal de la USI. Resultados obtenidos El plan de capacitación definido para la Unidad de Sistemas, muestra en forma general los cursos que deben ser realizados durante la gestión. Sin embargo, no especifica quienes serán las personas que deberán participar en los mismos. Tareas Adicionales Propuestas Procedimiento aplicado 21. Verificaremos el cumplimiento del plan de capacitación definido por la USI. Resultados obtenidos El nivel de cumplimiento del plan de capacitación muestra que, a la fecha de revisión, se ejecutó el 62,5% de los cursos definidos en el plan de capacitación, quedando aún pendiente los siguientes cursos: 1. Programación avanzada en SQL 2. Programación en tres capas 3. Generalidades sobre supervisión de entidades Financieras
Procedimiento aplicado 22. Verificaremos los procedimientos que son aplicados para la evaluación de riesgos. Resultados obtenidos
74
Como resultado de los procedimientos aplicados, observamos que no se cuenta con normas ni procedimientos establecidos para la administración de riesgos. Sin embargo, es importante hacer las siguientes consideraciones: Las mejores prácticas indican que el riesgo cuenta con tres elementos:
Las amenazas y vulnerabilidades de los procesos y/o activos. El impacto en los activos debido a las amenazas y vulnerabilidades. La probabilidad de ocurrencia de las amenazas. En relación a este aspecto, las mejores prácticas indican que las metodologías de análisis de riesgos consideran como una de las primeras actividades la clasificación de los activos que deben ser protegidos, entre los que normalmente son considerados los siguientes:
Información y datos Hardware Software Servicios Documentos Recursos Humanos Por lo tanto, es importante mencionar que si bien no se cuenta con normas ni procedimientos formalmente establecidos para el análisis de riesgos, la USI aplica procedimientos que están orientados a minimizar riesgos asociados a algunos de los aspectos anteriormente mencionados, como ser: Acciones que son aplicadas Obtención de copias de respaldo Se cuenta con mantenimiento preventivo y convenios de pólizas de seguro Existen normas para la aplicación y uso de antivirus, uso de software no autorizado y otros Existen normas claras para reclutamiento de personal, evaluaciones periódicas y planes de capacitación.
Area de riesgo asociada Información y datos Hardware Software Recursos Humanos
Procedimiento aplicado 23. Verificaremos la existencia administración de:
de
normas
y
procedimientos
para
la
75
La tecnología del proyecto Los tiempos y cronogramas de trabajo, contemplando: Organización del proyecto Ciclo de vida del proyecto Estrategia del proyecto Planificación El presupuesto Los proveedores externos La migración e implantación de los sistemas Resultados obtenidos Como resultado de los procedimientos aplicados observamos que no existen normas ni procedimientos formales para la administración de proyectos.
24. Para la administración procedimientos:
de
la
calidad,
se
aplicaron
los
siguientes
Procedimiento aplicado 25. Verificaremos la existencia normas y procedimientos para la administración de la calidad en los proyectos que encara el área de sistemas. Resultados obtenidos Como resultado del trabajo realizado observamos que la Unidad de Sistemas de Información no aplica procedimientos para la administración de la calidad. Consecuentemente no fue posible aplicar el procedimiento definido. Procedimiento aplicado 26. Tomando como base el alcance del Plan General de Calidad, evaluaremos la adherencia a estándares de calidad. Resultados obtenidos Como fue mencionado anteriormente, no se aplican procedimientos específicos para medir la calidad de los servicios ni de los sistemas en producción. Sin embargo, de acuerdo a la encuesta realizada respecto a la calidad del servicio que ofrece la USI, obtuvimos los siguientes resultados:
76
Supervisión Bancaria Supervisión No Bancaria Asuntos Jurídicos Estudios y Normas
Bueno
8
Bueno
5
Entre Bueno y 2 Muy Bueno Regular 6
1
1
5
2
1
3
Excelente
Muy bueno
Bueno
Regular
Cant.
Deficiente
Percepción promedio
Malo
Intendencia
1 3
1
1
1
1
Asimismo, se pudo determinar la percepción de los usuarios en relación a las fortalezas y debilidades de la USI, entre las que podemos mencionar: Fortalezas Personal capacitado Equipamiento de computación adecuado
Debilidades Desorganización Servicio inoportuno al usuario
Procedimiento aplicado 27. Verificaremos que existan procedimientos apropiados para el desarrollo de aplicaciones, tanto para el proceso mismo de desarrollo como para la documentación de las aplicaciones. Resultados obtenidos Como resultado de los procedimientos aplicados, observamos que se cuenta con normas establecidas para el desarrollo de aplicaciones y para la documentación de las mismas. Las normas consideran lo siguiente:
Análisis y Diseño de sistemas Diseño de las estructuras de datos Diccionario de datos Elaboración de manuales de programación, técnico, de usuario y de operaciones Estos aspectos fueron evaluados con mayor detalle en los puntos 32 y 33 de este informe, donde se puede observar que existen algunos aspectos que no son considerados dentro de las normas identificadas en este punto.
77
Procedimiento aplicado 28. Verificaremos la aplicación de procedimientos para generar reportes en base a las métricas definidas en el plan de calidad. Resultados obtenidos Como fue mencionado anteriormente, la USI no aplica procedimientos para la medición de los niveles de calidad, consecuentemente, no fue posible aplicar este procedimiento. Sin embargo, de acuerdo a procedimientos adicionales aplicados obtuvimos los siguientes resultados: El presente gráfico muestra el nivel de utilidad de las aplicaciones para el negocio (eje y) y la calidad técnica de los sistemas (eje x).
1
9 219
10
11
18 5 4
13
17
3
23
14
8
7
6
15
12
16
1.
CIRC
2.
SIF
3.
Acuotaciones
4.
Clausura y Rehab. de Ctas. Ctes.
5.
Operaciones Interbancarias
6.
Bolsí n Unix
7.
Bolsí n SQL
8.
Evolutivo
9.
CIRC M icrocrédito
10.
Apoyo a Supervisión
11.
CAEDEC
12.
Sistema RRHH
13.
Sistema de Accionistas
14.
Camel
15.
Perlas
16.
Sistemas Administrativos
17.
Control Documentario
18.
M ultas y Sanciones
19.
M esa de Entrada/M ultas
23
Informe confidencial
El cuadrante inferior izquierdo, muestra las aplicaciones que tienen un bajo nivel de utilidad para el negocio y una baja calidad técnica, de acuerdo a las mejores prácticas se debería analizar el retiro de las mismas. El cuadrante inferior derecho muestra las aplicaciones que tienen un bajo nivel de utilidad en el negocio y una alta calidad técnica, de acuerdo a las mejores prácticas estas aplicaciones deberían ser replanteados. El cuadrante superior izquierdo muestra las aplicaciones que tienen un alto nivel de utilidad en el negocio y una baja calidad técnica, de acuerdo a las mejores prácticas estas aplicaciones deberían ser renovado/reemplazado.
78
El cuadrante superior derecho muestra las aplicaciones que tienen un alto nivel de utilidad en el negocio y una alta calidad técnica, de acuerdo a las mejores prácticas estas aplicaciones deberían ser mantenidos/mejorados. Lista de aplicaciones
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 23
Sistema Central de Información de Riesgo crediticio Sistema de Información Financiera Sistema de Acuotaciones Sistema de Clausura y Rehabilitación de Cuentas Corrientes Operaciones Interbancarias Bolsín Unix Bolsín SQL Evolutivo Central de Información de Riesgo crediticio Microcrédito Sistema de Apoyo a Supervisión CAEDEC Sistema Recursos Humanos Sistema de Accionistas Camel Perlas Sistemas Administrativos Sistema de Control Documentario Sistema de Multas y Sanciones Mesa de Entrada/Multas Informe confidencial
DESARROLLO, ADQUISICION E IMPLANTACION DE SISTEMAS 29. Evaluar la aplicación de una metodología adecuada para el desarrollo, adquisición y mantenimiento de sistemas, así como el cumplimiento o implementación de políticas y estándares vigentes. En las pruebas a realizar se debe considerar la verificación de: Procedimiento aplicado 30. Verificaremos que existan procedimientos formalmente establecidos para:
La iniciación de proyectos Evaluaremos que existan procedimientos para realizar estudios de factibilidad y evaluar alternativas de solución.
Documentación del análisis y diseño del sistema Construcción
79
Estructura de la Base de Datos Especificaciones de programas Codificación y pruebas Controles de seguridad Diseño de pistas de auditoría Definición de estrategias de adquisición Implantación Documentación de usuario Documentación de operación del sistema Entrenamiento Implantación en el ambiente de producción Realizaremos pruebas sobre una muestra de proyectos, que nos permita verificar si los mismos son realizados según los procedimientos definidos. Resultados obtenidos No existen procedimientos formalmente establecidos para la iniciación de proyectos, que definan el tipo de documentación que se debe elaborar. Sin embargo, durante nuestra revisión encontramos que se ha elaborado documentación de inicio de proyecto para los siguientes sistemas:
CIRC SIF Acuotaciones CIRC Microcrédito Sistema de Control de Almacenes La documentación de inicio de proyecto que se ha elaborado para los proyectos de Informática mencionados contempla:
Especificaciones técnicas del proyecto de sistemas a ser elaborado Contratos de desarrollo de sistemas No existen procedimientos formalmente establecidos para la elaboración de Estudios de Factibilidad que permitan la evaluación de la solución planteada ni para el planteamiento de soluciones alternativas. Sin embargo, existe documentación relacionada a estudios de factibilidad para los siguientes proyectos de sistemas:
CIRC SIF Sistema de Control de almacenes
80
La documentación de “estudio de factibilidad” que se elabora para los proyectos de Informática no contempla:
Estimación de costos operativos Descripción de alternativas que incluyan: Descripciones técnicas Análisis costo/beneficio Existen lineamientos establecidos que definen formalmente el tipo de documentación que se debe elaborar durante las etapas de análisis y diseño de sistemas, los estándares de diseño y desarrollo se basan en la Metodología Estructurada de Gane–Sarson (la cual indica que un proyecto debe considerar las etapas de análisis, diseño y construcción, asimismo, está orientada a la implementación de los programas en forma estructurada y muchos autores se refieren a esta como metodología tradicional). Durante nuestra revisión se encontró documentación del análisis y diseño de los sistemas, para los siguientes proyectos desarrollados por la USI:
CIRC SIF Acuotaciones CIRC Microcrédito Sistema de Control de Almacenes Es importante mencionar que dicha información, para mantenerse actualizada, depende en gran medida de la existencia y cumplimiento de las normas definidas para los cambios a los programas. Estos aspectos están detallados en el punto 34. La documentación de análisis y diseño de sistemas que elabora la USI para los proyectos de Informática contempla:
Manual de Análisis y Diseño Manual de Programación Manual Técnico Existen lineamientos establecidos que definen formalmente el tipo de documentación que se debe elaborar para la etapa de construcción de sistemas. Durante nuestra revisión se encontró documentación de la construcción de los sistemas, para los siguientes proyectos desarrollados por la USI:
CIRC SIF Acuotaciones
81
CIRC Microcrédito Sistema de Control de Almacenes La documentación relacionada a la construcción de sistemas que se elabora para los proyectos de Informáticos contempla:
Estructura de la Base de Datos (diagramas Entidad - Relación), normalizados hasta la 3ra forma. Especificaciones de programas y de las interfaces de entrada y salida de datos La adquisición de Sistemas de Software especializados se realiza a través de la elaboración de requerimientos funcionales y especificaciones técnicas que se detallan en un pliego de especificaciones, el cual se utiliza para evaluar a los proveedores. Los proveedores que cumplen con los requerimientos funcionales y técnicos son preseleccionados para una segunda instancia, donde se evalúa el precio propuesto y se adjudica el proyecto al proveedor que haya obtenido mayor puntaje. Existen lineamientos establecidos que definen formalmente el tipo de documentación que se debe elaborar para la etapa de implantación de sistemas. Durante nuestra revisión se encontró documentación de la construcción de los sistemas, para los siguientes proyectos desarrollados por la USI:
CIRC SIF Acuotaciones CIRC Microcrédito Sistema de Control de Almacenes La documentación relacionada a la construcción de sistemas que se elabora para los proyectos de Informáticos contempla:
Manual del Usuario Manual de Operaciones Adicionalmente, durante nuestra revisión sólo encontramos material de entrenamiento para el Sistema CIRC (Central de Información de Riesgo Crediticio). No existen procedimientos establecidos que definan como llevar a cabo formalmente la implantación de los sistemas, tampoco se ha definido la documentación que se debe elaborar durante este proceso. Durante nuestra revisión no encontramos documentación formal que respalde las tareas de implantación de los proyectos para ninguno de los proyectos evaluados.
82
Procedimiento aplicado 31.
Verificaremos los procedimientos aplicados para: verificar los métodos de diseño, aprobación del diseño, definición de la estrategia de adquisición, documentación de los requerimientos, especificaciones, pruebas del software de aplicación, materiales de referencia y apoyo para y el usuario Realizaremos pruebas sobre una muestra de proyectos, que nos permita verificar si los mismos son realizados según los procedimientos definidos. Resultados obtenidos No existen procedimientos formales para verificar los métodos de diseño, aprobación del diseño, definición documentación de los requerimientos, especificaciones, pruebas del software de aplicación, materiales de referencia y de apoyo para los usuarios. Cada uno de los proyectos desarrollados por la SBEF es administrado de manera independiente y no se basa en procedimientos formalmente establecidos los puntos mencionados, por lo que la documentación existente varía según el proyecto. Procedimiento aplicado
32. Revisaremos, para una muestra, la aplicación de procedimientos para:
La evaluación de hardware y software nuevos. El mantenimiento preventivo de hardware. La seguridad del software del sistema. La instalación y mantenimiento del software del sistema. Resultados obtenidos La adquisición de equipos se realiza en función a las normas SABS (Sistema de Adquisición de Bienes y Servicios), para lo cual se elabora inicialmente un pliego de especificaciones para que las empresas presenten propuestas respecto a los bienes ofertados. Generalmente, la adquisición de equipos de computación se realiza con fondos de terceros como el BID (Banco Interamericano de Desarrollo) o BM (Banco Mundial) motivo por el cual además de cumplir con las normas básicas de la SABS se debe cumplir con los requerimientos de las entidades financiadoras. Sin embargo, no existen procedimientos formales para la evaluación del software y hardware nuevo, por lo que no se realizó esta actividad para los sistemas evaluados (ver cuadro adjunto), aquellos bienes que cumplen con el pliego de
83
especificaciones desarrollado por la SBEF podrían ser adquiridos, la adjudicación de compra de hardware o software se basa en el cumplimiento de las especificaciones técnicas y en el precio de la propuesta económica. Una de las especificaciones para la compra de equipos de hardware es que exista una garantía de 3 años para los equipos, luego de ese periodo se procede a realizar contratos de mantenimiento preventivo para los equipos. No existen procedimientos formales para la administración de Seguridad del Software del Sistema, por lo que ninguno de los proyectos de sistemas contempla este tipo de procedimientos (ver cuadro adjunto). No existen procedimientos formales para la instalación de los sistemas de software desarrollados por la USI, no se cuenta con procedimientos formales para la aceptación del sistema, procedimientos para el pase a producción ni procedimientos para la custodia de códigos fuente. Existen lineamientos generales para la administración de los cambios a los programas y la realización del mantenimiento a los sistemas. Sin embargo, no se cuenta con procedimientos formales para la ejecución de pruebas a las modificaciones ni para la aceptación formal de los cambios realizados. Documentación/Sis tema
CIRC
Evaluación de hardware y software nuevos Mantenimiento preventivo de hardware La seguridad del software del sistema Mantenimiento del software del sistema
No existe
SIF
Acuotacio nes
CIRC Microcréd ito
Sistema de Almacene s
No existe
No existe
No existe
No existe
Existe
Existe
Existe
Existe
Existe
No existe
No existe
No existe
No existe
No existe
Existe
Existe
Existe
Existe
Existe
Procedimiento aplicado 33.
Revisaremos para una muestra la aplicación de procedimientos y estándares de tecnología informática para: El manual de procedimientos del usuario El manual de operaciones
84
La capacitación El ajuste de desempeño La conversión Las pruebas de los cambios Criterios y desempeño de las pruebas paralelas/piloto Las pruebas de aceptación final La acreditación y pruebas de seguridad Las pruebas operativas La evaluación del cumplimiento de los requerimientos del usuario La revisión administrativa post implementación Resultados obtenidos Los proyectos de sistemas cuentan con documentación de manual de usuario, la cual detalla las características funcionales de los sistemas, se cuenta con un manual de operación que describe procedimientos adicionales que son realizados por el personal de sistemas. Como se puede apreciar en el cuadro adjunto, no existe documentación para la capacitación del personal operativo, este tipo de documentación debería incluir manuales de instructor y manual de instrucción para el participante. Sin embargo, durante los “cursos de inducción” que la SBEF dicta a sus empleados se muestra de manera general el funcionamiento de algunos de los sistemas. No existe documentación de ajustes de desempeño realizados a los sistemas operativos, bases de datos u otros relacionados con los sistemas evaluados (ver cuadro adjunto). De la documentación evaluada, ninguno de los sistemas tuvo un proceso de conversión de datos, motivo por el cual este punto no fue aplicable. La documentación de pruebas a los cambios que existe para los sistemas evaluados no es formal. Adicionalmente, los sistemas SIF y de Acuotaciones no tuvieron cambios importantes, por lo que el punto no es aplicable. No existe documentación de pruebas piloto o paralelas realizadas para todos los sistemas evaluados. Sin embargo, generalmente se realizan pruebas paralelas antes de realizar el pase a producción de cualquier sistema (ver cuadro adjunto). Se cuenta con formularios de aceptación para los sistemas evaluados. Sin embargo, los mismos son firmados por los usuarios finales y no por las personas que realizaron el requerimiento del sistema.
85
No existen procedimientos de acreditación ni pruebas de seguridad para los sistemas (Ver cuadro adjunto). No se realizan pruebas de seguridad para el sistema operativo, base de datos ni aplicación. Se realizan pruebas a los manuales de operación. Sin embargo, no existe documentación de las pruebas realizadas a los procedimientos descritos en los manuales de operación de los sistemas. Durante la realización de pruebas, los usuarios finales de cada uno de los sistemas participan para evaluar el cumplimiento de los requerimientos del sistema en cuestión por lo que la aceptación formal de los sistemas sólo ocurre después de que los sistemas cumplen con los requerimientos definidos por el área usuaria. No se realizan revisiones post implementación de los sistemas. Documentación/Sistema
CIRC
SIF
Acuotaci ones
CIRC Microcréd ito
Sistema de Almacene s
Manual de procedimientos del usuario Manual de operaciones Documentación de capacitación Documentación de ajustes de desempeño Documentación de conversión de datos
Existe
Existe
Existe
Existe
Existe
Existe No existe No existe No aplicab le No existe
Existe No existe No existe No aplicabl e Existe
Existe
Existe
Existe No existe No existe No aplicab le No aplicab le No existe Existe
Existe No existe No existe No aplicabl e No existe
Existe
Existe No Existe No existe No aplicab le No aplicab le Existe
No existe Existe
No existe Existe
No existe
No existe
No existe
No existe
No existe
No existe Existe
No existe Existe
No existe Existe
No existe Existe
No existe Existe
No
No
No
No
No
Documentación de pruebas a los cambios Documentación de las pruebas paralelas/piloto Aceptación final de las pruebas Acreditación y pruebas de seguridad en los sistemas Documentación de pruebas operativas Evaluación de cumplimiento de los requerimientos del usuario Revisión de controles
86
Documentación/Sistema
CIRC
SIF
Acuotaci ones
CIRC Microcréd ito
Sistema de Almacene s
post implantación
existe
existe
existe
existe
existe
Procedimiento aplicado 34.
Verificaremos la existencia de normas y procedimientos que permitan controlar las actividades relacionadas a la administración de cambios. Para lo cual verificaremos la existencia de procedimientos para: El inicio del cambio La evaluación de riesgo La priorización de los cambios Pruebas a los cambios Documentación de los cambios Aprobación y rechazo de los cambios Implantación del cambio Entrega de los cambios Cambios de emergencia Informes a la gerencia Realizaremos para una muestra, del total de los cambios que fueron formalmente registrados, pruebas que nos permitan verificar el cumplimiento de los procedimientos existentes. Resultados obtenidos En el caso de los sistemas evaluados, observamos que los mismos cuentan con cierta documentación de respaldo para los cambios realizados. No se realiza un evaluación de riesgo sobre los requerimientos de cambios a los programas. Sin embargo, para los sistemas de Acuotaciones, CIRC Microcrédito y el Sistema de Almacenes, no existieron cambios importantes que hubieran requerido de evaluaciones de riesgo. No se priorizan los requerimientos de cambios a programas, principalmente debido a que las áreas usuarias elaboran sus requerimientos de cambio cuando se presenta la necesidad y no planifican cambios futuros. Las pruebas a los cambios realizados no se encuentran formalmente documentadas para ninguno de los sistemas evaluados. A excepción del sistema SIF donde los cambios no afectaron la documentación del sistema, los demás sistemas cuentan con documentación actualizada de los cambios realizados.
87
Aprobación y rechazo Para la tarea de implantación de los cambios para los sistemas CIRC, SIF y Acuotaciones, no existe la documentación correspondiente, debido a que los cambios efectuados en estos sistemas no modificaron o adicionaron funcionalidades nuevas por lo que no existió un proceso normal de implantación. Todos los cambios realizados se entregan a través de una carta formal de la USI hacia el área usuaria correspondiente. No existen procedimientos para realizar cambios de emergencia a los sistemas. Las cartas formales de entrega, son a su vez informes a la gerencia por lo que todos los sistemas cuentan con este tipo de documentación. Adicionalmente, en sistemas más complejos como el CIRC y el SIF existen informes a la gerencia que se elaboraron durante el transcurso de proyecto.
Documentación/Sistema
CIRC
SIF
Acuotacio nes
CIRC Microcréd ito
Sistema de Almacene s
El inicio del cambio La evaluación de riesgo
Existe No existe
Existe No existe
Existe No aplicabl e No aplicabl e No existe Existe
Existe No aplicabl e No aplicabl e No existe No existe
Existe No aplicabl e No aplicabl e No existe No existe
Existe
Existe
Existe
No aplicabl e Existe No aplicabl e Existe
Existe
Existe
Existe No aplicabl e Existe
Existe No aplicabl e Existe
La priorización de los No cambios Aplicabl e Pruebas a los cambios No existe Documentación de los Existe cambios Aprobación y rechazo Existe de los cambios Implantación del cambio No aplicabl e Entrega de los cambios Existe Cambios de emergencia No aplicabl e Informes a la gerencia Existe
No aplicabl e No existe No aplicabl e Existe No aplicabl e Existe No aplicabl e Existe
88
De acuerdo a las indagaciones realizadas, el procedimiento evaluado no se aplica en algunos casos cuando se realizan cambios menores. OPERACION Y SOPORTE DE SISTEMAS 35. Evaluar la calidad de los controles, procedimientos y estándares implementados para la operación de los sistemas en explotación y la administración de los recursos tecnológicos. En las pruebas a realizar se debe considerar la verificación de: Procedimiento aplicado 36.
Verificaremos la existencia de acuerdos de nivel de servicio para administrar la relación entre el área de sistemas y los usuarios. Para lo cual revisaremos que los mismos contemplen: Definición de servicios a ser brindados Métricas de nivel de servicio Definición de informes de monitoreo Procedimientos de ajuste de servicio Resultados obtenidos No existen acuerdos de nivel de servicio definidos entre la USI y las áreas usuarias de la SBEF, tampoco existen procedimientos que permitan definir los servicios a ser brindados por la USI, métricas definidas para cada uno de los servicios, procedimientos de monitoreo ni procedimientos de ajuste de servicio. Procedimiento aplicado
37. Verificaremos los procedimientos de control aplicados en las interfaces con terceros. Verificaremos los procedimientos aplicados para la administración de requerimientos de terceros. Verificaremos los procedimientos de control que aplica la USI para mantener la continuidad de los servicios a terceros. Verificaremos los procedimientos aplicados para monitorear y controlar los servicios a terceros. Resultados obtenidos Existen dos sistemas que tienen interfaces con terceros, las instituciones financieras envían diaria y mensualmente datos para los sistemas SIF y CIRC
89
respectivamente, para lo cual se cuenta con una estructura de comunicación de líneas dedicadas y dial-up. Las entidades financieras cuentan con programas proporcionados por la SBEF que se encargan de realizar validaciones de la información antes del envío, existe un programa de comunicación que se encarga de enviar los datos a un programa receptor en la SBEF, una vez finalizada la transferencia de datos, el programa receptor verifica los mismos y si no presentan problemas se guardan bajo una estructura de directorio predeterminada que especifica las fechas de las transacciones y la entidad financiera que envió la información. (Ver detalle en el punto 57) Todos los requerimientos de terceros hacia la USI son realizados a través de un requerimiento formal de la entidad externa a la SBEF, tales requerimientos son recibidos por el Superintendente y analizados con la Intendencia correspondiente, verificando la aplicabilidad del mismo, en caso de que se decida atender al requerimiento, el requerimiento se pasa a la Unidad de Sistemas para su elaboración. La Unidad de Sistemas realiza un análisis del requerimiento y evalúa la factibilidad del requerimiento (pueden plantearse soluciones alternativas), procede a elaborar el requerimiento y entrega el mismo a la entidad solicitante. La administración de los requerimientos de terceros no recae en la Unidad de sistemas, los mismos son administrados y aprobados por instancias superiores que se encargan de evaluar la aplicabilidad de los requerimientos presentados por terceros. No existen procedimientos específicos para mantener la continuidad de los servicios a terceros, los servicios a terceros brindados por la SBEF se refieren a generación de reportes para entidades del estado y consultas al sistema de Informe Confidencial. No existen procedimientos formales para monitorear o controlar los servicios a terceros. Para los servicios brindados a las entidades financieras, los cuales consisten en dar soporte para el envío de información, las entidades financieras pueden realizar consultas telefónicas al personal de la USI. Para la generación de información para entidades gubernamentales, no existe ningún tipo de procedimiento formal, ya que la administración del requerimiento no recae en la USI. Asimismo, observamos que de acuerdo a la circular normativa N° 363 y a la implementación del sistema de difusión de normativa y consultas, las consultas telefónicas realizadas por las entidades financieras ó terceros, están prohibidas. Adicionalmente, podemos mencionar que el personal de la USI, monitorea y controla aspectos referidos a las estructuras tecnológicas responsables de brindar el servicio a terceros (redes de comunicaciones, hardware, etc.).
90
Procedimiento aplicado 38. Verificaremos, a través de una muestra, los procedimientos aplicados para la administración del desempeño y la capacidad del hardware, verificando la existencia de:
Requerimientos de disponibilidad y desempeño Plan de disponibilidad Monitoreo y reportes Herramientas de modelaje Administración proactiva del desempeño Administración de la carga de trabajo y la capacidad Disponibilidad y programación de recursos Resultados obtenidos
No existen procedimientos formales para la administración del desempeño del hardware: No se han identificado necesidades mínimas del negocio respecto a la disponibilidad de los servicios de información. No se han definido requerimientos mínimos en función a las necesidades. No existe un plan de disponibilidad No existen procedimientos de monitoreo ni de generación de reportes No se cuenta con herramientas de modelaje. Sin embargo, se han realizado tareas especificas dirigidas a pronosticar la carga de los sistemas, se realizó un análisis de requerimientos de capacidad de almacenamiento para los sistemas CIRC y SIF en función de un análisis del crecimiento de las bases de datos. Adicionalmente, observamos la existencia de un informe relacionado a un trabajo especial que fue realizado por una empresa externa, para analizar la carga de información sobre la red interna y sus conexiones, la cual sirvió como referencia para evaluar un incremento en el ancho de banda. Dicho informe surge como resultado de un análisis realizado por dicha empresa como parte de las tareas que realizó para mostrar la funcionalidad de sus productos de monitoreo de red y hacer una propuesta de venta a la SBEF. Asimismo, observamos que los servidores de producción mantienen información histórica en línea, solamente de la última gestión y de acuerdo a los resultados de las indagaciones realizadas a través de las encuestas observamos que sería recomendable mantener una mayor cantidad de información histórica en línea, lo cual implica que sería necesario ampliar la capacidad actual de almacenamiento (espacio en disco).
91
Por otro lado, dicha ampliación permitiría una mejor utilización en el caso de que se incorporen herramientas orientadas al usuario final (generador de reportes, datawarehousing, etc.). Asimismo, una vez implementadas dichas herramientas será necesario efectuar un análisis de performance de los servidores para evaluar su posible ampliación. Procedimiento aplicado 39. Evaluaremos las normas y procedimientos para la administración de contingencias, considerando: El marco referencial, mencionando el propósito del plan. Principios y criterios en base a los cuales a de utilizase el mismo. El contenido y alcance, que describa los pasos a seguir inmediatamente después de ocurrido el desastre. Los procedimientos detallados para la recuperación de las operaciones críticas de la organización. La descripción de responsabilidades, composición de equipos de trabajo y tareas de recuperación. La descripción de responsabilidades e identificación del personal clave para cada uno de los departamentos críticos. La información acerca de las medidas de prevención de desastres implantadas y su utilización. La información sobre convenios para la recuperación de desastres. Los anexos conteniendo: Inventarios, listas de contactos, mapas, diagramas y demás información detallada. Los procedimientos aplicados para el mantenimiento, pruebas y distribución del plan de contingencias. Los procedimientos aplicados para la capacitación del personal respecto al plan de contingencias. Verificaremos la existencia de acuerdos y pólizas de seguros que tengan por objetivo la protección de los bienes tecnológicos. Verificaremos la aplicación de procedimientos para la protección de bienes tecnológicos en el área de sistemas. Verificaremos la aplicación de procedimientos para el ingreso y salida del hardware. Resultados obtenidos Se cuenta un marco referencial general para las contingencias de sistemas y se han definido escenarios de contingencia para los sistemas. No existe un procedimiento formal para activar el plan de contingencias, por lo que no se han descrito los pasos a seguir inmediatamente después de ocurrida una contingencia.
92
Debido a que el Plan de Contingencias de la SBEF sólo considera aspectos de sistemas, no se han definido las operaciones críticas para la organización, por lo que no existen procedimientos para recuperar las funciones críticas de negocio. No existe una lista del personal clave para cada uno de los departamento existentes, sólo existe una lista de responsables para el área de sistemas, la cual está organizada por Sistema existente. No se han definido equipos de trabajo, ni tareas de recuperación detalladas para los distintos sistemas, en distintas situaciones y grados de contingencia. Se ha definido quienes deben intervenir en la recuperación de los sistemas, pero no existe una descripción clara de las responsabilidades del personal de sistemas, (quienes son los responsables de dirigir al personal en caso de contingencia). No se ha identificado al personal clave de las áreas de negocio de la SBEF que participarán en la recuperación del negocio. Aparte de las medidas de seguridad física, no existen medidas para la prevención de desastres. No se han definido las medidas mínimas de seguridad para la operación de los sistemas en una contingencia. No existen convenios para la recuperación de desastres. En el plan de contingencias no existe información detallada ni hace referencia a: Inventario de equipos u otros recursos tecnológicos, mapas de la edificación, inventario de recursos mínimos necesarios para procesar, lugares alternativos de procesamiento, procedimientos para el transporte de equipos, personal, etc. No existe un procedimiento formal para llevar a cabo la distribución del plan de contingencias, las pruebas al plan de contingencias no cuentan con características mínimas que permitan validar el plan de contingencias. No existen procedimientos formales que permitan la capacitación del personal en los procedimientos definidos en el Plan de Contingencias. La SBEF cuenta con pólizas de seguros que tienen como objetivo la protección de los bienes tecnológicos. Se cuenta con acceso restringido al área de producción y también al Centro de Cómputo, ambos mediante llave de proximidad y clave personal. Estas llaves sólo se encuentran en propiedad el personal de sistemas. Existen formularios para el registro de equipos que ingresan o deben ser retirados de la Superintendencia, en el mismo se detalla el equipo, características y motivo por el cual es retirado, si es el caso. Adicionalmente,
93
el momento que un equipo de computación ingresa o es retirado de la Superintendencia, el guardia de la entrada registra el código del equipo. 40. Seguridad de los sistemas Procedimiento aplicado 41. Evaluaremos contraseñas.
los
mecanismos
utilizados
para
la
administración
de
Resultados obtenidos No se cuenta con políticas ni normas formalmente establecidas para realizar la administración de contraseñas, excepto por la existencia de normas para la actualización de contraseñas que considera el cambio por parte de la USI de todas las contraseñas de la SBEF cada 120 días (las cuales no son aplicadas). El trabajo es realizado por el administrador siguiendo lo detallado a continuación:
Administrador recibe la comunicación interna Habilitación de cuenta de acceso al dominio (red) Habilitación de cuenta de e-mail Una vez habilitado con cuenta de mail el usuario tiene acceso a Internet De acuerdo a necesidad, cuenta de acceso a los sistemas Este trabajo es realizado por el Administrador del Sistema quien es el encargado de generar los passwords para todo el personal de la SBEF. Para dar de alta un usuario en el sistema, debe llegar un volante interno con la firma del interesado y del Jefe de Unidad o Intendente solicitando el alta del usuario en la red y en los sistemas que requiera para realizar su trabajo. Se utiliza el mismo login y password para los accesos a la red, al correo electrónico y a los sistemas. Los passwords son generador por el administrador utilizando un programa generador de claves. Las mismas son entregadas al usuario con carta. El password actual cuenta con 8 caracteres de los cuales 4 son letras, 3 números y el último es un carácter especial (#, $, etc.) Los usuarios no pueden cambiar el password asignado por la USI (sólo es posible en el sistema SIF). Los sistemas no obligan a realizar el cambio periódico de passwords. Ninguno de los sistemas actualmente en producción controla características de los passwords como ser:
94
Guardar los últimos tres passwords Repetición de caracteres iguales en el password Control de passwords cíclicos Procedimiento aplicado
Evaluaremos los procedimientos de alta, baja y modificación de usuarios. Resultados obtenidos Para el alta de usuarios existe un volante interno con el cual se realiza el requerimiento a la USI. El mismo debe contar con la firma del Jefe de Unidad o del Intendente y contiene la siguiente información:
Nombre del Usuario Fecha Intendencia Detalle del requerimiento de alta Firma del Usuario Firma del Jefe de Unidad o Intendente El administrador del sistema genera al acceso al dominio (red), cuenta de correo electrónico (e-mail) y acceso a los sistemas con los cuales tenga que trabajar el usuario. Cuando se requiere realizar algún cambio en los privilegios de acceso de los usuarios, se solicita los mismos utilizando el mismo volante interno. El momento que un usuario se retira de la SBEF, el departamento de Recursos Humanos envía un e-mail al administrador del sistema, para que este proceda a quitar todos los privilegios de acceso con los que contaba dicho usuario. Se elimina físicamente al usuario de la red. En el sistema queda el UserId del usuario (se lo elimina sólo lógicamente).
Procedimiento aplicado 42. Evaluaremos, para los usuarios del área de sistemas, si los mismos tienen acceso a datos en línea Resultados obtenidos Los desarrolladores que realizan modificaciones especialmente a los sistemas CIRC y SIF cuentan con acceso a los datos de producción de dichos sistemas.
95
Si bien se realizan copias locales para el desarrollo y para realizar pruebas de los cambios realizados, se cuenta con el acceso a los datos en línea. Procedimiento aplicado 43. Evaluaremos los procedimientos de alta, baja y modificación de usuarios. Resultados obtenidos Los procedimientos para el alta, baja y modificación de usuarios se encuentra detallada en el punto 41. Como se había mencionado, los principales aspectos son:
No existencia de políticas y normas formalmente establecidas y aprobadas Administración de passwords por parte del Administrador del Sistema Generación de passwords por parte de la USI mediante un programa generador de claves Existencia de autorización de jefatura o intendencia para el alta de usuarios Procedimiento aplicado
Revisaremos, para una muestra, el cumplimiento de los procedimientos definidos. Resultados obtenidos Como resultado de la revisión realizada obtuvimos los siguientes resultados: Los resultados fueron los siguientes:
4 usuarios de la gestión 2001 cuentan con la autorización respectiva 1 usuario de la gestión 2001 no cuenta con la autorización y 10 usuarios de las gestiones 2000, 1995, 1994, 1992 y 1988 no cuentan con la autorización respectiva.
Usuarios
Fecha
4 usuarios 1 usuario 10 usuarios
2001 2001 2000 1988
-
Formular io SB91 No existe No existe
Tipo de Acceso Detallado No existe No existe
Firmas Autorizadas Existen No existen No existen
Ver detalle en Anexo 2.
96
Procedimiento aplicado 44. Revisaremos las normas y procedimientos para la clasificación de datos. Resultados obtenidos Como resultado de los procedimientos aplicados, observamos que no se cuenta con normas ni procedimientos para la clasificación de datos. Normas internacionales de seguridad mencionan que los datos deberían ser separados en cuatro clases con requerimientos separados de manipulación: Secretos, Confidenciales, Privados y No Clasificados. Esta clasificación estándar de datos debería ser usada dentro de la Superintendencia. La clasificación es definida de la siguiente manera: Secretos: Esta clase es aplicada a la información más sensitiva del negocio cuyo uso es permitido estrictamente sólo a personal de la Superintendencia. El uso no autorizado de esta información puede causar un impacto muy fuerte para la Superintendencia, las Entidades Financieras y los clientes. Confidenciales: Esta clase es aplicada a la información menos sensitiva del negocio, cuyo uso es permitido sólo a personal de la Superintendencia. El uso no autorizado de esta información puede causar un impacto para la Superintendencia, las Entidades Financieras y los clientes. Privados: Esta clase es aplicada a información personal cuyo uso es permitido dentro de la Superintendencia. El uso no autorizado de esta información puede causar un impacto fuerte a la Superintendencia o a sus empleados. No Clasificados: Esta clase es aplicada a toda la demás información que no se encuentre claramente definida dentro de las tres anteriores clases. El uso no autorizado de esta información no supone un impacto para la Superintendencia, las Entidades Financieras o los clientes. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Debido a que no se cuenta con mecanismos para la clasificación de datos no fue posible aplicar este procedimiento.
97
Procedimiento aplicado 45. Revisaremos las normas y procedimientos para la emisión de reportes de violación y actividades de seguridad. Resultados obtenidos La página web de la SBEF no se encuentra publicada en un servidor que se encuentra en el Centro de Cómputo. Se utiliza para ello un servidor de Entel. En vista que no se tiene conexión entre la página web y la red interna de la SBEF no es posible que se tengan intentos de violación a la información de la SBEF por ese medio. Por tanto, no se tienen reportes de violación en el área de producción. Los intentos de violación a la información de la Superintendencia desde la red de la SBEF no cuentan con un registro, reporte ni revisión, para la resolución de actividades no autorizadas. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Debido a que no se cuenta con procedimientos establecidos para generar reportes de violación, no fue posible aplicar este procedimiento. Procedimiento aplicado
46. Revisaremos las normas y procedimientos para el manejo de incidentes. Resultados obtenidos No se tienen normas establecidas para el manejo de incidentes. No se cuenta con una clasificación (importantes, menores, etc.)
de
los
problemas
presentados.
Existe, hace aproximadamente dos meses, una planilla Excel (bitácora) en la cual se registran todos los problemas presentados y la solución dada. Esta planilla es llenada por cada uno de los operadores, la cual no es consolidada por el momento, se planifica realizar una consolidación a fin de mes para emitir estadísticas de los problemas presentados, usuarios que más soporte requieren y los problemas más importantes para darles una solución
98
definitiva. Sin embargo, dicha planilla aún no fue revisada ni analizada por la Jefe de la USI. No se tiene un detalle parecido para los problemas presentados en los servidores. Para ser implementado a futuro se evalúa actualmente un software de Help Desk que permita administrar todos los requerimientos usuarios, además que cuente con un inventario de equipos con el software instalado en los mismos, se pueda realizar asignación de tareas, etc. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Se revisó para una muestra de días, las planillas llenadas por los operadores. En base a la revisión de nueve días para los operadores de producción, se verificó que en todos los casos que existieron incidentes (requerimiento de usuarios), estos fueron registrados por los operadores. Ver detalle en Anexo 3. Procedimiento aplicado
47. Evaluaremos la administración de claves de acceso para los usuarios privilegiados. Resultados obtenidos Las claves de acceso para los usuarios privilegiados (analistas / programadores) son administradas de la misma forma que se realiza la administración de cuentas de los usuarios normales (punto 41). Como se había mencionado, los principales aspectos son:
No existencia de políticas y normas formalmente establecidas y aprobadas Administración de passwords por parte del Administrador del Sistema Generación de passwords por parte de la USI mediante un programa generador de claves Existencia de autorización de jefatura o intendencia para el alta de usuarios
99
Existen un usuario root en el sistema operativo Unix. Este usuario es de conocimiento del Administrador del Sistema y existe una copia del password en poder de la Jefe de la Unidad de Sistemas. Existen tres usuarios con acceso de DBA al sistema administrador de base de datos Informix. Estos son: circ, informix y mflores. Los dos primeros son de conocimiento de personal de producción, el último es un usuario de desarrollo que cuenta con este acceso provisionalmente para realizar algún trabajo específico. Procedimiento aplicado 48. Evaluaremos contraseñas.
los
mecanismos
utilizados
para
la
administración
de
Resultados obtenidos Los procedimientos para la administración de contraseñas se encuentra detallada en el punto 41. Como se había mencionado, los principales aspectos son:
No existen actualmente normas y procedimientos formalmente establecidas y aprobadas Administración de passwords por parte del Administrador del Sistema Generación de passwords por parte de la USI mediante un programa generador de claves No existe la posibilidad de cambio de clave inicial por parte del usuario No existe la renovación automática de claves No existe la posibilidad de cambio de clave por parte del usuario, a excepción del sistema SIF. Procedimiento aplicado
49. Revisaremos las normas y procedimientos aplicados para la prevención, detección y corrección de software malicioso. Resultados obtenidos No se cuenta con normas formalmente establecidas para estas tareas. Sin embargo, existe el “instructivo para el uso adecuado de herramientas de tecnología de información”, el cual detalla el antivirus que se utiliza, que el usuario debe asegurarse de tener el mismo instalado y el tipo de reportes que puede emitir el software.
100
Se cuenta con un antivirus instalado en los servidores. Adicionalmente el antivirus se encuentra instalado en las PCs de los usuarios. La actualización del antivirus se realiza en línea cada vez que el proveedor actualiza la versión. Toda la información que llega a la SBEF es revisada mediante el antivirus. Todas las comunicaciones que llegan vía e-mail al personal de la SBEF sufre un proceso de revisión automática. En caso de encontrarse virus, el antivirus limpia el virus y envía un mensaje al administrador del sistema, en caso que no pueda limpiar el virus, borra el mail y envía un mensaje al administrador y otro mensaje para el receptor y el remitente indicando que se encontró virus en el mensaje enviado. El software tiene la posibilidad de emitir reportes estadísticos acerca de los virus encontrados y los funcionarios que más virus recibieron. Periódicamente se emiten comunicaciones de precaución con algunos menajes (e-mail) que son enviados conteniendo algún virus. Esta información es recabada en base a suscripciones a CNN tecnología y la página de Trends (proveedor de antivirus). Existe la norma que indica cuál es el software autorizado para ser utilizado por los usuarios de la SBEF. Se hizo conocer a los usuarios que no deben instalar software no autorizado, no importando si este es “free-ware”. Las mejores practicas de seguridad señalan que es necesario establecer procedimientos para un adecuado control preventivo, detectivo y correctivo además del aviso y reporte de su ocurrencia. La gerencia de sistemas, debe asegurarse que los procedimientos han sido establecidos para proteger la información de virus informáticos. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Para una muestra de diez días, se encontraron los siguientes reportes de virus en seis días (en los restantes cuatro días no se presentaron reportes de virus): Fecha 19/07/2001 01/10/2001
Virus PE_Magistr.A PE_MAGISTR.DAM
Acción Clean Delete
101
Fecha 12/10/2001 12/11/2001 07/12/2001
10/12/2001
Virus PE_MAGISTR.B PE_MAGISTR.B TROJ_SIRCAM.A JOKE_FLIPPED PE_MAGISTR.B JOKE_WOBBLING PE_MAGISTR.B WORM_BADTRANS.B PE_Magistr.A JOKE_WINAVOID.A WORM_BADTRANS.B
Acción Delete Delete Delete Delete Delete Delete Delete Delete Clean Delete Delete
Ver detalle en Anexo 4. Procedimiento aplicado 50. Revisaremos la estructura de seguridad en los canales de telecomunicación (firewall). Resultados obtenidos Todas las personas tienen acceso a Internet, la única diferencia existente entre usuarios es la restricción de acceso al servicio La pagina Web se encuentra publicada a través de un proveedor de Web hosting, y el departamento de Normas está a cargo del mantenimiento de la información en la misma. No existe conexión directa con ninguna de las entidades. No se tiene definida la política sobre la utilización de Internet No existe documentación referente a la operación diaria del firewall, incluyendo monitoreo y revisiones de seguridad se encuentra documentada. No se realiza una revisión de los logs del firewall. No se cuenta con herramientas que permitan realizar este el monitoreo de intentos de hacking (herramientas IDS - Intrusion Detection System). Se está evaluando la posibilidad de compra, ya que se recomendó este punto en la auditoría de seguridad.
102
No existe una política de Internet formalmente definida. Sin embargo, durante los cursos de inducción que se da a los nuevos empleados se menciona como hacer uso correcto de Internet. La política sobre el uso de Internet no se encuentra en la Intranet de la institución. El firewall incluye mecanismos de control de acceso a nivel de Aplicación (Proxy server y Web Manager), para los usuarios normales TCP e IP (PIXFirewall) para todos los usuarios a través de restricción de puertos para la entrada de información y sin restricción para la salida El tráfico permitido de entrada solo puerto 25 SMTP y tráfico de salida cualquiera. (el control para la salida se lo realiza a través del proxy) Se cuenta con documentación acerca de la actualización de la configuración de los routers. Existe una persona encargada de administrar y monitorear la red. Sin embargo, observamos que no existe la función de control de calidad. Por otro lado, hemos observado que se realizó una consultoría de seguridad que dio como resultado recomendaciones sobre el manejo de la red Para el proceso de login. Los usuarios están definidos en un grupo de trabajo de WinNT el cual esta habilitado en el programa proxy y se restringe la cantidad de Kb de navegación a través del programa Web Manager, las direcciones IP 100.1.(9,5,3).X tienen privilegios de salida especiales que no son restringidos a través del software Web Manager Se generan backups de los logs existentes los cuales están direccionados a la maquina del responsable de comunicaciones. Dado el constante cambio de la tecnología, es recomendable la realización de pruebas de penetración en forma periódica para detectar las debilidades que surjan y tomar medidas correctivas. Procedimiento aplicado
Revisaremos los mecanismos de control de acceso físico a los dispositivos de comunicación. Resultados obtenidos Los mecanismos de control de acceso físico se detallan en el punto 64. Los principales aspectos con relación al acceso físico a los dispositivos de comunicación son los siguientes:
103
Acceso restringido al área de producción, sólo al personal de sistemas, mediante llave de proximidad Acceso restringido al Centro de Cómputo (lugar en el cual se encuentran los dispositivos de comunicación) sólo al personal de producción mediante llave de proximidad y clave No existe un registro del personal ajeno al área que ingresa al Centro de Cómputo Los dispositivos de comunicación se encuentran en muebles especiales, en un ambiente aislado Procedimiento aplicado
Evaluaremos la estructura de seguridad del sistema operativo. Resultados obtenidos Se revisaron los parámetros generales de seguridad para los servidores de “recepción” y servidor principal de dominio, los mismos tienen a su cargo el intercambio de datos con entidades financieras, la administración de los usuarios de red y el control de navegación Internet. Nuestra revisión contemplo los siguientes aspectos:
Evaluación de parámetros de usuarios. Evaluación de parámetros de grupos. Evaluación de parámetros de directorios. Las observaciones que surgieron de la revisión de los parámetros de seguridad del sistema operativo, se encuentran detalladas en las recomendaciones del presente informe. Procedimiento aplicado
Evaluaremos la estructura de seguridad del acceso a la red Resultados obtenidos Para el acceso a la red de la Superintendencia todos los usuarios cuentan con un password que es otorgado por la Unidad de Sistemas, las características de la administración de los passwords se encuentra detallado en el punto 41. Los principales aspectos son los siguientes:
No se cuenta con políticas y normas formalmente establecidas para la administración de passwords, las mismas se encuentran en etapa de aprobación Se cuenta con un procedimiento conocido por el personal de operaciones para realizar esta tarea
104
Existe un formulario el cual debe estar debidamente autorizado para el alta de un usuario en la red Existe una persona encargada de administrar y monitorear la red. No existe la función de control de calidad. Se realizó una consultoría de seguridad que dio como resultado recomendaciones sobre el manejo de la red. Las mismas serán implementadas paulatinamente. Se generan backups de los logs existentes los cuales están direccionados a la maquina del responsable de comunicaciones. Procedimiento aplicado
51. Verificaremos la existencia de acuerdos y pólizas de seguros que tengan por objetivo la protección de los bienes tecnológicos. Resultados obtenidos Existe una póliza de seguros con Alianza, Compañía de Seguros y Reaseguros S.A., en la misma se detalla el seguro de los bienes tecnológicos por un valor de $us. 2.220.000.- (equipos de computación, fotocopiadoras, equipos de comunicación, modems y máquinas de fax). No existen acuerdos verbales ni escritos con ninguno de los proveedores para el reemplazo de equipos. Procedimiento aplicado
Verificaremos la aplicación de procedimientos para la protección de bienes tecnológicos en el área de sistemas. Resultados obtenidos Ningún equipo principal es retirado del Centro de Cómputo, su limpieza y mantenimiento es realizado en el mismo. Todo equipo que es retirado del Centro de Cómputo y del área debe ser registrado por personal de sistemas y por personal de Activos Fijos. La protección de bienes tecnológicos en el área de sistemas incluye la seguridad con la que cuenta el Centro de Cómputo. Este aspecto es detallado en el punto 64. Los aspectos principales de la seguridad física son los siguientes:
Acceso restringido al área de producción, sólo al personal de sistemas, mediante llave de proximidad
105
Acceso restringido al Centro de Cómputo (lugar en el cual se encuentran los dispositivos de comunicación) sólo al personal de producción mediante llave de proximidad y clave No existe un registro del personal ajeno al área que ingresa al Centro de Cómputo Existen extintores de incendio en lugares visibles Se cuenta con aire acondicionado No se cuenta con detectores de humo ni alarma contra incendios Procedimiento aplicado
Verificaremos la aplicación de procedimientos para el ingreso y salida del hardware. Resultados obtenidos En la Unidad de Sistemas, se cuenta con un formulario para el registro de equipos que ingresan o deben ser retirados de la Superintendencia, en el mismo se detalla el equipo, características y motivo por el cual es retirado, si es el caso. Paralelamente, el momento del ingreso, el departamento de Activos Fijos registra el bien adquirido en un formulario especial, características del equipo y asigna un código de activo a cada uno de los componentes del bien. Adicionalmente, el momento que un equipo de computación ingresa o es retirado de la Superintendencia, el guardia de la entrada registra el código del equipo. Tareas adicionales propuestas Procedimiento aplicado
52. Adicionalmente, se realizará un análisis de la información del sistema de recursos humanos y de las cuentas de usuario del sistema central (CIRC y SIF) a fin de identificar:
Personal retirado que tiene una cuenta de usuario vigente Personal que tiene una cuenta de usuario vigente y no fue dado de alta en el sistema de Recursos Humanos Personal que ya no tiene una cuenta de usuario vigente y se encuentra como personal actual en el sistema de Recursos Humanos Personal con incompatibilidad entre su cargo y la cuenta de usuario asignado Inconsistencia de la información de cuentas de usuario Inconsistencia de la información del sistema de Recursos Humanos
106
Resultados obtenidos
No encontramos personal retirado que tenga una cuenta de usuario vigente en los sistemas No encontramos personal que tiene una cuenta vigente en los sistemas y no fue dado de alta en el sistema de Recursos Humanos Existe personal que no tiene cuenta vigente en los sistemas y se encuentra como personal actual en el sistema de Recursos Humanos (ej. Alvaro Javier Zalles Ballivian, Supervisor “A”). Sin embargo, esto se debe a que este personal no solicitó la habilitación correspondiente de acceso a los sistemas. No encontramos personal con incompatibilidad entre su cargo y la cuenta de usuario asignado. Existen usuarios que tienen distintos UserId para distintos sistemas. Sin embargo, esto debido a la cantidad de caracteres aceptados por los sistemas. No encontramos inconsistencia de la información del sistema de Recursos Humanos. Procedimiento aplicado
53. Verificaremos el plan de capacitación relacionado con aspectos de seguridad para los usuarios y verificaremos que incluye:
La identificación de las necesidades La administración de la capacitación (cronogramas y seguimiento)
Resultados obtenidos Como resultado de los procedimientos aplicados, observamos que la USI ha definido un plan de capacitación en función a los lineamientos estratégicos que fueron definidos en el documento “Plan estratégico de la USI”, el cual está alineado con los objetivos estratégicos de la SBEF definidos en el Plan Estratégico de la Superintendencia – PES. En relación a la administración de la capacitación como ya fue mencionado anteriormente en los puntos 19, 20 y 21, el plan de capacitación de la gestión 2001 no ha sido cumplido. Respecto a la capacitación a usuarios en temas relacionados con la seguridad, hemos observado que la USI, no ha definido acciones específicas al respecto. Sin embargo, como parte del trabajo de consultoría en seguridad que fue contratado por la SBEF, se realizaron sesiones de capacitación a los usuarios de la superintendencia. Procedimiento aplicado
107
54. Verificaremos la existencia de procedimientos para el registro y mantenimiento de las configuraciones de los recursos tecnológicos, considerando: Configuraciones de CPU, discos y controladores de discos, terminales, líneas de comunicación, impresoras y periféricos. Resultados obtenidos No existen procedimientos formalmente definidos para el registro y mantenimiento de las configuraciones de los recursos tecnológicos. Sin embargo, se cuenta con información de la configuración de los siguientes recursos:
Equipos de comunicación Configuración de la red Discos duros (Unix) Base de datos (Informix)
Procedimiento aplicado 55. Revisaremos las normas y procedimientos para la emisión de reportes de violación y actividades de seguridad.
Revisaremos las normas y procedimientos para el manejo de incidentes. Resultados obtenidos Los procedimientos para la emisión de reportes de violación así como el manejo de incidentes fue detallado en los puntos 45 y 46. Los aspectos más importantes son los siguientes:
No se cuenta con reportes de violación mediante la página web, en vista que el servidor Web no se encuentra en la Superintendencia. No existen normas ni procedimientos para el manejo de incidentes Se lleva una planilla Excel con el detalle de los requerimientos usuarios No se lleva un detalle de los incidentes en los servidores Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos
108
Debido a que no se cuenta con reportes de violación, no fue posible aplicar este procedimiento. En el punto 46 se detallan los resultados de la prueba realizada para el manejo de incidentes. 56. Administración de datos en todas las aplicaciones o sistemas en producción Procedimiento aplicado 57. Revisaremos los procedimientos para la preparación de datos, autorización de documentos fuente, y recolección de datos de documentos fuente, manejo de errores de documentos fuente, revisiones de precisión, integridad y autorización, administración de errores de alimentación y proceso de datos, integridad de procesamiento de datos, distribución de resultados, balance y conciliación de resultados y revisión y manejo de errores de resultados.
Resultados obtenidos Por el tipo de información que maneja la Superintendencia, no se cuenta con documentos fuente, estos son manejados en las entidades financieras, debido a que el manejo de documentos fuente se presenta cuando existe ingreso de datos. La Superintendencia no maneja documentos fuente, por tanto, no existe autorización de estos documentos. Los documentos fuente, generalmente son formas impresas para proporcionar uniformidad, exactitud y legibilidad. La recolección de datos es realizada mediante los sistemas CIRC y SIF de la Superintendencia. Sin embargo, no se reciben documentos fuente en ningún caso. Los sistemas CIRC y SIF recolectan en forma diaria datos de las entidades financieras, para lo cual se cuenta con una estructura de comunicación dedicada a tal objetivo. Para entender como funciona tal estructura de comunicaciones es necesario definir lo siguiente: SuperBank: Es la red interna de la SBEF dedicada al intercambio de información entre sus funcionarios y que permite el intercambio de correo electrónico con redes externas y la salida de los funcionarios a Internet. SuperNet: Es la red externa de la SBEF dedicada al intercambio de información entre las entidades financieras y la institución, dentro de esta red se encuentran:
109
el servidor de acceso remoto que permite la recolección de datos de los bancos. el servidor de “Informe Confidencial” al cual acceden las entidades financieras para realizar consultas. El proceso de recolección de datos se realiza de manera diaria, para lo cual las entidades financieras cuentan con programas proporcionados por la SBEF que se encargan de realizar validaciones de la información en la misma Entidad Financiera antes del envío, las validaciones que se realizan se encuentran documentadas en el “Cuadro de Validación de Errores”. Una vez validados los posible errores de datos que se pueden presentar en la información que será enviada por la entidad financiera, existe un programa de comunicación que se encarga de enviar los mismos a un programa receptor que se encuentra en el servidor RAS (Red SuperNet). Para poder verificar la adecuada transferencia de la información entre el programa de envío en la entidad financiera y el programa receptor en la SBEF, el programa de envío de información genera un log de validación de archivos, el cual consiste en generar campos de control del número de registros, tamaño de archivo, fecha de elaboración, y totales de control generados a través de algoritmos de dígito verificador. Una vez generado el log de validación de archivos, el usuario de la entidad financiera realiza la conexión con el programa receptor de la SBEF por medio de una línea dedicada, para lo cual cada usuario de las entidades financieras cuenta con un login que le permite establecer una conexión remota con el servidor RAS de la SBEF (la conexión se realiza a través del protocolo de validación de usuarios TACCACS+), una vez establecida la conexión remota, el programa que enviará la información establece una segunda conexión, esta vez con el servicio abierto para la recepción de los archivos, donde el programa cliente se registra (log-in) para iniciar la transacción a través de un login y password codificado en el programa cliente, y se inicia la transferencia de los archivos. Una vez finalizada la transferencia de archivos, el programa receptor verifica contra el log de validación la recepción adecuada de los archivos, si los mismos no presentan problemas, el programa receptor guarda los archivos bajo una estructura de directorio predeterminada que especifica las fechas de las transacciones y la entidad financiera que envió la información. El proceso de recolección de datos termina en este punto, luego la carga de los mismos en los sistemas CIRC y SIF se realiza a través de procedimientos adicionales que consisten en recuperar los archivos del servidor RAS y copiarlos a la red SuperBank y aplicar procesos de carga a la base de datos correspondiente (Informix para el sistema CIRC y SQL Server para el sistema SIF)
110
La distribución de los resultados es realizado mediante el sistema Informe Confidencial, al cual tienen acceso las entidades financieras para consulta de la situación financiera de un determinado cliente, para abrir una cuenta u otorgar un préstamo al mismo. No es necesario realizar una conciliación de resultados, este proceso es realizado el momento del envío de la información por parte de las entidades financieras y con la ayuda de los sistemas proporcionados por la Superintendencia. En caso que existieran errores en la información, estos son validados antes del envío de la información a la Superintendencia. Procedimiento aplicado
Realizaremos, para una muestra, pruebas que nos permitan verificar el cumplimiento de los procedimientos existentes. Resultados obtenidos Los documentos fuente, según las mejores prácticas internacionales, deben ser formas impresas para proporcionar uniformidad, exactitud y legibilidad. Los documentos fuente deben incluir encabezamientos, títulos, notas e instrucciones estándar. El diagrama del documento fuente debe:
Recalcar la facilidad de uso y legibilidad Agrupar los campos similares para facilitar la entrada Proporcionar códigos de entrada predeterminados para reducir los errores Contener números apropiados de referencia cruzada o un identificador comparable para facilitar la investigación y detección Utilizar casillas para identificar los errores del tamaño del campo Incluir un área apropiada para que la administración documente la autorización Todos los documentos fuente deben controlarse debidamente. Si los documentos fuente no se prenumeran, deben establecerse procedimientos para asegurar que todos ellos han sido ingresados y registrados. Estos procedimientos sobre los documentos fuente se encuentran estrechamente relacionados con el ingreso de datos a un sistema computadorizado. En el caso de la Superintendencia y por el tipo de trabajo que se realiza, no se manejan documentos fuente, por tanto no fue posible aplicar el procedimiento descrito. Procedimiento aplicado
111
58. Verificaremos que la transferencia de información sensible se realice a través de mecanismos que permitan la protección de los datos (encripción de datos) Resultados obtenidos En base al trabajo realizado y a los procedimientos existentes para la transferencia de datos a través de la red, encontramos que no existe ningún proceso de encripción de datos durante el proceso de transferencia. Procedimiento aplicado 59. Revisaremos la estructura de seguridad en los canales de telecomunicación. Resultados obtenidos La estructura de seguridad de los canales de telecomunicación se encuentra detallado en el punto 50. Los principales aspectos son los siguientes:
Todos los usuarios tienen acceso a Internet La página Web se encuentra publicada a través de un proveedor de Web Hosting No existe conexión directa con ninguna de las entidades No se cuenta con herramientas que permitan realizar el monitoreo de intentos de hacking (herramientas IDS) El firewall incluye mecanismos de control de acceso Se cuenta con documentación acerca de la actualización de la configuración de los routers Para el proceso de login, los usuarios están definidos en un grupo de trabajo de WinNT el cual esta habilitado en el programa proxy Procedimiento aplicado
Verificaremos los mecanismos de control de acceso físico a los dispositivos de comunicación. Resultados obtenidos Los mecanismos de control de acceso físico se detallan en el punto 64. Los principales aspectos con relación al acceso físico a los dispositivos de comunicación son los siguientes:
Acceso restringido al área de producción, sólo al personal de sistemas, mediante llave de proximidad
112
Acceso restringido al Centro de Cómputo (lugar en el cual se encuentran los dispositivos de comunicación) sólo al personal de producción mediante llave de proximidad y clave No existe un registro del personal ajeno al área que ingresa al Centro de Cómputo Los dispositivos de comunicación se encuentran en muebles especiales, en un ambiente aislado Procedimiento aplicado
Evaluaremos la estructura de seguridad del sistema operativo. Resultados obtenidos Las observaciones que surgieron de la revisión de los parámetros de seguridad del sistema operativo para el servidor Proxy, se encuentran detalladas en las recomendaciones del presente informe. Procedimiento aplicado
Evaluaremos la estructura de seguridad del acceso a la red Resultados obtenidos Para el acceso a la red de la Superintendencia todos los usuarios cuentan con un password que es otorgado por la Unidad de Sistemas, las características de la administración de los passwords se encuentra detallado en el punto 41. Los principales aspectos son los siguientes:
No se cuenta con políticas y normas formalmente establecidas para la administración de passwords, las mismas se encuentran en etapa de aprobación Se cuenta con un procedimiento conocido por el personal de operaciones para realizar esta tarea Existe un formulario el cual debe estar debidamente autorizado para el alta de un usuario en la red Existe una persona encargada de administrar y monitorear la red. No existe la función de control de calidad. Se realizó una consultoría de seguridad que dio como resultado recomendaciones sobre el manejo de la red. Las mismas serán implementadas paulatinamente. Se generan backups de los logs existentes los cuales están direccionados a la maquina del responsable de comunicaciones.
113
Procedimiento aplicado 60. Evaluaremos los procedimientos existentes para la destrucción de medios que contengan información sensible. Resultados obtenidos La única información “sensible” que se maneja en medios magnéticos es la obtenida en las copias de respaldo. No se desechan las copias de respaldo, las cintas que presentan problemas se encuentran en un gavetero en el área de sistemas. Por lo mencionado, no existen procedimientos para la destrucción de medios que contienen información sensible. Procedimiento aplicado 61. Revisaremos las normas y procedimientos aplicados para la administración de copias de respaldo, considerando: periodos de retención, plazos de almacenamiento, archivo, procedimientos de respaldo y restauración, tareas de respaldo y almacenamiento. Resultados obtenidos Se obtienen copias de respaldo diarias y mensuales. Se tiene dos cintas para las copias diarias, las cuales van rotando en el transcurso de la semana. Las copias mensuales son obtenidas en dos copias, una de las cuales queda en el área de producción, en un gavetero bajo llave; y la otra es enviada a una caja de seguridad en el Banco de Crédito. La copia diaria es obtenida en una sola copia. La copia mensual es obtenida en dos copias, una de las cuales se queda en un gavetero bajo llave en el área de Producción, y la otra es enviada a una Caja de Seguridad en el Banco de Crédito. Los servidores de los sistemas: Informe Confidencial, CIRC y el servidor de dominio tienen una periodicidad de obtención de copias de respaldo mensual. Las copias mensuales son permanentes. Los demás servidores tienen una frecuencia de obtención de copias de respaldo diaria y mensual. Diariamente se respaldan todo los datos. Se utilizan cintas de 4mm y cintas DLT para las copias de respaldo, se cuenta con dos cintas para las copias diarias, las cuales son intercaladas los días de la semana. El día que se obtiene la última copia del mes, la cinta diaria queda como copia mensual y se renueva la misma, para la copia diaria.
114
No se tiene identificado el ciclo de vida de las cintas. El momento que una presenta fallas se procede a su cambio. La cinta no es desechada, se la guarda en un gavetero bajo llave en el área de producción. Como medida de seguridad cuando se envían las cintas al Banco de Crédito siempre van dos personas, un empleado de sistemas y uno de administración. Las cintas que son enviadas al Banco son registradas en el área de producción. No se cuenta con un cronograma de operaciones o una bitácora de procesos para realizar el trabajo de obtención de copias de respaldo. Actualmente existe un encargado de realizar este trabajo. Mediante los logs del sistema se revisa si las copias de respaldo fueron obtenidas en las cintas correspondientes. De esta manera se puede conocer en caso que una de las copias no se haya ejecutado correctamente. Dado el caso se procede a obtener la copia del día siguiente, no se repite el proceso para el día anterior. Todas las cintas cuentan con la identificación del servidor y la fecha de la copia de respaldo. Adicionalmente se registra en un cuaderno la información referente al número de cinta, servidor y fecha. Aproximadamente se tienen copias desde 1996 en el área de producción, copias anteriores se encuentran almacenadas en el depósito que tiene la SBEF en la ciudad de El Alto. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Para realizar el trabajo se tomaron cinco meses de la gestión 2000 y cinco meses de la gestión 2001. No se encontraron, para todos los casos, las cintas de respaldo. En algunos casos existe el registro de la copia de respaldo pero no se encontró la cinta física. La administración de copias de respaldo tienen algunas falencias en cuando a la documentación y obtención. Ver detalle en Anexo 5.
115
Procedimiento aplicado 62. Revisaremos las normas y procedimientos aplicados para la protección de mensajes delicados. Resultados obtenidos No existen normas ni procedimientos para la protección de mensajes, tampoco se cuenta con normas que permitan contar con una clasificación de mensajes, motivo por el cual no fue posible aplicar el procedimiento establecido. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Por todo lo mencionado en el punto anterior no fue posible aplicar el procedimiento establecido. Procedimiento aplicado
63. Revisaremos las normas y procedimientos para autentificar los datos, verificar la integridad de las transacciones electrónicas y la integridad de los datos almacenados. Resultados obtenidos Los procedimientos para la autenticación de los datos y la integridad de las transacciones electrónicas se encuentra detallado en el punto 57. Los principales aspectos son los siguientes:
Los programas proporcionados por la SBEF a las entidades financieras realizan validaciones de la información en la misma Entidad antes del envío Las validaciones se encuentran documentadas en el “Cuadro de Validación de Errores” Existe un programa de comunicación que se encarga de enviar los mismos a un programa receptor El programa de envío genera un log de validación de archivos, el cual es luego utilizado para verificar la adecuada transferencia La conexión del usuario en la entidad financiera con la SBEF se realiza a través del protocolo de validación de usuarios TACCACS+ Una vez establecida la conexión, el programa establece una segunda conexión, con un servicio abierto para la recepción de los archivos
116
Una vez finalizada la transferencia de archivos, el programa receptor verifica contra el log de validación la recepción adecuada de los archivos La integridad de los datos almacenados esta dada por el proceso de validación de datos y archivos que se realizan antes, durante y luego de la transferencia. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Por todo lo mencionado procedimiento.
anteriormente
no
fue
posible
aplicar
este
Procedimiento aplicado 64. Verificaremos que el ambiente correspondiente al área de tecnología de información Ambiente IT (Tecnología de la Información), cuente con:
Mecanismos Mecanismos Mecanismos Mecanismos Mecanismos
de seguridad física de registro y monitoreo de visitantes de seguridad para el personal para la protección contra factores ambientales para el suministro ininterrumpido de energía
Resultados obtenidos Se cuenta con acceso restringido al área de producción y también al Centro de Cómputo, ambos mediante llave de proximidad y clave personal. Estas llaves sólo se encuentran en propiedad el personal de sistemas. Sin embargo, las puertas y paredes de acceso al Centro de Cómputo son todas de vidrio. El Centro de Cómputo tiene ventanas que dan al patio interior y no tienen rejas. No se cuenta con un registro de visitas (personas ajenas) que ingresan al Centro de Cómputo. Se cuenta con extintores de incendio en lugares visibles. También se cuenta con luces de emergencia. El piso del Centro de Cómputo es de cerámica, se cuenta con aire acondicionado, en su mayoría los servidores se encuentran en el piso, uno de ellos cuenta con rack.
117
Los dispositivos de comunicación se encuentran en un lugar aislado en el Centro de Cómputo, ubicado en muebles especiales. No se cuenta con detectores de humo, alarmas contra incendio o alarmas contra intrusos en el Centro de Cómputo No se realiza un mantenimiento periódico a los equipos de aire acondicionado, luces de emergencia, UPS, líneas de comunicación ni al sistema eléctrico. El mantenimiento de los servidores es realizado en el mismo lugar en el que se encuentran instalados. No se retiran los equipos del Centro de Cómputo. La limpieza del Centro de Cómputo es realizada siempre con la presencia de un funcionario de sistemas. Procedimiento aplicado 65. Revisaremos las normas y procedimientos aplicados para la administración operativa, contemplando:
Operaciones de procesamiento. Manual de instrucciones Documentación del proceso de inicio y otras operaciones Programación de tareas Desviaciones de la programación estándar de tareas Continuidad de procesamiento Bitácoras de operaciones Administración remota Resultados obtenidos Se cuenta con documentación establecida para las operaciones de procesamiento y manuales de instrucciones para los principales sistemas que maneja la Unidad de Sistemas. Estos documentos se encuentran detallados paso a paso y muestran en todos los casos las pantallas necesarias para llevar adelante el proceso. No se cuenta con documentación del proceso de inicio, programación de tareas ni con el detalle de desviaciones de la programación estándar de tareas. Las tareas se realizan por el conocimiento del personal. Para la continuidad del procesamiento, existen un Plan de Recuperación de Sistemas. Sin embargo, el mismo no contempla todos los aspectos necesarios
118
para posibilitar la continuidad operativa de la SBEF en caso de contingencia. Este aspecto es detallado en el punto 39. Existen bitácoras de operaciones, las cuales detallan los principales aspectos a ser considerados el momento de la carga de datos a los sistemas, entidad, fecha y hora además de verificación de existencia de errores durante el proceso. No existe para ningún caso la operación remota de alguno de los sistemas. Todo la operación se la realiza en la Unidad de Sistemas. En el punto 57 se detalla el procedimiento utilizado para la transferencia de datos desde las entidades financieras. Procedimiento aplicado
Verificaremos, para una muestra, el cumplimiento de las normas y procedimientos definidos. Resultados obtenidos Verificamos para una muestra de sistemas, la existencia de operaciones de procesamiento y manuales de instrucciones. Estos documentos se encuentran formalmente documentados. Verificamos para una muestra de meses, la existencia de bitácoras de operaciones. En todos los casos las bitácoras se encuentran con el detalle necesario y se encuentran archivadas.
119