IV

SUPERINTENDENCIA DE bANCOS

Y ENTIDADES FINANCIERAS

Consultora en Auditora de Sistemas a la

Unidad de Sistemas de Informacin

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.1Conclusin general

III.2Conclusiones especficas

IV. RECOMENDACIONES

IV.1.Resumen de recomendaciones

IV.2 Detalle de recomendaciones

V. RESULTADOS OBTENIDOS

I.OBJETIVO

El objetivo de nuestro trabajo fue evaluar la adecuada administracin de los recursos tecnolgicos 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 opinin respecto al ambiente de control existente en el procesamiento electrnico de datos.II.ALCANCE

Si bien el alcance del trabajo efectuado se basa en los trminos de referencia definidos en nuestra propuesta, hemos querido dar un valor agregado adicional en cuanto a la visin de los aspectos notados desde un punto de vista de la funcin informtica a nivel de toda la organizacin. De este modo la Superintendencia de Bancos y Entidades Financieras (SBEF) dispondr de mejor informacin para tomar acciones de mejora ms efectivas y de forma mas focalizada.

II.1INTRODUCCION

De acuerdo a lo relevado en el transcurso de nuestro trabajo, la SBEF nos ha trasmitido su preocupacin por lograr la optimizacin de la efectividad y eficiencia de su funcin informtica, apuntando al logro de sus objetivos institucionales.

Queremos hacer notar que cuando nos referimos a la funcin informtica, lo hacemos como a una funcin general de toda la organizacin, y no debe ser confundida con el rea informtica, que si bien es una parte importante de esta funcin, no es la nica que la compone.

Nuestra intencin es plantear las medidas requeridas por la funcin informtica, basndonos en los hallazgos surgidos de la ejecucin de nuestro programa de trabajo detallado. De este modo, la SBEF obtendr una visin clara de su problemtica general, comprendiendo las relaciones causa-efecto existentes entre los hallazgos obtenidos. Estas relaciones a las que nos referimos, difciles 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 funcin informtica de la SBEF:

Gestin informtica (planificacin estratgica de la Institucin y de sistemas)

Desarrollo y adquisicin de aplicaciones (planificacin tctica y entrega)

Operacin y soporte de sistemas (soporte a las aplicaciones existentes)

Analizando estas reas en un contexto ms amplio, podemos representarlas dentro del siguiente grfico.

Este modelo contiene seis componentes bsicos asociados con la provisin y operacin de los servicios informticos. Muchos de los problemas del rea informtica provienen de aspectos que pueden ser fcilmente identificados aplicando este modelo de alto nivel. Los seis componentes del modelo son:

Planificacin estratgica de la institucin. El mximo rgano ejecutivo de la institucin 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 informacin no han sido vistos como una ventaja competitiva potencial y por lo tanto pocas organizaciones tienen procesos o capacidades para examinar el uso estratgico de la informtica 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;

Planificacin estratgica de sistemas. La gerencia de sistemas debe cubrir dos actividades bsicas: el soporte permanente del conjunto de aplicaciones existentes y el desarrollo de nuevas aplicaciones (o mejoradas). El proceso de planeamiento estratgico atiende estas necesidades por medio de la asignacin 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 operacin, y estableciendo procesos de priorizacin para la atencin de requerimientos. El proceso involucra a la gerencia del negocio y a la de sistemas, el resultado de este proceso tiene dos contenidos principales: una lista de proyectos priorizados y la asignacin de recursos;

Planificacin tctica de sistemas. Una vez que el proceso de priorizacin ha identificado que proyectos se van a iniciar, el proceso de planificacin tctica identifica la forma en que los proyectos sern estructurados y gerenciados. Esto incluye aspectos como la asignacin de un gerente de proyecto, determinacin de las herramientas de gerenciamiento que sern utilizadas, establecimiento de la estructura del proyecto, organizacin de adecuados vnculos y definicin 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 realizacin 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 aplicacin o de un cambio a una ya existente. Este proceso esta relacionado con los aspectos del da a da del gerenciamiento de proyectos y la calidad de integracin 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 informacin acerca del conjunto de aplicaciones existentes es utilizada como insumo para proceso de planeamiento estratgico de sistemas, para determinar la mejor forma de cumplir con los requerimientos del negocio;

Cultura informtica. Este proceso provee una visin de alto nivel sobre la informacin provista en el anlisis que procede y ayuda a la gerencia a identificar necesidades de cambio de la postura de la organizacin en general con respecto a los sistemas de informacin, con el fin de emprender el desarrollo de nuevos productos o servicios.

III. RESUMEN EJECUTIVO

Con el objeto de facilitar la lectura del presente informe, a continuacin presentamos un resumen ejecutivo, de los aspectos ms relevantes que han surgido como resultado de nuestro trabajo.

III.1Conclusin general

Confiabilidad, integridad y adecuacin a normas vigentes.

Como resultado de nuestro trabajo, hemos detectado aspectos que afectan la confiabilidad, integridad y adecuacin a normas vigentes de los sistemas y su informacin, entre los que se destacan los siguientes:

los ambientes de desarrollo y produccin 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 estn claramente definidos,

las tareas de desarrollo e implantacin en el ambiente de produccin no estn segregadas, y

no se cuenta con normas ni procedimientos para realizar pruebas de los nuevos desarrollos, con participacin del usuario final en su ejecucin y constancia formal de su conformidad con el producto final.

Confidencialidad

Dentro del diseo general del ambiente de seguridad hemos visto aspectos que afectan la confidencialidad de la informacin, y deben ser mejorados en cuanto a:

segregacin inadecuada de las funciones de administracin de seguridad,

segregacin inadecuada de otras funciones tcnicas de sistemas (por ejemplo: desarrollo e implantacin en el ambiente de produccin)

el mecanismo de asignacin, modificacin y construccin de contraseas no cumple con las mejores prcticas,

no se cuenta con funciones de auditora interna de sistemas,

no se cuenta con una clasificacin de la informacin en cuanto a su criticidad (que incluye el concepto de confidencialidad) y por lo tanto tampoco con medidas de proteccin asociadas a cada categora.

existen oportunidades de mejora en la seguridad fsica (piso falso, paredes de vidrio, alarmas de incendio, detectores de humo, etc.)

Asimismo, es necesario contar con una mayor formalizacin y estandarizacin de los procedimientos relacionados con la administracin de seguridad.

Eficacia, eficiencia y oportunidad.

Consideramos que la Unidad de Sistemas de Informacin tiene una serie de debilidades que afectan la administracin de los recursos tecnolgicos y humanos del rea. Entre los aspectos ms importantes podemos mencionar:

falta de formalizacin de procedimientos,

la estructura organizacional de la USI no refleja su realidad actual,

falta de reas de apoyo (O&M y Auditora Interna de Sistemas),

inadecuado proceso de elaboracin del plan estratgico de sistemas y planificacin de tareas,

falta de mecanismos claros de priorizacin de trabajos,

falta de definicin 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:

no existe Plan de Contingencia del negocio

no existe uniformidad en la obtencin y custodia de copias de respaldo

III.2Conclusiones especficas

a.Cultura Informtica

Uno de los aspectos clave que se deben tener en cuenta en el diseo de la funcin informtica es su marco de funcionamiento, fijado por la cultura de la organizacin en cuanto a los sistemas. La medida de esta evaluacin es un componente fundamental que fija la direccin y el orden de magnitud de las acciones a tomar para la mejora de la eficacia y eficiencia de la gestin informtica de la Institucin.

Para realizar nuestra evaluacin hemos utilizado los criterios de niveles de madurez en el uso de la tecnologa, y en el proceso de incorporacin de software.

Nivel de madurez en el uso de la tecnologa

Hemos realizado la evaluacin 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 aplicacin de la tecnologa es incipiente, hay pocos ejemplos aislados y los sistemas tienen orientacin operativa

Contagio: conocidos los beneficios de la aplicacin de sistemas, se desarrollan mltiples aplicaciones para distintas reas de la organizacin mayormente no integradas entre si.

Control: la organizacin es consciente del poder de la informacin contenida en los sistemas y la usa para controlar su negocio.

Integracin: las aplicaciones comienzan a integrarse mas fuertemente, para lograr visiones integrales de los procesos y del negocio.

Estratgico: la organizacin comprende la importancia de los sistemas y los utiliza como herramientas para lograr ventajas en sus reas estratgicas

Creacin 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 clasificacin, podemos estimar un nivel de madurez de la SBEF cercano al estado de control.

