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

Conclusin general

III.2

Conclusiones especficas

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 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.1 INTRODUCCION
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.

Modelo de administracin de sistemas

Planificacin
estratgica
de la
institucin

Necesidades
del negocio

Administracin
del Negocio

Planificacin
estratgica
de sistemas

Soporte a las
aplicaciones
existentes

Proyectos
prioritarios

Planificacin
tctica de
sistemas

Nuevos
Cambios

Entrega de
Aplicaciones

Conjunto de aplicaciones nuevas

Administracin de Sistemas

Cultura Informtica

Este modelo contiene seis componentes

operacin de los servicios informticos.
informtica provienen de aspectos que
aplicando este modelo de alto nivel. Los

bsicos asociados con la provisin y

Muchos de los problemas del rea
pueden ser fcilmente identificados
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.1 Conclusin 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:

respaldo

no existe Plan de Contingencia del negocio

no existe uniformidad en la obtencin y custodia de copias de

III.2 Conclusiones 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.

10

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

11

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.

12

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.

13

IV.

RECOMENDACIONES

IV.1 RESUMEN 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:
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 participacin de la USI en el proceso de
elaboracin de los POAs de las reas usuarias
Planificacin estratgica de Sistemas
Consolidar el Comit de Sistemas
Adecuar la Estructura organizacional
Consolidar las funciones de apoyo de Auditora de Sistemas y
Organizacin & Mtodos
Definir mecanismos para la rotacin de personal
Planificar la carrera para el personal de la USI
Implantar un sistema de control presupuestario
Normar la adquisicin 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 capacitacin

Definir normas e implantar procedimientos para la Administracin

de la calidad

DESARROLLO, ADQUISICION E IMPLANTACION DE SISTEMAS

1.
2.
3.
4.

Definir mdulos de seguridad y de auditoria para los sistemas

Definir estndares formales para la codificacin de los sistemas
Definir una metodologa 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 cdigo fuente
Definir procedimientos formales para realizar pases a produccin
Definir procedimientos para la implantacin de los sistemas
Definir la participacin de auditora interna en la implantacin 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 metodologa para la administracin de proyectos
Definir procedimientos
proyectos externos

para

administrar

la

calidad

de

A
A
M
M
A
M
B
A

los

Restringir el conocimiento de claves de usuario por parte de la

USI
Modificar la parametrizacin de los passwords
Parametrizar el control de algunas caractersticas de los
passwords
Aplicar las normas y procedimientos para el alta de usuarios
Definir un documento especfico para el acceso de usuarios a la
red.
Separar las reas de desarrollo y produccin
Definir normas y procedimientos para la clasificacin de datos
Definir normas y procedimientos para el manejo de incidentes
Definir la elaboracin de reportes de violacin
Definir una poltica para el uso de Internet

Mejorar la seguridad fsica

Completar la documentacin de las configuraciones

Mejorar la administracin de los backups

Documentar las operaciones

Definir procedimientos para la proteccin de los datos

Mejorar los parmetros de seguridad del sistema Unix

Mejorar los parmetros de seguridad de los sistemas Windows NT

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 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

17

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

18

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 organizacional

Hemos 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.

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
Operacin de los sistemas en produccin
Administracin 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 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.

20

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.

21

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

22

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.

23

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.

24

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:

2.

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
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.

25

3.

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.
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:

26

 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.

27

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

28

entrenamiento del personal, documentacin

documentacin de las pruebas piloto/paralelas.

de

ajuste

de

despeo,

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.

29

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

30

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.

31

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

32

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 responsabilidades

III. 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,

33

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:

2.

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

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.

34

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

35

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.

36

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

37

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:

13.

Equipos de comunicacin
Configuracin de la red
Discos duros (Unix)
Base de datos (Informix)
Mejorar la administracin 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 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:

14.

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.

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

39

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:
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 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:
root
jcibieta

Usuarios
escritura

cuyo

Circ
Ggemio
directorio

home

mflores

permite

acceso

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:
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 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.
Grupo
Informix
Circ

Cantidad
2
2

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:
Men
Backup

Sec
Tape

Mail
Operator

Terminal

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

42

Identificador

Nombre
Usuario

Csantacruz

Cecicilia
Santa Secretaria de Normas
Cruz
Holbin Roca
Usuario Regional Santa 137
Cruz
PC Porttil volante solicitado por Conzuelo 66
INB
Prado
Superintendencia de Bancos
115

Hroca
Portinb1
Supban

del Descripcin

Ultimo
ingreso
(das)
123

Servidor DNS_LPZ Servidor de Recepcin

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
Adrin Herrera
Banco Nacin Argentina
471
Alberto Mocobono Cooperativa
Trapetro 556
Oriente
Adrian Morales
Cooperativa San Martn de 79
Porres
Ana Karina Moreno FONDO
FINANCIERO 704
Parejas
PRIVADO FASSIL
Alvaro
Muoz BANCO SOLIDARIO
531
Poveda
Alex
Nuez 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 Descripcin

Ultimo
ingreso
(das)
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 Descripcin

Ultimo
ingreso
(das)
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 Descripcin

Ultimo
ingreso
(das)
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 Nacin Argentina
764
Cinthia Poveda
Caja de Ahorro y Prstamo 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
Csar 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
Econmico 171
(Cheques Rechazados)
Elvira Guzmn
CVooperativa San Jos de 618
Bermejo
Eliott Ramos
FFP FIE
300
Enrique Martnez 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 Descripcin

Ultimo
ingreso
(das)

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 Descripcin

Ultimo
ingreso
(das)

Osinaga Arispe
GRACIELA
CITIBANK S.A
335
JUSTINIANO
German Sanchez BANCOS SOLIDARIO
530
Hilda Alccer
Mutual Progreso
700
Henry Hidalgo
Banco Solidario
253
Humbert Moreno Banco Econmico
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 Joaqun
421
Jos
Antonio ASOBAN
224
Cordova
Jorge Anez
Cooperativa
Jess 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
Jimnez
Arturo Justiniano
COOPERATIVA
JESUS 822
NAZARENO
Jenny Lpez
Mutual Paitit
524
Jos Alvarez
Banco Sol
414
Juan Fernndez
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. Jess 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 Descripcin

Ultimo
ingreso
(das)
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 Ftima
792
Miguel
Barrios FONDO FINANCIERO FASSIL 105
Cabero
Matilde Beltran
CITIBANK S.A
280
Maria Cecilia Caro Mutual La Paz
223
Velzquez
Mario Fortn
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 Prstamo 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 Descripcin

Ultimo
ingreso
(das)
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 Descripcin

Ultimo
ingreso
(das)

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 Rodrguez
Mutual Pando
570
Paola Gutirrez
Banco
Econmico 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
Ral Camacho
Mutual La Promotora
423
Ruth Camargo
Mutual La Plata
423
Roberto
Coriza COOPERATIVA
652
Llanos
FINANCIACOOP
Roberto de Irahola Banco Econmico
623
Ronald Havivi
BANCO SOLIDARIO
366
Ricardo
Herrera CITIBANK S.A
287
Lobo
Renn 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
Roco
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 Unin
186

50

Identificador

Nombre
Usuario

Rsoria
Rticona
Rtorrez
Rurquiza
Salcoba

Rodolfo Soria
Roxana Ticona
Rene Torrez
Rafael Urquiza
Salom Alcoba

del Descripcin
INB
FFP - FIE
Banco de la Unin
Banco Ganadero
Cooperativa Ftima

Ultimo
ingreso
(das)
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 Prstamo 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
Garca 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 estndar 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 prcticas 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 construccin compleja a
las dos cuentas.
Bloqueo automtico de las cuentas

El bloqueo automtico de cuentas despus de un nmero definido de intentos

fallidos de ingreso minimiza el riesgo de que las cuentas de los usuarios se
vean comprometidas a travs de ataques.
Las mejores prcticas de la industria, nos muestran que se utilizan los
siguientes parmetros:
Lockout: despus de 3-5 intentos fallidos de ingreso.
Reset counter: despus de [1440] minutos.
Lockout duration: se parametriza a [Forever (until admin unlocks)]
Servidor SERVERUSR3 Principal Domain Controller y Proxy
Server
Lockout: despus de 3 intentos fallidos de ingreso.
Reset counter: despus de [5] minutos.
Lockout duration: se parametriza a [5] minutos.
Servidor DNS_LPZ Servidor de Recepcin
Parmetros deshabilitados.
Servidor SERVERUSR4 Servidor SIF
Parmetros deshabilitados.

Restriccin 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, podran corromper el mismo,
ejecutar programas maliciosos (Trojan horse) o crear ataques de negacin de
servicio (denial of service) contra el servidor.
Las mejores prcticas 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 travs de la red

El parmetro 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 parmetro estuviera deshabilitado no sera
posible ingresar al servidor desde la red (login) por lo que el servidor no se
vera comprometido. Adicionalmente, usuarios no autorizados no tendran
acceso a la red.
Las mejores prcticas de la industria nos muestran que slo los siguientes
tipos de usuarios deberan 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 Recepcin
Todos los usuarios tienen habilitado este privilegio.
Servidor SERVERUSR4 Servidor SIF
Todos los usuarios tienen habilitado este privilegio.

Acceso irrestricto a los archivos

El parmetro 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 prcticas de la industria nos muestran que slo los siguientes
tipos de usuarios deberan 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 Recepcin
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 auditora

El parmetro de Administrar el registro de auditora y seguridad debe ser
restringido para ciertos usuarios, si este privilegio se otorga
innecesariamente existe el riesgo de que las pistas de auditora se vean
comprometidas por usuarios que ataquen el sistema y luego borren el
registro de auditora.
Las mejores prcticas de la industria nos muestran que slo usuarios como
Oficiales de Seguridad o Auditores deberan tener estos privilegios.
Servidor SERVERUSR3 Principal Domain Controller y Proxy Server
Los usuarios BUILTIN\Administrators tienen este privilegio.
Servidor DNS_LPZ Servidor de Recepcin
Los usuarios BUILTIN\Administrators tienen este privilegio.
Servidor SERVERUSR4 Servidor SIF
Los usuarios BUILTIN\Administrators tienen este privilegio.

