Está en la página 1de 37

ENTIDAD FINANCIERA MI BANCO

Examen en Auditora de Sistemas a la


Unidad de Sistemas de Informacin EN
CONFORMIDAD

CON LA NORMA DE

SEGURIDAD INFORMATICA ISO 17799

PROYECTO DE CONSULTORIA EN AUDITORIA DE SISTEMA A LA UNIDAD DE


SISTEMAS DE INFORMACION EN CONFORMIDAD
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

Detalle de recomendaciones

V.

RESULTADOS OBTENIDOS

CON LA NORMA ISO 17799

I.

OBJETIVO
El objetivo de nuestro trabajo
tecnologa

fue evaluar

y comunicaciones , conocer la efectividad de la seguridad lgica

accesos a la red as tambin verificar

II.

los accesos fsicos en la unidad de


de los

la seguridad de los sistemas web internos

ALCANCE
Los sistemas de informacin de la unidad de sistemas de informacin. (USI)

II.1

INTRODUCCION
De acuerdo a lo relevado en el transcurso de nuestro trabajo, MI BANCO

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, MI BANCO obtendr una visin clara de su problemtica
general, comprendiendo las relaciones causa-efecto existente 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 MI BANCO 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 MI BANCO:

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 bsicos asociados con la provisin y operacin
de los servicios informticos. Muchos de los problemas del rea informtica provienen
de aspectos que pueden ser fcilmente identificados aplicando este modelo de alto
nivel. Los seis componentes del modelo son:

Planificacin estratgica de la institucin.

El mximo rgano ejecutivo de la

institucin debe determinar los requerimientos que tienen los sistemas, si es que los
hay, para el soporte de los planes del negocio.

Tradicionalmente los sistemas de

informacin no han sido vistos como una ventaja competitiva potencial y por lo tanto
pocas organizaciones tienen procesos o capacidades para examinar el uso estratgico
de la informtica para maximizar sus beneficios para el negocio. El resultado de este
proceso tiende a ser un conjunto de requerimientos del negocio o pedidos de proyectos;

Planificacin estratgica de sistemas. La gerencia de sistemas debe cubrir dos


actividades bsicas: el soporte permanente del conjunto de aplicaciones existentes y el

desarrollo de nuevas aplicaciones (o mejoradas).

El proceso de planeamiento

estratgico atiende estas necesidades por medio de la asignacin de los limitados


recursos de sistemas al soporte y desarrollo, identificando una arquitectura de sistemas
y conjunto de herramientas que facilitar las tareas de desarrollo y operacin, y
estableciendo procesos de priorizacin para la atencin de requerimientos. El proceso
involucra a la gerencia del negocio y a la de sistemas, el resultado de este proceso tiene
dos contenidos principales: una lista de proyectos priorizados y la asignacin de
recursos;

Planificacin tctica de sistemas.

Una vez que el proceso de priorizacin ha

identificado que proyectos se van a iniciar, el proceso de planificacin tctica identifica


la forma en que los proyectos sern estructurados y gerenciados. Esto incluye aspectos
como la asignacin de un gerente de proyecto, determinacin de las herramientas de
gerenciamiento que sern utilizadas, establecimiento de la estructura del proyecto,
organizacin de adecuados vnculos y definicin de las responsabilidades de los
diversos participantes. Mientras que este proceso puede ser llevado adelante por la
gerencia de sistemas, el gerente del proyecto asignado puede a menudo provenir de la
gerencia del negocio. El resultado de este proceso deben ser proyectos para nuevas
aplicaciones o para la realizacin de cambios a los actuales sistemas;

Entrega de aplicaciones.

Una vez que los proyectos de han estructurado y los

recursos se han asignado, un proceso separado se lleva a cabo para entregar el


proyecto terminado, ya sea en la forma de una nueva aplicacin o de un cambio a una
ya existente.

Este proceso esta relacionado con los aspectos del da a da del

gerenciamiento de proyectos y la calidad de integracin entre el personal de sistemas y


del negocio para asegurar la entrega exitosa del proyecto. La salida de este proceso
debe ser el nuevo conjunto de aplicaciones existentes;

Soporte a las aplicaciones existentes.

Este proceso se relaciona con el

gerenciamiento y soporte del conjunto de aplicaciones existentes. Esto incluye a las