Nivel de madurez en el proceso de incorporacin de software

Hemos realizado la evaluacin del nivel de madurez aplicando el modelo de madurez de software de Watts Humphrey's, que identifica cinco niveles:

1. Inicial o ad hoc: catico, costos plazos y calidad impredecibles

2. Repetible: intuitivo, costos y calidad ampliamente variables, control razonable de plazos, procedimientos y metodologas 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 inversin continua en procesos de automatizacin y mejora.

Como resultado de los procedimientos aplicados y basados en esta clasificacin, podemos estimar que el nivel de madurez en el cual se encuentra la SBEF es 3.

De acuerdo a nuestra evaluacin, podemos estimar que la SBEF se encuentra en niveles medios de madurez de su cultura informtica. La mejora de este indicador no se lograr con medidas o acciones puntuales, sino que requerir un proceso continuo, liderado por los niveles ms altos de la Institucin. En lneas generales este proceso deber formalizar y estandarizar los procesos informticos en mayor medida, enfatizando que son procesos que involucran a toda la organizacin.

b.Planificacin estratgica

Hemos apreciado la existencia de un proceso de planificacin estratgica a nivel del negocio, cuya metodologa se encuentra delineada en el documento Reglamento Especfico del Sistema de Programacin de Operaciones.

Durante el presente ao la SBEF ha seguido los lineamientos definidos en dicho documento y realizado un proceso que culmin en la formulacin de una serie de objetivos institucionales de la SBEF y los planes operativos anuales (POAs) a nivel de cada una de sus distintas reas.

Metodolgicamente, 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 tcnicas.

Si bien la metodologa de planificacin estratgica que se aplica en su definicin cumple con las mejores prcticas, sus resultados en cuanto a la previsin de los trabajos del rea informtica 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 situacin tiene su origen en la falta de una definicin formal de los requerimientos de las reas usuarias en sus fichas tcnicas, identificando claramente los objetivos, productos y plazos. Asimismo, el proceso de los POAs de las distintas reas debera contar con la participacin de la USI, que las asesorara en cuanto a posibles proyectos de automatizacin y definira los lineamientos generales de los proyectos a llevar a cabo por la USI.

Asimismo, es importante incorporar polticas orientadas a establecer que este procedimiento es el canal formalmente establecido para la incorporacin de requerimientos al rea de sistemas y que solamente los requerimientos definidos en esta instancia sern 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 incorporacin en el POA de la USI.

En este proceso, las distintas reas tambin asignaran prioridades a los requerimientos realizados a la USI.

Una vez terminado el proceso de elaboracin de los POAs, e identificados todos los proyectos requeridos a la USI, esta realizara una estimacin primaria del esfuerzo requerido para su cumplimiento. En base a esta informacin, el comit de informtica definira el conjunto de proyectos a llevar a cabo en la gestin, sus prioridades, y opciones preliminares de implantacin. Con esta informacin la USI elaborara su POA, que en los hechos se consolidara como el plan informtico anual de la superintendencia. Cada ficha tcnica as definida debera incluir los datos bsicos de definicin de un proyecto: plazos, recursos, tareas, responsables, dependencias externas e internas, servicios subcontratados, presupuesto, etc.

El comit de informtica aprobara el POA de la USI, junto con su presupuesto, y posteriormente sera el encargado de su seguimiento y de la aprobacin de sus cambios. Este mecanismo permitira asignar los recursos informticos a las reas ms importantes.

Con el proceso arriba descripto, la superintendencia podra definir indicadores asociados al cumplimiento de los objetivos especficos planteados, que permitieran medir la performance de la USI y de las otras reas involucradas en los procesos informticos.

Este proceso tal como lo hemos descripto, debe estar enmarcado en la estrategia informtica de la USI en cuanto a aplicaciones, equipamiento y dotacin.

c.Estructura organizacional y segregacin de funciones

Existen varios aspectos que deben ser mencionados. En primer lugar, como tema estructural ms relevante, la estructura organizativa de la USI no contempla la asignacin real de funciones, existiendo por ejemplo personas que desempean funciones de supervisin sobre personal que jerrquicamente es su par, lo que dificulta el establecimiento de efectivos procedimientos de control y supervisin.

Asimismo, existen casos de funciones que no estn debidamente segregadas, como por ejemplo desarrollo e implantacin de sistemas de soporte a usuarios y seguridad de operacin, lo que afecta a la integridad, confiabilidad y confidencialidad de la informacin procesada por los sistemas.

Actualmente el servicio est estructurado en base a una asignacin de personas a aplicaciones o reas, que en los hechos se traduce en que las funciones de help desk son desempeadas por los tcnicos asignados a los sistemas en dnde se originan los incidentes. Esta funcin en la que todo el personal de sistemas se encuentra en la primera lnea de atencin 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 funcin), desde las ms sencillas hasta las tcnicamente ms complejas.

Creemos que se debera crear formalmente la funcin de help desk, responsable de la recepcin y atencin primaria de los incidentes. Slo los incidentes que no pudieran ser resueltos en esta primera instancia, deberan ser derivados a los tcnicos responsables. Este proceso debera ser apoyado por un software que automatizara el proceso de atencin, y a la vez realizara estadsticas acerca del origen y tipo de incidentes, tiempo de respuesta y resolucin, etc.

Un aspecto importante que debe ser notado en la estructura de funciones vinculadas a la funcin informtica es la debida asignacin de roles y responsabilidades que le competen a las reas usuarias, que deben ser desarrollados bajo la premisa de que el usuario es el dueo final de los datos, y que el rea informtica en este proceso desempea una funcin de servicio (disponibilizar los sistemas para el procesamiento de la informacin).

En relacin al prrafo anterior, actualmente existe un comit integrado por todas las intendencias, que se encarga de la definicin y seguimiento de los proyectos informticos. 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 mencionramos en la seccin planificacin estratgica).

La Institucin no cuenta con la funcin de auditoria interna de sistemas, responsable natural del control del cumplimiento de las directivas emanadas de su rgano director. Consideramos de gran importancia la incorporacin de esta funcin, como parte de un proceso de mayor formalizacin y control de las actividades informticas.

La Institucin tampoco cuenta con una funcin, formalmente establecida, de Organizacin y Mtodos, que sea encargada de la implantacin de las polticas definidas por la Gerencia dentro del vnculo entre los sistemas y los procedimientos de usuario. Esta funcin podra tener a su cargo las tareas de confeccin de normas de documentacin de los sistemas para el usuario, eventualmente elaborara la documentacin de sistemas de desarrollo interno, controlara la documentacin entregada por proveedores externos, asesorara a las Intendencias en cuanto a cambios en los procesos y eventualmente sera la encargada de atender los incidentes no tcnicos de los sistemas referidos por la funcin de help desk (p.ej. los originados en desconocimiento de los sistemas).

Si bien la Unidad de Desarrollo Operativo desempea 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 informtica, las mismas registran diferentes grados de formalizacin. La mayor formalizacin se puede encontrar en las reas ms tcnicas, como ser desarrollo de aplicaciones y configuracin de equipos, mientras que en otras (ej: pruebas de sistemas, pasajes a produccin, administracin de seguridad) la formalizacin es menor.

Esta falta de documentacin de los procedimientos no permite evaluar su cumplimiento, adecuacin y estabilidad.

Dentro del proceso de formalizacin de los procedimiento informticos se debera prestar atencin a los aspectos de: custodia de programas fuente, prueba y aprobacin de programas por parte de los usuarios, y pasajes a produccin.

Asimismo se deberan 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 adquisicin de aplicaciones

Hemos observado que existen ocasiones en las que la USI no participa en la definicin de los proyectos que involucran la incorporacin de software o hardware. Esta modalidad de trabajo dificulta la planificacin de la USI, a la vez que no permite mantener estndares tecnolgicos y de calidad de los sistemas (cada proyecto externo es realizado con su propia metodologa y enfoque), todo lo cual termina impactando en el costo final de operacin.

Dentro de los aspectos mencionados en la seccin de Planificacin estratgica de la Institucin, se incluyen aspectos que propician la elaboracin en forma ms oportuna del POA de sistemas y su interrelacin con los POAs de las otras reas. Estos aspectos deben ser la base que asegure la participacin adecuada de la USI en los proyectos de desarrollo y adquisicin de aplicaciones.

Dentro de los principales aspectos a ser considerados por la Institucin para su implantacin se encuentran:

Definicin de roles y responsabilidades de reas usuarias y de sistemas