Privilegios de restauracin de directorios y archivos

55

El parmetro 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 prcticas de la industria nos muestran que slo los siguientes
tipos de usuarios deberan 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 Recepcin

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 parmetro 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 podra ser
apagado repentinamente.
Las mejores prcticas de la industria nos muestran que slo los
siguientes tipos de usuarios deberan 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 Recepcin

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 parmetro 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 prcticas de la industria nos muestran que ninguno de los
usuarios deberan tener este privilegio. Sin embargo, en algunos ambientes
sera 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 Recepcin
Los usuarios BUILTIN\Administrators tienen este privilegio.
Servidor SERVERUSR4 Servidor SIF
Los usuarios BUILTIN\Administrators tienen este privilegio.

57

V. RESULTADOS OBTENIDOS
Gestin informtica
1. Evaluacin de la gestin informtica de la Unidad de Sistemas (USI).
Procedimiento aplicado
2. Verificaremos la existencia de normas y procedimientos para la
administracin de las funciones estratgicas del rea de sistemas que
permitan controlar la consistencia, orientacin tecnolgica y el efectivo
enfoque tecnolgico del Plan Estratgico de Sistemas. Adicionalmente
verificaremos que el plan estratgico de sistemas est alineado a los
objetivos definidos en el plan estratgico de la SBEF.
Resultados obtenidos
Como resultado del anlisis del documento Plan estratgico de la SBEF para
el perodo 2001 2007, obtuvimos los siguientes resultados:
El documento incluye los siguientes aspectos:
1.
2.
3.
4.

Misin de la USI
Funciones
Anlisis FODA
Estrategias generales de gestin, donde se definen los objetivos.
Asimismo, observamos que el procedimiento utilizado para la planificacin
estratgica y operativa de las distintas reas consider las siguientes etapas:

1.
2.
3.
4.
5.
6.

Taller de planificacin, donde se definieron los objetivos estratgicos (PES).

Elaboracin de los POAs
Definicin de las fichas tcnicas.
Priorizacin de los trabajos a cargo del comit de sistemas.
Nuevos requerimientos.
Asignacin de los trabajos en la USI.
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:

1. Identificacin de posibles implantaciones

2. Definicin de los estndares de hardware y software de base que sern
adoptados.
3. Identificacin de necesidades de informacin de las reas usuarias
4. Identificacin de oportunidades de proyectos.

58

5.
6.
7.
8.

Priorizacin de proyectos
Definir las estrategias de desarrollo
Cuantificar los esfuerzos de desarrollo y mantenimiento.
Definicin de las estrategias de HW y SW.
Asimismo, como resultado del anlisis del documento Planificacin
estratgica de la USI gestin 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 estratgico de IT (Tecnologa de la Informacin)
Desarrollo de valor IT (Tecnologa de la Informacin)
Administracin del riesgo
Medidas de performance

Funciones de la Unidad de Sistemas

Planificacin estratgica
Anlisis FODA
Estrategias a partir del anlisis FODA
En relacin a las estrategias observamos que dicho documento incluye
acciones estratgicas de la USI directamente relacionadas con las estrategias
generales del Plan Estratgico de la SBEF. Sin embargo, los objetivos
definidos en el POA no reflejan tareas especficas, lo cual ocasiona que el
trabajo de seguimiento y evaluacin sobre el logro de los mismos, cuente un
grado de subjetividad.
Por otro lado, la falta de objetivos y tareas concretas en los POAs de las
intendencias, dificulta la definicin 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, estn alineadas con los objetivos
estratgicos definidos en el PES.
Ver detalle de acciones estratgicas 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 estndares, 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 especificacin
de los requerimientos a la Unidad de Sistemas de Informacin, 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 especficos son recibidos por la USI en forma posterior a la
definicin 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 peridicamente en la
intranet. Sin embargo, es importante controlar que la actualizacin de dicha
informacin 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 relacin directa con las
caractersticas 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 disposicin no es el
adecuado.
No se emiten informes especficos de seguimiento al POA de sistemas.
Procedimiento aplicado

4. Revisaremos los procedimientos aplicados para la evaluacin peridica de los

sistemas.
Resultados obtenidos
Como resultado de los procedimientos aplicados no encontramos evidencia
relacionada con la aplicacin de procedimientos peridicos formales,
orientados a medir el desempeo de los sistemas ni de los recursos
tecnolgicos de hardware.

60

Procedimiento aplicado
5. Evaluaremos los procedimientos establecidos para realizar estudios de
factibilidad y verificaremos el cumplimiento de los procedimientos de
adquisicin de bienes y servicios definidos SBEF.
Resultados obtenidos
Como resultado de los procedimientos aplicados no hemos identificado
evidencia de la aplicacin de procedimientos formalmente documentados
para realizar estudios de factibilidad de hardware ni de software.
En relacin a la adquisicin de bienes y servicios, observamos que se aplican
los procedimientos definidos por la Contralora General de la Nacin 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 porttiles
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 especficos de los proyectos.
Realizaremos pruebas sobre una muestra de proyectos de la USI, que nos
permitan verificar si los proyectos de sistemas son manejados segn los
procedimientos definidos.
Resultados obtenidos
Se adopt la metodologa del Reglamento especfico del sistema de
programacin de operaciones, la cual incluye informacin relacionada con:

Presupuesto de tiempo de las actividades

Requerimientos generales de las reas usuarias.
Sin embargo, el documento Plan Estratgico de la USI, no incluye los
aspectos especficos de un plan estratgico de Sistemas, el cual de acuerdo a
las mejores prcticas de la industria debera contemplar, entre otros, los
siguientes aspectos.

I.
II.
III.
IV.

Definicin de las necesidades de la organizacin y de informacin

Definicin de los objetivos tecnolgicos
Definir y seleccionar una estrategia de sistemas
Desarrollo del plan de implementacin de la estrategia de sistemas
En relacin a las pruebas realizadas para verificar el cumplimiento de los
procedimientos para la administracin de proyectos, estas fueron
documentadas en el punto 30, 32 y 33.
Procedimiento aplicado

7. Realizaremos una evaluacin general del ambiente de la Base de Datos

DBMS, revisando el ambiente de ejecucin 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 actualizacin de la Base de Datos y los procedimientos
aplicados para la recuperacin y respaldo de la misma.
Resultados obtenidos

Estructura de seguridad del sistema operativo:

Se revisaron los parmetros 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
revisin contemplo los siguientes aspectos:

62

Evaluacin de parmetros de usuarios.

Evaluacin de parmetros de grupos
Evaluacin de parmetros de directorios
Las observaciones que surgieron de la revisin de los parmetros 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 administracin de
passwords y el alta, baja y modificacin de usuarios. Estos aspectos se
encuentran detallados en el punto 41.
Los principales aspectos son los siguientes:

No existencia de polticas y normas formalmente establecidas y aprobadas

Administracin de passwords por parte del Administrador del Sistema
Generacin de passwords por parte de la USI mediante un programa
generador de claves
Existencia de autorizacin 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 renovacin automtica de claves
No existe la posibilidad de cambio de clave por parte del usuario, a excepcin
del sistema SIF.
Bloqueo de permiso de acceso luego de tres intentos fallidos. Habilitacin a
las 24 horas sin necesidad de requerimiento del usuario dueo de la cuenta.
Mantenimiento y actualizacin:
No existen procedimientos formales para el mantenimiento y actualizacin de
las bases de datos. Sin embargo, para la base de datos Informix se ejecuta
peridicamente el procedimiento update statistics, para la base de datos
SQL Server se monitorea peridicamente la cantidad de registros existentes y
su crecimiento.

Recuperacin y respaldo:
La recuperacin y respaldo de la informacin 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 bveda 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 bitcora de operacin para la obtencin 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 polticas, normas y procedimientos, para la

supervisin 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 estn 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 estn 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 tcnico
Encargado tcnico en comunicaciones
Operador de sistemas
Asimismo, observamos que el personal de sistemas est agrupado en las
siguientes categoras:
CATEGORIA
Jefe de Divisin B
SIB
S II A

CANTIDAD
DE
PERSONAL
1
1
3

%
42%

64

S
S
S
S

VA
VII C
VIII C
IX B

TIB
TIC
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 ms altos de la estructura. Asimismo,
observamos que las reas de desarrollo y produccin no estn
adecuadamente segregadas ya que los analistas/programadores tienen
acceso tanto a las herramientas de desarrollo, programas fuente, como a los
programas en produccin y datos en lnea.
Por otro lado, observamos que los manuales de funciones estn alineados
con los cargos actuales, excepto por la falta de la designacin formal de los
responsables de las reas de desarrollo y produccin. Asimismo, observamos
que no se ha definido formalmente la funcin de oficial de seguridad de los
sistemas.
Por todo lo mencionado anteriormente, consideramos que el organigrama no
refleja la estructura jerrquica real.
Adicionalmente, observamos que no se cuenta con la funcin de auditora de
sistemas, si bien esta funcin no forma parte de la estructura organizativa de
la USI, es recomendable la definicin de dicha funcin como parte de la
Unidad de auditora interna.
Por otro lado, observamos que si bien se ha definido la funcin de un comit
de sistemas, dicha instancia no ha mantenido regularidad en sus funciones,
debido principalmente por la falta de una planificacin 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 planificacin, decisin y supervisin de
los recursos IT (Tecnologa de la Informacin).
Asimismo, y en atencin a una expectativa manifestada por la Intendencia
General y la lder del equipo de contraparte, hemos realizado un anlisis de la
cantidad de personal en la USI, para lo cual se consideraron encuestas
internacionales realizadas durante el ao 2001, las cuales muestran
estadsticas porcentuales de la dotacin 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
informacin:

del