aplicaciones en s mismas, el grado de cobertura que proveen a las necesidades del
negocio, el mantenimiento y soporte de estas aplicaciones y las operaciones del

computador relacionadas. La informacin acerca del conjunto de aplicaciones existentes


es utilizada como insumo para proceso de planeamiento estratgico de sistemas, para
determinar la mejor forma de cumplir con los requerimientos del negocio;

Cultura informtica.

Este proceso provee una visin de alto nivel sobre la

informacin provista en el anlisis que procede y ayuda a la gerencia a identificar


necesidades de cambio de la postura de la organizacin en general con respecto a los
sistemas de informacin, con el fin de emprender el desarrollo de nuevos productos o
servicios.

III.

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

al examinar

el nivel

de conformidad

con la norma de

seguridad informtica ISO 17799.

III.1 HALLAZGOS GENERALES


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.

III.2 HALLAZGOS ESPECIFICOS

a. 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 MI BANCO

ha seguido los lineamientos definidos en dicho

documento y realizado un proceso que culmin en la formulacin de una serie de


objetivos institucionales de MI BANCO y los planes operativos anuales (POAs) a nivel
de cada una de sus distintas reas.
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 MI BANCO .
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.

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

10

Esta falta de documentacin de los procedimientos no permite evaluar su cumplimiento,


adecuacin y estabilidad.
Dentro del proceso de formalizacin de los procedimientos 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.

c. Operacin y soporte de sistemas


Seguridad fsica
De acuerdo al trabajo realizado, hemos visto que la sala del computador no cuenta con
los siguientes dispositivos o medidas de proteccin: detectores de humo, alarma contra
incendios, alarma contra intrusos.

Asimismo, estimamos conveniente mejorar las

medidas de proteccin fsica, sellando las ventanas y sustituyendo las divisiones de


vidrio por paredes.
Estas medidas deberan ser extendidas en la medida de lo aplicable al resto de las
reas de sistemas, donde tambin residen equipamiento, documentacin e informacin.
Asimismo, hemos observado que:
-

Existen ocasiones en que las puertas de acceso al ambiente de sistemas permanecen


abiertas,

Personal ajeno a sistemas accede a la sala del computador sin la real necesidad.

No se poseen armarios ignfugos para el almacenamiento de las cintas de respaldo.

11

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

Los mecanismos de administracin de usuarios y contraseas no cumple con las


mejores prcticas ni con las normas internas. Por ejemplo:

otorgamiento de autorizaciones de acceso basado en la premisa necesidad de


conocer, necesidad de hacer,

autorizaciones formales para alta o modificacin de usuarios,

reglas para la construccin de claves (longitud mnima, caducidad, reglas de

construccin, etc.)

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


seguridad.

No se cuenta con una clasificacin de la informacin en cuanto a su criticidad y por


lo tanto tampoco con medidas de proteccin asociadas a cada categora definida.

Operacin

12

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


esta rea:
-

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

A. GESTION DE LA UNIDAD
1. Planificacin Estratgica de Sistemas
Como resultado del trabajo realizado, observamos que la funcin informtica
no est plenamente integrada al proceso de planificacin estratgica MI
BANCO 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 Plan Estratgico de Sistemas

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.

14

2. Adecuacin de la Estructura organizacional


Hemos observado que la estructura organizacional de la Unidad de Sistemas de
Informacin no refleja las jerarquas ni los niveles de mando que en la prctica
existen, esta situacin crea problemas en la segregacin de funciones y designacin
de responsabilidades, y dificulta las tareas de supervisin y control de los trabajos.
De acuerdo a las mejores prcticas la estructura organizacional de un rea de
sistemas debe estar alineada a las tareas y responsabilidades existentes dentro de
esta.
De acuerdo a lo observado el rea de sistemas realiza tareas en las siguientes
reas de trabajo:

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

15

3. Consolidar las funciones de apoyo de Auditora de Sistemas y Organizacin &


Mtodos
Hemos observado que no se cuenta con la funcin de Auditora interna de Sistemas.
En relacin a la Auditora Interna de Sistemas y debido a las caractersticas de MI
BANCO

consideramos que dicha funcin no debe implicar necesariamente la