Implementacin de estndares mnimos a exigir (participacin de reas tcnicas, tecnologa, documentacin, capacitacin, etc.)

Establecer mecanismos de aprobacin y seguimiento de proyectos

Implementar normas y procedimientos formalmente establecidos para la definicin, control y gestin de proyectos de desarrollo e implantacin de aplicaciones.

De acuerdo a lo relevado, una parte importante de los desarrollos realizados por la USI se orientan a la generacin de informacin especial para las reas usuarias. Estimamos conveniente que la Institucin considere la adquisicin de herramientas de usuario final orientadas a la extraccin y anlisis de informacin (ej: generadores de reportes, como tambin herramientas de datawarehousing que podran contribuir a la obtencin de informacin estadstica o consolidada).

f.Operacin y soporte de sistemas

Seguridad fsica

De acuerdo al trabajo realizado, hemos visto que la sala del computador no cuenta con los siguientes dispositivos o medidas de proteccin: detectores de humo, alarma contra incendios, alarma contra intrusos. Asimismo, estimamos conveniente mejorar las medidas de proteccin fsica, sellando las ventanas y sustituyendo las divisiones de vidrio por paredes.

Estas medidas deberan ser extendidas en la medida de lo aplicable al resto de las reas de sistemas, donde tambin residen equipamiento, documentacin e informacin.

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 ignfugos para el almacenamiento de las cintas de respaldo.

Por otro lado, es importante mencionar que las actuales instalaciones fsicas de la USI no han sido diseadas especficamente para tal fin, lo cual no contribuye a la solucin de los aspectos antes mencionados.

Estos aspectos inciden directamente en la disponibilidad y confidencialidad de la informacin.

Seguridad lgica

Existen varios aspectos a mejorar en cuanto a la seguridad lgica:

La funcin de administracin de seguridad no esta formalmente asignada y segregada de funciones incompatibles.

No se cuenta con polticas, normas y procedimientos formalmente establecidas.

Los mecanismos de administracin de usuarios y contraseas no cumple con las mejores prcticas 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 modificacin de usuarios,

reglas para la construccin de claves (longitud mnima, caducidad, reglas de construccin, etc.)

No se cuenta con mecanismos de control y supervisin de las actividades de seguridad.

No se cuenta con una clasificacin de la informacin en cuanto a su criticidad y por lo tanto tampoco con medidas de proteccin asociadas a cada categora definida.

Operacin

De acuerdo al trabajo realizado, hemos notado los siguientes aspectos relacionadas a esta rea:

Como ya lo mencionramos, los operadores desempean funciones vinculadas a la administracin de seguridad.

No se cuenta con procedimientos formales de control de los trabajos de operacin (revisin de bitcoras, logs), ni se deja evidencia de las revisiones.

No existen cronogramas de operacin formalmente documentados.

No existen normas para la ejecucin de tareas de mantenimiento y limpieza de los discos de los sistemas.

Existen deficiencias en la administracin de copias de respaldo (backups)

Queremos mencionar que las tareas de operacin relacionadas con el procesamiento de datos no tienen un alto grado de complejidad, por lo que la implantacin de estos aspectos no debera ser costosa.

Plan de contingencia

La SBEF no cuenta con plan de contingencias del negocio, slo se cuenta con un plan de recuperacin operativo de sistemas.

Asimismo, tampoco se han definido los procedimientos formales para la capacitacin del personal de sistemas en los procedimientos definidos en el plan de contingencias.

IV.RECOMENDACIONES

IV.1RESUMEN DE RECOMENDACIONES

A continuacin presentamos un resumen de los hallazgos que surgieron como resultado de la aplicacin de los procedimientos previamente definidos.

Dichos hallazgos han sido clasificados en funcin a la prioridad que consideramos se le debera dar para la implementacin de las soluciones sugeridas.

A: Alta M: Media B: Baja

A. GESTION DE LA UNIDAD

Hallazgo

1.Reestructurar la participacin de la USI en el proceso de elaboracin de los POAs de las reas usuariasA

2.Planificacin estratgica de SistemasA

3.Consolidar el Comit de SistemasA

4.Adecuar la Estructura organizacionalA

5.Consolidar las funciones de apoyo de Auditora de Sistemas y Organizacin & MtodosM

6.Definir mecanismos para la rotacin de personalM

7.Planificar la carrera para el personal de la USIB

8.Implantar un sistema de control presupuestarioM

9.Normar la adquisicin de sistemas y/o servicios de desarrollo de sistemasM

10.Definir normas y procedimientos de derechos de autorB

11.Reestructurar el plan de capacitacinB

12.Definir normas e implantar procedimientos para la Administracin de la calidadM

B. DESARROLLO, ADQUISICION E IMPLANTACION DE SISTEMAS

1.Definir mdulos de seguridad y de auditoria para los sistemasM

2.Definir estndares formales para la codificacin de los sistemasM

3.Definir una metodologa formal para realizar pruebas a los sistemasA

4.Establecer un ambiente de pruebas para los sistemas basados en informixA

5.Definir procedimientos para la custodia de cdigo fuenteA

6.Definir procedimientos formales para realizar pases a produccinA

7.Definir procedimientos para la implantacin de los sistemasM

8.Definir la participacin de auditora interna en la implantacin de los sistemasM

9.Definir un plan de contingencias para la continuidad del negocio A

10.Definir procedimientos formales para el monitoreo continuo del hardwareM

11.Definir acuerdos de nivel de servicio entre la USI y las reas usuariasB

12.Definir una metodologa para la administracin de proyectosA

13.Definir procedimientos para administrar la calidad de los proyectos externosM

C. OPERACION Y SOPORTE DE SISTEMAS1.Restringir el conocimiento de claves de usuario por parte de la USIA

2.Modificar la parametrizacin de los passwordsA

3.Parametrizar el control de algunas caractersticas de los passwordsA

4.Aplicar las normas y procedimientos para el alta de usuariosA

5.Definir un documento especfico para el acceso de usuarios a la red.M

6.Separar las reas de desarrollo y produccinA

7.Definir normas y procedimientos para la clasificacin de datosM

8.Definir normas y procedimientos para el manejo de incidentesM

9.Definir la elaboracin de reportes de violacinM

10.Definir una poltica para el uso de InternetM

11.Mejorar la seguridad fsicaA

12.Completar la documentacin de las configuracionesM

13.Mejorar la administracin de los backupsA

14.Documentar las operacionesM

15.Definir procedimientos para la proteccin de los datosM

16.Mejorar los parmetros de seguridad del sistema UnixB

17.Mejorar los parmetros de seguridad de los sistemas Windows NT y Windows 2000M

IV.2DETALLE DE RECOMENDACIONES

I. GESTION DE LA UNIDAD

1. Reestructurar la participacin de la USI en el proceso de elaboracin de los POAs de las reas usuarias

Como resultado de la revisin de las fichas tcnicas hemos observado que las mismas no reflejan en forma clara y especfica las necesidades de apoyo que las reas de la SBEF requerirn de la USI, lo cual dificulta, entre otros, los siguientes aspectos:

Identificacin de necesidades de informacin de las reas usuarias.

Identificacin de nuevos desarrollos.

Mantenimiento de estndares de hardware y software de base.

Mantenimiento de estndares de desarrollo.

Identificacin de oportunidades de proyectos no mencionados como tales.

Priorizacin de proyectos.

Previsin de esfuerzos de desarrollo y mantenimiento.

Establecimiento de estrategias de hardware y software.

Por todo lo mencionado anteriormente y de acuerdo a las mejores prcticas de la industria es recomendable que las fichas tcnicas especifiquen claramente las tareas a ser desarrolladas por cada intendencia de forma tal que cada ficha tcnica refleje un proyecto especfico, 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 metodologa debera ser complementada con las definiciones mnimas que deben ser proporcionadas para la definicin de un proyecto de la USI en esta etapa de elaboracin de los POAs.

El desempeo por parte de la USI del rol de asesor interno ser de gran beneficio a las reas usuarias en el proceso de generacin de sus fichas tcnicas ya que permitir utilizar su experiencia en la definicin de proyectos que cuenten con el soporte tecnolgico y proponer nuevos mecanismos de automatizacin de procesos y/o implementacin de nuevos sistemas.

De este modo, una vez elaboradas las fichas tcnicas de las reas usuarias, la USI deber tomar los proyectos en ellas incluidos como base para elaborar sus propias fichas tcnicas.

2. Planificacin Estratgica de Sistemas