trabajo

realizado

Aspecto analizado
Porcentaje de personal en el
rea de sistema en relacin
al total de empleados de la
organizacin 1
Porcentaje de distribucin
de personal por tareas
Soporte/Mantenimiento
Produccin/Operaciones
Desarrollo
Administracin de los
sistemas
Otras tareas

hemos

obtenido

la

Mtrica
internacional
5.5 %

Situacin
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 mtrica por si sola,
no proporciona una visin completa, por lo que es necesario considerar
adicionalmente, aspectos tales como:

Presupuesto de sistemas como porcentaje del total presupuestado.

Presupuesto de tecnologa por empleado.
Costo tecnolgico por usuario.
Costo de operacin de los sistemas.
Inversiones tecnolgicas.
Costo de mantenimiento de los sistemas.
Costo del personal de sistemas.
Aspecto analizado
Porcentaje del presupuesto
tecnologa
con
relacin
presupuesto total.

de
al

Mtrica
internacio
nal
6.08 %

Situacin
actual
7.2 %

66

Porcentaje de gastos de tecnologa

por tipo de recurso.
Costo de personal
Costo de Hardware
Costo de Software
Costo de proveedores externos
Costo de comunicaciones de
voz
Costo de comunicacin 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 informacin

disponible no cuenta con el nivel de desagregacin necesaria.
Procedimientos aplicado
10. Verificaremos los procedimientos aplicados para supervisar los trabajos en
ejecucin, as como la utilizacin de los recursos de manera apropiada.
Resultados obtenidos
Como resultado del trabajo realizado observamos que no existen
procedimientos formales para supervisar los trabajos en ejecucin, sean
estos de desarrollo, modificacin 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 estndar para la
supervisin de los trabajos en ejecucin, 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 realizacin de
sus funciones, a travs de un anlisis de cumplimiento de los requerimientos
definidos en los perfiles de cargo, para lo cual tomaremos como base la
currcula 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 formacin formal
excede a los requerimientos del perfil de cargo definido ya que los mismos
cuentan con maestra).
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 estn relacionados con la formacin
acadmica y experiencia.
A continuacin 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 Tcnico 0
Encargado de Soporte Tcnico 0
de Comunicaciones
Operador
67
PROMEDIO
48,6

Formacin
Complementa
ria
100
81
100
100

Experien Ingls
cia
tcnic
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
estn especializados en las aplicaciones que estn a su cargo y en caso de
vacacin 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 Informacin
Riesgo crediticio
Sistema
de
Informacin
Financiera
Sistema de Acuotaciones
Clausura y Rehabilitacin de
Cuentas Corrientes
Operaciones Interbancarias
Bolsn Unix
Bolsn SQL
Evolutivo
Central de Informacin de
Riesgo crediticio Microcrdito
Sistema
de
Apoyo
a
Supervisin
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 asignacin de
passwords
Entidades
Financieras
Informe confidencial
Boletn CIRC
Sistema de asignacin 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

Como se puede observar en el cuadro existen cuatro personas que tienen

asignado la responsabilidad de tres o ms sistemas, entre los cuales se
encuentran los ms importantes para la operacin de la Superintendencia.
Tareas Adicionales Propuestas

69

Procedimiento aplicado
13.

Realizaremos una evaluacin general de todas las funciones existentes en

la USI y no solamente las requeridas en el punto 9.
Evaluaremos el perfil psicolgico a travs de pruebas generales
psicosomtricas orientadas a evaluar: inteligencia, habilidad verbal, habilidad
numrica, habilidad espacial, nivel de concentracin y atencin, resolucin de
problemas simples y complejos, rasgos de personalidad.
Resultados Obtenidos
Como resultado de las pruebas psicosomtricas, aplicadas al personal de la
USI, obtuvimos los siguientes resultados generales:
Aspecto evaluado
Capacidad intelectual
Trabajo bajo presin
Razonamiento verbal

Razonamiento espacial
Razonamiento numrico

Resolucin
simples

de

problemas

Atencin a los detalles

Resolucin
complejos

de

Concentracin

problemas

Resultado obtenido
Nivel de inteligencia general
superior
a
los
parmetros
normales
Desempeo bajo presin dentro de
los parmetros normales
Adecuados
niveles
de
razonamiento verbal, los cuales
muestran
ser
ligeramente
superiores a los normales
Razonamiento espacial entro de
los parmetros normales.
Adecuados
niveles
de
razonamiento numrico, los cueles
muestran
estar
ligeramente
superiores
a
los
parmetros
normales.
Capacidad
de
resolucin
de
problemas simples dentro de los
parmetros normales.
Capacidad de atencin a detalles
dentro
de
los
parmetros
normales.
Capacidad
de
resolucin
de
problemas complejos dentro de los
niveles normales.
Niveles de concentracin 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

Resolucin de

Atencin a

Resolucin de

Intelectual

P resin

Verbal

Espacial

Numrico

P roblemas

Detalles

P roblemas

Simples

Concentracin

Complejos

Como se puede observar en el grfico la capacidad intelectual es el

parmetro evaluado con mayor puntaje y no existe ningn aspecto que se
encuentre por debajo de los parmetros normales.
Procedimiento aplicado
14.

Verificaremos los procedimientos aplicados para el seguimiento al

presupuesto anual de tecnologa, y los procedimientos para el monitoreo del
costo y del beneficio. Asimismo, verificaremos el cumplimiento de los
procedimientos de adquisicin de bienes y servicios definidos.
No emitiremos una opinin en relacin 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 peridico al presupuesto anual de tecnologa ni se
monitorea la relacin 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
porttiles
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 recepcin
definitivo y el informe
al UEP, estn en
proceso.
70,854,4 10,122,07 El acta de recepcin
8
definitivo y el informe

71

al UEP,
proceso.

estn

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 participacin de la Unidad de Sistemas, tales como:

Sistema CIRC de Microcrdito

A de Juan
Spyral

15. Para la evaluacin de la administracin del rea, se aplicaron los siguientes

procedimientos:
Para la evaluacin de la administracin del rea, se aplicaron los siguientes
procedimientos:
Procedimiento aplicado
16. Verificaremos si las polticas y normas de seguridad establecidas por la USI
estn claramente definidas, documentadas y aprobadas.
Verificaremos si las polticas y normas son peridicamente revisadas y
actualizadas.
Verificaremos que las funciones y responsabilidades del rea de
Administracin de la Seguridad de los Sistemas de Informacin se encuentran
formalmente definidas y documentadas.
Resultados obtenidos
Como resultado de los procedimientos aplicados observamos que se cuenta
con normas para seguridad como ser: obtencin de copias de respaldo,
proteccin contra virus, control de ingreso al rea de sistemas, control de
ingreso para limpieza, uso de software, actualizacin de passwords, y otros.
Sin embargo, de acuerdo con las mejores prcticas no se cuenta con la
totalidad de las normas que se consideran mnimas necesarias para la
administracin de la seguridad.
Este aspecto est ms ampliamente evaluado en el punto 40.
Procedimiento aplicado
17. Verificaremos la existencia de polticas 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 ningn tipo de clusula especfica orientada
a proteger los derechos de propiedad intelectual de la SBEF.
Procedimiento aplicado
18. Verificaremos la existencia de polticas referentes a la administracin del
personal, para lo cual revisaremos la existencia de:

Polticas formales para la contratacin 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 contratacin 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 capacitacin el cual es
preparado a inicios de ao con la colaboracin del rea de RRHH quin es
responsable por la planificacin y seguimiento de los mismos.
Procedimiento aplicado

19. Verificaremos la existencia de un plan de capacitacin que est formalmente

definido y presupuestado.
Resultados obtenidos
Como resultado de las pruebas realizadas obtuvimos los siguientes resultados

Curso Planificado
Realizado
Programacin en tres capas
0
Generalidades sobre supervisin de entidades Financieras 1 0
Programacin avanzada en Lotus Notes
1

73

Programacin avanzada en SQL

Curso avanzado de CISCO
Programa de Post Grado
Ingls

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 sera de 62,5%.
Procedimiento aplicado
20. Que existan planes de capacitacin adecuados para el personal de la USI.
Resultados obtenidos
El plan de capacitacin definido para la Unidad de Sistemas, muestra en
forma general los cursos que deben ser realizados durante la gestin. Sin
embargo, no especifica quienes sern las personas que debern participar en
los mismos.
Tareas Adicionales Propuestas
Procedimiento aplicado
21. Verificaremos el cumplimiento del plan de capacitacin definido por la USI.
Resultados obtenidos
El nivel de cumplimiento del plan de capacitacin muestra que, a la fecha de
revisin, se ejecut el 62,5% de los cursos definidos en el plan de
capacitacin, quedando an pendiente los siguientes cursos:
1. Programacin avanzada en SQL
2. Programacin en tres capas
3. Generalidades sobre supervisin de entidades Financieras

Procedimiento aplicado
22. Verificaremos los procedimientos que son aplicados para la evaluacin de
riesgos.
Resultados obtenidos

74

Como resultado de los procedimientos aplicados, observamos que no se

cuenta con normas ni procedimientos establecidos para la administracin de
riesgos. Sin embargo, es importante hacer las siguientes consideraciones:
Las mejores prcticas 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 relacin a este aspecto, las mejores prcticas indican que las
metodologas de anlisis de riesgos consideran como una de las primeras
actividades la clasificacin de los activos que deben ser protegidos, entre los
que normalmente son considerados los siguientes:

Informacin 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 anlisis de riesgos, la USI
aplica procedimientos que estn orientados a minimizar riesgos asociados a
algunos de los aspectos anteriormente mencionados, como ser:
Acciones que son aplicadas
Obtencin de copias de respaldo
Se cuenta con mantenimiento preventivo
y convenios de plizas de seguro
Existen normas para la aplicacin y uso
de antivirus, uso de software no
autorizado y otros
Existen normas claras para reclutamiento
de personal, evaluaciones peridicas y
planes de capacitacin.