designacin a tiempo completa 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.
4. 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 Unidad de Sistemas de Informacin.
Consideramos que este tipo de acciones pueden llegar a ser contraproducentes
para la financiera 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 MI BANCO.
Consideramos necesario que este tipo de procedimientos sean eliminados en la
empresa

MI BANCO

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 Unidad de Sistemas de Informacin.

B. DESARROLLO , ADQUISICION E IMPLANTACION DE SISTEMAS


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

16

No existen procedimientos formales que permitan definir mdulos de seguridad y


auditora para los sistemas. No se contempla durante las etapas del desarrollo de
sistemas la definicin de los mdulos de seguridad y de auditoria.
De acuerdo a las mejores prcticas de la industria, el ciclo de desarrollo de los
sistemas debera asegurar que se consideren mecanismos para definir mdulos
especficos de rastros de auditora y que se evalen los mecanismos de seguridad
que proporcionar el sistema para proteger los datos e informacin sensible. Los
aspectos ms importantes a tomar en cuenta durante la definicin de estos
mdulos son:
Acceso a los datos
Administracin de privilegios
Acceso a funciones especiales
Definicin de rastros de auditora
Definicin de procedimientos para la revisin de los incidentes de seguridad
Definicin de procedimientos para la revisin de auditora
2. Definir estndares formales para la codificacin de los sistemas
Durante nuestra revisin no encontramos estndares para la codificacin de los
sistemas, que permitan que la misma se realice de manera uniforme, facilitando el
mantenimiento y soporte de los sistemas.
Los estndares y acuerdos de programacin deberan cubrir los siguientes
aspectos:

Acuerdos sobre el estilo de programacin identificando entradas y salidas,


composicin y formato de los almacenamientos de los datos y arreglos,
acuerdos de numeracin de prrafos y otros que proporciones un estilo de
escritura fcil y predecible que pueda ayudar en una inspeccin inicial de los

programas y su posterior mantenimiento.


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

3.

Definir una metodologa formal para realizar pruebas a los sistemas

17

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 Unidad de Sistemas de

Informacin

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

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

18

Que se realicen comparaciones entre las versiones modificadas y versiones


anteriores para identificar los cambios.

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

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 de procedimientos para el respaldo de documentacin sensible

(copias de contratos, acuerdos firmados, etc.).


Procedimientos formales para realizar pruebas al plan de contingencias

mnimos

de

hardware,

software

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

19

De acuerdo a las mejores prcticas de la industria, se debera contar con un


Plan de Contingencias que permita proteger la continuidad operativa del
negocio, el mismo debera identificar los procesos crticos del negocio y los
recursos requeridos para mantener un nivel aceptable de operacin, para lo
cual se deberan preparar y probar procedimientos que aseguren la continuidad
de la entidad en caso de contingencia.

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

20

C. OPERACION Y SOPORTE DE SISTEMAS


1.

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


La generacin de claves (passwords) para todos los usuarios de la SBEF y para los
usuarios externos (Entidades Financieras) es realizado mediante un programa
generador de claves, el cual esta conformado por cuatro letras, tres nmeros y un
carcter especial. Por este proceso el rea de produccin de la USI tiene conocimiento
de todas las claves de usuarios.
De acuerdo a normas internacionales de seguridad lgica, cada usuario debera ser
responsable de su clave y debe ser la nica persona que conozca la misma. El sistema
debera permitir el cambio de clave al usuario el momento de ingresar por primera vez al
sistema.
Adems se deberan tomar en cuenta los siguientes aspectos:

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

Permitir la misma clave para todos los sistemas solamente con autorizacin expresa

Cambio de clave por parte del usuario el momento de la sospecha de conocimiento


de la clave por parte de alguna otra persona

Las claves no deben ser escritas y dejadas al alcance de otras personas

Prohibicin de la utilizacin de claves comunes

2.

Modificar la parametrizacin de las claves

Actualmente, ninguno de los sistemas en produccin solicita (obliga) al usuario el


cambio peridico de claves.
Normas

de las

ISO

17799

de seguridad generalmente utilizada, sealan que

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

Parametrizar el control de algunas caractersticas de las claves


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

Los sistemas deben guardar al menos las ltimas tres claves para que las mismas
no puedan repetirse.

No debe ser posible repetir el mismo carcter varias veces en la construccin de la


clave.

Debe existir al menos un dgito numrico en la clave.


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

4.

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