Como resultado del trabajo realizado, observamos que la funcin informtica no est plenamente integrada al proceso de planificacin estratgica de la SBEF de forma tal que se pueda elaborar en forma oportuna y eficaz el plan estratgico de sistemas.

La elaboracin de un Plan Estratgico de Sistemas (Strategic Information Systems Planning SISP) incluye el proceso de desarrollo de un plan del uso de la tecnologa de la Informacin dentro de la organizacin, 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) Identificacin de posibles implantaciones

b) Definicin de los estndares de hardware y software de base que sern adoptados.

c) Identificacin de necesidades de informacin de las reas usuarias

d) Identificacin de oportunidades de proyectos.

e) Priorizacin de proyectos

f) Definir las estrategias de desarrollo

g) Cuantificar los esfuerzos de desarrollo y mantenimiento.

h) Definicin de las estrategias de HW y SW.

La implantacin de las medidas mencionadas en la recomendacin 1 (Reestructuracin de las Fichas Tcnicas) abordara los aspectos a), c) y d).

El control y monitoreo llevado a cabo por el comit de informtica (descripto tanto en el resumen ejecutivo como en la siguiente recomendacin) abordara el aspecto e).

Como elementos restantes, la USI debera definir los aspectos b), f), g) y h).

Si bien hemos observado que la USI cuenta con un Plan Estratgico, el cual incluye las tareas a ser desarrolladas a fin de contribuir al logro de los objetivos estratgicos de la SBEF, es importante considerar los aspectos anteriormente mencionados.

3. Consolidacin 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 situacin anteriormente planteada es totalmente explicable considerando que el rea de sistemas no cuenta con un plan de trabajo que muestre claramente las tareas que sern desarrolladas y que un porcentaje muy importante de sus actividades son tareas no planificadas, aproximadamente ms del 60%.

Bajo esta situacin 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 funcin 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 planificacin, priorizacin, aprobacin, 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,

Contratacin de personal adicional,

Contratacin de consultoras,

Coordinacin de los trabajos de desarrollo y/o modificacin de sistemas a fin de posibilitar la participacin oportuna y adecuada de las reas usuarias.

De esta forma las decisiones de priorizacin para la ejecucin de los trabajos pasa a ser una responsabilidad del comit, dnde se tiene la visin global de la situacin de la organizacin y se est informado sobre los cambios de accin o decisiones que se toman en los niveles ejecutivos.

Por todo lo mencionado anteriormente, consideramos de vital importancia consolidar la funcin del comit de sistemas, el cual deber mantener reuniones en forma peridica, tomando como base de referencia la planificacin de tareas de acuerdo a lo mencionado en el punto 1, Reestructuracin de las fichas tcnicas, de este documento.

4. Adecuacin de la Estructura organizacionalHemos observado que la estructura organizacional de la USI no refleja las jerarquas ni los niveles de mando que en la prctica existen, esta situacin crea problemas en la segregacin de funciones y designacin de responsabilidades, y dificulta las tareas de supervisin y control de los trabajos.

De acuerdo a las mejores prcticas la estructura organizacional de un rea de sistemas debe estar alineada a las tareas y responsabilidades existentes dentro de esta.

De acuerdo a lo observado el rea de sistemas realiza tareas en las siguientes reas de trabajo:

1. Desarrollo y mantenimiento de sistemas

2. Soporte a usuarios, internos y externos

3. Operacin de los sistemas en produccin

4. Administracin y Soporte en equipos, redes y comunicaciones

5. Seguridad de los sistemas

Sin embargo, como resultado de nuestro trabajo observamos que las funciones de responsable de seguridad y soporte a usuarios no estn formalmente definidas. Asimismo, observamos que las funciones de los responsables de las reas de desarrollo y produccin 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 organizacin 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 funcin permitira contar con un nico canal de comunicacin para hacer los requerimientos de soporte, lo cual le permitira a la USI contar con una primera instancia de apoyo, que debera atender los aspectos ms simples de forma tal que solamente los casos ms complejos sean dirigidos a las personas correspondientes.

Asimismo, esta instancia debera 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 realizara un uso ms eficiente de recursos, asignando las tareas ms complejas al personal mas capacitado.

Oficial de seguridad, esta funcin permitira concentrar en una persona las funciones de seguridad de los sistemas, ya sean relacionadas con aplicaciones, administracin de base de datos, administracin del correo electrnico, sistemas operativos, etc.

Esta persona debera ser la nica que tenga acceso simultneo a las reas de desarrollo y produccin y debera ser el responsable de la supervisn de los pases a produccin de los nuevos sistemas o de los cambios que son realizados por los analistas / programadores.

Asimismo, y en base a una planificacin previamente definida, se debera 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 deberan ser informadas al oficial de seguridad suplente solamente en caso de contingencia.

Es importante definir canales de comunicacin formales para que las reas usuarias realicen sus requerimientos cotidianos, de forma tal de minimizar la posibilidad de que interacten en forma directa con el personal de la USI, lo cual puede afectar significativamente la planificacin 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 Auditora de Sistemas y Organizacin & Mtodos

Hemos observado que la funcin de O&M no est claramente definida ni establecida en la SBEF, si bien en los ltimos meses la Unidad de Desarrollo Operativo desempea 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 funcin de Auditora interna de Sistemas.

Consideramos importante la consolidacin 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 funcin sea permanente dentro de la estructura de la organizacin.

En relacin a la Auditora Interna de Sistemas y debido a las caractersticas de la SBEF, consideramos que dicha funcin no debe implicar necesariamente la designacin a tiempo completo de un funcionario de la Unidad de Auditora Interna. Dicha funcin, podra ser designada a terceras partes de forma tal que los trabajos puedan ser realizados peridicamente en funcin a las necesidades de la organizacin.

6.Definir mecanismos para la rotacin de personal

La estructura de la USI, en el rea de desarrollo, se basa en la designacin de responsables por aplicaciones, lo cual ocasiona que cada analista sea un experto en los sistemas que estn a su cargo. Sin embargo, esta forma de estructurar las funciones y responsabilidades de los analistas, ocasiona la creacin, en cierta medida, de personal indispensable sin el cual no es posible atender oportunamente requerimientos de los usuarios.

Actualmente la USI trata de minimizar esta situacin asignando varias personas para los proyectos, de forma de que varias personas compartan el conocimiento.

Las mejores prcticas indican que uno de los mecanismos ms comunes que utilizan las organizaciones para contrarrestar esta situacin es la creacin de planes de rotacin de personal.

De esta forma las personas son asignadas peridicamente a distintas aplicaciones, con lo cual se logra la especializacin de varias personas en cada aplicacin, 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 rotacin 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 formacin acadmica de las personas del rea de desarrollo es adecuada, existiendo varias personas que cuentan con estudios de maestra.

Si bien esta situacin le permite a la SBEF contar con personal altamente capacitado que puede poner a disposicin de la organizacin todo su potencial acadmico, es importante considerar que existen algunos aspectos que deben ser considerados en relacin a este personal:

Personal que tiene bastante experiencia y al mismo tiempo tienen una buena formacin acadmica, 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 organizacin. Esto podra ocasionar que algunos funcionarios dejen la organizacin 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. Implantacin de un sistema de control presupuestario

Hemos observado que el rea de administracin de la SBEF no cuenta con un sistema que cubra sus necesidades funcionales ni de informacin 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 informacin de los usuarios.

Asimismo, el sistema a ser implementado debera contribuir a la generacin de informacin para efectuar anlisis de costo/beneficio de las distintas actividades, incluidas las de la USI, para lo cual sera 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 informtica, la USI podra por ejemplo controlar los gastos originados en el rubro de informtica, impidiendo que se realicen adquisiciones de bienes o servicios informticos por fuera de los procedimientos establecidos.

9. Normar la adquisicin 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 implantacin de sistemas computadorizados sin la intervencin 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 idnea 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 adquisicin de bienes tecnolgicos sean iniciados con la participacin activa de la USI.

10.Definicin 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 situacin se repite para la otras reas de la SBEF.

De acuerdo a las mejores prcticas es recomendable que se definan normas y procedimientos orientados a la inclusin de clusulas especficas de derechos de autor en los contratos de trabajo que los empleados contraen con la organizacin.

11. Reestructurar el plan de capacitacin

Hemos observado que la USI cuenta con un plan de capacitacin el cuales definido a principio de cada gestin, el cual es formalmente documentado y aprobado a travs 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 revisin y que muy difcilmente se llegar a cumplirlo.

Sin embargo, consideramos que es importante que el Plan de Capacitacin cuente con mayor precisin en su informacin, esto es:

Alinear el plan hacia los proyectos planificados y estrategias tecnolgicas definidas.

Definir quines sern las personas del rea de sistemas que participarn en cada curso.

Hacer una estimacin de costos detallada.

Definir las fechas en las cuales sera recomendable realizar la capacitacin.

Para los cursos internos, se debera 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 sera ms eficiente y cuantificable.

12. Definir normas e implantar procedimientos para la Administracin 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 funcin tiene como responsabilidad la aplicacin de pruebas y verificacin para evaluar si los sistemas, los cambios realizados a los programas y la documentacin cuenten con los requisitos mnimos de calidad antes de que los mismos sean puestos en produccin.

Es importante que esta funcin 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.

La responsabilidad de esta funcin recae tanto en el rea de sistemas, en cuanto a aspectos tcnicos, como en las reas usuarios, en cuanto a la funcionalidad hacia el usuario final.

II.DESARROLLO, ADQUISICION E IMPLANTACION DE SISTEMAS

1. Definir mdulos de seguridad y de auditoria para los sistemas

No existen procedimientos formales que permitan definir mdulos de seguridad y auditora para los sistemas. No se contempla durante las etapas del desarrollo de sistemas la definicin de los mdulos de seguridad y de auditoria.

De acuerdo a las mejores prcticas de la industria, el ciclo de desarrollo de los sistemas debera asegurar que se consideren mecanismos para definir mdulos especficos de rastros de auditora y que se evalen los mecanismos de seguridad que proporcionar el sistema para proteger los datos e informacin sensible. Los aspectos ms importantes a tomar en cuenta durante la definicin de estos mdulos son:

Acceso a los datos

Administracin de privilegios

Acceso a funciones especiales

Definicin de rastros de auditora

Definicin de procedimientos para la revisin de los incidentes de seguridad

Definicin de procedimientos para la revisin de auditora

2. Definir estndares formales para la codificacin de los sistemas

Durante nuestra revisin no encontramos estndares para la codificacin 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 prcticas de la industria, deberan existir estndares y acuerdos para la programacin de los sistemas. Estos estndares de codificacin deberan incluir a lenguajes de consulta (querys), lenguajes de 4ta generacin, generadores de reportes, generadores de pantallas y generadores de cdigo. Los estndares y acuerdos de programacin deberan cubrir los siguientes aspectos:

Guas de formato para el cdigo fuente, incluyendo aspectos tales como identificacin del cdigo fuente, formato de los programas fuente en prrafos separados, comentarios, descripcin del programa/mdulo/subrutina/funcin, datos recibidos y valores retornados y otros aspectos que permitan comprender el flujo del programa durante la depuracin de errores.

Acuerdos sobre el estilo de programacin identificando entradas y salidas, composicin y formato de los almacenamientos de los datos y arreglos, acuerdos de numeracin de prrafos y otros que proporciones un estilo de escritura fcil y predecible que pueda ayudar en una inspeccin inicial de los programas y su posterior mantenimiento.

Lineamientos enfocados a promover una mayor eficiencia en lo concerniente a la representacin de elementos de datos, definiciones de conjuntos de datos, rutinas de acceso y ubicacin de subrutinas dentro de un mdulo.

3. Definir una metodologa formal para realizar pruebas a los sistemas

Durante nuestra revisin no encontramos una metodologa para la realizacin de pruebas a los sistemas, que permita realizar las mismas segn estndares de aceptacin de pruebas y correccin 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 metodologa de pruebas y no existe documentacin formal que respalde la realizacin de las mismas.

De acuerdo a las mejores prcticas de la industria, la documentacin de pruebas debera realizarse como parte integral del proceso de desarrollo de sistemas. Deberan existir estndares para la elaboracin de pruebas que detallen la documentacin a generarse, la cual debera 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. Especficamente, 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 automticas con otros sistemas)

Especifica los miembros y responsables del equipo de pruebas

Especifica el plan de trabajo para el desarrollo y ejecucin del Plan de Pruebas

Define los recursos a ser requeridos para la realizacin de las pruebas Plan de Pruebas: Para poder elaborar un plan de pruebas es necesario contar con documentacin del sistema y contar con un adecuado entendimiento del diseo del mismo, ya que el Plan de Pruebas se elabora en funcin a la documentacin existente, la calidad y nivel de detalle de la documentacin afectar la calidad y nivel de detalle del Plan de Pruebas. Un Plan de pruebas incluye:

Una definicin 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 definicin de los datos de prueba

La descripcin de los resultados esperados

4. Establecer un ambiente de pruebas para los sistemas basados en Informix

Durante nuestra revisin 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 correccin de errores, prueba de actualizaciones recibidas de proveedores, pruebas de cambios a programas y otros. De acuerdo a las mejores prcticas de la industria, un ambiente de pruebas requiere de la seleccin, adquisicin, instalacin e integracin del hardware, sistemas de software, redes y herramientas que permitan contar con una replica del ambiente productivo.

Actualmente, la USI utiliza el servidor de produccin 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 cdigo fuente

No existen procedimientos formales para la custodia de cdigo fuente, el cdigo fuente de los sistemas basados en SQL Server y Visual Basic se administra a travs de un directorio de cdigo 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 segn la persona que modifica el sistema).

De acuerdo a las mejores prcticas de la industria, deberan existir procedimientos que permitan controlar la custodia de cdigo fuente, la administracin de versiones y el control de los cambios al cdigo. Estos procedimientos podran basarse en mecanismos de control, tales como:

Software de administracin de libreras, que permita el control de las versiones, el control del cdigo fuente y su estado, permitiendo el control de la modificacin simultanea del mismo.

Custodia de las libreras a travs de copias de respaldo.

Procedimientos de entrega y recepcin de libreras.

Herramientas de comparacin de cdigo fuente que permitan asegurar que todos los cambios en el cdigo se encuentran identificados.

El cdigo 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 produccin

Durante nuestra revisin no encontramos procedimientos formales para realizar los pases a produccin de los cambios a los sistemas, por lo cual existe el riesgo de que se puedan implantar en el ambiente de produccin 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 prcticas de la industria, deberan existir procedimientos que permitan realizar los pases a produccin de manera controlada y totalmente documentada. La secuencia para realizar los pases a produccin debera contemplar:

Transferencias al ambiente de produccin basadas en requerimientos autorizados.

Transferencias entre ambientes realizadas por una funcin independiente de la de desarrollo.

Existencia de software de administracin de libreras para el control de movimientos de software.

Que slo cdigos fuente sean transferidos entre el ambiente de desarrollo, pruebas y produccin.

Que los cdigos fuente sean recompilados en el ambiente de produccin para crear los programas ejecutables.

Que se realicen comparaciones entre las versiones modificadas y versiones anteriores para identificar los cambios.

Los pases a produccin de los sistemas basados en Informix se realizan copiando las modificaciones en el ambiente de produccin donde, el administrador de la base de datos reemplaza las modificaciones y recompila los programas. 7. Definir procedimientos para la implantacin de los sistemas

No se consideran algunos procedimientos de aceptacin antes de la implantacin del sistema: entrega de documentacin de usuario, documentacin de operacin del sistema, documentacin para el entrenamiento del personal, documentacin de ajuste de despeo, documentacin de las pruebas piloto/paralelas.

De acuerdo a las mejores prcticas de la industria, deberan existir procedimientos para la implantacin de los sistemas que permitan controlar:

Documentacin de usuario.

Documentacin de entrenamiento.

Documentacin para la operacin.

Estndares para la conversin de datos.

Pruebas de aceptacin.

Procedimientos para la recepcin y correccin de errores para las aplicaciones externas.

Garantas y acuerdos de mantenimiento.

Documentacin formal de finalizacin del proyecto.

La SBEF cuenta con procedimientos para la aceptacin de los sistemas por parte de los usuarios.8. Definir la participacin de auditora interna en la implantacin de los sistemas

No se han definido procedimientos formales que permitan la participacin del rea de Auditora Interna en los proyectos de desarrollo de sistemas.

De acuerdo a las mejores prcticas de la industria, el departamento de Auditora Interna debera participar en los proyectos de desarrollo de sistemas a travs de la ejecucin de procedimientos de control. Se recomienda la participacin del rea de Auditora Interna en los siguientes aspectos del desarrollo de aplicaciones:

Controlar la adecuacin de los objetivos planteados contra los resultados obtenidos.

Controlar la participacin de las reas implicadas.

Revisar la adecuacin de la documentacin y el cumplimiento de polticas, normas, procedimientos y estndares definidos.