Area
de
riesgo
asociada
Informacin y datos
Hardware
Software
Recursos Humanos

Procedimiento aplicado
23. Verificaremos la existencia
administracin de:

de

normas

procedimientos

para

la

75

La tecnologa del proyecto

Los tiempos y cronogramas de trabajo, contemplando:
Organizacin del proyecto
Ciclo de vida del proyecto
Estrategia del proyecto
Planificacin
El presupuesto
Los proveedores externos
La migracin e implantacin de los sistemas
Resultados obtenidos
Como resultado de los procedimientos aplicados observamos que no existen
normas ni procedimientos formales para la administracin de proyectos.

24. Para la administracin

procedimientos:

de

la

calidad,

se

aplicaron

los

siguientes

Procedimiento aplicado
25. Verificaremos la existencia normas y procedimientos para la administracin
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 Informacin no aplica procedimientos para la administracin 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 estndares de calidad.
Resultados obtenidos
Como fue mencionado anteriormente, no se aplican procedimientos
especficos para medir la calidad de los servicios ni de los sistemas en
produccin. Sin embargo, de acuerdo a la encuesta realizada respecto a la
calidad del servicio que ofrece la USI, obtuvimos los siguientes resultados:

76

Supervisin
Bancaria
Supervisin
No Bancaria
Asuntos
Jurdicos
Estudios
y
Normas

Bueno

Bueno

Entre Bueno y 2
Muy Bueno
Regular
6

Excelente

Muy bueno

Bueno

Regular

Cant.

Deficiente

Percepcin
promedio

Malo

Intendencia

1
3

Asimismo, se pudo determinar la percepcin de los usuarios en relacin a las

fortalezas y debilidades de la USI, entre las que podemos mencionar:
Fortalezas
Personal capacitado
Equipamiento de computacin
adecuado

Debilidades
Desorganizacin
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
documentacin 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
documentacin de las mismas.
Las normas consideran lo siguiente:

Anlisis y Diseo de sistemas

Diseo de las estructuras de datos
Diccionario de datos
Elaboracin de manuales de programacin, tcnico, 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 aplicacin de procedimientos para generar reportes en base
a las mtricas definidas en el plan de calidad.
Resultados obtenidos
Como fue mencionado anteriormente, la USI no aplica procedimientos para la
medicin 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 grfico muestra el nivel de utilidad de las aplicaciones para el
negocio (eje y) y la calidad tcnica de los sistemas (eje x).

9 219

10

11

18
5
4

13

17

23

14

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 icrocrdito

10.

Apoyo a Supervisin

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 tcnica, de acuerdo a las
mejores prcticas se debera 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 tcnica, de acuerdo a las
mejores prcticas estas aplicaciones deberan ser replanteados.
El cuadrante superior izquierdo muestra las aplicaciones que tienen un alto
nivel de utilidad en el negocio y una baja calidad tcnica, de acuerdo a las
mejores prcticas estas aplicaciones deberan 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 tcnica, de acuerdo a las
mejores prcticas estas aplicaciones deberan 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 Informacin de Riesgo crediticio
Sistema de Informacin Financiera
Sistema de Acuotaciones
Sistema de Clausura y Rehabilitacin de Cuentas Corrientes
Operaciones Interbancarias
Bolsn Unix
Bolsn SQL
Evolutivo
Central de Informacin de Riesgo crediticio Microcrdito
Sistema de Apoyo a Supervisin
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 aplicacin de una metodologa adecuada para el desarrollo,
adquisicin y mantenimiento de sistemas, as como el cumplimiento o
implementacin de polticas y estndares vigentes. En las pruebas a realizar
se debe considerar la verificacin de:
Procedimiento aplicado
30. Verificaremos que existan procedimientos formalmente establecidos para:

La iniciacin de proyectos
Evaluaremos que existan procedimientos para realizar estudios de factibilidad
y evaluar alternativas de solucin.

Documentacin del anlisis y diseo del sistema

Construccin

79

Estructura de la Base de Datos

Especificaciones de programas
Codificacin y pruebas
Controles de seguridad
Diseo de pistas de auditora
Definicin de estrategias de adquisicin
Implantacin
Documentacin de usuario
Documentacin de operacin del sistema
Entrenamiento
Implantacin en el ambiente de produccin
Realizaremos pruebas sobre una muestra de proyectos, que nos permita
verificar si los mismos son realizados segn los procedimientos definidos.
Resultados obtenidos
No existen procedimientos formalmente establecidos para la iniciacin de
proyectos, que definan el tipo de documentacin que se debe elaborar. Sin
embargo, durante nuestra revisin encontramos que se ha elaborado
documentacin de inicio de proyecto para los siguientes sistemas:

CIRC
SIF
Acuotaciones
CIRC Microcrdito
Sistema de Control de Almacenes
La documentacin de inicio de proyecto que se ha elaborado para los
proyectos de Informtica mencionados contempla:

Especificaciones tcnicas del proyecto de sistemas a ser elaborado

Contratos de desarrollo de sistemas
No existen procedimientos formalmente establecidos para la elaboracin de
Estudios de Factibilidad que permitan la evaluacin de la solucin planteada
ni para el planteamiento de soluciones alternativas. Sin embargo, existe
documentacin relacionada a estudios de factibilidad para los siguientes
proyectos de sistemas:

CIRC
SIF
Sistema de Control de almacenes

80

La documentacin de estudio de factibilidad que se elabora para los

proyectos de Informtica no contempla:

Estimacin de costos operativos

Descripcin de alternativas que incluyan:
Descripciones tcnicas
Anlisis costo/beneficio
Existen lineamientos establecidos que definen formalmente el tipo de
documentacin que se debe elaborar durante las etapas de anlisis y diseo
de sistemas, los estndares de diseo y desarrollo se basan en la
Metodologa Estructurada de GaneSarson (la cual indica que un proyecto
debe considerar las etapas de anlisis, diseo y construccin, asimismo, est
orientada a la implementacin de los programas en forma estructurada y
muchos autores se refieren a esta como metodologa tradicional). Durante
nuestra revisin se encontr documentacin del anlisis y diseo de los
sistemas, para los siguientes proyectos desarrollados por la USI:

CIRC
SIF
Acuotaciones
CIRC Microcrdito
Sistema de Control de Almacenes
Es importante mencionar que dicha informacin, para mantenerse
actualizada, depende en gran medida de la existencia y cumplimiento de las
normas definidas para los cambios a los programas. Estos aspectos estn
detallados en el punto 34.
La documentacin de anlisis y diseo de sistemas que elabora la USI para
los proyectos de Informtica contempla:

Manual de Anlisis y Diseo

Manual de Programacin
Manual Tcnico
Existen lineamientos establecidos que definen formalmente el tipo de
documentacin que se debe elaborar para la etapa de construccin de
sistemas. Durante nuestra revisin se encontr documentacin de la
construccin de los sistemas, para los siguientes proyectos desarrollados por
la USI:

CIRC
SIF
Acuotaciones

81

CIRC Microcrdito
Sistema de Control de Almacenes
La documentacin relacionada a la construccin de sistemas que se elabora
para los proyectos de Informticos contempla:

Estructura de la Base de Datos (diagramas Entidad - Relacin), normalizados

hasta la 3ra forma.
Especificaciones de programas y de las interfaces de entrada y salida de
datos
La adquisicin de Sistemas de Software especializados se realiza a travs de
la elaboracin de requerimientos funcionales y especificaciones tcnicas 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 tcnicos son preseleccionados para una segunda instancia,
donde se evala el precio propuesto y se adjudica el proyecto al proveedor
que haya obtenido mayor puntaje.
Existen lineamientos establecidos que definen formalmente el tipo de
documentacin que se debe elaborar para la etapa de implantacin de
sistemas. Durante nuestra revisin se encontr documentacin de la
construccin de los sistemas, para los siguientes proyectos desarrollados por
la USI:

CIRC
SIF
Acuotaciones
CIRC Microcrdito
Sistema de Control de Almacenes
La documentacin relacionada a la construccin de sistemas que se elabora
para los proyectos de Informticos contempla:

Manual del Usuario

Manual de Operaciones
Adicionalmente, durante nuestra revisin slo encontramos material de
entrenamiento para el Sistema CIRC (Central de Informacin de Riesgo
Crediticio).
No existen procedimientos establecidos que definan como llevar a cabo
formalmente la implantacin de los sistemas, tampoco se ha definido la
documentacin que se debe elaborar durante este proceso. Durante nuestra
revisin no encontramos documentacin formal que respalde las tareas de
implantacin de los proyectos para ninguno de los proyectos evaluados.

82

Procedimiento aplicado
31.

Verificaremos los procedimientos aplicados para: verificar los mtodos de

diseo, aprobacin del diseo, definicin de la estrategia de adquisicin,
documentacin de los requerimientos, especificaciones, pruebas del software
de aplicacin, 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 segn los procedimientos definidos.
Resultados obtenidos
No existen procedimientos formales para verificar los mtodos de diseo,
aprobacin del diseo, definicin documentacin de los requerimientos,
especificaciones, pruebas del software de aplicacin, 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 documentacin existente vara segn el proyecto.
Procedimiento aplicado

32. Revisaremos, para una muestra, la aplicacin de procedimientos para:

La evaluacin de hardware y software nuevos.