casos
Mediante la aplicacin de pruebas de cumplimiento, se evidenci que no en todos los
casos se cuenta con el formulario firmado para dar de alta un usuario en el sistema.

5.

Definir normas y procedimientos para la clasificacin de datos


No se cuenta con una clasificacin de los datos manejados por MI BANCO Las.
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 MI BANCO. El uso no autorizado de esta
informacin puede causar un impacto muy fuerte para la financiera MI BANCO, 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 MI BANCO. 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 MI BANCO. 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 MI BANCO, las Entidades Financieras o
los clientes.

6.

Definir normas y procedimientos para el manejo de incidentes


No se cuenta con normas ni procedimientos formalmente establecidos para el manejo
de incidentes.
Segn las mejores prcticas de seguridad, deberan existir normas y procedimientos
establecidos para asegurar que todos los eventos de operacin que no sean comunes
(incidentes, errores o problemas) sean correctamente registrados, analizados y
resueltos en un tiempo prudente.
Adems se debera consolidar la informacin generada por todos los operadores para
realizar luego un anlisis y emitir estadsticas sobre el tipo de incidentes que se
producen y los usuarios que ms soporte requieren. Asimismo el anlisis gerencial
permitir tomar decisiones para solucionar los principales problemas en forma definitiva.
Actualmente se cuenta, en el rea de produccin, con una planilla Excel, en la cual
deben registrarse todos los requerimientos de soporte de los usuarios.

7.

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 EN MI BANCO

8.

Mejorar la seguridad fsica


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

No existen normas y procedimientos formalmente establecidos para esta tarea

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

No existen alarmas contra intrusos

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


autorizado)

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


la visita

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

No se realiza el mantenimiento peridico del sistema

elctrico del Centro de

Cmputo, luces de emergencia ni aire acondicionado.

Las ventanas que dan al exterior no se encuentran selladas.

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


Las mejores prcticas de seguridad mencionan que deberan existir los aspectos
mencionados para incrementar la seguridad fsica.
Asimismo, es importante mencionar que las actuales instalaciones fsicas de la USI no
fueron diseadas especficamente para tal efecto, lo cual no contribuye a la solucin de
los aspectos anteriormente mencionados.

9.

Mejorar la administracin de Backups


Como resultado de los procedimientos aplicados, encontramos que no se cuenta, en
todos los casos, con las copias de respaldo de los servidores. Tampoco se cuenta con
un cronograma de operaciones o una bitcora para la obtencin de copias de respaldo.
Debera llevarse un control detallado de todas las copias obtenidas para que, en caso
de ser necesario, se tenga a mano toda la informacin de los meses y gestiones
anteriores.
Debera existir un cronograma de operacin para que el operador conozca exactamente
el orden de la obtencin de las copias de respaldo. Adems debera existir una bitcora
en la cual se detalle las copias de respaldo diarias obtenidas, si es que existi algn
problema el momento de realizar esta tarea y alguna observacin especial sobre el
proceso para cada uno de los servidores.

10.

Definir procedimientos para la proteccin de los datos

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.

V. RESULTADOS OBTENIDOS SEGN EXAMEN DE NIVEL DE CONFORMIDAD DE


SEGURIDAD INFORMATICA ISO 17799
DESARROLLO, ADQUISICION E IMPLANTACION DE SISTEMAS
1. 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
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

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

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

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

Procedimiento aplicado

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

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
Revisaremos, para una muestra, la aplicacin de procedimientos para:

La evaluacin de hardware y software nuevos.

10

El mantenimiento preventivo de hardware.

La seguridad del software del sistema.

La instalacin y mantenimiento del software del sistema.

Resultados obtenidos

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

Procedimiento aplicado

11

Revisaremos para una muestra la aplicacin de procedimientos y estndares de


tecnologa informtica para:

El manual de procedimientos del usuario

El manual de operaciones

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

12

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

Seguridad de los sistemas


Procedimiento aplicado
Evaluaremos los mecanismos utilizados para la administracin de contraseas.

13

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

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

14

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.

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

15

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
Revisaremos las normas y procedimientos para el manejo de incidentes.

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

16

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
Evaluaremos los mecanismos utilizados para la administracin de contraseas.
Resultados obtenidos
Los procedimientos para la administracin de contraseas se encuentra detallada en el
punto
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.

17

También podría gustarte