Participar en la definicin de controles.

Participar en el diseo de pistas de auditora y mdulos de control.

Evaluar los procedimientos de pruebas, pase a produccin, conversin y generacin de copias de respaldo

Seguimiento post implantacin.

9. Definir un plan de contingencias para la continuidad del negocio

Durante nuestra revisin no encontramos procedimientos que permitan la recuperacin del negocio en caso de contingencia, el plan de contingencias existente no contempla los aspectos crticos de negocio, tales como:

Anlisis de impacto para el negocio.

Medidas formalmente definidas para minimizar los riesgos identificados.

Definicin de tiempos mximos y mnimos para la recuperacin de los procesos.

Priorizacin de los procesos crticos de negocio (secuencia de recuperacin)

Lista de distribucin del plan de contingencias.

Aprobacin formal de los procedimientos definidos en el plan de contingencias.

Procedimientos para la recuperacin de los procesos crticos del negocio (actualmente el plan de contingencias slo contempla procedimientos para la recuperacin de los sistemas).

Detalle de requerimientos mnimos de insumos necesarios para operar en caso de contingencia.

Detalle de los requerimientos mnimos de hardware, software y comunicaciones para recuperar el negocio.

Lista de contactos telefnicos (proveedores y terceros) crticos para la recuperacin del negocio.

Lista de contactos telefnicos del personal responsable de administrar y participar en los procedimientos definidos.

Definicin formal de los componentes de los equipos de contingencia (responsables, equipos de contingencia, personal de seguridad y de procesamiento de datos).

Definicin de las responsabilidades especificas para cada uno de los equipos de contingencia.

Definicin de procedimientos para el respaldo de documentacin 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 perodos pico y normales e, procedimientos de notificacin, lneas de comunicacin, medicin del rendimiento de las pruebas previstas y no previstas, etc.).

Mecanismos para registrar los resultados de las pruebas y realizar la actualizacin de los procedimientos.

De acuerdo a las mejores prcticas de la industria, se debera contar con un Plan de Contingencias que permita proteger la continuidad operativa del negocio, el mismo debera identificar los procesos crticos del negocio y los recursos requeridos para mantener un nivel aceptable de operacin, para lo cual se deberan preparar y probar procedimientos que aseguren la continuidad de la entidad en caso de contingencia. Un Plan de Contingencias debera tomar en cuenta las siguientes etapas:

Anlisis de impacto: Que permite identificar y evaluar los procesos crticos del negocio, las aplicaciones que los soportan, la posibilidad de interrupcin, la cuantificacin de costos de negocio y escalas de tiempo de recuperacin.

Estrategia para la continuidad del negocio: Que proporciona un anlisis comparativo de las soluciones que permitirn la continuidad del negocio, basados en los requerimientos identificados durante el anlisis.

Desarrollo del Plan de Contingencias: El cual define los procedimientos para una adecuada administracin de las interrupciones en el negocio.

Mantenimiento y Pruebas al Plan de Contingencias: Permite la validacin de las estrategias de recuperacin, y la elaboracin de procedimientos para el mantenimiento del mismo.

10. Definir procedimientos formales para el monitoreo continuo del hardware

Durante nuestra revisin no encontramos procedimientos formales que permitan monitorear de manera continua el rendimiento de los equipos de hardware.

De acuerdo a las mejores prcticas de la industria, se debera 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:

Definicin de los requerimientos de disponibilidad y desempeo de los servicios informticos.

Plan de disponibilidad que permita monitorear y controlar la disponibilidad de los servicios informticos.

Procedimientos para monitorear de forma continua los recursos tecnolgicos y para elaborar informes peridicos de hallazgos.

Herramientas de modelaje que permitan ajustar los sistemas en funcin a la previsin 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.

Un Acuerdo de Nivel de Servicio se define como un mecanismo que nos permite controlar una relacin de tercerizacin, la adecuada definicin del mismo es la clave para el xito de la tercerizacin. 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 ms importantes a considerar son:

Definir claramente los servicios: La definicin 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 definicin de servicios debe adems definir las responsabilidades de la USI y de las reas usuarias para cada uno de los servicios. Tener un periodo de medicin 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 medicin que permita determinar el nivel de normal de servicio a ser brindado.

Definir mtricas de nivel de servicio: Las mtricas permiten medir la calidad del servicio que se brinda, pueden utilizarse mtricas tales como: tiempo de resolucin de problemas, cantidad de solicitudes de requerimiento de cambios, horas de programacin ejecutadas, porcentaje de disponibilidad de la aplicacin, grado de satisfaccin de los usuarios, etc.

Se recomienda que las mtricas que se apliquen se basen en un procedimiento de medicin tipo Scorecard, donde deberan contemplarse 3 dimensiones de medicin:

Mediciones tecnolgicas: Como por ejemplo, tiempo de disponibilidad del sistema, tiempo de disponibilidad de la red, horas de programacin.

Mediciones de calidad de servicio: Como por ejemplo, tiempo de respuesta del Help Desk, tiempos de resolucin de problemas, cronogramas de proyectos y otros.

Satisfaccin del usuario: Debido a que un presupuesto de tecnologa es generalmente restringido y se tienen varios proyectos prioritarios, que no se pueden ejecutar al mismo tiempo, es importante medir la satisfaccin del usuario final para poder analizar los aspectos estratgicos referidos a la tecnologa.

Definir la elaboracin informes: No slo es necesario definir las mtricas que permitirn medir la calidad de servicio, sino tambin definir que informes se generarn para monitorear el nivel de servicio.

Determinar el porcentaje de crecimiento: Un Acuerdo de Nivel de Servicio debera definir un porcentaje de crecimiento razonable de los servicios ofrecidos, el cual podra estar basado por ejemplo: en el crecimiento de las transacciones en el sistema o en el crecimiento de los requerimientos de cambio.

12. Definir una metodologa para la administracin de proyectos

No se cuenta con un marco referencial general que permita administrar los proyectos de sistemas que defina procedimientos para la planificacin de los proyectos, administracin y medicin del avance de proyectos, administracin de los aspectos administrativos e implantacin y operacin del sistema.

De acuerdo a las mejores prcticas de la industria, se debera contar con procedimientos formales para la administracin de proyectos de sistemas que contemplen:

Administracin de los recursos tecnolgicos del proyecto.

Administracin tiempos y cronogramas del proyecto.

Administracin y monitoreo de aspectos financieros y presupuestarios.

Administracin de proveedores.

Migracin e implantacin.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 prcticas de la industria, se debera contar con procedimientos formales que permitan la administracin y control de los proyectos externos de sistemas, que contemplen:

Un plan de calidad de proyectos

Estndares de calidad definidos para cada una de las fases de desarrollo del proyecto

Definicin de productos a entregar

Definicin de responsabilidadesIII.OPERACION Y SOPORTE DE SISTEMAS

1. Restringir el conocimiento de claves de usuario por parte de la USI

La generacin 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, tres nmeros y un carcter especial. Por este proceso el rea de produccin de la USI tiene conocimiento de todas las claves de usuarios.

De acuerdo a normas internacionales de seguridad lgica, cada usuario debera ser responsable de su clave y debe ser la nica persona que conozca la misma. El sistema debera permitir el cambio de clave al usuario el momento de ingresar por primera vez al sistema.

Adems se deberan tomar en cuenta los siguientes aspectos:

Cada usuario debera contar con una clave distinta para cada uno de los sistemas.

Permitir la misma clave para todos los sistemas solamente con autorizacin 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

Prohibicin de la utilizacin de claves comunes

2. Modificar la parametrizacin de las claves

Actualmente, ninguno de los sistemas en produccin solicita (obliga) al usuario el cambio peridico de claves.

Normas de seguridad generalmente utilizadas, sealan que deberan configurarse los sistemas operativos y las aplicaciones para que se posibilite el cambio peridico de claves y que todos los usuarios realicen el cambio de sus claves teniendo como mximo un lapso de 90 das.

3. Parametrizar el control de algunas caractersticas de las claves

Los sistemas no controlan algunas caractersticas de las claves que son importantes para incrementar la seguridad y la confidencialidad de la informacin.

Las caractersticas que debera tener la administracin 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 carcter varias veces en la construccin de la clave.

Debe existir al menos un dgito numrico en la clave.

Estas son algunas de las caractersticas de las mejores prcticas en cuanto a la seguridad lgica de los sistemas de informacin.

4. Aplicar las normas y procedimientos para el alta de usuarios en todos los casos