El mantenimiento preventivo de hardware.
La seguridad del software del sistema.
La instalacin y mantenimiento del software del sistema.
Resultados obtenidos
La adquisicin de equipos se realiza en funcin a las normas SABS (Sistema
de Adquisicin 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 adquisicin de equipos de
computacin se realiza con fondos de terceros como el BID (Banco
Interamericano de Desarrollo) o BM (Banco Mundial) motivo por el cual
adems de cumplir con las normas bsicas de la SABS se debe cumplir con
los requerimientos de las entidades financiadoras. Sin embargo, no existen
procedimientos formales para la evaluacin 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 podran ser adquiridos, la

adjudicacin de compra de hardware o software se basa en el cumplimiento
de las especificaciones tcnicas y en el precio de la propuesta econmica.
Una de las especificaciones para la compra de equipos de hardware es que
exista una garanta de 3 aos para los equipos, luego de ese periodo se
procede a realizar contratos de mantenimiento preventivo para los equipos.
No existen procedimientos formales para la administracin 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 instalacin de los sistemas de
software desarrollados por la USI, no se cuenta con procedimientos formales
para la aceptacin del sistema, procedimientos para el pase a produccin ni
procedimientos para la custodia de cdigos fuente. Existen lineamientos
generales para la administracin de los cambios a los programas y la
realizacin del mantenimiento a los sistemas. Sin embargo, no se cuenta con
procedimientos formales para la ejecucin de pruebas a las modificaciones ni
para la aceptacin formal de los cambios realizados.
Documentacin/Sis
tema

CIRC

Evaluacin
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
Microcrd
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 aplicacin de procedimientos y

estndares de tecnologa informtica para:
El manual de procedimientos del usuario
El manual de operaciones

84

La capacitacin
El ajuste de desempeo
La conversin
Las pruebas de los cambios
Criterios y desempeo de las pruebas paralelas/piloto
Las pruebas de aceptacin final
La acreditacin y pruebas de seguridad
Las pruebas operativas
La evaluacin del cumplimiento de los requerimientos del usuario
La revisin administrativa post implementacin
Resultados obtenidos
Los proyectos de sistemas cuentan con documentacin de manual de
usuario, la cual detalla las caractersticas funcionales de los sistemas, se
cuenta con un manual de operacin que describe procedimientos adicionales
que son realizados por el personal de sistemas.
Como se puede apreciar en el cuadro adjunto, no existe documentacin para
la capacitacin del personal operativo, este tipo de documentacin debera
incluir manuales de instructor y manual de instruccin para el participante.
Sin embargo, durante los cursos de induccin que la SBEF dicta a sus
empleados se muestra de manera general el funcionamiento de algunos de
los sistemas.
No existe documentacin de ajustes de desempeo realizados a los sistemas
operativos, bases de datos u otros relacionados con los sistemas evaluados
(ver cuadro adjunto).
De la documentacin evaluada, ninguno de los sistemas tuvo un proceso de
conversin de datos, motivo por el cual este punto no fue aplicable.
La documentacin 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 documentacin de pruebas piloto o paralelas realizadas para todos
los sistemas evaluados. Sin embargo, generalmente se realizan pruebas
paralelas antes de realizar el pase a produccin de cualquier sistema (ver
cuadro adjunto).
Se cuenta con formularios de aceptacin 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 acreditacin ni pruebas de seguridad para los

sistemas (Ver cuadro adjunto). No se realizan pruebas de seguridad para el
sistema operativo, base de datos ni aplicacin.
Se realizan pruebas a los manuales de operacin. Sin embargo, no existe
documentacin de las pruebas realizadas a los procedimientos descritos en
los manuales de operacin de los sistemas.
Durante la realizacin de pruebas, los usuarios finales de cada uno de los
sistemas participan para evaluar el cumplimiento de los requerimientos del
sistema en cuestin por lo que la aceptacin formal de los sistemas slo
ocurre despus de que los sistemas cumplen con los requerimientos definidos
por el rea usuaria.
No se realizan revisiones post implementacin de los sistemas.
Documentacin/Sistema

CIRC

SIF

Acuotaci
ones

CIRC
Microcrd
ito

Sistema
de
Almacene
s

Manual
de
procedimientos
del
usuario
Manual de operaciones
Documentacin
de
capacitacin
Documentacin
de
ajustes de desempeo
Documentacin
de
conversin 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

Documentacin
de
pruebas a los cambios
Documentacin de las
pruebas paralelas/piloto
Aceptacin final de las
pruebas
Acreditacin y pruebas
de seguridad en los
sistemas
Documentacin
de
pruebas operativas
Evaluacin
de
cumplimiento
de
los
requerimientos
del
usuario
Revisin de controles

86

Documentacin/Sistema

CIRC

SIF

Acuotaci
ones

CIRC
Microcrd
ito

Sistema
de
Almacene
s

post implantacin

existe

existe

existe

existe

existe

Procedimiento aplicado
34.

Verificaremos la existencia de normas y procedimientos que permitan

controlar las actividades relacionadas a la administracin de cambios. Para lo
cual verificaremos la existencia de procedimientos para:
El inicio del cambio
La evaluacin de riesgo
La priorizacin de los cambios
Pruebas a los cambios
Documentacin de los cambios
Aprobacin y rechazo de los cambios
Implantacin 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 documentacin de respaldo para los cambios realizados.
No se realiza un evaluacin de riesgo sobre los requerimientos de cambios a
los programas. Sin embargo, para los sistemas de Acuotaciones, CIRC
Microcrdito 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 excepcin del sistema SIF donde los cambios no afectaron la
documentacin del sistema, los dems sistemas cuentan con documentacin
actualizada de los cambios realizados.

87

Aprobacin y rechazo
Para la tarea de implantacin de los cambios para los sistemas CIRC, SIF y
Acuotaciones, no existe la documentacin 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
implantacin.
Todos los cambios realizados se entregan a travs 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 documentacin.
Adicionalmente, en sistemas ms complejos como el CIRC y el SIF existen
informes a la gerencia que se elaboraron durante el transcurso de proyecto.

Documentacin/Sistema

CIRC

SIF

Acuotacio
nes

CIRC
Microcrd
ito

Sistema
de
Almacene
s

El inicio del cambio

La evaluacin 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 priorizacin de los No
cambios
Aplicabl
e
Pruebas a los cambios
No
existe
Documentacin de los Existe
cambios
Aprobacin y rechazo Existe
de los cambios
Implantacin 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 estndares
implementados para la operacin de los sistemas en explotacin y la
administracin de los recursos tecnolgicos. En las pruebas a realizar se debe
considerar la verificacin de:
Procedimiento aplicado
36.

Verificaremos la existencia de acuerdos de nivel de servicio para

administrar la relacin entre el rea de sistemas y los usuarios. Para lo cual
revisaremos que los mismos contemplen:
Definicin de servicios a ser brindados
Mtricas de nivel de servicio
Definicin 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, mtricas 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 administracin 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 envan diaria y mensualmente datos para los sistemas SIF y CIRC

89

respectivamente, para lo cual se cuenta con una estructura de comunicacin

de lneas dedicadas y dial-up. Las entidades financieras cuentan con
programas proporcionados por la SBEF que se encargan de realizar
validaciones de la informacin antes del envo, existe un programa de
comunicacin 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 informacin. (Ver detalle en
el punto 57)
Todos los requerimientos de terceros hacia la USI son realizados a travs 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 elaboracin. La Unidad de Sistemas realiza un anlisis del
requerimiento y evala la factibilidad del requerimiento (pueden plantearse
soluciones alternativas), procede a elaborar el requerimiento y entrega el
mismo a la entidad solicitante.
La administracin 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 especficos para mantener la continuidad de los
servicios a terceros, los servicios a terceros brindados por la SBEF se refieren
a generacin 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 envo de informacin, las entidades
financieras pueden realizar consultas telefnicas al personal de la USI. Para la
generacin de informacin para entidades gubernamentales, no existe
ningn tipo de procedimiento formal, ya que la administracin del
requerimiento no recae en la USI.
Asimismo, observamos que de acuerdo a la circular normativa N 363 y a la
implementacin del sistema de difusin de normativa y consultas, las
consultas telefnicas realizadas por las entidades financieras terceros,
estn prohibidas.
Adicionalmente, podemos mencionar que el personal de la USI, monitorea y
controla aspectos referidos a las estructuras tecnolgicas responsables de
brindar el servicio a terceros (redes de comunicaciones, hardware, etc.).

90

Procedimiento aplicado
38. Verificaremos, a travs de una muestra, los procedimientos aplicados para la
administracin del desempeo y la capacidad del hardware, verificando la
existencia de:

Requerimientos de disponibilidad y desempeo

Plan de disponibilidad
Monitoreo y reportes
Herramientas de modelaje
Administracin proactiva del desempeo
Administracin de la carga de trabajo y la capacidad
Disponibilidad y programacin de recursos
Resultados obtenidos

No existen procedimientos formales para la administracin del desempeo

del hardware:
No se han identificado necesidades mnimas del negocio respecto a la
disponibilidad de los servicios de informacin.
No se han definido requerimientos mnimos en funcin a las necesidades.
No existe un plan de disponibilidad
No existen procedimientos de monitoreo ni de generacin 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 anlisis de requerimientos de capacidad
de almacenamiento para los sistemas CIRC y SIF en funcin de un anlisis 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 informacin 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 anlisis 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 produccin mantienen
informacin histrica en lnea, solamente de la ltima gestin y de acuerdo a
los resultados de las indagaciones realizadas a travs de las encuestas
observamos que sera recomendable mantener una mayor cantidad de
informacin histrica en lnea, lo cual implica que sera necesario ampliar la
capacidad actual de almacenamiento (espacio en disco).

91

Por otro lado, dicha ampliacin permitira una mejor utilizacin 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 anlisis de performance de los
servidores para evaluar su posible ampliacin.
Procedimiento aplicado
39. Evaluaremos las normas y procedimientos para la administracin de
contingencias, considerando:
El marco referencial, mencionando el propsito 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
despus de ocurrido el desastre.
Los procedimientos detallados para la recuperacin de las operaciones
crticas de la organizacin.
La descripcin de responsabilidades, composicin de equipos de trabajo y
tareas de recuperacin.
La descripcin de responsabilidades e identificacin del personal clave para
cada uno de los departamentos crticos.
La informacin acerca de las medidas de prevencin de desastres
implantadas y su utilizacin.
La informacin sobre convenios para la recuperacin de desastres.
Los anexos conteniendo: Inventarios, listas de contactos, mapas, diagramas y
dems informacin detallada.
Los procedimientos aplicados para el mantenimiento, pruebas y distribucin
del plan de contingencias.
Los procedimientos aplicados para la capacitacin del personal respecto al
plan de contingencias.
Verificaremos la existencia de acuerdos y plizas de seguros que tengan por
objetivo la proteccin de los bienes tecnolgicos.
Verificaremos la aplicacin de procedimientos para la proteccin de bienes
tecnolgicos en el rea de sistemas.
Verificaremos la aplicacin 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 despus de
ocurrida una contingencia.

92

Debido a que el Plan de Contingencias de la SBEF slo considera aspectos de

sistemas, no se han definido las operaciones crticas para la organizacin, por
lo que no existen procedimientos para recuperar las funciones crticas de
negocio.
No existe una lista del personal clave para cada uno de los departamento
existentes, slo 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 recuperacin detalladas para los distintos sistemas, en
distintas situaciones y grados de contingencia.
Se ha definido quienes deben intervenir en la recuperacin de los sistemas,
pero no existe una descripcin 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 participarn en la recuperacin del negocio.
Aparte de las medidas de seguridad fsica, no existen medidas para la
prevencin de desastres. No se han definido las medidas mnimas de
seguridad para la operacin de los sistemas en una contingencia.
No existen convenios para la recuperacin de desastres.
En el plan de contingencias no existe informacin detallada ni hace referencia
a: Inventario de equipos u otros recursos tecnolgicos, mapas de la
edificacin, inventario de recursos mnimos 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 distribucin del plan
de contingencias, las pruebas al plan de contingencias no cuentan con
caractersticas mnimas que permitan validar el plan de contingencias.
No existen procedimientos formales que permitan la capacitacin del
personal en los procedimientos definidos en el Plan de Contingencias.
La SBEF cuenta con plizas de seguros que tienen como objetivo la
proteccin de los bienes tecnolgicos.
Se cuenta con acceso restringido al rea de produccin y tambin al Centro
de Cmputo, ambos mediante llave de proximidad y clave personal. Estas
llaves slo 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,
caractersticas y motivo por el cual es retirado, si es el caso. Adicionalmente,

93

el momento que un equipo de computacin ingresa o es retirado de la

Superintendencia, el guardia de la entrada registra el cdigo del equipo.
40. Seguridad de los sistemas
Procedimiento aplicado
41. Evaluaremos
contraseas.

los

mecanismos

utilizados

para

la

administracin

de

Resultados obtenidos
No se cuenta con polticas ni normas formalmente establecidas para realizar
la administracin de contraseas, excepto por la existencia de normas para la
actualizacin de contraseas que considera el cambio por parte de la USI de
todas las contraseas de la SBEF cada 120 das (las cuales no son aplicadas).
El trabajo es realizado por el administrador siguiendo lo detallado a
continuacin:

Administrador recibe la comunicacin interna

Habilitacin de cuenta de acceso al dominio (red)
Habilitacin 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
electrnico 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
nmeros y el ltimo es un carcter especial (#, $, etc.)
Los usuarios no pueden cambiar el password asignado por la USI (slo es
posible en el sistema SIF). Los sistemas no obligan a realizar el cambio
peridico de passwords.
Ninguno de los sistemas actualmente en produccin controla caractersticas
de los passwords como ser:

94

Guardar los ltimos tres passwords

Repeticin de caracteres iguales en el password
Control de passwords cclicos
Procedimiento aplicado

Evaluaremos los procedimientos de alta, baja y modificacin 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 informacin:

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 electrnico (e-mail) y acceso a los sistemas con los cuales tenga que
trabajar el usuario.
Cuando se requiere realizar algn 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 enva 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 fsicamente al usuario de la red. En el sistema
queda el UserId del usuario (se lo elimina slo lgicamente).

Procedimiento aplicado
42. Evaluaremos, para los usuarios del rea de sistemas, si los mismos tienen
acceso a datos en lnea
Resultados obtenidos
Los desarrolladores que realizan modificaciones especialmente a los sistemas
CIRC y SIF cuentan con acceso a los datos de produccin 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 lnea.
Procedimiento aplicado
43. Evaluaremos los procedimientos de alta, baja y modificacin de usuarios.
Resultados obtenidos
Los procedimientos para el alta, baja y modificacin de usuarios se encuentra
detallada en el punto 41.
Como se haba mencionado, los principales aspectos son:

No existencia de polticas y normas formalmente establecidas y aprobadas

Administracin de passwords por parte del Administrador del Sistema
Generacin de passwords por parte de la USI mediante un programa
generador de claves
Existencia de autorizacin 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 revisin realizada obtuvimos los siguientes resultados:
Los resultados fueron los siguientes:

4 usuarios de la gestin 2001 cuentan con la autorizacin respectiva

1 usuario de la gestin 2001 no cuenta con la autorizacin y 10 usuarios de
las gestiones 2000, 1995, 1994, 1992 y 1988 no cuentan con la autorizacin
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 clasificacin de datos.
Resultados obtenidos
Como resultado de los procedimientos aplicados, observamos que no se
cuenta con normas ni procedimientos para la clasificacin de datos.
Normas internacionales de seguridad mencionan que los datos deberan ser
separados en cuatro clases con requerimientos separados de manipulacin:
Secretos, Confidenciales, Privados y No Clasificados. Esta clasificacin
estndar de datos debera 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.
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 clasificacin de datos no
fue posible aplicar este procedimiento.

97

Procedimiento aplicado
45. Revisaremos las normas y procedimientos para la emisin de reportes de
violacin y actividades de seguridad.
Resultados obtenidos
La pgina web de la SBEF no se encuentra publicada en un servidor que se
encuentra en el Centro de Cmputo. Se utiliza para ello un servidor de Entel.
En vista que no se tiene conexin entre la pgina web y la red interna de la
SBEF no es posible que se tengan intentos de violacin a la informacin de la
SBEF por ese medio.
Por tanto, no se tienen reportes de violacin en el rea de produccin.
Los intentos de violacin a la informacin de la Superintendencia desde la red
de la SBEF no cuentan con un registro, reporte ni revisin, para la resolucin
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 violacin, 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 clasificacin
(importantes, menores, etc.)

de

los

problemas

presentados.

Existe, hace aproximadamente dos meses, una planilla Excel (bitcora) en la

cual se registran todos los problemas presentados y la solucin dada. Esta
planilla es llenada por cada uno de los operadores, la cual no es consolidada
por el momento, se planifica realizar una consolidacin a fin de mes para
emitir estadsticas de los problemas presentados, usuarios que ms soporte
requieren y los problemas ms importantes para darles una solucin

98

definitiva. Sin embargo, dicha planilla an 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 evala actualmente un software de Help
Desk que permita administrar todos los requerimientos usuarios, adems que
cuente con un inventario de equipos con el software instalado en los mismos,
se pueda realizar asignacin 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 das, las planillas llenadas por los operadores.
En base a la revisin de nueve das para los operadores de produccin, 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 administracin 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
administracin de cuentas de los usuarios normales (punto 41).
Como se haba mencionado, los principales aspectos son:

No existencia de polticas y normas formalmente establecidas y aprobadas

Administracin de passwords por parte del Administrador del Sistema
Generacin de passwords por parte de la USI mediante un programa
generador de claves
Existencia de autorizacin 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 produccin, el ltimo es un usuario de desarrollo
que cuenta con este acceso provisionalmente para realizar algn trabajo
especfico.
Procedimiento aplicado
48. Evaluaremos
contraseas.

los

mecanismos

utilizados

para

la

administracin

de

Resultados obtenidos
Los procedimientos para la administracin de contraseas se encuentra
detallada en el punto 41.
Como se haba mencionado, los principales aspectos son:

No existen actualmente normas y procedimientos formalmente establecidas y

aprobadas
Administracin de passwords por parte del Administrador del Sistema
Generacin 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 renovacin automtica de claves
No existe la posibilidad de cambio de clave por parte del usuario, a excepcin
del sistema SIF.
Procedimiento aplicado

49. Revisaremos las normas y procedimientos aplicados para la prevencin,

deteccin y correccin 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
tecnologa de informacin, 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 actualizacin del antivirus se realiza en lnea cada vez que el proveedor
actualiza la versin.
Toda la informacin que llega a la SBEF es revisada mediante el antivirus.
Todas las comunicaciones que llegan va e-mail al personal de la SBEF sufre
un proceso de revisin automtica. En caso de encontrarse virus, el antivirus
limpia el virus y enva un mensaje al administrador del sistema, en caso que
no pueda limpiar el virus, borra el mail y enva 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 estadsticos acerca de los
virus encontrados y los funcionarios que ms virus recibieron.
Peridicamente se emiten comunicaciones de precaucin con algunos
menajes (e-mail) que son enviados conteniendo algn virus. Esta informacin
es recabada en base a suscripciones a CNN tecnologa y la pgina de Trends
(proveedor de antivirus).
Existe la norma que indica cul 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 sealan que es necesario establecer
procedimientos para un adecuado control preventivo, detectivo y correctivo
adems del aviso y reporte de su ocurrencia. La gerencia de sistemas, debe
asegurarse que los procedimientos han sido establecidos para proteger la
informacin de virus informticos.
Procedimiento aplicado

Verificaremos, para una muestra, el cumplimiento de las normas y

procedimientos definidos.
Resultados obtenidos
Para una muestra de diez das, se encontraron los siguientes reportes de
virus en seis das (en los restantes cuatro das no se presentaron reportes de
virus):
Fecha
19/07/2001
01/10/2001

Virus
PE_Magistr.A
PE_MAGISTR.DAM

Accin
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

Accin
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 telecomunicacin
(firewall).
Resultados obtenidos
Todas las personas tienen acceso a Internet, la nica diferencia existente
entre usuarios es la restriccin de acceso al servicio
La pagina Web se encuentra publicada a travs de un proveedor de Web
hosting, y el departamento de Normas est a cargo del mantenimiento de la
informacin en la misma.
No existe conexin directa con ninguna de las entidades.
No se tiene definida la poltica sobre la utilizacin de Internet
No existe documentacin referente a la operacin diaria del firewall,
incluyendo monitoreo y revisiones de seguridad se encuentra documentada.
No se realiza una revisin 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
auditora de seguridad.

102

No existe una poltica de Internet formalmente definida. Sin embargo,

durante los cursos de induccin que se da a los nuevos empleados se
menciona como hacer uso correcto de Internet.
La poltica sobre el uso de Internet no se encuentra en la Intranet de la
institucin.
El firewall incluye mecanismos de control de acceso a nivel de Aplicacin
(Proxy server y Web Manager), para los usuarios normales TCP e IP
(PIXFirewall) para todos los usuarios a travs de restriccin de puertos para la
entrada de informacin y sin restriccin para la salida
El trfico permitido de entrada solo puerto 25 SMTP y trfico de salida
cualquiera. (el control para la salida se lo realiza a travs del proxy)
Se cuenta con documentacin acerca de la actualizacin de la configuracin
de los routers.
Existe una persona encargada de administrar y monitorear la red. Sin
embargo, observamos que no existe la funcin de control de calidad. Por otro
lado, hemos observado que se realiz una consultora de seguridad que dio
como resultado recomendaciones sobre el manejo de la red
Para el proceso de login. Los usuarios estn definidos en un grupo de trabajo
de WinNT el cual esta habilitado en el programa proxy y se restringe la
cantidad de Kb de navegacin a travs del programa Web Manager, las
direcciones IP 100.1.(9,5,3).X tienen privilegios de salida especiales que no
son restringidos a travs del software Web Manager
Se generan backups de los logs existentes los cuales estn direccionados a la
maquina del responsable de comunicaciones.
Dado el constante cambio de la tecnologa, es recomendable la realizacin de
pruebas de penetracin en forma peridica para detectar las debilidades que
surjan y tomar medidas correctivas.
Procedimiento aplicado

Revisaremos los mecanismos de control de acceso fsico a los dispositivos de

comunicacin.
Resultados obtenidos
Los mecanismos de control de acceso fsico se detallan en el punto 64. Los
principales aspectos con relacin al acceso fsico a los dispositivos de
comunicacin son los siguientes:

103

Acceso restringido al rea de produccin, slo al personal de sistemas,

mediante llave de proximidad
Acceso restringido al Centro de Cmputo (lugar en el cual se encuentran los
dispositivos de comunicacin) slo al personal de produccin mediante llave
de proximidad y clave
No existe un registro del personal ajeno al rea que ingresa al Centro de
Cmputo
Los dispositivos de comunicacin se encuentran en muebles especiales, en
un ambiente aislado
Procedimiento aplicado

Evaluaremos la estructura de seguridad del sistema operativo.

Resultados obtenidos
Se revisaron los parmetros generales de seguridad para los servidores de
recepcin y servidor principal de dominio, los mismos tienen a su cargo el
intercambio de datos con entidades financieras, la administracin de los
usuarios de red y el control de navegacin Internet. Nuestra revisin
contemplo los siguientes aspectos:

Evaluacin de parmetros de usuarios.

Evaluacin de parmetros de grupos.
Evaluacin de parmetros de directorios.
Las observaciones que surgieron de la revisin de los parmetros 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 caractersticas
de la administracin de los passwords se encuentra detallado en el punto 41.
Los principales aspectos son los siguientes:

No se cuenta con polticas y normas formalmente establecidas para la

administracin de passwords, las mismas se encuentran en etapa de
aprobacin
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 funcin de control de calidad. Se realiz una consultora de seguridad que
dio como resultado recomendaciones sobre el manejo de la red. Las mismas
sern implementadas paulatinamente.
Se generan backups de los logs existentes los cuales estn direccionados a la
maquina del responsable de comunicaciones.
Procedimiento aplicado

51. Verificaremos la existencia de acuerdos y plizas de seguros que tengan por

objetivo la proteccin de los bienes tecnolgicos.
Resultados obtenidos
Existe una pliza de seguros con Alianza, Compaa de Seguros y Reaseguros
S.A., en la misma se detalla el seguro de los bienes tecnolgicos por un valor
de $us. 2.220.000.- (equipos de computacin, fotocopiadoras, equipos de
comunicacin, modems y mquinas de fax).
No existen acuerdos verbales ni escritos con ninguno de los proveedores
para el reemplazo de equipos.
Procedimiento aplicado

Verificaremos la aplicacin de procedimientos para la proteccin de bienes

tecnolgicos en el rea de sistemas.
Resultados obtenidos
Ningn equipo principal es retirado del Centro de Cmputo, su limpieza y
mantenimiento es realizado en el mismo.
Todo equipo que es retirado del Centro de Cmputo y del rea debe ser
registrado por personal de sistemas y por personal de Activos Fijos.
La proteccin de bienes tecnolgicos en el rea de sistemas incluye la
seguridad con la que cuenta el Centro de Cmputo. Este aspecto es detallado
en el punto 64. Los aspectos principales de la seguridad fsica son los
siguientes:

Acceso restringido al rea de produccin, slo al personal de sistemas,

mediante llave de proximidad

105

Acceso restringido al Centro de Cmputo (lugar en el cual se encuentran los

dispositivos de comunicacin) slo al personal de produccin mediante llave
de proximidad y clave
No existe un registro del personal ajeno al rea que ingresa al Centro de
Cmputo
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 aplicacin 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, caractersticas 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, caractersticas del equipo
y asigna un cdigo de activo a cada uno de los componentes del bien.
Adicionalmente, el momento que un equipo de computacin ingresa o es
retirado de la Superintendencia, el guardia de la entrada registra el cdigo
del equipo.
Tareas adicionales propuestas
Procedimiento aplicado

52. Adicionalmente, se realizar un anlisis de la informacin 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 informacin de cuentas de usuario
Inconsistencia de la informacin 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 habilitacin 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 informacin del sistema de Recursos
Humanos.
Procedimiento aplicado

53. Verificaremos el plan de capacitacin relacionado con aspectos de seguridad

para los usuarios y verificaremos que incluye:

La identificacin de las necesidades

La administracin de la capacitacin (cronogramas y seguimiento)

Resultados obtenidos
Como resultado de los procedimientos aplicados, observamos que la USI ha
definido un plan de capacitacin en funcin a los lineamientos estratgicos
que fueron definidos en el documento Plan estratgico de la USI, el cual
est alineado con los objetivos estratgicos de la SBEF definidos en el Plan
Estratgico de la Superintendencia PES.
En relacin a la administracin de la capacitacin como ya fue mencionado
anteriormente en los puntos 19, 20 y 21, el plan de capacitacin de la gestin
2001 no ha sido cumplido.
Respecto a la capacitacin a usuarios en temas relacionados con la
seguridad, hemos observado que la USI, no ha definido acciones especficas
al respecto. Sin embargo, como parte del trabajo de consultora en seguridad
que fue contratado por la SBEF, se realizaron sesiones de capacitacin 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 tecnolgicos,
considerando:
Configuraciones de CPU, discos y controladores de discos, terminales,
lneas de comunicacin, impresoras y perifricos.
Resultados obtenidos
No existen procedimientos formalmente definidos para el registro y
mantenimiento de las configuraciones de los recursos tecnolgicos. Sin
embargo, se cuenta con informacin de la configuracin de los siguientes
recursos:

Equipos de comunicacin
Configuracin de la red
Discos duros (Unix)
Base de datos (Informix)

Procedimiento aplicado
55. Revisaremos las normas y procedimientos para la emisin de reportes de
violacin y actividades de seguridad.

Revisaremos las normas y procedimientos para el manejo de incidentes.

Resultados obtenidos
Los procedimientos para la emisin de reportes de violacin as como el
manejo de incidentes fue detallado en los puntos 45 y 46. Los aspectos ms
importantes son los siguientes:

No se cuenta con reportes de violacin mediante la pgina 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 violacin, no fue posible aplicar

este procedimiento.
En el punto 46 se detallan los resultados de la prueba realizada para el
manejo de incidentes.
56. Administracin de datos en todas las aplicaciones o sistemas en produccin
Procedimiento aplicado
57. Revisaremos los procedimientos para la preparacin de datos, autorizacin
de documentos fuente, y recoleccin de datos de documentos fuente, manejo
de errores de documentos fuente, revisiones de precisin, integridad y
autorizacin, administracin de errores de alimentacin y proceso de datos,
integridad de procesamiento de datos, distribucin de resultados, balance y
conciliacin de resultados y revisin y manejo de errores de resultados.

Resultados obtenidos
Por el tipo de informacin 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
autorizacin de estos documentos. Los documentos fuente, generalmente
son formas impresas para proporcionar uniformidad, exactitud y legibilidad.
La recoleccin de datos es realizada mediante los sistemas CIRC y SIF de la
Superintendencia. Sin embargo, no se reciben documentos fuente en ningn
caso.
Los sistemas CIRC y SIF recolectan en forma diaria datos de las entidades
financieras, para lo cual se cuenta con una estructura de comunicacin
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
informacin entre sus funcionarios y que permite el intercambio de correo
electrnico con redes externas y la salida de los funcionarios a Internet.
SuperNet: Es la red externa de la SBEF dedicada al intercambio de
informacin entre las entidades financieras y la institucin, dentro de esta red
se encuentran:

109

 el servidor de acceso remoto que permite la recoleccin de datos de los

bancos.
el servidor de Informe Confidencial al cual acceden las entidades
financieras para realizar consultas.
El proceso de recoleccin 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 informacin en la misma
Entidad Financiera antes del envo, las validaciones que se realizan se
encuentran documentadas en el Cuadro de Validacin de Errores.
Una vez validados los posible errores de datos que se pueden presentar en la
informacin que ser enviada por la entidad financiera, existe un programa
de comunicacin 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 informacin entre el programa de
envo en la entidad financiera y el programa receptor en la SBEF, el programa
de envo de informacin genera un log de validacin de archivos, el cual
consiste en generar campos de control del nmero de registros, tamao de
archivo, fecha de elaboracin, y totales de control generados a travs de
algoritmos de dgito verificador.
Una vez generado el log de validacin de archivos, el usuario de la entidad
financiera realiza la conexin con el programa receptor de la SBEF por medio
de una lnea dedicada, para lo cual cada usuario de las entidades financieras
cuenta con un login que le permite establecer una conexin remota con el
servidor RAS de la SBEF (la conexin se realiza a travs del protocolo de
validacin de usuarios TACCACS+), una vez establecida la conexin remota,
el programa que enviar la informacin establece una segunda conexin,
esta vez con el servicio abierto para la recepcin de los archivos, donde el
programa cliente se registra (log-in) para iniciar la transaccin a travs 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 validacin la recepcin 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 informacin.
El proceso de recoleccin de datos termina en este punto, luego la carga de
los mismos en los sistemas CIRC y SIF se realiza a travs 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 distribucin de los resultados es realizado mediante el sistema Informe

Confidencial, al cual tienen acceso las entidades financieras para consulta de
la situacin financiera de un determinado cliente, para abrir una cuenta u
otorgar un prstamo al mismo.
No es necesario realizar una conciliacin de resultados, este proceso es
realizado el momento del envo de la informacin por parte de las entidades
financieras y con la ayuda de los sistemas proporcionados por la
Superintendencia.
En caso que existieran errores en la informacin, estos son validados antes
del envo de la informacin 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, segn las mejores prcticas internacionales, deben
ser formas impresas para proporcionar uniformidad, exactitud y legibilidad.
Los documentos fuente deben incluir encabezamientos, ttulos, notas e
instrucciones estndar. El diagrama del documento fuente debe:

Recalcar la facilidad de uso y legibilidad

Agrupar los campos similares para facilitar la entrada
Proporcionar cdigos de entrada predeterminados para reducir los errores
Contener nmeros apropiados de referencia cruzada o un identificador
comparable para facilitar la investigacin y deteccin
Utilizar casillas para identificar los errores del tamao del campo
Incluir un rea apropiada para que la administracin documente la
autorizacin
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 informacin sensible se realice a travs

de mecanismos que permitan la proteccin de los datos (encripcin de
datos)
Resultados obtenidos
En base al trabajo realizado y a los procedimientos existentes para la
transferencia de datos a travs de la red, encontramos que no existe ningn
proceso de encripcin de datos durante el proceso de transferencia.
Procedimiento aplicado
59. Revisaremos la estructura de seguridad en los canales de telecomunicacin.
Resultados obtenidos
La estructura de seguridad de los canales de telecomunicacin se encuentra
detallado en el punto 50. Los principales aspectos son los siguientes:

Todos los usuarios tienen acceso a Internet

La pgina Web se encuentra publicada a travs de un proveedor de Web
Hosting
No existe conexin 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 documentacin acerca de la actualizacin de la configuracin
de los routers
Para el proceso de login, los usuarios estn 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 fsico a los dispositivos de

comunicacin.
Resultados obtenidos
Los mecanismos de control de acceso fsico se detallan en el punto 64. Los
principales aspectos con relacin al acceso fsico a los dispositivos de
comunicacin son los siguientes:

Acceso restringido al rea de produccin, slo al personal de sistemas,

mediante llave de proximidad

112

Acceso restringido al Centro de Cmputo (lugar en el cual se encuentran los

dispositivos de comunicacin) slo al personal de produccin mediante llave
de proximidad y clave
No existe un registro del personal ajeno al rea que ingresa al Centro de
Cmputo
Los dispositivos de comunicacin 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 revisin de los parmetros 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 caractersticas
de la administracin de los passwords se encuentra detallado en el punto 41.
Los principales aspectos son los siguientes:

No se cuenta con polticas y normas formalmente establecidas para la

administracin de passwords, las mismas se encuentran en etapa de
aprobacin
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 funcin de control de calidad. Se realiz una consultora de seguridad que
dio como resultado recomendaciones sobre el manejo de la red. Las mismas
sern implementadas paulatinamente.
Se generan backups de los logs existentes los cuales estn direccionados a la
maquina del responsable de comunicaciones.

113

Procedimiento aplicado
60. Evaluaremos los procedimientos existentes para la destruccin de medios
que contengan informacin sensible.
Resultados obtenidos
La nica informacin sensible que se maneja en medios magnticos 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 destruccin de medios
que contienen informacin sensible.
Procedimiento aplicado
61. Revisaremos las normas y procedimientos aplicados para la administracin
de copias de respaldo, considerando: periodos de retencin, plazos de
almacenamiento, archivo, procedimientos de respaldo y restauracin, 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 produccin, en un gavetero bajo llave; y la otra es enviada a una caja
de seguridad en el Banco de Crdito.
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 Produccin, y la otra es enviada a una Caja de Seguridad en el Banco
de Crdito.
Los servidores de los sistemas: Informe Confidencial, CIRC y el servidor de
dominio tienen una periodicidad de obtencin de copias de respaldo mensual.
Las copias mensuales son permanentes.
Los dems servidores tienen una frecuencia de obtencin 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 das de
la semana. El da 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 produccin.
Como medida de seguridad cuando se envan las cintas al Banco de Crdito
siempre van dos personas, un empleado de sistemas y uno de
administracin. Las cintas que son enviadas al Banco son registradas en el
rea de produccin.
No se cuenta con un cronograma de operaciones o una bitcora de procesos
para realizar el trabajo de obtencin 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 da siguiente, no se repite el proceso
para el da anterior.
Todas las cintas cuentan con la identificacin del servidor y la fecha de la
copia de respaldo. Adicionalmente se registra en un cuaderno la informacin
referente al nmero de cinta, servidor y fecha.
Aproximadamente se tienen copias desde 1996 en el rea de produccin,
copias anteriores se encuentran almacenadas en el depsito 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 gestin 2000 y cinco
meses de la gestin 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
fsica.
La administracin de copias de respaldo tienen algunas falencias en cuando a
la documentacin y obtencin.
Ver detalle en Anexo 5.

115

Procedimiento aplicado
62. Revisaremos las normas y procedimientos aplicados para la proteccin de
mensajes delicados.
Resultados obtenidos
No existen normas ni procedimientos para la proteccin de mensajes,
tampoco se cuenta con normas que permitan contar con una clasificacin 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 electrnicas y la integridad de los
datos almacenados.
Resultados obtenidos
Los procedimientos para la autenticacin de los datos y la integridad de las
transacciones electrnicas 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 informacin en la misma Entidad antes del envo
Las validaciones se encuentran documentadas en el Cuadro de Validacin de
Errores
Existe un programa de comunicacin que se encarga de enviar los mismos a
un programa receptor
El programa de envo genera un log de validacin de archivos, el cual es
luego utilizado para verificar la adecuada transferencia
La conexin del usuario en la entidad financiera con la SBEF se realiza a
travs del protocolo de validacin de usuarios TACCACS+
Una vez establecida la conexin, el programa establece una segunda
conexin, con un servicio abierto para la recepcin de los archivos

116

Una vez finalizada la transferencia de archivos, el programa receptor verifica

contra el log de validacin la recepcin adecuada de los archivos
La integridad de los datos almacenados esta dada por el proceso de
validacin 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 tecnologa de
informacin Ambiente IT (Tecnologa de la Informacin), cuente con:

Mecanismos
Mecanismos
Mecanismos
Mecanismos
Mecanismos

de seguridad fsica
de registro y monitoreo de visitantes
de seguridad para el personal
para la proteccin contra factores ambientales
para el suministro ininterrumpido de energa

Resultados obtenidos
Se cuenta con acceso restringido al rea de produccin y tambin al Centro
de Cmputo, ambos mediante llave de proximidad y clave personal. Estas
llaves slo se encuentran en propiedad el personal de sistemas. Sin embargo,
las puertas y paredes de acceso al Centro de Cmputo son todas de vidrio. El
Centro de Cmputo 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 Cmputo.
Se cuenta con extintores de incendio en lugares visibles. Tambin se cuenta
con luces de emergencia.
El piso del Centro de Cmputo es de cermica, se cuenta con aire
acondicionado, en su mayora los servidores se encuentran en el piso, uno de
ellos cuenta con rack.

117

Los dispositivos de comunicacin se encuentran en un lugar aislado en el

Centro de Cmputo, ubicado en muebles especiales.
No se cuenta con detectores de humo, alarmas contra incendio o alarmas
contra intrusos en el Centro de Cmputo
No se realiza un mantenimiento peridico a los equipos de aire
acondicionado, luces de emergencia, UPS, lneas de comunicacin ni al
sistema elctrico.
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 Cmputo.
La limpieza del Centro de Cmputo es realizada siempre con la presencia de
un funcionario de sistemas.
Procedimiento aplicado
65. Revisaremos las normas y procedimientos aplicados para la administracin
operativa, contemplando:

Operaciones de procesamiento.
Manual de instrucciones
Documentacin del proceso de inicio y otras operaciones
Programacin de tareas
Desviaciones de la programacin estndar de tareas
Continuidad de procesamiento
Bitcoras de operaciones
Administracin remota
Resultados obtenidos
Se cuenta con documentacin 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 documentacin del proceso de inicio, programacin de
tareas ni con el detalle de desviaciones de la programacin estndar de
tareas.
Las tareas se realizan por el conocimiento del personal.
Para la continuidad del procesamiento, existen un Plan de Recuperacin 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 bitcoras 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 adems de verificacin de existencia de errores durante el
proceso.
No existe para ningn caso la operacin remota de alguno de los sistemas.
Todo la operacin 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 bitcoras de
operaciones. En todos los casos las bitcoras se encuentran con el detalle
necesario y se encuentran archivadas.

119