Mediante la aplicacin 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 gestin 2001 no cuenta con la autorizacin para su alta. De las gestiones anteriores, de los 10 usuarios seleccionados, ninguno de los mismos cuenta con la autorizacin respectiva.

Debera cumplirse con lo establecido en todos los casos.

5. Definir un documento especfico para el requerimiento de acceso de alta de usuarios a la red

No se cuenta con un formulario especfico para el requerimiento de acceso de los usuarios. El formulario SB91 es utilizado para todo tipo de requerimientos de las reas usuarias.

Debera existir un formulario especfico para la solicitud de acceso de los usuarios a la red y a los sistemas. De esta manera podra 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 produccin

No existe una separacin entre los ambientes de desarrollo y produccin, por lo que los programadores podran tener acceso a modificar programas y datos en el ambiente de produccin, pudiendo ocasionar la degradacin 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 sealan que el momento de realizar modificaciones a los sistemas, los desarrolladores no deberan contar con la posibilidad al acceso a datos en lnea. Debera existir para ello un servidor especficamente dedicado al desarrollo y mantenimiento de las aplicaciones.

7. Definir normas y procedimientos para la clasificacin de datos

No se cuenta con una clasificacin 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 deberan ser separados en cuatro clases de informacin con requerimientos separados de manipulacin para cada caso: Secretos, Confidenciales, Privados y No Clasificados. Esta clasificacin estndar de datos podra ser usada dentro de la Superintendencia. La clasificacin es definida de la siguiente manera:

Secretos: Esta clase es aplicada a la informacin ms sensitiva del negocio cuyo uso es permitido estrictamente slo a personal de la Superintendencia. El uso no autorizado de esta informacin puede causar un impacto muy fuerte para la Superintendencia, las Entidades Financieras y los clientes.

Confidenciales: Esta clase es aplicada a la informacin menos sensitiva del negocio, cuyo uso es permitido slo a personal de la Superintendencia. El uso no autorizado de esta informacin puede causar un impacto para la Superintendencia, las Entidades Financieras y los clientes.

Privados: Esta clase es aplicada a informacin personal cuyo uso es permitido dentro de la Superintendencia. El uso no autorizado de esta informacin puede causar un impacto fuerte a la Superintendencia o a sus empleados.

No Clasificados: Esta clase es aplicada a toda la dems informacin que no se encuentre claramente definida dentro de las tres anteriores clases. El uso no autorizado de esta informacin no supone un impacto para la Superintendencia, las Entidades Financieras o los clientes.

En la medida de lo aplicable los aspectos anteriormente mencionados deberan ser considerados en el caso de los mensajes enviados y recibidos mediante correo electrnico 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.

Segn las mejores prcticas de seguridad, deberan existir normas y procedimientos establecidos para asegurar que todos los eventos de operacin que no sean comunes (incidentes, errores o problemas) sean correctamente registrados, analizados y resueltos en un tiempo prudente.

Adems se debera consolidar la informacin generada por todos los operadores para realizar luego un anlisis y emitir estadsticas sobre el tipo de incidentes que se producen y los usuarios que ms soporte requieren. Asimismo el anlisis gerencial permitir tomar decisiones para solucionar los principales problemas en forma definitiva.

Actualmente se cuenta, en el rea de produccin, con una planilla Excel, en la cual deben registrarse todos los requerimientos de soporte de los usuarios.

9. Definir la generacin de reportes de violacin

Actualmente no se cuenta con reportes de violacin a la red de la Superintendencia de Bancos y Entidades Financieras. Tampoco existen reportes de violacin a la pgina web de la SBEF.

Deberan existir normas y procedimientos que detallen la manera de realizar el monitoreo a la red para la deteccin, reporte y revisin de los intentos de violacin. Las mejores prcticas de seguridad mencionan que deben existir estos documentos as como debe realizarse el monitoreo a todas las actividades de seguridad.

10. Definir una poltica para el uso de Internet

No existe una poltica de Internet formalmente definida.

Las mejores prcticas relacionadas con la seguridad sealan que el uso de Internet presenta nuevos y serios potenciales problemas de seguridad, es por este motivo que debera contarse en principio, con una poltica claramente definida de las posibilidades y las responsabilidades de los usuarios, as como el detalle de los riesgos incluidos en la navegacin y descarga de informacin.

11. Mejorar la seguridad fsica

Actualmente no se cuenta con algunos aspectos importantes para la administracin de la seguridad fsica:

No existen normas y procedimientos formalmente establecidos para esta tarea

No existen alarmas contra incendio ni detectores de humo en el Centro de Cmputo

No existen alarmas contra intrusos

Las paredes del Centro de Cmputo son de vidrio (posibilidad de acceso no autorizado)

No se cuenta con un registro de los visitantes al Centro de Cmputo y el motivo de la visita

Existen tomas de corriente en el piso del Centro de Cmputo. No existe piso falso.

No se realiza el mantenimiento peridico del sistema elctrico del Centro de Cmputo, luces de emergencia ni aire acondicionado.

Las ventanas que dan al exterior no se encuentran selladas.

No se poseen armarios ignfugos para el almacenamiento de copias de respaldo.

Las mejores prcticas de seguridad mencionan que deberan existir los aspectos mencionados para incrementar la seguridad fsica.

Asimismo, es importante mencionar que las actuales instalaciones fsicas de la USI no fueron diseadas especficamente para tal efecto, lo cual no contribuye a la solucin 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 adquisicin de un mecanismo automatizado de control el cual permita a travs de sensores identificar si una persona est ingresando y saliendo con un dispositivo de propiedad de la SBEF y permita registrar informacin como cdigo de equipo, hora, fecha, etc.

Este tipo de mecanismos fortalecera el ambiente de control y permitira que dicho proceso sea ms eficaz y eficiente.

12. Completar la documentacin de las configuraciones

No se cuenta con el registro de configuraciones para todos los recursos tecnolgicos.

Debera existir el registro de configuraciones de CPU, impresoras, perifricos, etc. Adems deberan existir procedimientos formalmente establecidos para realizar esta tarea, con el objetivo de permitir restituir todo el sistema (configuracin) en caso de falla del equipo o alguna otra contingencia.

Actualmente se cuenta con registro de las configuraciones de los siguientes recursos:

Equipos de comunicacin

Configuracin de la red

Discos duros (Unix)

Base de datos (Informix)

13. Mejorar la administracin de Backups

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 bitcora para la obtencin de copias de respaldo.

Debera llevarse un control detallado de todas las copias obtenidas para que, en caso de ser necesario, se tenga a mano toda la informacin de los meses y gestiones anteriores.

Debera existir un cronograma de operacin para que el operador conozca exactamente el orden de la obtencin de las copias de respaldo. Adems debera existir una bitcora en la cual se detalle las copias de respaldo diarias obtenidas, si es que existi algn problema el momento de realizar esta tarea y alguna observacin especial sobre el proceso para cada uno de los servidores.

Actualmente se cuenta con un cuaderno en el cual se registra el nmero de la cinta y el servidor del cual se obtuvo la informacin.

Adicionalmente deberan considerarse aspectos tales como:

Definir la vida til de las cintas para la obtencin de respaldo, de acuerdo a la informacin del proveedor para evitar fallas inesperadas de estos medios.

Adquisicin de un dispositivo para la obtencin automtica de copias de respaldo que posibilite la programacin de esta tarea.

14. Documentar las operaciones

Actualmente no se cuenta con documentacin de operaciones que detalle las tareas a ser realizadas para:

Proceso de inicio y otras operaciones

Programacin de tareas

Desviaciones de la programacin estndar de tareas

Normas internacionales de seguridad mencionan que el personal de operaciones debe estar familiarizado con el proceso de inicio y otras tareas de operacin contando con documentacin, peridicamente revisada y actualizada cuando es necesario.

Adems, la programacin de trabajos, procesos y tareas debera estar organizada de la forma ms eficiente de manera de maximizar la utilizacin de los recursos, alcanzar los objetivos y brindar un buen servicio. Los cambios a estas tareas deberan encontrarse formalmente aprobados.

Los procesos de inicio deberan encontrarse establecidas de manera de permitir identificar y registrar las desviaciones de la programacin estndar de tareas.

15. Definir procedimientos para la proteccin de los datos

Actualmente no se cuenta con ningn procedimiento de encripcin para los datos que son enviados desde la Entidades Financieras.

Las mejores prcticas de seguridad mencionan que la transferencia de datos sensitivos debera ser realizado slo a travs de una ruta confiable. Informacin sensitiva incluye informacin de administracin de seguridad, transacciones de datos sensitivos, claves y llaves criptogrficas. Para llegar a tener una ruta confiable debera contarse con procedimientos de encripcin en las lneas de comunicacin: entre usuarios, entre usuarios y sistemas y entre sistemas.

16. Mejorar los parmetros 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 mquina que est clasificada como un Husped Confiable, el mismo no requerir una clave de entrada y podr iniciar una sesin sin problemas en la misma.

Si estas cuentas nos son requeridas, deberan 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:

NobodyNobodyVDaemonBin

UucpUucpaAuthCron

LpTcbRisWnn

Usuarios con GID = 0Todo grupo que presente GID = 0, generalmente es conocido como el grupo sistema o grupo wheel. En la mayora de los sistemas Unix solamente los usuarios pertenecientes a este grupo tienen la posibilidad de utilizar el comando su. Por consiguiente, estos usuarios podran llegar a convertirse en superusuarios.

Se recomienda revisar los usuarios descritos a continuacin para asegurar que no se presentarn excepciones si llegaran a ser superusuarios.

Se tienen los siguientes 5 usuarios secundarios que tiene GID=0:

rootCircmflores

jcibietaGgemio

Usuarios cuyo directorio home permite acceso a escritura

Si el directorio home de un usuario permite acceso a escritura, cualquier persona podra modificar sus archivos. Esta es una manera fcil 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:rwxgroup:r xworld:

Se encontraron 11 usuarios:

UsuarioPermisoDirectorio Home

CircRwxrwx---/home/datos1/circ/

CircsrcRwxrwxr-x/users/usrdes/circsrc/

MfloresRwxrwxr-x/users/usrdes/mflores/

JcibietaRwxrwxr-x/users/usrdes/jcibieta/

GgemioRwxrwxr-x/users/usrdes/ggemio/

CquintaRwxrwx---/users/usrcom/cquinta/

AdipsRwxrwx---/users/usrcom/adips/

AsivilaRwxrwx---/users/usrcom/asivila/

KguzmanRwxrwx---/users/usrcom/kguzman/

RsalazarRwxrwx---/users/usrcom/rsalazar/

JcandiaRwxrwxr-x/users/usrdes/jcandia/

Grupos con Nombre Duplicado en el Archivo de GrupoEsto podra confundir al sistema y existe la posibilidad de que se presenten errores. Los problemas podran 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.

GrupoCantidad

Informix2

Circ2

Grupos sin usuarios

Los siguientes grupos no cuentan con ningn usuario vlido asignado. Si estos grupos no cuentan con usuario alguno no deberan 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 ningn usuario vlido:

MenSecMailTerminal

BackupTapeOperator

18. Mejorar los parmetros de seguridad de los sistemas Windows NT Y Windows 2000

Usuarios con cuentas inactivas

Las cuentas inactivas deberan 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 prcticas de la industria nos muestran que las cuentas que no son utilizadas durante un periodo de 60 das o mayor deberan considerarse inactivas y deshabilitarse.

Servidor SERVERUSR3 Principal Domain Controller y Proxy Server

IdentificadorNombre del UsuarioDescripcinUltimo ingreso (das)

CsantacruzCecicilia Santa CruzSecretaria de Normas123

HrocaHolbin RocaUsuario Regional Santa Cruz137

Portinb1PC Porttil volante INBsolicitado por Conzuelo Prado66

SupbanSuperintendencia de Bancos115

Servidor DNS_LPZ Servidor de Recepcin

IdentificadorNombre del UsuarioDescripcinUltimo ingreso (das)

AalmarazAmalia Almaraz DelgadilloCAJA DE AHORRO Y PRESTAMO LOS ANDES701

AbazanAlvaro BazanCITIBANK S.A.559

AberkhanAdolfo BerkhanCaja los Andes66

AcatariAlfredo CatariCaja Los Andes613

AciCompania Internacional Almacenara S.A.525

AdavilaAngel DavilaCooperativa San Jos de Punata177

AgdAlmacenes Generales de Deposito AGEDESA820

AherreraAdrin HerreraBanco Nacin Argentina471

AmocobonoAlberto MocobonoCooperativa Trapetro Oriente556

AmoralesAdrian MoralesCooperativa San Martn de Porres79

AmorenoAna Karina Moreno ParejasFONDO FINANCIERO PRIVADO FASSIL704

AmunozAlvaro Muoz PovedaBANCO SOLIDARIO531

AnunezAlex Nuez JustinianoFONDO FINANCIERO PRIVADO FASSIL.624

AortizAsteria OrtizCooperativa San Jose de Punata332

AriberoAlejandra Ribero UrquietaBANCO GANADERO S.A.819

ArojasAbel RojasBanco Union628

AsolanoAlejandro Solano CondorCoop. Pio X451

AsuarezAlberto Suarez MendezCOOPERATIVA LA MERCED820

AtaborgaArmando TaborgaCooperativa San Luis643

AtorreAdalid de la TorreBanco Mercantil861

AwcWarrant Santa Cruz S.A.896

AzabalaArturo ZabalaCITIBANK805

BaaBanco Boliviano Venta668

BabBanco Agricola de Bolivia128

BalarconBruno Alarcon ArrietaCitibank S.A.338

BamABM Amro Bank N.V.Ex- Banco Real.133

BbaBanco Boliviano Americano457

BbrBBA RECOMPRABANCO BOLIVIANO AMERICANO673

Bbv696

BherediaBenjamin HerediaCooperativa Hospicio Ltda.322

BonosnfbBonos NFB468

BreBanco Real598

BvacaBetty Vaca CalderonCOOPERATIVA LA MERCED340

CacordovaCarlos CordovaBanco Industrial (Cheques Rechazados)163

CalvaradoCecilia AlvaradoCAJA DE AHORRO Y PRESTAMO LOS ANDES825

CamichelCarlos MichelCooperativa PIO X622

CarteroClemencia Artero VelascoBANCO GANADERO S.A.745

CazambranaCarlos Eric ZambranaMUTUAL GUAPAY674

CbernalCristina BernalBANCO UNION693

CbustilloCarmen Bustillo ZamoranoBANCO ECONOMICO S.A.(COCHABAMBA)504

CcevascoCarla CevascoCITIBANK679

CchavezCarlos ChavezBanco Ganadero63

CherediaCoral HerediaFondo Financiero FIE464

CjustinianoClaudia JustinianoBANCO MERCANTIL S.A821

CluisagaClover Luisaga GalarzaCOOPERATIVA JESUS NAZARENO159

CmichelCarlos MichelCooperativa San Antonio793

CpereiraCarlos PereiraBanco Nacin Argentina764

CpovedaCinthia PovedaCaja de Ahorro y Prstamo Los Andes489

CriveraCarlos riveraCitibank157

CsaavedraClaudia SaavedraCITIBANK S.A819

CsanchezCiro SanchezBNA65

CsjCooperativa San Jose Obrero724

CslCooperativa San Luis209

CvacaflorCsar VacaflorCooperativa Catedral763

CvbCooperativa de Vivienda Bermejo (Bermejo - Tarija)661

DbarahonaDaniel BarahonaCooperativa San Roque63

DcasapiaDirza CasapiaCITIBANK S.A.365

DfloresDante FloresCitibank288

DperedoDanitza PeredoCoop. San Pedro Ltda.136

DsaricDavor SaricMutual La Paz178

EbocapineErika Paola Bocapine ArdayaFONDO FINANCIERO FASSIL583

EcalcinaEmilio CalcinaCooperativa San Martin533

EcondoriEugenio CondoriBanco Sol427

EdcorderoEdgar CorderoBanco Sol429

EescobarEduardo EscobarBanco Union - Santa Cruz657

EfabianiEdwin fabianiBANCO SOLIDARIO S.A.437

EfargoEdgar FargoBanco Econmico (Cheques Rechazados)171

EguzmanElvira GuzmnCVooperativa San Jos de Bermejo618

ElramosEliott RamosFFP FIE300

EmartinezEnrique MartnezCITIBANK S.A.611

EortizEdwin OrtizBanco Union66

EpatroniEsteban PatroniFONDO DE DESARROLLO CAMPESINO134

EperaltaEdwin Peralta SalcedoMUTUAL GUAPAY496

EramosEdwin Damaso Ramos MirandaFONDO FINANCIERO FASSIL692

EriveroEduardo RiveroMutual Guapay884

EsalasEdwin Salas329

EsilesEdgar SilesBanco Sol35