Está en la página 1de 161

AUDITORIA INFORMÁTICA DE CONTROL INTERNO DE

TECNOLOGÍA INFORMÁTICA (TI) DE LA MUNICIPALIDAD


DE RAÚL ARSENIO OVIEDO SEGÚN LAS NORMAS COBIT
Y MCIIEF

Steven Samuel Marmolejo Araujo

Tutora: Dra. Patricia Figueredo de Mitjans

Tesis presentada a la Facultad de Tecnología Informática de la


Universidad Tecnológica Intercontinental como requisito para obtención
del Título de Ingeniero en Sistemas Informáticos

Caaguazú – Paraguay

Junio, 2016
ii

DERECHO DE AUTOR

Quien suscribe, Steven Samuel Marmolejo Araujo, con Documento Nº


4.928.511, autor del trabajo de investigación titulado “Auditoria Informática
de control interno de tecnología informática (TI) de la Municipalidad de Raúl
Arsenio Oviedo según las normas COBIT y el MCIIEF”, declara que
voluntariamente cede al título gratuito y en forma pura y simple, ilimitada e
irrevocablemente a favor de la Universidad Tecnológica Intercontinental el
derecho de autor de contenido patrimonial que como autor le corresponde
sobre el trabajo de referencia.

Conforme a lo anteriormente expresado, esta cesión otorga a la UTIC la


faculta de comunicar la obra, divulgarla, publicarla y reproducirla en
soportes analógicos o digitales en la oportunidad que ella así lo estime
conveniente. La UTIC deberá indicar que la autoría o creación del trabajo
corresponde a mi persona y hará referencia al tutor y a las personas que
hayan colaborado en la realización del presente trabajo de investigación

En la ciudad de Caaguazú, a los 08 días del mes de junio de 2016.

………………………………………..

Steven Samuel Marmolejo Araujo


iii

CONSTANCIA DE APROBACIÓN DEL TUTOR

Quien Suscribe, Dra. Patricia Figueredo de Mitjans con Documento de


identidad Nº 1.090.157, Tutora del Trabajo de Investigación titulado
Auditoria Informática de control interno de tecnología informática (TI) de la
Municipalidad de Raúl Arsenio Oviedo según las normas COBIT y el
MCIIEF, elaborado por el alumno Steven Samuel Marmolejo Araujo para
obtener el título de Ingeniero en Informática hace constar que dicho trabajo
reúne los requisitos exigidos por la Facultad de Tecnología Informática y
Ciencias Exactas de la Universidad Tecnológica Intercontinental y puede
ser sometido a evaluación y presentarse ante los docentes que fueren
designados para integrar la Mesa Examinadora.

En la ciudad de Caaguazú, a los 08 días del mes de junio de 2016.

……………………………………..

Dra. Patricia Figueredo de Mitjans


iv

DEDICATORIA.

A mi familia por el apoyo incondicional para


la culminación de la Carrera.

A cada uno de los docentes que me


enseñaron durante estos años y me
formaron como profesional.
v

AGRADECIMIENTO

Agradezco a Dios todo poderoso por estar


siempre conmigo y por darme la
oportunidad de culminar este proyecto
satisfactoriamente.

Al tutor por el acompañamiento durante el


desarrollo del proyecto.
vi

Auditoria informática de control interno de Tecnología Informática


(TI) de la Municipalidad de Raúl Arsenio Oviedo según las normas
COBIT y MCIIEF

Autor: Steven Samuel Marmolejo Araujo

Tutor: Dra. Patricia Figueredo de Mitjans

RESUMEN
La Municipalidad de Raúl Arsenio Oviedo, Avda. 7 de Octubre y Sinforiano
Bogarín del Distrito de Raúl Arsenio Oviedo posee un sistema de
información que carece de seguridad informática para el resguardo seguro
de las informaciones. Los principales problemas están en la seguridad
física y lógica en el sistema de aplicación y redes.
Dar recomendaciones y posterior solución a estos problemas es el objetivo
de este proyecto a través de una auditoria informática que ayude en la toma
de decisiones por la intendencia y la junta municipal, aplicando la norma
COBIT (Control Objectives for Information and Related Technology) y el
MCIIEF (Manual de Control Interno Informático para Entidades Financieras
de la Superintendencia de Bancos, del Banco Central del Paraguay).
Con esta auditoria informática se analizan los puntos: estructura de TI y
gerenciamiento, sistemas de información, seguridad lógica y física,
documentaciones de TI (Tecnología Informática) y evaluación de recursos
humanos. Con el desarrollo de las notas de control interno de las
vulnerabilidades encontradas en los sistemas de aplicación y LAN.
En base a la labor realizada, en el marco de la auditoría del área informática
se observan situaciones que son necesarios informar a la intendencia. Los
procedimientos y funciones que actualmente no son considerados en el
área informática, así como los temas observados, junto con sus
recomendaciones para su corrección, son detallados en este proyecto.

Palabras Claves:
Auditoria, Informática, Tecnología Informática, Información, Control,
Seguridad, Gerenciamiento, Evaluación, COBIT, MCIIEF.
vii

INDICE

Contenido Pág.
PORTADA................................................................................................... i
DERECHO DE AUTOR .............................................................................. ii
CONSTANCIA DE APROBACIÓN DEL TUTOR ....................................... iii
DEDICATORIA. ......................................................................................... iv
AGRADECIMIENTO .................................................................................. v
RESUMEN ................................................................................................. vi
INDICE ...................................................................................................... vii
LISTA DE TABLAS Y FIGURAS ................................................................ x
Introducción ............................................................................................ 1
CAPITULO I – MARCO INTRODUCTORIO............................................... 3
Tema: ..................................................................................................... 3
I.1 Planteamiento y delimitación del problema:................................. 4
I.1.1 Formulación del problema ........................................................... 4
I.1.2 Preguntas de investigación ................................................... 4
I.1.2.1 Preguntas General: ............................................................ 4
I.1.2.2 Preguntas Específicas: ....................................................... 5
I.2 Objetivos de la Investigación ........................................................ 5
I.2.1 Objetivo General ................................................................... 5
I.2.2 Objetivos Específicos ............................................................ 6
I.3 Justificación de la investigación .................................................... 6
CAPÍTULO II – MARCO TEÓRICO ........................................................... 8
II.1 Antecedentes de la Investigación ..................................................... 8
II.2 Bases Teóricas ............................................................................... 10
II.2.1 La Auditoría de Sistemas de Información .................................... 10
II.2.2 La auditoría .................................................................................. 12
II.2.3 El alcance de la Auditoría de Sistemas de Información ............... 13
II.2.4 Características de la Auditoría de Sistemas de Información ....... 14
viii

II.2.5 Síntomas de necesidad de una Auditoría de Sistemas de


Información ........................................................................................... 15
II.2.6 Tipos y clases de Auditoría de Sistemas de Información ............ 17
II.2.7 Auditoría Informática de Sistemas ............................................... 18
II.2.8 ESTANDARES INTERNACIONALES - COBIT (Control Objectives
............................................................................................................. 21
II.2.8.1 Breve introducción a COBIT .................................................. 23
II.2.8.2 COBIT cubre cuatro dominios: .............................................. 26
II.2.8.3 Navegación en el Marco de Trabajo COBIT .......................... 29
II.2.8.4 Áreas de enfoque del Gobierno de TI.................................... 30
II.2.9 MCIIEF - Manual de Control Interno Informático para Entidades
Financieras de la Superintendencia de Bancos, del Banco Central del
Paraguay .............................................................................................. 32
II.2.9.1 Planificación y Organización ................................................. 33
II.2.9.2 Adquisición e Implementación: .............................................. 35
II.2.9.3 Producción y Servicios: ......................................................... 36
II.2.9.4 Monitoreo: ............................................................................. 38
II.2.10 Tecnologías de Información ...................................................... 38
II.2.11 Breve Presentación de la Organización Auditada...................... 40
II.2.11.1 Descripción de la Organización. .......................................... 40
II.2.11.2 Principales Funciones. ........................................................ 40
II.2.11.3 Tipo de forma de Organización. .......................................... 41
II.2.11.4 Actividades de Planificación. ............................................... 41
II.2.11.5 Estructura de la Municipalidad de Raúl Arsenio Oviedo ...... 42
II.2.11.6 A continuación describimos lo disponible en Hardware y
Software: ........................................................................................... 43
II.3 Aspectos Legales ........................................................................... 43
II.3.1 Código Penal Paraguayo Ley Nº 1160/97 ................................ 43
II.3.2 Ley Nº 4439 .............................................................................. 45
II.4 Definición de variables .................................................................... 51
II.4.1 Cuadro de Variables ................................................................. 51
CAPITULO III – MARCO METODOLOGICO ........................................... 53
III.1 Características Metodológicas ....................................................... 53
ix

III.1.1 Tipo de Investigación:.............................................................. 53


III.1.2 Nivel de Conocimiento esperado: ............................................ 53
III.1.3 Diseño de la Investigación: ...................................................... 53
III.2 Descripción de la población y muestra .......................................... 54
III.3 Técnicas e Instrumentos de recolección de Datos ........................ 54
III.4 Descripción del procedimiento de análisis de datos ...................... 54
CAPITULO IV – RESULTADOS Y ANALISIS DE DATOS ....................... 55
IV.1 Desarrollo de las Notas de Control Interno (Informe) .................... 55
IV.1.1 Problemas identificados: ......................................................... 55
IV.1.2 Desarrollo de Caso Práctico ....................................................... 58
CAPITULO V – CONCLUSIONES Y RECOMENDACIONES ................ 119
V.1 Conclusiones ................................................................................ 119
V.2 Recomendaciones........................................................................ 120
BIBLIOGRAFÍA ...................................................................................... 122
ANEXO .................................................................................................. 124
Anexo 1. Parte Complementaria ......................................................... 124
Cronograma .................................................................................... 124
Diagrama de Gantt .......................................................................... 125
Presupuesto .................................................................................... 122
Anexo 2. Papeles de Trabajo de Controles Generales de TI .............. 123
Anexo 3. Propuesta de Servicios ........................................................ 144
x

LISTA DE TABLAS Y FIGURAS

Contenido Pág.

Figura 1. Recursos de TI, Objetivos de Negocio y Dominios de COBIT


.......................................................................................................... 25
Figura 2. El Cubo COBIT................................................................... 25
Figura 3. Marco de trabajo COBIT .................................................... 29
Figura 4. Área del Gobierno de TI ..................................................... 30
Figura 5. PO1 Definir un Plan Estratégico de TI................................ 31
Figura 6. Matriz RACI ........................................................................ 31
Figura 7. Metas y Métricas ................................................................ 32
Figura 8. Organigrama de la Municipalidad de Raúl Arsenio Oviedo 42
Introducción

La información es un activo esencial para toda institución, y como resultado


de la creciente interconectividad, la información está expuesta a un número
cada vez mayor y una variedad más amplia de amenazas y
vulnerabilidades. De ahí la importancia de la seguridad de la información,
que es la protección contra las amenazas para poder asegurar la
continuidad de las operaciones institucionales, minimizar el riesgo y
maximizar la eficiencia y eficacia de los procesos.

En la actualidad la informática se encuentra evidentemente vinculada con


la gestión de las empresas y es por esto que es de vital importancia que
exista la auditoria informática, para analizar el desempeño y funcionamiento
de los sistemas de información, de los cuales depende la organización.

Toda empresa, pública o privada, que posean Sistemas de Información


medianamente complejos, deben de someterse a un control estricto de
evaluación de eficacia y eficiencia.

Es por ello que se ha decidido realizar una auditoria informática en la


Municipalidad de Raúl Arsenio Oviedo utilizando los estándares de las
normas COBIT y el MCIIEF.

Los procedimientos de la auditoría de sistemas, tienen por objeto regular la


administración de las tecnologías de información y comunicaciones
utilizadas por las instituciones para el control adecuado de la información
generada.

En este trabajo se realiza una auditoría informática a la Municipalidad de la


ciudad de Raúl Arsenio Oviedo aplicando las normas COBIT y el MCIIEF,
los puntos analizados son: estructura de TI y gerenciamiento, sistemas de
información, seguridad lógica y física, documentaciones de TI y evaluación
de recursos humanos.
Página |2

Después se procede al desarrollo de las notas de control interno de las


vulnerabilidades encontradas en los sistemas de aplicación.
CAPITULO I – MARCO INTRODUCTORIO

Tema:

Auditoria Informática de Control Interno de Tecnología Informática (TI) de


la Municipalidad de Raúl Arsenio Oviedo según las normas COBIT y
MCIIEF.
Página |4

I.1 Planteamiento y delimitación del problema:

I.1.1 Formulación del problema

La Municipalidad de Raúl Arsenio Oviedo sufre inconvenientes en el uso y


manejo de los sistemas de aplicaciones y redes. No cuenta con gerente de
Tecnología informática interno, por lo tanto si existe un problema en el sistema
se debe esperar la disponibilidad de un informático externo.

Posee un déficit en el manejo de usuarios, ya que los funcionarios de la


Municipalidad cuentan con las contraseñas de sus compañeros por lo que no
se puede saber a ciencia cierta quien es el dueño del usuario, no cuenta con
pistas de auditoria y no se cuenta con un manual de confidencialidad de datos.

Los principales problemas están en la seguridad física y lógica del sistema de


aplicación y redes, para el resguardo seguro y la continuidad del
procesamiento de la información, debido a que los planes de contingencias
existentes no están preparados en caso de interrupciones en los servicios,
originados por desastres u otras contingencias. Por lo tanto existe una
necesidad de realizar una Auditoria Informática.

I.1.2 Preguntas de investigación

I.1.2.1 Preguntas General:

 ¿Cuál es el resultado de la Auditoría Informática de Control Interno de


Tecnología Informática (TI) de la Municipalidad de Raúl Arsenio Oviedo
según las Normas Estándares de COBIT y MCIIEF?
Página |5

I.1.2.2 Preguntas Específicas:

 ¿Cuál es la situación de Tecnología Informática en cuanto a la


estructura organizativa y Gerenciamiento?
 ¿Los sistemas de información están basados en el enfoque de
confiabilidad de las informaciones y que flexibilidad proporcionan?
 ¿Existen políticas de seguridad lógica vigentes que puedan minimizar
la posibilidad de accesos no autorizados en los sistemas de
información y LAN?
 ¿Los planes de contingencias en cuanto a seguridad física están
preparados para asegurar la continuidad del procesamiento de la
información en caso de interrupciones en los servicios, originados por
desastres u otras contingencias?
 ¿Cuáles son las documentaciones pertinentes utilizadas por el
Departamento de Tecnología Informática?
 ¿Los usuarios cuentan con una capacitación adecuada en las
operaciones de los módulos del sistema informático?

I.2 Objetivos de la Investigación

I.2.1 Objetivo General

Determinar el resultado de la Auditoría Informática de Control Interno de


Tecnología Informática (TI) de la Municipalidad de Raúl Arsenio Oviedo según
las Normas Estándares de COBIT y MCIIEF.
Página |6

I.2.2 Objetivos Específicos

 Verificar la estructura organizativa y Gerenciamiento de Tecnología


Informática.
 Evaluar los sistemas de información basados en el enfoque de
confiabilidad de las informaciones y la flexibilidad que proporcionan.
 Evaluar que las políticas de seguridad lógica vigentes puedan
minimizar la posibilidad de accesos no autorizados en los sistemas de
información y LAN.
 Evaluar los planes de contingencias de seguridad física a efectos de
asegurar la continuidad del procesamiento de la información en caso
de interrupciones en los servicios, originados por desastres u otras
contingencias.
 Identificar las documentaciones pertinentes utilizadas por el
Departamento de Tecnología Informática.
 Evaluar la adecuada capacitación de los usuarios en las operaciones
de los módulos del sistema informático.

I.3 Justificación de la investigación

En la actualidad la informática está vinculada directamente en la gestión de


las empresas u organizaciones y es por esto que es de vital importancia que
exista la auditoria informática, para analizar el desempeño y funcionamiento
de los sistemas de información, de los cuales depende la empresa o
institución.

A través de la auditoría informática se puede detectar las vulnerabilidades en


los sistemas de aplicación, redes y equipos informáticos, y dar
recomendaciones tendientes a mejorar el control interno del área informática.
Esto ayudará a que la intendencia pueda tomar las mejores decisiones para
contrarrestar las vulnerabilidades existentes en la Municipalidad, de esta
forma obtener la seguridad de que no se perderán las informaciones
Página |7

importantes en los movimientos administrativos y finanzas, liquidación de


patentes (comercial, inmobiliario), dirección de seguridad y tránsito, como así
también la continuidad de los mismos ante posibles contingencias.
CAPÍTULO II – MARCO TEÓRICO

II.1 Antecedentes de la Investigación

MIÉRCOLES, 16 DE JUNIO DE 2010

INFORME DE AUDITORIA

Identificación del informe

Auditoria de la Ofimática

Identificación del Cliente

El área de Informática

Identificación de la Entidad Auditada

Municipalidad Provincial Mariscal Nieto

Objetivos

 Verificar si el hardware y software se adquieren siempre y cuando tengan


la seguridad de que los sistemas computarizados proporcionaran mayores
beneficios que cualquier otra alternativa.
 Verificar si la selección de equipos y sistemas de computación es
adecuada
 Verificar la existencia de un plan de actividades previo a la instalación
Página |9

 Verificar que los procesos de compra de Tecnología de Información,


deben estar sustentados en Políticas, Procedimientos, Reglamentos y
Normatividad en General, que aseguren que todo el proceso se realiza en
un marco de legalidad y cumpliendo con las verdaderas necesidades de
la organización para hoy y el futuro, sin caer en omisiones, excesos o
incumplimientos.
 Verificar si existen garantías para proteger la integridad de los recursos
informáticos.
 Verificar la utilización adecuada de equipos acorde a planes y objetivos.

Hallazgos Potenciales

 Falta de licencias de software.


 Falta de software de aplicaciones actualizados
 No existe un calendario de mantenimiento ofimatico.
 Faltan material ofimática.

Auditoria De Sistemas

 Carece de seguridad en Acceso restringido de los equipos ofimáticos y


software.

Alcance de la auditoria

Nuestra auditoria, comprende el presente periodo 2004 y se ha realizado


especialmente al Departamento de centro de cómputo de acuerdo a las
normas y demás disposiciones aplicable al efecto.

El alcance ha de definir con precisión el entorno y los límites en que va a


desarrollarse la auditoria Ofimática, se complementa con los objetivos de ésta.
(Auditoría de Sistemas, 2010)

Auditoria de Sistemas

 Elaborar un calendario de mantenimiento de rutina periódico.


 Capacitar al personal.

Fecha del Informe


P á g i n a | 10

Planeamiento Ejecución Informe

FECHAS 01–10–04 al 15–10-04 16-10–04 al 20–11-04 23–11–04 al 28–11-


04

Identificación y Firma del Auditor

Apellidos y Nombres Cargo

Quiñonez Mayta Carmen Auditor Superior. (Auditoría de Sistemas, 2010)

II.2 Bases Teóricas

II.2.1 La Auditoría de Sistemas de Información

A finales del siglo XX, los Sistemas Informáticos se han constituido en las
herramientas más poderosas para materializar uno de los conceptos más
vitales y necesarios para cualquier organización empresarial, los Sistemas de
Información de la empresa.

La Informática hoy, está subsumida en la gestión integral de la empresa, y por


eso las normas y estándares propiamente informáticos deben estar, por lo
tanto, sometidos a los generales de la misma. En consecuencia, las
organizaciones informáticas forman parte de lo que se ha denominado el
"management" o gestión de la empresa. Cabe aclarar que la Informática no
gestiona propiamente la empresa, ayuda a la toma de decisiones, pero no
decide por sí misma. Por ende, debido a su importancia en el funcionamiento
de una empresa, existe la Auditoría Informática.

El término de Auditoría se ha empleado incorrectamente con frecuencia ya


que se ha considerado como una evaluación cuyo único fin es detectar errores
y señalar fallas. A causa de esto, se ha tomado la frase "Tiene Auditoría" como
sinónimo de que, en dicha entidad, antes de realizarse la auditoría, ya se
habían detectado fallas.
P á g i n a | 11

El concepto de auditoría es mucho más que esto. Es un examen crítico que


se realiza con el fin de evaluar la eficacia y eficiencia de una sección, un
organismo, una entidad, etc.

La palabra auditoría proviene del latín auditorius, y de esta proviene la palabra


auditor, que se refiere a todo aquel que tiene la virtud de oír.

Por otra parte, el diccionario Español Sopena lo define como: Revisor de


Cuentas colegiado. En un principio esta definición carece de la explicación del
objetivo fundamental que persigue todo auditor: evaluar la eficiencia y eficacia.

De todo esto sacamos como deducción que la auditoría es un examen crítico


pero no mecánico, que no implica la preexistencia de fallas en la entidad
auditada y que persigue el fin de evaluar y mejorar la eficacia y eficiencia de
una sección o de un organismo.

Los principales objetivos que constituyen a la auditoría Informática son el


control de la función informática, el análisis de la eficiencia de los Sistemas
Informáticos que comporta, la verificación del cumplimiento de la Normativa
general de la empresa en este ámbito y la revisión de la eficaz gestión de los
recursos materiales y humanos informáticos.

El auditor informático ha de velar por la correcta utilización de los amplios


recursos que la empresa pone en juego para disponer de un eficiente y eficaz
Sistema de Información. Claro está, que para la realización de una auditoría
informática eficaz, se debe entender a la empresa en su más amplio sentido,
ya que una Universidad, un Ministerio o un Hospital son tan empresas como
una Sociedad Anónima o empresa Pública. Todos utilizan la informática para
gestionar sus "negocios" de forma rápida y eficiente con el fin de obtener
beneficios económicos y de costos.

Por eso, al igual que los demás órganos de la empresa (Balances y Cuentas
de Resultados, Tarifas, Sueldos, etc.), los Sistemas Informáticos están
sometidos al control correspondiente, o al menos debería estarlo. La
importancia de llevar un control de esta herramienta se puede deducir de
varios aspectos. He aquí algunos:
P á g i n a | 12

 Las computadoras y los Centros de Proceso de Datos se convirtieron


en blancos apetecibles no solo para el espionaje, sino para la
delincuencia y el terrorismo. En este caso interviene la Auditoría
Informática de Seguridad.

 Las computadoras creadas para procesar y difundir resultados o


información elaborada pueden producir resultados o información
errónea si dichos datos son, a su vez, erróneos. Este concepto obvio
es a veces olvidado por las mismas empresas que terminan
perdiendo de vista la naturaleza y calidad de los datos de entrada a
sus Sistemas Informáticos, con la posibilidad de que se provoque un
efecto cascada y afecte a Aplicaciones independientes. En este caso
interviene la Auditoría Informática de Datos.

 Un Sistema Informático mal diseñado puede convertirse en una


herramienta peligrosa para la empresa: como las maquinas
obedecen ciegamente a las órdenes recibidas y la modelización de
la empresa está determinada por las computadoras que materializan
los Sistemas de Información, la gestión y la organización de la
empresa no puede depender de un Software y Hardware mal
diseñados.

Estos son solo algunos de los varios inconvenientes que puede presentar un
Sistema Informático, por eso, la necesidad de la Auditoría de Sistemas.
(Thorin, 1989)

II.2.2 La auditoría

La auditoría nace como un órgano de control de algunas instituciones


estatales y privadas.

La función auditora debe ser absolutamente independiente; no tiene carácter


ejecutivo, ni son vinculantes sus conclusiones. Queda a cargo de la empresa
tomar las decisiones pertinentes. La auditoría contiene elementos de análisis,
P á g i n a | 13

de verificación y de exposición de debilidades y disfunciones. Aunque pueden


aparecer sugerencias y planes de acción para eliminar las disfunciones y
debilidades antedichas; estas sugerencias plasmadas en el Informe final
reciben el nombre de Recomendaciones.

Las funciones de análisis y revisión que el auditor informático realiza, puede


chocar con la psicología del auditado, ya que es un informático y tiene la
necesidad de realizar sus tareas con racionalidad y eficiencia. La reticencia
del auditado es comprensible y, en ocasiones, fundada. El nivel técnico del
auditor es a veces insuficiente, dada la gran complejidad de los Sistemas,
unidos a los plazos demasiado breves de los que suelen disponer para realizar
su tarea.

Además del chequeo de los Sistemas, el auditor somete al auditado a una


serie de cuestionario. Dichos cuestionarios, llamados Check List, son
guardados celosamente por las empresas auditoras, ya que son activos
importantes de su actividad. Las Check List tienen que ser comprendidas por
el auditor al pie de la letra, ya que si son mal aplicadas y mal recitadas se
pueden llegar a obtener resultados distintos a los esperados por la empresa
auditora. La Check List puede llegar a explicar cómo ocurren los hechos pero
no por qué ocurren. El cuestionario debe estar subordinado a la regla, a la
norma, al método. Sólo una metodología precisa puede desentrañar las
causas por las cuales se realizan actividades teóricamente inadecuadas o se
omiten otras correctas.

El auditor sólo puede emitir un juicio global o parcial basado en hechos y


situaciones incontrovertibles, careciendo de poder para modificar la situación
analizada por él mismo. (Asociados, 2005)

II.2.3 El alcance de la Auditoría de Sistemas de Información

El alcance ha de definir con precisión el entorno y los límites en que va a


desarrollarse la auditoría informática, se complementa con los objetivos de
P á g i n a | 14

ésta. El alcance ha de figurar expresamente en el Informe Final, de modo que


quede perfectamente determinado no solamente hasta que puntos se ha
llegado, sino cuales materias fronterizas han sido omitidas. Ejemplo: ¿Se
someterán los registros grabados a un control de integridad exhaustivo*? ¿Se
comprobará que los controles de validación de errores son adecuados y
suficientes*? La indefinición de los alcances de la auditoría compromete el
éxito de la misma.

 Control de integridad de registros:

Hay Aplicaciones que comparten registros, son registros comunes. Si una


Aplicación no tiene integrado un registro común, cuando lo necesite utilizar no
lo va encontrar y, por lo tanto, la aplicación no funcionaría como debería.

 Control de validación de errores:

Se corrobora que el sistema que se aplica para detectar y corregir errores sea
eficiente. (Etchenique J. , 1999)

II.2.4 Características de la Auditoría de Sistemas de


Información

La información de la empresa y para la empresa, siempre importante, se ha


convertido en un Activo Real de la misma, como sus Stocks o materias primas
si las hay. Por ende, han de realizarse inversiones informáticas, materia de la
que se ocupa la Auditoría de Inversión Informática.

Del mismo modo, los Sistemas Informáticos han de protegerse de modo global
y particular: a ello se debe la existencia de la Auditoría de Seguridad
Informática en general, o a la auditoría de Seguridad de alguna de sus áreas,
como pudieran ser Desarrollo o Técnica de Sistemas.

Cuando se producen cambios estructurales en la Informática, se reorganiza


de alguna forma su función: se está en el campo de la Auditoría de
Organización Informática.
P á g i n a | 15

Estos tres tipos de auditorías engloban a las actividades auditoras que se


realizan en una auditoría parcial. De otra manera: cuando se realiza una
auditoria del área de Desarrollo de Proyectos de la Informática de una
empresa, es porque en ese Desarrollo existen, además de ineficiencias,
debilidades de organización, o de inversiones, o de seguridad, o alguna
mezcla de ellas. (Etchenique J. A., 1999)

II.2.5 Síntomas de necesidad de una Auditoría de Sistemas de


Información

Las empresas acuden a las auditorías externas cuando existen síntomas bien
perceptibles de debilidad. Estos síntomas pueden agruparse en clases:

 Síntomas de descoordinación y desorganización:

- No coinciden los objetivos de la Informática de la Compañía y de


la propia Compañía.

- Los estándares de productividad se desvían sensiblemente de


los promedios conseguidos habitualmente.

- [Puede ocurrir con algún cambio masivo de personal, o en una


reestructuración fallida de alguna área o en la modificación de
alguna Norma importante]

 Síntomas de mala imagen e insatisfacción de los usuarios:

- No se atienden las peticiones de cambios de los usuarios.


Ejemplos: cambios de Software en los terminales de usuario,
resfrecamiento de paneles, variación de los ficheros que deben
ponerse diariamente a su disposición, etc.

- No se reparan los desperfectos del Hardware ni se resuelven


incidencias en plazos razonables. El usuario percibe que está
abandonado y desatendido permanentemente.
P á g i n a | 16

- No se cumplen en todos los casos los plazos de entrega de


resultados periódicos. Pequeñas desviaciones pueden causar
importantes desajustes en la actividad del usuario, en especial
en los resultados de Aplicaciones críticas y sensibles.

 Síntomas de debilidades económico-financiero:

- Incremento desmesurado de costos.

- Necesidad de justificación de Inversiones Informáticas (la


empresa no está absolutamente convencida de tal necesidad y
decide contrastar opiniones).

- Desviaciones Presupuestarias significativas.

- Costos y plazos de nuevos proyectos (deben auditarse


simultáneamente a Desarrollo de Proyectos y al órgano que
realizó la petición).

 Síntomas de Inseguridad: Evaluación de nivel de riesgos

- Seguridad Lógica

- Seguridad Física

- Confidencialidad

- [Los datos son propiedad inicialmente de la organización que los


genera. Los datos de personal son especialmente
confidenciales]

- Continuidad del Servicio. Es un concepto aún más importante


que la Seguridad. Establece las estrategias de continuidad entre
fallos mediante Planes de Contingencia* Totales y Locales.

- Centro de Proceso de Datos fuera de control. Si tal situación


llegara a percibirse, sería prácticamente inútil la auditoría. Esa
es la razón por la cual, en este caso, el síntoma debe ser
sustituido por el mínimo indicio. (Asociados, 2005)
P á g i n a | 17

Planes de Contingencia:

Por ejemplo, la empresa sufre un corte total de energía o explota, ¿Cómo sigo
operando en otro lugar? Lo que generalmente se pide es que se hagan
Backups de la información diariamente y que aparte, sea doble, para tener un
Backup en la empresa y otro afuera de ésta. Una empresa puede tener unas
oficinas paralelas que posean servicios básicos (luz, teléfono, agua) distintos
de los de la empresa principal, es decir, si a la empresa principal le proveía
teléfono Telecom, a las oficinas paralelas, Telefónica. En este caso, si se
produce la inoperancia de Sistemas en la empresa principal, se utilizaría el
Backup para seguir operando en las oficinas paralelas. Los Backups se
pueden acumular durante dos meses, o el tiempo que estipule la empresa, y
después se van reciclando. (Asociados, 2005)

II.2.6 Tipos y clases de Auditoría de Sistemas de Información

El departamento de Informática posee una actividad proyectada al exterior, al


usuario, aunque el "exterior" siga siendo la misma empresa. He aquí, la
Auditoría Informática de Usuario. Se hace esta distinción para contraponerla
a la informática interna, en donde se hace la informática cotidiana y real. En
consecuencia, existe una Auditoría Informática de Actividades Internas.

El control del funcionamiento del departamento de informática con el exterior,


con el usuario se realiza por medio de la Dirección. Su figura es importante,
en tanto en cuanto es capaz de interpretar las necesidades de la Compañía.
Una informática eficiente y eficaz requiere el apoyo continuado de su
Dirección frente al "exterior". Revisar estas interrelaciones constituye el objeto
de la Auditoría Informática de Dirección. Estas tres auditorías, más la auditoría
de Seguridad, son las cuatro Áreas Generales de la Auditoría Informática más
importantes.

Dentro de las áreas generales, se establecen las siguientes divisiones de


Auditoría Informática: de Explotación, de Sistemas, de Comunicaciones y de
P á g i n a | 18

Desarrollo de Proyectos. Estas son las Áreas Específicas de la Auditoría


Informática más importantes.

Cada Área Específica puede ser auditada desde los siguientes criterios
generales:

 Desde su propio funcionamiento interno.

 Desde el apoyo que recibe de la Dirección y, en sentido ascendente,


del grado de cumplimiento de las directrices de ésta.

 Desde la perspectiva de los usuarios, destinatarios reales de la


informática.

 Desde el punto de vista de la seguridad que ofrece la Informática en


general o la rama auditada.

 Estas combinaciones pueden ser ampliadas y reducidas según las


características de la empresa auditada. (Asociados, 2005)

II.2.7 Auditoría Informática de Sistemas

Se ocupa de analizar la actividad que se conoce como Técnica de Sistemas


en todas sus facetas. Hoy, la importancia creciente de las telecomunicaciones
ha propiciado que las Comunicaciones, Líneas y Redes de las instalaciones
informáticas, se auditen por separado, aunque formen parte del entorno
general de Sistemas. (Alonso Rivas, 1998)

Sistemas Operativos:

Engloba los Subsistemas de Teleproceso, Entrada/Salida, etc. Debe


verificarse en primer lugar que los Sistemas están actualizados con las últimas
versiones del fabricante, indagando las causas de las omisiones si las hubiera.
El análisis de las versiones de los Sistemas Operativos permite descubrir las
posibles incompatibilidades entre otros productos de Software Básico
adquiridos por la instalación y determinadas versiones de aquellas. Deben
P á g i n a | 19

revisarse los parámetros variables de las Librerías más importantes de los


Sistemas, por si difieren de los valores habituales aconsejados por el
constructor. (Alonso Rivas, 1998)

Software Básico:

Es fundamental para el auditor conocer los productos de software básico que


han sido facturados aparte de la propia computadora. Esto, por razones
económicas y por razones de comprobación de que la computadora podría
funcionar sin el producto adquirido por el cliente. En cuanto al Software
desarrollado por el personal informático de la empresa, el auditor debe
verificar que éste no agreda ni condiciona al Sistema. Igualmente, debe
considerar el esfuerzo realizado en términos de costos, por si hubiera
alternativas más económicas. (Alonso Rivas, 1998)

Software de Teleproceso (Tiempo Real):

No se incluye en Software Básico por su especialidad e importancia. Las


consideraciones anteriores son válidas para éste también. (Alonso Rivas,
1998)

Tunning:

Es el conjunto de técnicas de observación y de medidas encaminadas a la


evaluación del comportamiento de los Subsistemas y del Sistema en su
conjunto. Las acciones de tunning deben diferenciarse de los controles
habituales que realiza el personal de Técnica de Sistemas. El tunning posee
una naturaleza más revisora, estableciéndose previamente planes y
programas de actuación según los síntomas observados. Se pueden realizar:

 Cuando existe sospecha de deterioro del comportamiento parcial o


general del Sistema

 De modo sistemático y periódico, por ejemplo cada 6 meses. En este


caso sus acciones son repetitivas y están planificados y organizados
de antemano.
P á g i n a | 20

El auditor deberá conocer el número de Tunning realizados en el último año,


así como sus resultados. Deberá analizar los modelos de carga utilizados y
los niveles e índices de confianza de las observaciones. (Alonso Rivas, 1998)

Optimización de los Sistemas y Subsistemas:

Técnica de Sistemas debe realizar acciones permanentes de optimización


como consecuencia de la realización de tunnings preprogramados o
específicos. El auditor verificará que las acciones de optimización* fueron
efectivas y no comprometieron la Operatividad de los Sistemas ni el plan
crítico de producción diaria de Explotación. (Alonso Rivas, 1998)

Optimización:

Por ejemplo: cuando se instala una Aplicación, normalmente está vacía, no


tiene nada cargado adentro. Lo que puede suceder es que, a medida que se
va cargando, la Aplicación se va poniendo cada vez más lenta; porque todas
las referencias a tablas es cada vez más grande, la información que está
moviendo es cada vez mayor, entonces la Aplicación se tiende a poner lenta.
Lo que se tiene que hacer es un análisis de performance, para luego
optimizarla, mejorar el rendimiento de dicha Aplicación. (Alonso Rivas, 1998)

Administración de Base de Datos:

El diseño de las Bases de Datos, sean relaciones o jerárquicas, se ha


convertido en una actividad muy compleja y sofisticada, por lo general
desarrollada en el ámbito de Técnica de Sistemas, y de acuerdo con las áreas
de Desarrollo y usuarios de la empresa. Al conocer el diseño y arquitectura de
éstas por parte de Sistemas, se les encomienda también su administración.
Los auditores de Sistemas han observado algunas disfunciones derivadas de
la relativamente escasa experiencia que Técnica de Sistemas tiene sobre la
problemática general de los usuarios de Bases de Datos.
P á g i n a | 21

La administración tendría que estar a cargo de Explotación. El auditor de Base


de Datos debería asegurarse que Explotación conoce suficientemente las que
son accedidas por los Procedimientos que ella ejecuta. Analizará los Sistemas
de salvaguarda existentes, que competen igualmente a Explotación. Revisará
finalmente la integridad y consistencia de los datos, así como la ausencia de
redundancias entre ellos. (Alonso Rivas, 1998)

Investigación y Desarrollo:

Como empresas que utilizan y necesitan de informáticas desarrolladas, saben


que sus propios efectivos están desarrollando Aplicaciones y utilidades que,
concebidas inicialmente para su uso interno, pueden ser susceptibles de
adquisición por otras empresas, haciendo competencia a las Compañías del
ramo. La auditoría informática deberá cuidar de que la actividad de
Investigación y Desarrollo no interfiera ni dificulte las tareas fundamentales
internas.

<La propia existencia de aplicativos para la obtención de estadísticas


desarrollados por los técnicos de Sistemas de la empresa auditada, y su
calidad, proporcionan al auditor experto una visión bastante exacta de la
eficiencia y estado de desarrollo de los Sistemas> (Alonso Rivas, 1998)

II.2.8 ESTANDARES INTERNACIONALES - COBIT (Control


Objectives for Information and related Technology), Cobit versión 4.1 -
Derechos de autor (Copyright ©) 2007 por el IT Governance Institute.

COBIT (Objetivos de Control para Tecnología de Información y Tecnologías


relacionadas), lanzado en 1996, es una herramienta de administración de TI
que ha cambiado la forma en que trabajan los profesionales de TI. Vinculando
tecnología informática y prácticas de control, COBIT consolida y armoniza
estándares de fuentes globales prominentes en un recurso crítico para la
gerencia, los profesionales de control y los auditores.

COBIT se aplica a los sistemas de información de toda la empresa, incluyendo


las computadoras personales, mini computadoras y ambientes distribuidos.
Está basado en la filosofía de que los recursos de TI necesitan ser
P á g i n a | 22

administrados por un conjunto de procesos naturalmente agrupados para


proveer la información pertinente y confiable que requiere una organización
para lograr sus objetivos (Association, 2005).

Misión:

“Investigar, desarrollar, publicar y promover un conjunto actualizado de


objetivos de control para la tecnología de información que sea de uso cotidiano
para gerentes y auditores”

 La Gerencia: para apoyar sus decisiones de inversión en TI y control


sobre el rendimiento de las mismas, analizar el costo beneficio del
control.

 Los Usuarios Finales: quienes obtienen una garantía sobre la


seguridad y el control de los productos que adquieren interna y
externamente.

 Los Auditores: para soportar sus opiniones sobre los controles de los
proyectos de TI, su impacto en la organización y determinar el control
mínimo requerido.

 Los Responsables de TI: para identificar los controles que requieren en


sus áreas. (Association, 2005)

Visión:

COBIT ofrece una visión y ámbito de aplicación mucho más allá de una
auditoría.

Se trata de la convergencia entre los requerimientos de negocio, los recursos


de TI y los procesos de TI. Se podría afirmar que la auditoría es una pequeña
parte del COBIT, que conformará la percepción sobre la calidad y procesos e
incluso propondrá algunas buenas prácticas para la mejora. (Association,
2005)
P á g i n a | 23

II.2.8.1 Breve introducción a COBIT

La Misión de COBIT es la siguiente: "Investigar, desarrollar, publicar y


promover un conjunto de objetivos de control, tecnología de información con
autoridad, actualizados, de carácter internacional y aceptados generalmente
para el uso cotidiano de gerentes de empresas y auditores." (ISACAF-EXS,
2000).

COBIT está diseñado como un estándar aplicable y aceptable en general para


la buena práctica de la auditoría de las tecnologías de la Información en todo
el mundo. El producto COBIT utiliza los Objetivos de Control de ISACA,
mejorados con estándares específicos de tipo técnico, profesional, normativo
e industrial existentes y emergentes. Los objetivos de control se han
desarrollado para su aplicación en el amplio espectro de sistemas de
información en la empresa. Estos objetivos de control tienen en cuenta lo
siguiente:

 Adecuación a los estándares y normativas legislativas y de hecho


existentes que se aplican en el marco global, así como en los objetivos de
control individuales.

 Revisión crítica de las diferentes actividades y tareas bajo los dominios de


control y posibilitando la especificación de indicadores de prestaciones
importantes (normas, reglas, etc.)

 Establecimiento de unas directrices y fundamentos para proporcionar


investigación consistente sobre los temas de auditoría y control de TI.

El sistema consiste en objetivos de control de TI de alto nivel y una estructura


global para su clasificación y funcionamiento. La teoría subyacente para la
clasificación elegida, en línea con las experiencias de Re-Ingeniería, es que
hay, en esencia tres niveles de esfuerzos en TI cuando se considera la gestión
de los recursos de TI:
P á g i n a | 24

 Actividades: las actividades, junto con las tareas están en el nivel inferior.
Las actividades tienen el concepto de ciclo de vida mientras que las tareas
se consideran discretas en el tiempo.

 Procesos: se definen en un nivel superior como series de actividades


unidas con puntos de control naturales.

 Dominios: correspondientes al nivel superior, son agrupaciones de


procesos. COBIT distingue cuatro dominios en línea con el ciclo de gestión
o el ciclo de vida aplicables a los procesos de TI (véase la Figura 1):

El marco conceptual se enfoca desde tres puntos de vista distintos: criterios


de gestión para la información, recursos de TI y procesos de TI. Estos tres
puntos de vista se ensamblan en un formato cúbico y permiten que se
obtengan referencias cruzadas en dicho marco y se pueda acceder a él
eficientemente (véase la Figura 2).

Los objetivos de control de TI están organizados inicialmente


por proceso/actividad, pero las ayudas para la navegación que se aportan,
facilitan la entrada desde cualquier punto estratégico. También facilitan la
adopción de enfoques combinados o globales, tal como la
instalación/implementación de un proceso, responsabilidades de gestión
global para un proceso, y el uso de los recursos de TI por un proceso.

La información que los procesos de gestión necesitan está proporcionada por


el uso de los recursos de TI. Para asegurar que los requisitos de gestión para
la información se aplican, se tiene que definir medidas de control adecuadas,
se tiene que implementarlas y monitorizarlas sobre estos recursos. Está claro
que no todas las medidas de control satisfarán los requisitos de gestión en el
mismo grado, así que se hace una distinción en COBIT contemplando el
cumplimiento:

 Primario (P): grado en que el objetivo de control satisface completamente


el requisito de información correspondiente.
P á g i n a | 25

 Secundario (S): grado en que el objetivo de control satisface solamente


en menor extensión o indirectamente el requisito de información
correspondiente.

Figura 1. Recursos de TI, Objetivos


Figura 2. El Cubo COBIT
de Negocio y Dominios de COBIT
P á g i n a | 26

"Derechos de autor 1996, 1998, Fundación de Auditoría y Control de Sistemas


de Información 2000. Reimpreso con el permiso de la Fundación de Auditoría
y Control de Sistemas de Información y TI Governance Institute." (Bernal R.,
1996)

II.2.8.2 COBIT cubre cuatro dominios:

 Planificación y Organización

 Adquisición e Implementación

 Servicio y Soporte

 Monitoreo

II.2.8.2.1 Planificación y Organización

La Planificación y el dominio de Organización cubren el empleo de tecnología


y como esto puede ser usado en una empresa para ayudar a alcanzar los
objetivos. Esto también destaca la forma de organización e infraestructura de
TI que debe tomar para alcanzar los resultados óptimos y generar ventajas
del empleo de TI. La mesa siguiente cataloga los objetivos de control de nivel
alto para el dominio de Organización y la Planificación. (Association, 2005)

PO1 Definen un Plan Estratégico de TI

PO2 Definen la Arquitectura de Información

PO3 Determinan Dirección Tecnológica

PO4 Definen los Procesos de TI, Organización y Relaciones

PO5 Manejan la Inversión TI

PO6 Comunican Objetivos de Dirección

PO7 Manejan Recursos Humanos de TI


P á g i n a | 27

PO8 Manejan Calidad

PO9 Evalúan y Manejan Riesgos de TI

PO10 Manejan Proyectos

II.2.8.2.2 Adquisición e Implementación

Para llevar a cabo la estrategia de TI, las soluciones deben ser identificadas,
desarrolladas o adquiridas, así como implementadas e integradas dentro del
proceso del negocio. Además, este dominio cubre los cambios y el
mantenimiento realizados a sistemas existentes. (Association, 2005)

AI1 Identifican Soluciones Automatizadas

AI2 Adquieren y Mantienen Software de aplicación

AI3 Adquieren y Mantienen Infraestructura de Tecnología

AI4 Desarrollan y Mantienen procedimientos relacionados con TI

AI5 Instalan y Acreditan Sistemas

AI6 Administran Cambios

II.2.8.2.3 Servicios y Soporte

En este dominio se hace referencia a la entrega de los servicios requeridos,


que abarca desde las operaciones tradicionales hasta el entrenamiento,
pasando por seguridad y aspectos de continuidad. Con el fin de proveer
servicios, deberán establecerse los procesos de soporte necesarios. Este
dominio incluye el procesamiento de los datos por sistemas de aplicación,
frecuentemente clasificados como controles de aplicación. (Association, 2005)

DS1 Definir niveles de servicio

DS2 Administrar Servicios de Terceros

DS3 Administrar Desempeño y Capacidad

DS4 Asegurar Servicio Continuo


P á g i n a | 28

DS5 Garantizar la Seguridad de Sistemas

DS6 Identificar y Asignar Costos

DS7 Capacitar Usuarios

DS8 Asistir a los Clientes de TI

DS9 Administrar la Configuración

DS10 Administrar Problemas e Incidentes

DS11 Administrar Datos

DS12 Administrar Instalaciones

DS13 Administrar Operaciones

II.2.8.2.4 Monitoreo

Todos los procesos necesitan ser evaluados regularmente a través del tiempo
para verificar su calidad y suficiencia en cuanto a los requerimientos de
control. (Association, 2005)

M1 Monitoreo del Proceso

M2 Evaluar lo adecuado del Control Interno

M3 Obtención de Aseguramiento Independiente

M4 Proveer Auditoria Independiente


P á g i n a | 29

II.2.8.3 Navegación en el Marco de Trabajo COBIT

Para cada uno de los procesos TI de COBIT, se proporciona un objetivo de


control de alto nivel, junto con las metas y métricas clave en forma de cascada.
(Association, 2005)

Figura 3. Marco de trabajo COBIT


P á g i n a | 30

II.2.8.4 Áreas de enfoque del Gobierno de TI

Figura 4. Área del Gobierno de TI

Directrices Gerenciales

Las entradas y salidas se han añadido para ilustrar lo que los procesos
necesitan de otros y lo que típicamente generan. También se proporcionan
actividades y responsabilidades asociadas. Las entradas y las metas de las
actividades reemplazan a los factores críticos de éxito de COBIT 3ra Edición.
Las métricas ahora se basan en una cascada consistente de metas de
negocio, metas de TI, de proceso y de actividades. El juego de métricas de
COBIT 3ra Edición también se corrigió y mejoró para hacerlo más
representativo y medible. (Association, 2005)
P á g i n a | 31

Figura 5. PO1 Definir un Plan Estratégico de TI

Figura 6. Matriz RACI


P á g i n a | 32

Figura 7. Metas y Métricas

II.2.9 MCIIEF - Manual de Control Interno Informático para


Entidades Financieras de la Superintendencia de Bancos, del
Banco Central del Paraguay

De modo a demostrar y comentar las normativas que afectan a la seguridad


del área de informática, en nuestro mercado la única instancia de control, y
que se encuentra implementado para las entidades regidas por la
Superintendencia de Bancos del Banco Central del Paraguay, es el Manual
P á g i n a | 33

de Control Interno para Entidades Financieras, aprobado por resolución Nº


188 del año 2002.

Está basado primariamente en Normas de Control Interno en el ámbito de la


TI, provenientes de publicaciones de instituciones de renombre internacional
y autores destacados especialistas en el tema, y en especial, las Normas
contenidas en los que a juicio de la Superintendencia de Bancos, constituyen
los principales cuerpos normativos actuales en la materia. El Manual se
encuentra redactado y clasificado según las medidas de control que deben
ser aplicadas en las diversas áreas de actividad relacionada con la TI. A
continuación, se detallan el alcance de dicho manual, lo cual se encuentra
desarrollado íntegramente, las áreas definidas a efectos del Manual de
Control Informático son las siguientes: (Paraguay, 2002)

II.2.9.1 Planificación y Organización

Abarca las decisiones estratégicas y tácticas que definen la manera en que la


TI contribuirá de mejor manera para el logro de los objetivos de la Entidad.
También se refiere a la manera en que esta visión estratégica genera planes,
organización, infraestructura tecnológica y procedimientos administrativos.
(Paraguay, 2002)

 Definición del Plan Estratégico de TI: La TI como parte de los Planes


de la Entidad, Plan de TI a Largo Plazo, Método, Estructura en la
elaboración Planes de TI a Largo Plazo, Modificaciones del Plan de TI
a Largo Plazo, Plan de TI a Corto Plazo, Evaluación de los Sistemas
existentes.

 Definición de la arquitectura de información: Modelo de la Arquitectura


de Información, Diccionario de Datos Corporativo y Reglas de Sintaxis
de Datos, Esquema de Clasificación de Datos, Niveles de Seguridad
de Datos.
P á g i n a | 34

 Determinación de la dirección tecnológica: Plan de Infraestructura


Tecnológica, Monitoreo de Tendencias Futuras y Regulaciones, Planes
de Contingencia e Infraestructura Tecnológica, Planes de Adquisición
de Hardware y Software, Normas Tecnológicas.

 Definición de la Organización y Relacionamientos de la Unidad


Funcional de TI: Comité de Dirección y Planificación de los Servicios
de TI, Ubicación, Estructural del Área de Servicios de TI, Revisión
estructural de la Gerencia de TI de la Entidad, Funciones y
Responsabilidades, Responsabilidad de la Seguridad Física y Lógica,
Propiedad y Custodia de Datos y Sistemas.

 Separación de Responsabilidades: Dotación de Personal de Servicios


de TI, Descripción de Cargos del Personal de Servicios de TI, Personal
clave de TI, Relacionamiento.

 Administración de la inversión en TI: Presupuesto anual de la Unidad


Funcional de Servicios de TI Monitoreo del Costo/Beneficio,
Justificación de Costos y Beneficios.

 Administración de Recursos Humanos: Calificación del personal,


Entrenamiento del personal, Personal de respaldo, Evaluación del
trabajo del Personal.

 Cumplimiento de requisitos externos: Revisión de los Requisitos


Externos, Prácticas y Procedimientos para Cumplir con requisitos
Externos, Operaciones Electrónicas, Cumplimiento de los
requerimientos de Compañías de Seguros.

 Administración de Proyectos: Esquema de Administración de


Proyectos de TI de la Entidad, Participación de Usuario en el inicio del
Proyecto, Formación del Equipo de Proyecto y Asignación de
Responsabilidades, Definición del proyecto, Aprobación del proyecto,
Estudio de Viabilidad Tecnológica, Estudio de Viabilidad Económica,
Conversión, Aprobación de Fase de proyecto, Plan Maestro del
Proyecto, Plan de Control de Calidad de Sistemas, Planificación de
P á g i n a | 35

Métodos de Seguridad, Formalización de la Administración de Riesgos


del Proyecto, Plan de Pruebas del Proyecto, Plan de Entrenamiento.

 Administración de la Calidad: Plan General de Calidad, Esquema de


Garantía de Calidad, Compatibilidad de la revisión de Garantía de
Calidad con las Normas y Procedimientos habituales en funciones de
TI, Metodología de Desarrollo de Sistemas, Actualización de la
Metodología de Desarrollo de Sistemas respecto a Cambios en la TI,
Coordinación y Comunicación, Relaciones con Proveedores que
Desarrollan Sistemas, Normas de Documentación de Programas.

 Normas de Pruebas de Programas: Normas respecto a la Prueba de


Sistemas, Pruebas Piloto o en Paralelo, Documentación de las Pruebas
de Sistemas, Evaluación del cumplimiento de Garantía de Calidad de
las Normas de Desarrollo, Revisión de Garantía de Calidad del logro
de los Objetivos de la Unidad Funcional de TI.

II.2.9.2 Adquisición e Implementación:

Para poner en práctica las estrategias definidas se deben identificar


soluciones de TI, adquirirlas o desarrollarlas, y por supuesto hacerlas
operativas, implementando e integrándolas como procedimientos del día a
día. Forman parte de esta área todas las modificaciones que hacen posible
la continuidad operativa de lo implantado, tanto para adecuaciones que
devienen de cambios en el entorno como aquellas que se refieren a mejoras
operativas. (Paraguay, 2002)

 Identificación de Soluciones: Control de Adquisiciones, Definición de


Requisitos de la Información, Requisitos de Servicios de Terceros,
Diseño de Pistas de Auditoría, Selección de Software de Base,
Aceptación de Tecnología.

 Desarrollo y Mantenimiento de Software de Aplicación: Métodos de


Diseño Grandes de Cambios en los Sistemas Existentes, Aprobación
P á g i n a | 36

del Diseño, Aprobación de la Funcionalidad del Sistema, Definición de


Requisitos de Archivos y Documentación, Especificaciones de los
Programas Críticos, Definición de las Interfases, Definición de
Requisitos de Proceso y Documentación, Requisitos de Control,
Verificación de Software de Aplicación, Guías del Usuario y Materiales
de Apoyo.

 Adquisición y Mantenimiento de la Infraestructura de Tecnología:


Evaluación del Nuevo Hardware y Software, Mantenimiento Preventivo
del Hardware, Instalación de Software de Base, Seguridad de Software
de Base, Mantenimiento de Software de Base, Control de Cambios del
Software de Base.

 Instalación y Autorización de Sistemas: Criterio para Pruebas Piloto y


Pruebas en Paralelo, Prueba de Cambios, Prueba de Aceptación Final,
Prueba de la Seguridad y Autorización, Paso a Producción.

 Administración de Cambios de Sistemas de Aplicación: Pedido de


Cambios y Control, Evaluación del Impacto, Documentación y
Procedimientos, Autorización del Mantenimiento, Distribución de
Software.

II.2.9.3 Producción y Servicios:

Esta área abarca las actividades que relacionadas con los sistemas en
producción de los servicios de TI, engloban las actividades tradicionales de
producción, las de entrenamiento, los procedimientos para garantizar la
continuidad de los servicios, operaciones de seguridad, etc. También abarcan
las actividades de soporte a los sistemas en producción. Esta área incluye el
procesamiento de los datos por sistemas de aplicación. (Paraguay, 2002)

 Administración de Servicios de Terceros: Mantenimiento del Software


Adquirido de Terceros, Contratos de Servicios, Calificaciones
Proveedores, Monitoreo.
P á g i n a | 37

 Garantizar la Continuidad del Servicio: Plan de Continuidad de TI,


Mantenimiento del Plan de Continuidad de TI, Prueba del Plan de
Continuidad de TI, Entrenamiento respecto al Plan de Continuidad de
TI, Distribución del Plan de Continuidad de TI, Recursos
Fundamentales de TI, Local y Hardware de Respaldo.

 Garantizar la Seguridad de los Sistemas: Administración de las


Medidas de Seguridad, Identificación, Autenticación y Acceso,
Seguridad de Acceso en Línea a los Datos, Administración de las
Cuentas del Usuario, Violaciones e Informes de Actividad de
Seguridad, Mantenimiento de Privilegios de Acceso, Administración de
Claves de Encriptación, Medidas de Seguridad y Conexiones con
Redes Públicas.

 Asistencia y Asesoría a Usuarios: Área de Asistencia a Usuarios,


Registro de Solicitudes de Usuarios, Priorización de Solicitudes de
Usuarios, Monitoreo de Soluciones a las Solicitudes de Usuarios,
Análisis de Tendencias e Informes.

 Administración de Datos: Verificación de Exactitud, Integridad y


Validez, Tratamiento de Errores de Datos de Entrada, Integridad del
Procesamiento de Datos, Tratamiento y Retención de Salidas,
Distribución de la Salida, emitidas en el departamento de TI, Protección
de Datos Confidenciales durante su Transmisión y Transporte,
Responsabilidades de Administración de la Biblioteca de Medios de
Almacenamiento, Respaldo, Almacenamiento y Restauración.

 Administración de Soportes y Seguridad Física: Seguridad Física,


Escolta del Visitante, Protección contra Factores del Medio Ambiente,
Alimentación Eléctrica no Interrumpible.

 Administración de Operaciones: Software no Autorizado,


Procedimientos de Operación y Manual de Instrucciones, Continuidad
del Procesamiento, Registro de Operaciones, Operaciones Remotas.
P á g i n a | 38

II.2.9.4 Monitoreo:

Todos los procesos de TI deben ser evaluados regularmente, tanto en cuanto


a su calidad, como al cumplimiento de los requerimientos de control. Esta
área atiende la participación de la gerencia y demás órganos de línea en los
procesos de retroalimentación de los mecanismos de verificación y la
evaluación proveniente de auditorías internas y externas. (Paraguay, 2002)

 Obtención de Certificación Independiente: Certificación Independiente


de la Seguridad y el Control Interno de TI, Certificación Independiente
de la Seguridad y Servicios de Proveedores Externos, Evaluación
Independiente de la Efectividad de los Servicios de TI, Certificación
Independiente de Cumplimiento con Leyes, Regulaciones, Normativas
y Compromisos Contractuales.

 Implementación de Auditoría Informática Interna: Carácter de la


Auditoría Informática, Independencia, Ética Profesional y Normas.

 Calificación de los Auditores Internos: Planificación del trabajo de


Auditoría Informática, Desempeño del Trabajo de Auditoría Informática,
Informes de Auditoría Informática.

II.2.10 Tecnologías de Información

Un elemento crítico para el éxito y la supervivencia de las organizaciones, es


la administración efectiva de la información y de la Tecnología de Información
(TI) relacionada. En esta sociedad global (donde la información viaja a través
del “ciberespacio” sin las restricciones de tiempo, distancia y velocidad) esta
criticidad emerge de: > La creciente dependencia en información y en los
sistemas que proporcionan dicha información > La creciente vulnerabilidad y
un amplio espectro de amenazas, tales como las “ciber amenazas” y la guerra
de información > El costo de las inversiones actuales y futuras en información
y en tecnología de información; y > El potencial que tienen las tecnologías
P á g i n a | 39

para cambiar radicalmente las organizaciones y las prácticas de negocio,


crear nuevas oportunidades y reducir costos. Para muchas organizaciones, la
información y la tecnología que la respalda, representan los activos más
valiosos de la empresa, por lo que la gestión de los riesgos asociados de la
Tecnología de Información, o Gobernabilidad de TI (IT Governance), ha
ganado notoriedad en tiempos recientes como un aspecto clave de la
gobernabilidad corporativa, dada su capacidad de proporcionar valor
agregado al negocio, balanceando la relación entre el riesgo y el retorno de la
inversión sobre TI y sus procesos. Estos aspectos se enfatizan en el Marco
de referencia COBIT, el cual se define como conjunto de Objetivos de Control
para la Información y Tecnologías Relacionadas. Bajo este escenario, una
adecuada administración de los recursos de TI es fundamental para mejorar
la calidad de los productos y servicios brindados por el área, lo que se reflejará
en mejoras en los procesos que respalda, y en el nivel de seguridad y control
con el cual se trabaja, elevando su capacidad para satisfacer los objetivos de
cumplimiento definidos en la estructura de control interno de la organización,
reduciendo además los costos administrativos asociados al entorno
informático. (COBIT), define un marco de referencia que clasifica los procesos
de las unidades de tecnología de información de las organizaciones en cuatro
(4) “dominios” principales, a saber: - Planificación y organización - Adquisición
e implantación - Soporte y Servicios - Monitoreo Estos dominios agrupan
objetivos de control de alto nivel, que cubren tanto los aspectos de
información, como de la tecnología que la respalda. En conjunto, estos
dominios y los objetivos de control, facilitan que la generación y
procesamiento de la información cumplan con las características de
efectividad, eficiencia, confidencialidad, integridad, disponibilidad,
cumplimiento y confiabilidad. Asimismo, se deben tomar en cuenta los
recursos que proporciona la Tecnología de Información, tales como: datos,
sistemas de aplicación, tecnología (plataformas), instalaciones y el recurso
humano. (COBIT, 2007)
P á g i n a | 40

II.2.11 Breve Presentación de la Organización Auditada

II.2.11.1 Descripción de la Organización.

La Municipalidad de Raúl Arsenio Oviedo posee una organización que regida


por las leyes institucionales implementado por otras Instituciones Estatales
superiores y a la vez basándose bajo sus propias leyes Orgánicas Internas
que son las Ordenanzas.

Partiendo de las jerarquías institucionales el Intendente con su Secretario, la


Junta Municipal y demás Funcionarios, se encargan de llevar a cabo las
funciones necesarias para el logro de todos los objetivos previstos.

II.2.11.2 Principales Funciones.

Las principales funciones por la cual se basa la Municipalidad son;

 la de velar por la seguridad ciudadana,

 ejecutar proyectos para el beneficio de la comunidad,

 Generar fuente de trabajo a través de los proyectos previstos,

 Buscar el bien común sin distinción de raza, religión, preferencia


política u otras diferencias étnicas,

 Buscar la forma de obtener los recursos necesarios para la ejecución


de los proyectos,

 Utilizar adecuadamente dichos recursos para el bien de la comunidad.


P á g i n a | 41

II.2.11.3 Tipo de forma de Organización.

Como todas las instituciones, ya sean privadas o públicas, posee una


organización que funciona bajo el nivel de la Jerarquía, lo que es común en
todas las organizaciones.

II.2.11.4 Actividades de Planificación.

Las actividades que son planificadas son expuestas en los presupuestos


anuales que una vez aprobadas por la junta Municipal pasa al Ministerio de
Hacienda para su posterior visto bueno; hecha las operaciones necesarias
para obtener los recursos se procede a ejecutarlas siguiendo lo planificado en
el presupuesto.
P á g i n a | 42

II.2.11.5 Estructura de la Municipalidad de Raúl Arsenio Oviedo

Junta Intendencia
Municipal Municipal

MESA DE
ENTRADA
SECRETARIA S
Secretaria GENERAL ARCHIVO
Municipal

DIRECCION DE DIRECCION DE DIRECCION DE


HIGIENE ADMINISTRACION SEGURIDAD Y TRANSITO
SALUBRIDAD Y Y FINANZAS
AMBIENTE
POLICIA
MUNICIPAL
CAJA

LIQUIDACION

Figura 8. Organigrama de la Municipalidad de Raúl Arsenio Oviedo

El 80% de los movimientos de la Municipalidad son realizados mediante


tecnologías informáticas, aproximadamente de los movimientos
administrativos y finanzas, liquidación de patentes (comercial, inmobiliario),
dirección de seguridad y tránsito, se hizo un análisis preliminar de la situación
actual de la entidad, y se han detectado muchas falencias que se orientan a
la parte tecnológica y de documentos para cada operación, por lo tanto los
directivos han solicitado una auditoría.
P á g i n a | 43

II.2.11.6 A continuación describimos lo disponible en Hardware y


Software:

II.2.11.6.1 Hardware

Un servidor dedicado intel(R) Core(TM) i3-220, con 4 Gb. de memoria RAM,


un disco de 500 Gb, SIETE estaciones Clientes. con 3 Gb memoria RAM, dd
de 500 Gb, Cinco impresora HP inyección de tinta, Dos impresora Samsung
ML-2465 con tonner, Tres impresora con fotocopiadora Brother DCP-8085DN
Printer con Tonner.

II.2.11.6.2 Software

Sistema operativo Windows XP Profesional con licencia, usado como un


sistema de red.

Windows XP con licencia para 7 usuarios.

Office 2007 con licencia para 7 usuarios

Sistemas de Gestión Tributaria Municipal: Tránsito, liquidación, caja, libro de


bancos, ingresos y gastos, con el lenguaje de programación FoxPro.

II.3 Aspectos Legales

II.3.1 Código Penal Paraguayo Ley Nº 1160/97

CAPÍTULO II

HECHOS PUNIBLES CONTRA OTROS DERECHOS PATRIMONIALES

ARTÍCULO 174. – ALTERACIÓN DE DATOS.

1º El que lesionando el derecho de disposición de otro sobre datos los borrara,


suprimiera, inutilizara o cambiara, será castigado con pena privativa de
libertad de hasta dos años o con multa.
P á g i n a | 44

2º En estos casos, será castigada también la tentativa.

3º Como datos, en el sentido del inciso 1º, se entenderán sólo aquellos que
sean almacenados o se transmitan electrónica o magnéticamente, o en otra
forma no inmediatamente visible. (Justicia, 2001)

ARTÍCULO 175. – SABOTAJE DE COMPUTADORAS

1º El que obstaculizara un procesamiento de datos de importancia vital para


una empresa o establecimiento ajenos, o una entidad de la administración
pública mediante:

1. un hecho punible según el artículo 174, inciso 1º, o

2. la destrucción, inutilización sustracción o alteración de una instalación de


procesamiento de datos, de una unidad de almacenamiento o de otra parte
accesoria vital, será castigado con pena privativa de libertad de hasta cinco
años o con multa. (Justicia, 2001)

2º En estos casos, será castigada también la tentativa.

Artículo 188.- Operaciones fraudulentas por computadora

1º El que con la intención de obtener para sí o para otro un beneficio


patrimonial indebido, influyera sobre el resultado de un procesamiento de
datos mediante: (Justicia, 2001)

1. programación falsa;

2. utilización de datos falsos o incompletos;

3. utilización indebida de datos; o otras influencias indebidas sobre el


procesamiento, y con ello, perjudicara el patrimonio de otro, será castigado
con pena privativa de libertad de hasta cinco años o con multa.

2º En estos casos, se aplicará también lo dispuesto en el artículo 187, incisos


2º al 4º.

La Ley 4439 representa una modificación del Código Penal, fue


sancionada en el Congreso Nacional el 8 de septiembre de 2011,
P á g i n a | 45

promulgada por el Poder Ejecutivo el 3 de octubre de 2011 y publicada


el 5 de octubre de 2011 en la Gaceta Oficial N° 192.

II.3.2 Ley Nº 4439

QUE MODIFICA Y AMPLIA VARIOS ARTICULOS DE LA LEY N° 1160/97


“CODIGO PENAL”

EL CONGRESO DE LA NACION PARAGUAYA SANCIONA CON FUERZA


DE LEY

Artículo 1°.- Modifícanse los Artículos 140, 175, y 188 de la Ley N° 1160
“CODIGO PENAL”, de fecha 26 de noviembre de 1997, modificado
parcialmente por la Ley N° 3440 del 16 de julio de 2008 y amplíase el Código
Penal, introduciendo en la misma los Artículos 146 b, 146 c, 146 d, 174 b, 175
b, y 248 b, los cuales quedan redactados de la siguiente manera: (Legislativo,
2008)

“Art. 140.- Pornografía relativa a niños y adolescentes.

1° El que:

1. produjere publicaciones, en el sentido del Artículo 14, inciso 3°, que


representen actos sexuales con participación de personas menores de
dieciocho años de edad o la exhibición de sus partes genitales;

2. organizará, financiara o promocionara espectáculos, públicos o privados,


en los que participe una persona menor de dieciocho años en la realización
de actos sexuales, o;

3. distribuyera, importara, exportara, ofertara, canjeara, exhibiera, difundiera,


promocionara o financiara la producción o reproducción de publicaciones en
sentido del numeral 1, será castigado con pena privativa de libertad de hasta
cinco años o multa.
P á g i n a | 46

2° El que reprodujera publicaciones según el numera l 1 del inciso 1°, será


castigado con pena privativa de libertad de hasta tres años o multa.

3° La pena de los incisos anteriores podrá ser aumentada hasta diez años
cuando:

1. las publicaciones y espectáculos en el sentido de los incisos 1° y 2° se


refieran a menores de catorce años o se dé acceso a los menores de dicha
edad a publicaciones y espectáculos, en sentido de los incisos citados;

2. el autor tuviera la patria potestad, deber de guarda o tutela del niño o


adolescente, o se le hubiere confiado la educación o cuidado del mismo;

3. el autor operara en connivencia con personas a quienes competa un deber


de educación, guarda o tutela respecto del niño o adolescente;

4. el autor hubiere procedido, respecto del niño o adolescente, con violencia,


fuerza, amenaza, coacción, engaño, recompensa o promesa remuneratoria
de cualquier especie; o

5. el autor actuara comercialmente o como miembro de una banda dedicada


a la realización reiterada de los hechos punibles señalados.

4° El que obtuviera la posesión de publicaciones en el sentido de los incisos


1° y

3°, será castigado con pena privativa de libertad de hasta tres años o con
multa.

5° Se aplicará, en lo pertinente, también lo dispuesto en los Artículos 57 y 94.”

“Artículo 146 b.- Acceso indebido a datos.

1° El que sin autorización y violando sistemas de seguridad obtuviere para sí


o para terceros, el acceso a datos no destinados a él y especialmente
protegidos contra el acceso no autorizado, será castigado con pena privativa
de libertad de hasta tres años o multa.
P á g i n a | 47

2° Como datos en sentido del inciso 1°, se entenderán solo aquellos, que se
almacenan o transmiten electrónicamente, magnéticamente o de otra manera
no inmediatamente visible.” (Legislativo, 2008)

“Artículo 146 c.- Interceptación de datos.

El que, sin autorización y utilizando medios técnicos:

1° obtuviere para sí o para un tercero, datos en sentido del Artículo 146 b,


inciso 2°, no destinados para él;

2° diera a otro una transferencia no pública de datos; o

3° transfiriera la radiación electromagnética de un equipo de procesamiento


de datos, será castigado con pena privativa de libertad de hasta dos años o
multa, salvo que el hecho sea sancionado por otra disposición con una pena
mayor.”

“Artículo 146 d.- Preparación de acceso indebido e interceptación de datos.

1° El que prepare un hecho punible según el Artículo 146 b o el Artículo 146 c


produciendo, difundiendo o haciendo accesible de otra manera a terceros:

1. las claves de acceso u otros códigos de seguridad, que permitan el acceso


a datos en sentido del Artículo 146 b, inciso 2°; o

2. los programas de computación destinados a la realización de tal hecho,


será castigado con pena privativa de libertad de hasta un año o multa.

2° Se aplicará, en lo pertinente, lo previsto en el Artículo 266, incisos 2° y 3°.”

“Artículo 174 b.- Acceso indebido a sistemas informáticos.

1° El que accediere a un sistema informático o a su s componentes, utilizando


su identidad o una ajena; o excediendo una autorización, será castigado con
pena privativa de libertad de hasta tres años o multa.

2° Se entenderá como sistema informático a todo dispositivo aislado o al


conjunto de dispositivos interconectados o relacionados entre sí, cuya función,
P á g i n a | 48

o la de alguno de sus componentes, sea el tratamiento de datos por medio de


un programa informático.”

Nos parece bastante plausible esta segunda reforma del Código Penal. Se
han cubierto algunas lagunas de punibilidad importantes, que surgieron
debido a que los adelantos tecnológicos convirtieron a los clásicos delitos
contra la intimidad, el patrimonio y la prueba documental como ineficientes
para proteger dichos bienes jurídicos. (Ricardo Preda del Puerto, consultor
ICED) (Legislativo, 2008)

“Art. 175.- Sabotaje de sistemas informáticos.

1° El que obstaculizara un procesamiento de datos de un particular, de una


empresa, asociación o de una entidad de la administración pública, mediante:

1. un hecho punible según el Artículo 174, inciso 1°; o

2. la destrucción, inutilización, sustracción o alteración de una instalación de


procesamiento de datos, de una unidad de almacenamiento o de otra de sus
partes componentes indispensable.

Será castigado con pena privativa de libertad de hasta cinco años o con multa.

2° En estos casos será castigada también la tentativa.” (Legislativo, 2008)

“Artículo 175 b.- Instancia.

En los casos de los Artículos 174 y 175, la persecución penal dependerá de


la instancia de la víctima; salvo que la protección del interés público requiera
la persecución de oficio.” (Legislativo, 2008)

“Artículo 188.- Estafa mediante sistemas informáticos.

1° El que, con la intención de obtener para sí o para un tercero un beneficio


patrimonial indebido, influyera sobre el resultado de un procesamiento de
datos mediante: (Legislativo, 2008)

1. una programación incorrecta;

2. el uso de datos falsos o incompletos;


P á g i n a | 49

3. el uso indebido de datos; u

4. la utilización de otra maniobra no autorizada; y con ello causara un perjuicio


al patrimonio de otro, será castigado con pena privativa de libertad de hasta
cinco años o con multa.

2° En estos casos, se aplicará también lo dispuesto en el Artículo 187, incisos


2° al 4°.

3° El que preparare un hecho punible señalado en el inciso 1°, mediante la


producción, obtención, venta, almacenamiento u otorgamiento a terceros de
programas de computación destinados a la realización de tales hechos, será
castigado con pena privativa de libertad de hasta tres años o con multa.

4° En los casos señalados en el inciso 3°, se aplicará lo dispuesto en el


Artículo 266, incisos 2° y 3°.”

“Artículo 248 b.- Falsificación de tarjetas de débito o de crédito y otros


medios electrónicos de pago. (Legislativo, 2008)

1° El que, con la intención de inducir en las relaciones jurídicas al error o de


facilitar la inducción a tal error:

1. falsificare o alterare una tarjeta de crédito o débito u otro medio electrónico


de pago; o

2. adquiera para sí o para un tercero, ofreciere, entregare a otro o utilizare


tales tarjetas o medios electrónicos, será castigado con pena privativa de
libertad de hasta cinco años o con multa.

2° Se castigará también la tentativa.

3° Cuando el autor actuara comercialmente o como miembro de una


organización criminal dedicada a la realización de los hechos punibles
señalados, la pena privativa de libertad podrá ser aumentada hasta diez años.

4° Tarjetas de crédito, en sentido del inciso 1°, son aquellas que han sido
emitidas por una entidad de crédito o de servicios financieros para su uso en
P á g i n a | 50

dicho tipo de transacciones y que, por su configuración o codificación, son


especialmente protegidas contra su falsificación.

5° Medios electrónicos de pago en el sentido del inciso 1°, son aquellos


instrumentos o dispositivos que actúan como dinero electrónico, permitiendo
al titular efectuar transferencias de fondos, retirar dinero en efectivo, pagar en
entidades comerciales y acceder a los fondos de una cuenta.”

Artículo 2°.- Comuníquese al Poder Ejecutivo.

Aprobada el Proyecto de Ley por la Honorable Cámara de Senadores, a


treinta días del mes de mayo del año dos mil once, quedando sancionado
el mismo, por la Honorable Cámara de Diputados, a ocho días del mes de
setiembre del año dos mil once, de conformidad a lo dispuesto en el Artículo
207, numeral 1) de la Constitución Nacional. (Legislativo, 2008)

Víctor Alcides Bogado González Jorge Oviedo Matto


Presidente Presidente
H. Cámara de Diputados H. Cámara de Senadores

Mario Soto Estigarribia Mario Cano Yegros


Secretario Parlamentario Secretario Parlamentario

Asunción, 3 de octubre de 2011.


Téngase por Ley de la República, publíquese e insértese en el Registro
Oficial.

El Presidente de la República

Fernando Armindo Lugo Méndez

Humberto Blasco
Ministro de Justicia y Trabajo
P á g i n a | 51

II.4 Definición de variables

II.4.1 Cuadro de Variables

Variable Concepto Dimensiones Indicadores Técnicas e


instrument
os
I - Estructura de - Estructura del Área de TI
TI y - Organización de la
Gerenciamiento Estructura de TI
- Evaluación de Gestión de
TI – Gerenciamiento
II - Sistemas de - Relevamiento del Sistema
Información de Información del Cliente
Análisis del - Evaluación Del Desarrollo
resultado de Y Mantenimiento De
Auditoria la Auditoría Sistemas - Equipo Interno
Informática Informática - Evaluación del Desarrollo Planilla de
de Control de Control y Mantenimiento de controles
Interno de Interno de Sistemas – Consultoría Generales
Tecnología Tecnología Externa de TI
Informática Informática III – Seguridad - Aplicación de Contraseñas
(TI) (TI) según Lógica – LAN (Red de Área Local)
las Normas - Aplicación de Contraseñas
Estándares – Sistema aplicativo
de COBIT y - Administración de Claves
MCIIEF. – Sistemas de Información y
LAN
- Evaluación de Protección
Contra Software Malicioso
P á g i n a | 52

IV – Seguridad - Planes de Continuidad del


Física Negocio
- Evaluación de la Sala de
Servidores – Data Center y
Alta Disponibilidad.
- Evaluación del Resguardo
de la Información - Copias
de respaldos.
V– - Documentación de
Documentacione Funciones y Procedimientos
s de TI - Relevamiento de
Inventarios y Manuales
Técnicos
- Evaluación de La
Administración de Proyectos
- Evaluación del
Cumplimiento de Contrato
VI – Evaluación - Administración de los
de RR.HH. Recursos Humanos –
Evaluación del desempeño
- Capacitación y
entrenamiento
CAPITULO III – MARCO METODOLOGICO

III.1 Características Metodológicas

III.1.1 Tipo de Investigación:

Cuantitativa; Se adopta este tipo de investigación por que en el ambiente en


que se realizan los procesos se necesita que no se limite a solo el
relevamiento y recolección sino a la identificación de las variables con que
cuentan las actividades.

III.1.2 Nivel de Conocimiento esperado:

Descriptiva; Toda la información recabada se va narrando y definiendo para


delimitar exactamente el o los problemas con que se cuenta.

III.1.3 Diseño de la Investigación:

El diseño es no experimental por qué se realiza los estudios sin la


manipulación deliberadas de variables y en los que se observan los
fenómenos en su ambiente natural para después analizarlos.
P á g i n a | 54

III.2 Descripción de la población y muestra

La población está conformada por 6 personas que se detallan:


 1 Intendente Municipal
 1 Secretario General
 1 Programador Externo
 1 Encargado de administración y finanzas
 1 Encarado de liquidación
 1 Encargado de Transito

Se toma toda la población por la poca cantidad de individuos.

III.3 Técnicas e Instrumentos de recolección de Datos

Las técnicas e instrumentos de recolección de datos son a través de


entrevistas a los funcionarios y observaciones dentro del ente utilizando los
instrumentos y técnicas de las buenas prácticas de auditoría de sistemas.

El mecanismo que usa el investigador para recolectar y registrar la información


será el escrito (instrumento), utilizando los papeles de Trabajo de Controles
Generales de TI.

Se utiliza fuentes primarias, porque se obtendrá información por contacto


directo con el sujeto de estudio, por medio de cuestionarios. De esta forma se
recaba datos imprescindibles para el conocimiento y realización del proyecto.

III.4 Descripción del procedimiento de análisis de datos

Para la presentación de los resultados se utilizan los informes de


recomendaciones para su posterior discusión y análisis.
CAPITULO IV – RESULTADOS Y ANALISIS DE
DATOS

IV.1 Desarrollo de las Notas de Control Interno (Informe)

IV.1.1 Problemas identificados:

1. Inexistencia de TI y Gerenciamiento

2. No se cuenta con departamento de TI, por lo tanto el programa


fuente es cerrado de un proveedor externo.

3. No se dispone con procedimientos ante eventual caída del sistema.

4. No se tiene ningún mecanismo para el cierre diario del sistema, por


lo tanto cualquier empleado relacionado con la administración puede
cerrar y abrir a la hora que quiera.

5. Inexistencia de ajustes eventuales de registros ya procesados

6. No se dispone de ningún documento que avalen las operaciones de


análisis, de modo que no han considerado los controles de
procedimientos de seguridad.

7. No se dispone de políticas con niveles de utilización de encriptación


para el resguardo de las contraseñas.
P á g i n a | 56

8. No se contempla la Auditoría Interna de Sistemas en el contrato con


el desarrollador externo

9. No existe expiración automática de contraseñas en la LAN.

10. No se bloquea el acceso por intento con claves erróneas, sin


embargo tampoco permite acceder a la red.

11. No se dispone ningún documento que avalen la aplicación para alta-


baja y modificaciones de usuarios de la red.

12. No existe ningún registro histórico y/o logs de auditoría a nivel de la


LAN.

13. No existe restricción alguna de accesos a discos desde otra terminal.

14. No existen documentos en el que los usuarios firman señalando que


comprenden y aceptan las condiciones para el acceso a la red.

15. Los usuarios pueden acceder a todas las páginas de internet sin
ninguna protección de acceso a la misma.

16. No existe restricción de horario en la LAN, los usuarios pueden


acceder la hora que deseen mientras esté abierto la municipalidad.

17. No existe expiración de contraseñas en forma automática en el


sistema de aplicación.

18. No existe desconexión del sistema por tiempo muerto.

19. Falta de activación de los registros de auditoría a nivel de sistema

20. No se bloquea el acceso por intento con claves erróneas, sin


embargo tampoco permite acceder al sistema.

21. No existe documentación y procedimiento aplicado para el alta, baja


y actualización de usuarios del sistema.
P á g i n a | 57

22. No existe documentos en el que los usuarios firman señalando que


comprenden y aceptan las condiciones para el acceso al sistema y
determinación de confidencialidad.

23. No existe control de programación de pistas de auditoría interna a


través del sistema de aplicación y revisión de eventos.

24. No se dispone de política de restricción en el uso de medios de


almacenamiento externo USB.

25. No existe vencimiento de contraseña administrado en la Red LAN

26. No existe sala de servidor independiente y restricción de acceso

27. No existe Bitácora de accesos a la sala de Servidores

28. Solo existe un listado de servidores

29. No existe un servidor espejado

30. No existe arquitectura servidor - clon

31. No se dispone de rack de protección para el servidor.

32. No se cuenta con certificación del cableado de red.

33. No se dispone de detectores de humo y calor.

34. Inexistencia de extintores para computadoras

35. No se dispone del Sistema de puesta a tierra en el Data Center

36. No se cuenta con generador, que suministre energía eléctrica ante


posible caída de la ANDE.

37. Fallas en el resguardo de la información

38. No existe un Registro de Planilla de control de copias de respaldo

39. Falta de un encargado de mantenimiento a las computadoras

40. Inexistencia de un plan de seguridad contra catástrofes


P á g i n a | 58

41. Inexistencia de una copia de respaldo fuera del local

42. Inexistencia de una protección para el servidor

43. Inexistencia de un control de perfiles de usuarios

44. Inexistencia de requerimientos de calificaciones y experiencia para


integrar la cartera de usuarios de la Municipalidad

45. No existe una metodología de evaluación del personal

46. Inexistencia de un plan general de entrenamiento y desarrollo para


usuarios

Se Solicita

1. Informe sobre el resultado del trabajo realizado.

2. Informe sobre las sugerencias y recomendaciones tendientes a mejorar


el control interno del área informática.

IV.1.2 Desarrollo de Caso Práctico

El problema o Especificar el título del problema o debilidad


debilidad

Descripción del Descripción de la problemática o debilidad


problema

Riesgo Alto – Medio - Bajo

Descripción del riesgo Descripción de lo que ocurriría si el problema o


la debilidad persiste

Recomendaciones Presentar las alternativas de recomendaciones


disponibles
P á g i n a | 59

1. Verificar la estructura organizativa y las normas vigentes en el


Departamento de Informática.

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


ENTIDAD: Municipalidad Raúl Arsenio Oviedo Ref.
T.I.
PERIODO: 2015 P.T.:
I - ESTRUCTURA DE TI Y GERENCIAMIENTO
Objetivo de control:

 El propósito de este formulario es obtener conocimiento de la estructura


administrativa del área de Tecnología de la Información, determinando la
buena gestión de gerenciamiento.

R INDICADORES DE RELEVAMIENTO NCI Riesgo


EVALUACIÓN
E (Describa la √ - N/A 3=Alto
situación
F observada) 2=Medi
o
1=Bajo

1.1 – ESTRUCTURA DEL ÁREA DE TI

1.1.1 Ubicación Estructural del Área x


de Servicios de TI

1.1.2 Organigrama de TI – disponible X


y actualizado

1.1.3 Otras observaciones X

1.2 – ORGANIZACIÓN DE LA ESTRUCTURA DE TI

1.2.1 Gerente/Jefe/Encargado de TI X

1.2.2 Responsable de la X
Administración de BD

1.2.3 Responsable de la X
Administración de Redes
P á g i n a | 60

1.2.4 Responsable de la X
Administración de Sistemas

1.2.5 Soporte técnico/Estructura X

1.2.6 Desarrolladores X

1.2.7 Responsables de la X
Administración de la Seguridad

1.2.8 Separación de funciones - X


Identificación del Personal
Clave de Tecnología de
Información

1.2.9 Otras observaciones X

1.3 - EVALUACIÓN DE GESTIÓN DE TI – Gerenciamiento

1.3.1 Plan de TI a largo plazo, X


enfoque y estructura,
aprobación

1.3.2 Plan de TI a corto plazo, X


planificación de la capacidad de
la infraestructura tecnológica

1.3.3 Cambios al plan de TI a largo X


plazo – Aprobación

1.3.4 Evaluación permanente del Plan X


Estratégico de Tecnología de
Información

1.3.5 Metodología de control de X


adquisiciones - procedimientos

1.3.6 Otras observaciones No se cuenta con el X 2


Departamento de TI
– Gerenciamiento,
por lo tanto no se
puede evaluar la
estructura de TI y
Gerenciamiento.
P á g i n a | 61

Caso 1

1. Inexistencia de TI y Gerenciamiento

Descripción del problema: Se ha constatado que la municipalidad no


cuenta con departamento de TI y Gerenciamiento, por lo tanto el programa
fuente es cerrado, de un proveedor externo. Todos los mantenimientos los
realizan personas externas y no existe un buen control de los equipos
informáticos tanto físicos como lógicos

Riesgo: Medio

Descripción del riesgo: La no existencia de TI dentro de la Municipalidad


provoca que los programas fuentes sean cerrados, y la entidad no cuenta
con esos códigos, de manera a que la municipalidad depende totalmente
del desarrollador externo para cualquier modificación o continuidad del
software, como así también los mantenimientos de los equipos informáticos
tanto físicos como lógicos.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica debe tener
un departamento de TI y gerenciamiento para la buena gestión de los
recursos informáticos, recomendamos a la Municipalidad si se dispone de
presupuesto para formar un Departamento de TI y Gerenciamiento, y
comprar el código fuente del proveedor externo, de esta forma para no
depender de una persona o empresa para la continuidad del software y los
mantenimientos de los equipos informáticos.

Observación

La no existencia de gerenciamiento de TI, impide que se pueda evaluar


dicho departamento. Es por eso que más arriba se recomienda crear un
departamento dentro de la institución municipal si se dispone de
presupuesto. Por lo tanto no se podrá obtener conocimiento de la estructura
P á g i n a | 62

administrativa del área de Tecnología de la Información, ni se podrá


determinar la buena gestión de gerenciamiento.

2. Evaluar los sistemas informáticos basados en el enfoque de


confiabilidad de las informaciones y la flexibilidad que
proporcionan.

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD: Ref.
Oviedo
P.T.:
PERIODO: 2015
II - SISTEMAS DE INFORMACIÓN
Objetivo de control:

 El propósito de este formulario es obtener conocimiento del sistema de


información automatizado del cliente y dejar documentado en el archivo
permanente.

R INDICADORES DE RELEVAMIENTO NCI Riesgo


EVALUACIÓN
E (Describa la situación √ - N/A 3=Alto
observada)
F 2=Medi
o
1=Bajo

2.1 - RELEVAMIENTO DEL SISTEMA DE INFORMACIÓN DEL CLIENTE

2.1.1 Identificación del Sistema de Gestión


sistema, describir el Tributaria Municipal,
nombre del sistema, la hecho en el lenguaje de
plataforma de base de programación FoxPro.
datos, lenguaje de
programación

2.1.2 Proveedor (interno - El proveedor es externo,


externo), describir si el el sistema fue adquirido
sistema fue adquirido de de tercero
terceros o desarrollado
internamente
P á g i n a | 63

2.1.3 Descripción de los Tránsito, liquidación,


módulos, detallar los caja, libro de bancos,
módulos que comprende ingresos y gastos.

2.1.4 Objetivo de los módulos, Transito: Patente de


describir la funcionalidad rodados y Registro de
de cada módulo Conducir

Liquidación: Patente
comercial, impuesto
inmobiliario, localización,
varios.

Caja: cobro de todas las


liquidaciones y tránsito,
arqueo de caja.

Libro de banco: cheques


emitidos, registro de
depósitos, informes de
libros de banco por
cuentas

Ingresos: Informes
presupuestarios, informe
estado de cuentas,
informes mensuales del
Ministerio de Hacienda

Gastos: Presupuesto
actual,
reprogramaciones,
órdenes de pago, informe
de presupuesto, informe
cuatrimestral, informe
mensual, informe de
orden pagos emitidos,
ejecución presupuestaria
1er y 2do semestre,
ejecución cuatrimestral
final anual, informe
mensual de Hacienda.
P á g i n a | 64

2.1.5 Integración de módulos – El sistema no realiza


ERP, (identificación de contabilidad, por lo tanto
los módulos no no está integrado en el
integrados a la sistema, los otros
contabilidad), identificar módulos están integrados
los módulos no entre sí. Se optó por
integrados y las razones realizar la contabilidad
de la no integración netamente manual

2.1.6 Asientos manuales Libro diario, libro mayor,


realizados, debido a la no estado de resultados,
automatización – Ajustes, balance general. Se
describir si existen casos realiza manualmente por
de asientos manuales motivo de que el sistema
desarrollados, así como no cuenta con módulo de
el motivo de dichos contabilidad integrada
asientos

2.1.7 Tipo de software Se trabaja con software


(propietario – libre), propietario, con
versiones, describir la plataforma Cliente-
plataforma del sistema, si Servidor, y opera bajo
opera bajo sistema sistema propietario
propietario o no, y la Windows XP.
funcionalidad en el
servidor

2.1.8 Disponibilidad de Programa fuente cerrada, X 2


fuentes, detallar si se con soporte técnico y
dispone los programas certificación.
fuentes y si se ha
certificado la
actualización de la
versión

2.1.9 Control de versiones del No existe un X


código fuente y departamento de TI, por
autorización para el lo tanto no se podrá
traspaso al entorno de evaluar el control de
producción, describir versiones del código
procedimiento fuente y autorización
para el traspaso al
entorno de producción, ni
P á g i n a | 65

describir los
procedimientos

2.1.1 Pruebas del sistema en No se puede describir el X


0 forma paralela antes del procedimiento debido a
traspaso a producción, que no se cuenta con un
describir procedimiento departamento de
producción y
gerenciamiento de TI

2.1.1 Prueba de aceptación No se puede describir el X


1 final antes del traspaso a procedimiento debido a
producción, describir que no se cuenta con un
procedimiento departamento de
producción y
gerenciamiento de TI

2.1.1 Estructura de desarrollo No se puede describir la X


2 paralelo – servidor estructura de desarrollo
independiente, describir paralelo – servidor
estructura independiente debido a
que no se cuenta con
departamento de
producción y
gerenciamiento de TI.

2.1.1 Procedimientos aplicados No se cuenta con X 3


3 ante la eventual caída del procedimientos ante la
sistema , describir caída del sistema
procedimiento

2.1.1 Mecanismo para el cierre No se tiene ningún X 2


4 diario del sistema – mecanismo para el cierre
Participantes – diario del sistema, por lo
Aprobación tanto cualquier empleado
relacionado con la
administración puede
cerrar y abrir la hora que
quiera.

2.1.1 Mecanismo de La contabilidad se realiza X


5 conciliación con los de forma manual, el
demás módulos del
P á g i n a | 66

sistema – libros auxiliares sistema no cuenta con el


– saldos contables módulo de contabilidad

2.1.1 En casos de ajustes No se realizan ajuste X 3


6 eventuales de registros eventuales de registros
ya procesados, ¿cómo se ya procesados
realiza y quien autoriza?

2.1.1 Otras observaciones


7

2.2 - EVALUACIÓN DEL DESARROLLO Y MANTENIMIENTO DE SISTEMAS


- Equipo interno

2.2.1 Procedimientos controles No existe ningún X 2


de seguridad aplicados documento que avalen
en la etapa de análisis y las operaciones de
diseño del sistema, análisis, por lo tanto no
determinar si en la etapa se han considerado los
de diseño se ha procedimientos de
considerado los seguridad.
procedimientos de
seguridad

2.2.2 Seguridad en los Algunas de las


Sistemas de Aplicación, validaciones son: cada
validación de datos de usuario tiene su propio
entrada, detallar los perfil, de modo que no
criterios de validación puede acceder o realizar
aplicado en cada dato de todas las transacciones a
entrada (manual y no ser que sea usuario
automático) administrador, las
facturas no se pueden
borrar, si no se cargan
datos obligatorios no
permite guardar, entre
otros.

2.2.3 Política de utilización de No se dispone de X 2


controles criptográficos, políticas con niveles de
encriptación, evaluar si la utilización de
base de datos aplica encriptación.
códigos de encriptación,
principalmente para el
P á g i n a | 67

resguardo de las
contraseñas

2.2.4 Protección de los datos No se puede evaluar si X


de prueba del sistema, las pruebas de base de
aplicación de otras BD datos son aplicados en
para pruebas, evaluar si una base de datos
las pruebas a nivel de paralelo, debido a que la
base de datos son protección de datos de
aplicados en una base de prueba del sistema lo
datos paralelo realiza el proveedor
externo que viene una
vez al mes a realizar
mantenimiento.

2.2.5 Control de cambios a No existe ni una


datos operativos, posibilidad que un
manipulación de datos a usuario ingrese a la base
través de un MGBD, de datos, ya que el único
evaluar si existe la que tiene acceso a la
posibilidad que un base de datos es el
usuario ingresa a la base proveedor externo, el
de datos conociendo el cual posee el código
password y si a través de fuente del sistema y de la
dicho ingreso es posible base de datos
alterar datos de
producción

2.2.6 Mecanismo, registro y No se puede evaluar el X


control de acceso a las mecanismo, registro y
bibliotecas de programas control de acceso a las
fuentes, evaluar si bibliotecas de programas
quienes tienen acceso a fuentes, porque el único
los programas fuentes, que tiene acceso al
inclusive a las versiones código fuente es el
anteriores proveedor externo

2.2.7 Otras observaciones X

2.3 - EVALUACIÓN DEL DESARROLLO Y MANTENIMIENTO DE SISTEMAS


– Consultoría externa
P á g i n a | 68

2.3.1 Acuerdos de licencias, El código fuente le


propiedad de código y pertenece
derechos conferidos. exclusivamente al
desarrollador, ya que es
un proveedor externo.

2.3.2 Requerimientos Existe contrato de


contractuales con soporte técnico, con
respecto a la calidad del garantía y asistencia en
código y la existencia de los sistemas por parte del
garantías. desarrollador.

2.3.3 Procedimientos de En el contrato con el X 3


certificación de la calidad, proveedor contempla los
que incluyan auditorías procedimientos de
internas de sistemas. certificación de calidad y
precisión del trabajo del
mismo, que incluye
revisión de código
malicioso, verificación del
cumplimiento de los
requisitos de seguridad
del software. Sin
embargo no cuenta con
auditorias de sistemas
informáticos

2.3.4 Acuerdos de custodia de La custodia de las X


las fuentes del software. fuentes del software lo
hace el proveedor, la
municipalidad no posee
el código fuente del
software

2.3.5 Otras observaciones X


P á g i n a | 69

Caso 2

2. Inexistencia de TI, se cuenta con programa fuente cerrada

Descripción del problema: Se ha constatado que la municipalidad no


cuenta con departamento de TI, por lo tanto el programa fuente es cerrado,
de un proveedor externo.

Riesgo: Medio

Descripción del riesgo: La no existencia de TI dentro de la Municipalidad


provoca que los programas fuentes sean cerrados, y no cuenta con esos
códigos, de manera a que depende totalmente del desarrollador externo
para cualquier modificación o continuidad del software.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica debe tener
un departamento de TI y gerenciamiento para la buena gestión de los
recursos informáticos, recomendamos a la Municipalidad si se dispone de
presupuesto para formar un Departamento de TI, y comprar el código
fuente del proveedor externo, de esta forma para no depender de una
persona o empresa para la continuidad del software.

Caso 3

3. Falta de procedimientos ante eventual caída del sistema

Descripción del problema: Se detectó que la Municipalidad no cuenta con


procedimientos ante caída del sistema, de modo que los empleados lo
realizan empíricamente, no se tiene la certeza de que el sistema siga
funcionando correctamente.

Riesgo: Alto

Descripción del riesgo: La no disponibilidad de un procedimiento ante una


posible caída del sistema, puede ocasionar la no continuidad del servicio
durante un tiempo determinado, lo cual afectaría directamente a la
P á g i n a | 70

municipalidad, puesto que casi todas las operaciones se realizan por medio
del sistema informático.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica de TI debe
tener un plan de contingencias de cualquier naturaleza, recomendamos la
creación e implementación de plan de riesgos ante una eventual caída del
sistema, implementando los procedimientos que se tienen que llevar a cabo
si existe una caída del sistema y contratar una persona encargado de dicho
procedimiento o bien capacitar a los empleados.

Caso 4

4. Inexistencia de un mecanismo para el cierre diario del sistema.

Descripción del problema: Se ha detectado que no existe ningún


mecanismo para el cierre diario del sistema, por lo tanto cualquier
empleado puede abrir y cerrar el sistema a la hora que quiera.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de un mecanismo para el


cierre diario del sistema y la falta de algún responsable de la misma, puede
ocasionar un riesgo ya que cualquier empleado lo realiza sin tener en
cuenta los pasos que debe llevar a cabo para el cierre y también lo puede
hacer sin ninguna autorización. De modo que se deja el camino libre para
manipular el sistema a cuenta propia.

Recomendación: De manera a cumplir con los estándares de seguridad


recomendamos que se implemente un mecanismo para el cierre diario del
sistema, de manera a mitigar los riegos de la mala utilización del sistema y
para resguardar correctamente el patrimonio más importante de la empresa
que son las informaciones.

Caso 5

5. Inexistencia de ajustes eventuales de registros ya procesados


P á g i n a | 71

Descripción del problema: Se ha constatado que en la Municipalidad no


se cuenta con un mecanismo que se aplique para casos de eventuales
ajustes al sistema en cuanto a registros ya procesados.

Riesgo: Alto

Descripción del riesgo: La no disponibilidad de ajustes eventuales de


registros ya procesados puede haber inconvenientes en los resultados ya
que puede existir errores al cargar los datos en la facturación, de sueldos,
facturas que se deban anular, entre otros y si no existe un mecanismo para
reprocesar esos datos cabe la posibilidad de que se cobre mal a los
contribuyentes y por ende un desbalance en la contabilidad.

Recomendación: De manera a cumplir con los estándares de seguridad,


recomendamos a la Municipalidad que implemente un mecanismo que se
pueda aplicar en casos de eventuales ajustes del sistema realizando los
siguientes: reproceso de facturaciones, reproceso de sueldos, cuentas
contables entre otros. También que haya una persona encargada para la
autorización de dichos ajustes y verificación del mismo.

Caso 6

6. Falta de documentos de análisis y control de procedimientos de


seguridad

Descripción del problema: Se ha constatado que en la etapa de análisis


y diseños no se implementaron los controles de seguridad, por lo tanto no
se cuenta con ninguna documentación que avalen dichas operaciones y no
se han considerado los procedimientos de seguridad.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de documentos que avalen


las operaciones de análisis y diseños con un control de seguridad, no se
tiene la certeza de que el sistema tenga todos los procedimientos de
seguridad requerida, ya que en el momento de diseño no se tuvo en cuenta.
P á g i n a | 72

Recomendación: De manera a cumplir con los requisitos del MCIIEF, en


la que establece rigurosamente los procedimientos a seguir para el
desarrollo del área tecnológica, recomendamos que se realice un análisis
del sistema para documentar las bases de datos, los diagramas de flujos,
los procedimientos del sistema y la realización de un manual de seguridad
y otros documentos que le dé a la Municipalidad un respaldo y por ende a
organizarse mejor por cualquier cambio o implementación que pueda surgir
dentro de la entidad. De esta forma garantizar el buen funcionamiento del
sistema con todos los procedimientos de seguridad requerida.

Caso 7

7. Inexistencia de encriptación de resguardo de contraseñas

Descripción del problema: Se ha detectado que la Municipalidad no


dispone de políticas con niveles de utilización de encriptación, de modo que
el sistema no realiza encriptación para resguardo de contraseñas.

Riesgo: Alto

Descripción del riesgo: La no disponibilidad de políticas de niveles de


encriptación, el sistema no realiza encriptación para resguardo de
contraseñas ante posibles situaciones de inserción de usuarios no
autorizados que puedan modificar, borrar o copiar datos sensibles de la
Municipalidad.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos a la Municipalidad que adopte una
política de seguridad, de modo que se pueda implementar una forma de
encriptación para el resguardo de las contraseñas.

Caso 8

8. No se contempla la Auditoría Interna de Sistemas en el contrato con


el desarrollador externo
P á g i n a | 73

Descripción del problema: Se ha detectado que en el contrato con el


desarrollador externo no se contempla la implementación de auditorías
internas de sistemas informáticos.

Riesgo: Alto

Descripción del riesgo: La no disponibilidad de Auditorías internas de


sistemas por parte del desarrollador externo permite que haya poco control
de la seguridad lógica y física del sistema, redes y de los equipos
informáticos existentes, por ende existen muchos riesgos y
vulnerabilidades ya sea para realizar fraudes, como para la no continuidad
del sistema por cualquier contingencia, entre otros.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un control de todos equipos
informáticos y el manejo de los mismos, recomendamos a la Municipalidad
que se haga un nuevo contrato con el desarrollador externo en el que se
pueda contemplar una Auditoría interna de sistemas para así tener buenos
mecanismos de control de seguridad lógica y física de los sistemas de
información y el resguardo seguro del activo más importante de la
Municipalidad que es la información.

3. Evaluar que las políticas de seguridad de datos vigentes en el


Departamento de Informática estén elaborados para minimizar
la posibilidad de accesos no autorizados a los datos y
programas.

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD: Ref.
Oviedo
P.T.:
PERIODO: 2015
III – SEGURIDAD LÓGICA
Objetivo de control:
P á g i n a | 74

Evaluar si los sistemas de información cumplen con los siguientes objetivos


principales:
 Integridad: garantizar que los datos sean los que se supone que son.
 Confidencialidad: asegurar que sólo los individuos autorizados tengan
acceso a los recursos que se intercambian.
 Disponibilidad: garantizar el correcto funcionamiento de los sistemas
de información.
 Evitar el rechazo: garantizar de que no pueda negar una operación
realizada.
 Autenticación: asegurar que sólo los individuos autorizados tengan
acceso a los recursos.
R INDICADORES DE RELEVAMIENTO NCI Ries
EVALUACIÓN go
E (Describa la situación √ - N/A
observada) 3=Alt
F o

2=Me
dio1=
Bajo

3.1 - APLICACIÓN DE CONTRASEÑAS – LAN (Red de Área Local)

3.1.1 Requerimiento de La LAN cuenta con


contraseñas - LAN requerimiento de
contraseñas. No se
puede acceder si no se
cuenta con la contraseña.
Cada usuario tiene
autorización por parte de
la administración y
finanzas para el uso de la
LAN.

3.1.2 Aplicación de usuarios Cada usuario posee un


únicos, no genéricos perfil único, y limitado a
algunos módulos por
cada perfil de usuario,
esto permite identificar
las tareas de los usuarios
en forma individual
P á g i n a | 75

3.1.3 Expiración de No existe expiración de X 2


contraseñas, en forma contraseñas del sistema
automática operativo de red de forma
automática.

3.1.4 Contraseña diferenciada Las contraseñas son


a la identificación del diferentes a la
usuario identificación de cada
usuario, de manera que
brinda seguridad en la
red.

3.1.5 Bloqueo por intento de No se bloquea el acceso X 2


accesos con claves por intento con claves
erróneas erróneas, sin embargo
tampoco permite acceder
a la red.

3.1.6 Documentación aplicado No existen documentos X 2


para alta – baja y que avalen la aplicación
modificación de usuarios para alta-baja y
modificación de usuarios.

3.1.7 Habilitación de los No se han activado los X 2


registros históricos y/o registros de auditoría a
logs de auditorías que nivel de la LAN, por lo
reporten sobre intentos tanto no se tiene
de usuarios mal registrado los intentos de
intencionados acceso a usuarios no
autorizados.

3.1.8 Restricción de accesos a No existen restricciones X 3


otras unidades de discos de acceso a otras
desde una estación de unidades de discos
trabajo desde una estación de
trabajo.

3.1.9 Documento firmado por No existen documentos X 2


los usuarios señalando en el que los usuarios
que comprenden y firman señalando que
aceptan las condiciones comprenden y aceptan
para el acceso a la red las condiciones para el
de área local y acceso a la red.
P á g i n a | 76

determinación de
confidencialidad

3.1.10 Protección de acceso a Los usuarios pueden X 3


internet, documento de acceder a todas las
autorización para el páginas de internet sin
acceso ninguna protección de
acceso a la misma.

3.1.11 Restricciones de accesos No existe restricción de X 2


por horario en la red LAN horario en la LAN, los
- limitación del horario de usuarios pueden acceder
conexión la hora que deseen
mientras esté abierto la
municipalidad

3.1.12 Otras observaciones X

3.2 - APLICACIÓN DE CONTRASEÑAS – Sistema aplicativo

3.2.1 Requerimiento de El Sistema de Gestión


contraseñas - Sistema cuenta con requerimiento
de Gestión de contraseñas. No se
puede acceder si no se
cuenta con la contraseña.
Cada usuario tiene
autorización por parte de
la administración y
finanzas para el uso del
Sistema de Aplicación.

3.2.2 Expiración de No existe expiración de X 2


contraseñas, en forma contraseñas de usuarios
automática y del sistema de
aplicativo de forma
automática.

3.2.3 Aplicación correcta de Se aplica correctamente


perfiles de usuarios los perfiles de usuarios.

3.2.4 No repetición de El sistema de aplicación


contraseñas en los posee la validación en la
sistemas de gestión que no permite la
P á g i n a | 77

repetición de contraseñas
de al menos 5 anteriores.

3.2.5 Aplicación de contraseña Las contraseñas son


diferente a la diferentes a la
identificación de usuario identificación de cada
usuario.

3.2.6 Desconexión del sistema No existe desconexión X 3


por tiempo muerto – del sistema por tiempo
Desactivación del código muerto.
de usuario

3.2.7 Registro en el sistema de El sistema no cuenta con X 2


acceso de usuarios, para pistas de auditoría, por lo
auditoría tanto no se tiene
registrado los intentos de
acceso a usuarios no
autorizados.

3.2.8 Bloqueo por intento de No existe bloqueo por X 3


claves erróneas intento de claves
erróneas, sin embargo no
permite el acceso al
sistema.

3.2.9 Documentación y No existen documentos X 2


procedimiento aplicado que avalen la aplicación
para la alta – baja y para alta-baja y
mantenimiento de modificación de usuarios
usuarios del sistema.

3.2.10 Documento firmado por No existen documentos X 2


los usuarios señalando en el que los usuarios
que comprenden y firman señalando que
aceptan las condiciones comprenden y aceptan
para el acceso a los las condiciones para el
sistemas y determinación acceso al sistema.
de confidencialidad

3.2.11 Control de programación No existe control de X 2


de pistas de auditoría programación de pistas
interna a través del de auditoría interna a
sistema de aplicación -
P á g i n a | 78

Registro y Revisión de través del sistema de


Eventos aplicación

3.2.12 Uso de medios de No existe política de X 2


almacenamiento externo restricción en el uso de
USB, en tareas críticas – medios de
política de restricción almacenamiento externo
USB

3.2.13 Revisión de los de El proveedor en conjunto


derechos de acceso de con el administrador/a de
usuarios, por parte de los la municipalidad realiza la
propietarios de datos revisión de los derechos
de acceso de los
usuarios del sistema,
como así también los
perfiles de cada usuario.

3.2.14 Otras observaciones X

3.3 - ADMINISTRACIÓN DE CLAVES – SISTEMAS DE INFORMACIÓN Y LAN

3.3.1 Vencimiento de No existe vencimiento de X 2


contraseñas contraseñas
administradores de Red administradores de Red
LAN LAN

3.3.2 Vencimiento de No se puede evaluar X


contraseñas debido a que el
administradores de BD administrador de la BD
es el proveedor externo y
el único que tiene acceso
a la misma

3.3.3 Vencimiento de No se puede evaluar X


contraseñas debido a que el
administradores de administrador de
Sistemas sistemas es el proveedor
externo y es el único que
maneja la contraseña.

3.3.4 Resguardo en sobre La Intendencia municipal


lacrado, con no posee las contraseñas
de la BD (el proveedor
P á g i n a | 79

conocimiento de la Alta externo es el único dueño


Gerencia de la contraseña de la
base de datos y del
sistema), sin embargo la
Municipalidad cuenta con
la contraseña de la Red
LAN, el cual es
resguardado bajo llave y
solo el administrador y la
intendencia tienen
autorización para utilizar
en caso de suma
necesidad.

3.3.5 Otras observaciones X

3.4 – EVALUACIÓN DE PROTECCIÓN CONTRA SOFTWARE MALICIOSO

3.4.1 Controles aplicados para Se cuenta con antivirus


la prevención de software (ESET Smart Security)
malicioso - Virus para contrarrestar
software malicioso –
Virus

Caso 9

9. No existe expiración automática de contraseñas en la LAN

Descripción del problema: Se ha constatado que la red de área local no


cuenta con expiración automática de contraseñas que permita a la empresa
tener el control de accesos y se pueda modificar automáticamente cada
cierto tiempo.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de una expiración automática


de las contraseñas en red de área local, no existe un control de contraseñas
por parte de la Municipalidad, de modo que los usuarios antiguos pueden
seguir accediendo sin autorización a la red con sus mismas contraseñas.
P á g i n a | 80

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica de TI debe
tener un plan de contingencias de cualquier naturaleza, recomendamos que
la Municipalidad pueda tomar las medidas de prevención, adquiriendo o
implementando un control sobre las contraseñas de los usuarios de la red,
de modo que se tenga la seguridad que solamente este accediendo a la
red un usuario autorizado.

Caso 10

10. Falta de bloqueo por intento de claves erróneas

Descripción del problema: Se detectó que la red de área local no dispone


de bloqueos de usuario por intento con claves erróneas, sin embargo
tampoco permite el acceso a la red.

Riesgo: Medio

Descripción del riesgo: La falta de bloqueo de usuario por intento con


claves erróneas, por más que no permita el acceso a la red, permite a un
usuario mal intencionado a seguir intentando con diferentes claves, lo cual
podría darse el caso de insertar la clave correcta y pueda acceder a la red.
De esta forma que se puede modificar o alterar algunas informaciones de
la red.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica de TI debe
tener un plan de contingencias de cualquier naturaleza, recomendamos que
la empresa pueda tomar las medidas de prevención, implementando una
política de seguridad en el que se pueda bloquear el acceso a la red si se
insertan claves erróneas más de tres veces, de modo que si se bloquea la
misma, solo el administrador de sistemas pueda desbloquear el usuario de
la red, de ahí a que el empleado ponga sus motivos y el porqué de las
claves erróneas.
P á g i n a | 81

Caso 11

11. Inexistencia de documento que avalen la aplicación para alta-baja


y modificaciones de usuarios de la red.

Descripción del problema: Se ha detectado que no se cuenta con


documentos de respaldo para la aplicación de alta-baja y modificaciones
de usuarios de la red área local, así cualquier persona con conocimiento
informática puede realizar los cambios sin ningún documento que
demuestre el motivo de dichas operaciones.

Riesgo: Medio

Descripción del riesgo: La falta de un documento de respaldo en las


aplicaciones de alta-baja y modificaciones de usuarios de la red, no permite
a la empresa conocer el motivo de estas aplicaciones y existe un riesgo de
que cualquier persona con conocimiento de informática lo pueda realizar
sin autorización de la gerencia.

Recomendación: De manera a cumplir con las normas COBIT y el MCIIEF,


en la que establece claramente que se tiene que documentar los planes y
políticas del área tecnológica, recomendamos a la Municipalidad que
adopte una documentación para las aplicaciones de alta-baja y
modificaciones de usuario de la red, que sirva de respaldo para el empleado
que lo realiza, en donde se ponga el motivo de las operaciones para que
de esta forma el intendente y otras autoridades pueda tener en
conocimiento de las operaciones que se realizan.

Caso 12

12. Inexistencia de registros históricos y/o logs de auditoría a nivel de


la LAN

Descripción del problema: Se ha detectado que en la LAN no se


encuentra activado los registros históricos y/o logs de auditoría, de modo
P á g i n a | 82

que no se registran los intentos de acceso a usuarios no autorizados y no


se tiene ningún registro histórico de usuarios mal intencionados.

Riesgo: Medio

Descripción del riesgo: La no activación de los registros de auditoría a


nivel de la LAN, no se cuenta con hechos históricos de empleados mal
intencionados, esto ocasiona un déficit para prevenir a futuros hechos de
usuarios mal intencionados que puedan dañar la red o acceder a la misma
para copiar datos sensibles de la municipalidad para su beneficio o para
dañar la imagen de la entidad.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la activación de los registros de
auditoría a nivel de la LAN, de manera a registrar los intentos de acceso a
usuarios no autorizados, para que así se pueda reportar sobre intentos de
usuarios mal intencionados, que se tenga en conocimiento y se pueda
implementar mecanismos de prevención a esas operaciones, para que la
red del sistema no sea vulnerable.

Caso 13

13. Falta de restricciones de accesos a discos

Descripción del problema: Se ha detectado que no existe una política de


seguridad de redes en cuanto al acceso de discos desde otra terminal.

Riesgo: Alto

Descripción del riesgo: La falta de un Administrador de red interna dentro


de la empresa, por esa razón no existe una restricción de acceso a discos
desde otra terminal, de modo que se pueden copiar, modificar y borrar
datos de otras computadoras. También ocasionaría que no se podría
identificar al sujeto que accedió, porque como habíamos mencionado en
P á g i n a | 83

puntos anteriores, la Municipalidad no cuenta con políticas de seguridad de


claves de acceso.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la contratación de un
Administrador de red con vasta experiencia en el área de seguridad de
redes y que pueda autenticar a las maquinas el acceso a otros discos. De
esta forma adoptar políticas de seguridad para mitigar los riesgos de
accesos no autorizados a Discos que contengan datos sensibles de la
Municipalidad.

Caso 14

14. Inexistencia de documentos en donde los usuarios acepten las


condiciones para el acceso a la red

Descripción del problema: Se ha detectado que no se dispone de


documentos en el que los usuarios firman señalando que comprenden y
aceptan las condiciones para el acceso a la red, los usuarios pueden
acceder a toda la red sin ninguna restricción.

Riesgo: Medio

Descripción del riesgo: La no existencia de documentos en el que los


usuarios firman y aceptan las condiciones para el acceso a la red, puede
ocasionar la falta de confidencialidad de datos, ya que no existe ninguna
restricción para el usuario. Como no existe ninguna documentación firmada
puede darse el caso de que los usuarios puedan dar sus contraseñas a los
compañeros de trabajo, lo cual dificultaría saber quién está accediendo a
la red.

Recomendación: De manera a cumplir con las normas COBIT y el MCIIEF,


en la que establece claramente que se tiene que documentar los planes y
políticas del área tecnológica, recomendamos que se realice un documento
en donde se establezca todas las condiciones para acceder a la red y de
P á g i n a | 84

esta forma se pueda definir claramente quien es responsable de todas las


actividades que se realice con su usuario, con la aceptación y firma de la
misma. De ahí que se tenga la confidencialidad tanto del manejo de la red
como el de las contraseñas.

Caso 15

15. Falta de restricciones de accesos a internet

Descripción del problema: Se ha detectado que no existe protección para


el acceso a las páginas de internet, y los usuarios pueden acceder sin
restricción alguna, descargando todo lo que se le antoje incluso pueden
descargar virus que puede afectar a la red.

Riesgo: Alto

Descripción del riesgo: La falta de una protección para el acceso a


internet que filtre los datos que se descargan y la falta de restricciones para
los usuarios, puede ocasionar un déficit en la seguridad de la red y de todo
el sistema, además de enlentecer la velocidad de internet, ya que los
usuarios pueden descargar todo tipo informaciones y programas, de modo
que se pueden descargar virus que afecte a la red.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la implementación de políticas de
seguridad de acceso a internet, utilizando filtros de páginas web para
mitigar el riego de descargar de virus o algún programa malicioso que
pueda dañar el sistema, y restricciones para los usuario en el acceso a las
páginas de internet, así los usuarios van a usar en forma correcta el internet
usando lo que necesita para realizar su trabajo dentro de la municipalidad,
y la velocidad de internet estaría en óptimas condiciones.
P á g i n a | 85

Caso 16

16. Inexistencia de restricciones de horario en el uso de la LAN

Descripción del problema: Se ha detectado que no se cuenta con las


restricciones de horario para el acceso a la LAN, los usuarios pueden
acceder incluso fuera de la hora de trabajo.

Riesgo: Medio

Descripción del riesgo: La falta restricciones de hora de acceso a la LAN


puede ocasionar que los usuarios puedan realizar algunas operaciones en
la red fuera del horario de trabajo establecido, esto puede causar conflictos
en las documentaciones y también se tiene la posibilidad de realizar
fraudes, ya que no va a existir control en el uso de la red.

Recomendación: De manera a cumplir con las normas COBIT y el MCIIEF,


en la que establece claramente que se tiene que documentar los planes y
políticas del área tecnológica, recomendamos que se implemente una
política del uso de la LAN, en el que se establezca que solo se pueden usar
en horas de trabajo, con algunas restricciones de horarios de acceso, de
modo que la LAN no permita el acceso de cualquier usuario fuera del
horario de trabajo. Y así evitar conflictos en la red y por ende evitar que se
realicen fraudes.

Caso 17

17. No existe expiración automática de contraseñas en el sistema de


aplicación

Descripción del problema: Se constató que el sistema de aplicación no


cuenta con expiración automática de contraseñas que permita a la empresa
tener el control de accesos y se pueda modificarlas automáticamente cada
cierto tiempo.

Riesgo: Medio
P á g i n a | 86

Descripción del riesgo: La no disponibilidad de una expiración automática


de las contraseñas en el sistema de aplicación, no existe un control de
contraseñas por parte de la empresa, de modo que los usuarios antiguos
pueden seguir accediendo sin autorización a la red con sus mismas
contraseñas, como así también los usuarios activos pueden modificar sus
contraseñas sin el conocimiento de la gerencia.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos que la Municipalidad pueda tomar
las medidas de prevención, adquiriendo o implementando un control sobre
las contraseñas de los usuarios del sistema de aplicación, de modo que se
tenga la seguridad que solamente este accediendo a la red un usuario
autorizado.

Caso 18

18. Falta de desconexión del sistema por tiempo muerto

Descripción del problema: Se ha detectado que el sistema no cuenta con


desconexión por tiempo muerto, y los usuarios pueden acceder al sistema
fuera del horario de trabajo sin ninguna restricción.

Riesgo: Alto

Descripción del riesgo: La falta de desconexión del sistema fuera del


horario de trabajo o tiempo muerto puede ocasionar que los usuarios
puedan realizar algunas operaciones en el sistema fuera del horario de
trabajo establecido, esto puede causar conflictos en las transacciones que
realiza la empresa y también existe la posibilidad de realizar fraudes, ya
que no va a existir control en el uso del sistema.

Recomendación: De manera a cumplir con las normas COBIT y el MCIIEF,


en la que establece claramente que se tiene que documentar los planes y
políticas del área tecnológica, recomendamos que se implemente una
política del uso del sistema, que el sistema sea capaz de desconectarse
P á g i n a | 87

automáticamente fuera del horario de trabajo, de modo que se pueda


conectar otra vez a la hora establecida para su uso. Y así evitar conflictos
en las transacciones realizadas por la municipalidad y por ende evitar que
se realicen fraudes o malversaciones.

Caso 19

19. Falta de activación de los registros de auditoría a nivel de sistema

Descripción del problema: Se ha detectado que no se cuenta con ningún


registro histórico de usuarios mal intencionados, esto es porque no se han
activado los registros de auditoría a nivel del sistema.

Riesgo: Medio

Descripción del riesgo: La no existencia de registros de auditoría, no se


cuenta con hechos históricos de empleados mal intencionados, esto
ocasiona un déficit para prevenir a futuros hechos de usuarios mal
intencionados que puedan dañar el sistema y por ende a la municipalidad.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la activación de los registros de
auditoría a nivel del sistema, de manera a registrar los intentos de acceso
a usuarios no autorizados, para que así se pueda reportar sobre intentos
de usuarios mal intencionados, de forma que se tenga en conocimiento y
se pueda implementar mecanismos de prevención a esas operaciones,
para que sistema de aplicación no sea vulnerable.

Caso 20

20. No existe Bloqueo de usuarios por intento de claves erróneas.

Descripción del problema: Se ha detectado que el Sistema Aplicativo no


bloquea a los usuarios que fallan repetitivamente en la autenticación de las
contraseñas o claves de acceso al Sistema.
P á g i n a | 88

Riesgo: Alto

Descripción del riesgo: Cuando no se bloquea a un usuario que exceda


en la cantidad de intentos permitidos por el Sistema de aplicación se corre
el riesgo de que un ataque mediante el ingreso sucesivo de valores al azar
tenga éxito.

Recomendación: De manera a cumplir con las medidas de seguridad


lógica, recomendamos a la Administración que solicite al proveedor del
Sistema que introduzca el bloqueo de usuarios por intentos de contraseñas
fallidas y que una vez superado el límite de intentos permitidos el usuario
deberá realizar el cambio correspondiente de la clave o contraseña por los
medios fijados por la Administración. También cabe señalar que el cambio
de la clave deberá ser autorizada por la persona correspondiente.

Caso 21

21. No existe documentación y procedimiento aplicado para el alta,


baja y actualización de usuarios del sistema.

Descripción del problema: Se ha constatado que no existe ninguna


documentación y procedimiento respecto al registro, eliminación o
actualización de usuarios del Sistema.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de documentos y


procedimientos en cuanto a la gestión de usuarios imposibilita a la
Administración del ente la continuidad del servicio si es que la Persona o
Individuo que sabe hacerla abandonará su cargo.

Recomendación: De manera a cumplir con las normas COBIT y el MCIIEF,


en la que establece claramente que se tiene que documentar los planes y
políticas del área tecnológica, recomendamos a la Administración la
documentación de los procedimientos de alta, baja y eliminación de
usuarios para que haya fluidez y mejora en las acciones de los nuevos
P á g i n a | 89

empleados o funcionarios que desean gestionar un usuario. Los


documentos de procedimientos permiten la correcta toma de decisiones.

Caso 22

22. No existen Documentos firmados por los usuarios señalando que


comprenden y aceptan las condiciones para el acceso a los sistemas
y determinación de confidencialidad.

Descripción del problema: Se ha comprobado que no hay documentos


firmados por los usuarios donde se estipulan las condiciones y/o
responsabilidad de acceso a los Sistemas y determinación de
confidencialidad de datos.

Riesgo: Medio

Descripción del riesgo: La no existencia de documentos firmados donde


el usuario comprende las condiciones y/o responsabilidades de acceso a
los Sistemas de Aplicación y también la confidencialidad o privacidad de
los datos puede ocasionar que usuarios malintencionados divulguen datos
de carácter privado y/o personal, alteren los datos o usen para sus propios
fines y que queden impunes por no contar con ningún tipo de instrumento
legal que garantice que dichas acciones serán sancionadas o penadas.

Recomendación: De manera a cumplir con las normas COBIT y el MCIIEF,


en la que establece claramente que se tiene que documentar los planes y
políticas del área tecnológica, recomendamos la celebración de un contrato
de uso y confidencialidad de datos entre Municipalidad y el usuario en
donde conste las cláusulas de condiciones y/o responsabilidades lo que
garantizará la seguridad de la información a la que acceden y tratan.
P á g i n a | 90

Caso 23

23. No existe un Control de programación de pistas de auditoría


interna y Revisión de Eventos.

Descripción del problema: Se ha detectado que no existe un control de


programación de pistas de auditoría interna a través del sistema de
aplicativo y registro de eventos.

Riesgo: Medio

Descripción del riesgo: Al no controlar la programación de pistas de


auditoría es imposible conocer el camino de los datos, programas o
procesos utilizados desde su origen hasta los resultados finales que realizar
los usuarios dentro del sistema.

Recomendación: Recomendamos a la Administración el control de la


programación de pistas de auditoría y registro de eventos para poder así
individualizar a los responsables de las acciones, reconstruir un evento
realizado en el sistema, identificar intrusiones o problemas.

Caso 24

24. No existe restricción en el uso de medios de almacenamiento


externo USB.

Descripción del problema: Se ha visto que no existe una política de


restricción de uso de dispositivos de almacenamiento externo USB.

Riesgo: Medio

Descripción del riesgo: Si no hay una política de restricción de uso de


dispositivos de almacenamiento externo USB el ente corre el riesgo de que
usuarios malintencionados copien o graben archivos desde o hacia el
medio de almacenamiento USB, y por qué no la Base de Datos en el
extremo de la situación, también los USB son los medios preferidos de los
virus de computadora para camuflarse y propagarse.
P á g i n a | 91

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la realización de estrictas políticas
de restricción de uso de cualquier medio o dispositivo de almacenamiento
externo por parte de los usuarios de los Sistemas de aplicación por medidas
de seguridad para mitigar posibles daños al Sistema base Operativo y la
integridad de la información contenida.

Caso 25

25. No existe vencimiento de contraseña administrador en la Red LAN

Descripción del problema: Se ha constatado que no existe un


procedimiento para el vencimiento de contraseña administrador de la Red
de Área Local que permita a la municipalidad tener el control de accesos y
se pueda modificar por lo menos cada 2 meses.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de un procedimiento para el


vencimiento de la contraseña administrador de la red de área local, no
existe un control de contraseñas por parte de la Municipalidad, de modo
que un administrador de red antiguo puede seguir accediendo sin
autorización a la red con su misma contraseña.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica de TI debe
tener un plan de contingencias de cualquier naturaleza, recomendamos que
la Municipalidad pueda tomar las medidas de prevención, y definir un
procedimiento formal para el vencimiento de las contraseñas de la Red de
Área Local, de al menos cada 2 meses, lo cual debe ser comunicado al
Administrador de RED, de modo que se tenga la seguridad que solamente
está accediendo a la misma un Administrador de red autorizado.
P á g i n a | 92

4. Evaluar los planes de contingencias desarrollados por el


Departamento de Informática a efectos de asegurar la
continuidad del procesamiento de la información en caso de
interrupciones en los servicios, originados por desastres u
otras contingencias.

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD Ref.
Oviedo
P.T.:
PERIODO: 2015
IV – SEGURIDAD FÍSICA
Objetivo de control:
 Determinar si la Gerencia de TI, ha obtenido una evaluación real y efectiva
sobre los posibles riesgos físicos, identificando la vulnerabilidad de los bienes
tangibles y personales.
 Evaluar si la Gerencia de TI ha implantado los planes de acción, mecanismos
de respuesta y sistemas para controlar y reducir hasta donde sea posible los
riesgos identificados y minimizar o eliminar los daños o consecuencias.
R INDICADORES DE RELEVAMIENTO NCI Riesgo
EVALUACIÓN
E (Describa la √ - N/A 3=Alto
situación
F observada) 2=Medi
o,
1=Bajo

4.1 - PLANES DE CONTINUIDAD DEL NEGOCIO

4.1.1 Disponibilidad de los Planes No se puede X


de Continuidad de las evaluar los planes
actividades de TI (Plan de de contingencias
contingencia) necesarios para
garantizar la
continuidad de las
actividades de la
Municipalidad,
debido a que no se
cuenta con el
departamento de TI.
P á g i n a | 93

4.1.2 Ensayo, mantenimiento y No se puede X


evaluación de los planes de evaluar, ya que no
Continuidad de TI existe el
departamento de TI.
(Pruebas)

4.1.3 Aprobación por la Alta No se puede X


Gerencia del plan de evaluar, debido a
contingencias que no existe un
departamento de TI
que realice planes
de contingencias,
por lo tanto no se
puede aprobar

4.1.4 Disponibilidad del Plan de La no existencia TI X


Seguridad TI en la Municipalidad,
no se puede evaluar
la disponibilidad del
plan de Seguridad
de TI

4.1.5 Aprobación del Plan de No se puede X


Seguridad TI aprobar el plan de
seguridad TI. No se
cuenta con
departamento de TI

4.1.6 Otras observaciones X

4.2 - EVALUACIÓN DE LA SALA DE SERVIDORES – DATA CENTER Y ALTA


DISPONIBILIDAD

4.2.1 Sala de servidores No existe control de X 3


independiente y restricción acceso físico en la
de accesos, Controles de sala de servidores.
Acceso Físico

4.2.2 Restricción de accesos a la No existe X 3


sala de servidores, Bitácora restricciones de
de accesos acceso a la sala de
servidores
P á g i n a | 94

4.2.3 Evidencia del Todos los


mantenimiento de equipos mantenimientos de
preventivos equipos
informáticos y
periféricos,
principalmente del
servidor poseen
evidencia, ya que
todos los trabajos
de personas o
empresas externas
se realizan bajo
documentación
legal, que a su vez
la administración
realizan informes de
las mismas.

4.2.4 Lista de servidores No se cuenta con X 3


un listado de
servidores
disponibles, debido
a que solo existe un
servidor en la
Municipalidad

4.2.5 Servidor espejado - fuera No existe servidor X 3


del recinto principal fuera del recinto
principal

4.2.6 Arquitectura servidor – clon No existe Clon del X 2


servidor

4.2.7 Sistema operativo Server – Sistema Operativo


propietario – Libre Propietario

4.2.8 Rack de protección, No existe Rack de X 2


protegido con llave protección

4.2.9 Cableado de red ordenado, El cableado está


identificado por usuarios bien ordenado en el
cual se puede
P á g i n a | 95

identificar por
usuarios

4.2.10 Certificación del cableado No se cuenta con X 2


de red certificación del
cableado de red

4.2.11 Identificación de materiales No existe materiales


inflamables, en el recinto del inflamables en el
Data Center recinto de la Data
Center

4.2.12 Disponibilidad de detectores No se cuenta con X 3


de humo y calor detectores de humo
y calor en el Data
Center

4.2.13 Extintores especiales contra No se cuenta con X 2


incendios extintores
especiales para
equipos
computacionales en
el Data Center

4.2.14 Licencias de los sistemas La Municipalidad


operativos de redes cuenta con las
licencias de los
sistemas operativos
de redes

4.2.15 Disponibilidad del Sistema No se dispone del X 2


de puesta a tierra Sistema de puesta a
tierra en el Data
Center

4.2.16 Suministros de energía Todos los equipos


eléctrica, UPS poseen suministros
de energía eléctrica
ininterrumpible
(UPS) para proteger
los equipos en caso
de interrupciones de
la red eléctrica de la
ANDE
P á g i n a | 96

4.2.17 Suministros de energía No se cuenta con X 2


eléctrica, Generador de generador, que
electricidad suministre energía
eléctrica ante
posible caída de la
ANDE

4.2.18 Otras observaciones X

4.3 - EVALUACIÓN DEL RESGUARDO DE LA INFORMACIÓN - Copias de


respaldos

Se realizan copias
de respaldo en
4.3.1 Medio (dispositivo) de dispositivos de
realización almacenamiento
externo, que es
resguardado por la
administración y
finanzas

Cantidad de copias Fallas en el X 3


resguardo de la
4.3.2 información. Se
realizan 3 copias,
cada 4 meses

4.3.3 Lugar de almacenamiento, 2 copias internos,


interno/externo dentro del recinto y
1 copia externa, lo
tiene el
desarrollador.

Bases de datos
completo
4.3.4 Datos que se respaldan

Se realiza a través
del sistema de
4.3.5 Software de realización aplicación, con el
usuario autorizado
para su realización

El desarrollador
(encargado de
P á g i n a | 97

4.3.6 Responsable de realización mantenimiento del


sistema)

Registro de Planilla de No existe planilla de X 2


control de copias control de copias
4.3.7

4.3.8 Otras observaciones X

Caso 26

26. No existe sala de servidor independiente y restricción de acceso.

Descripción del problema: Se constatado que el ente no cuenta con una


sala de servidor independiente y por ende la ausencia de restricción de
acceso al mismo.

Riesgo: Alto

Descripción del riesgo: La no disponibilidad de una sala especial de


servidor impide adoptar una medida de restricción de cualquier empleado
al acceso donde está alojado el Servidor, el activo más importante dentro
de un ente es la información guardada en el servidor por consiguiente se
debe preservar ante posibles daños, catástrofes o intrusiones.

Recomendación: Recomendamos a la Administración la construcción de


una sala especialmente diseñada para alojar a los servidores, lo que
permitirá adoptar medidas de restricción de acceso al mismo y así
preservar la sala ante eventuales situaciones desfavorables.

Caso 27

27. No existe Bitácora de accesos a la sala de Servidores.

Descripción del problema: Se ha detectado que no existe una bitácora de


acceso a la Sala de Servidores.

Riesgo: Alto
P á g i n a | 98

Descripción del riesgo: Al no existir una bitácora de acceso a la sala de


servidores un empleado o persona externa que desea acceder al mismo no
registrará importantemente los datos de, Fecha de entrada, Nombre o
empresa, Motivo y la firma para justificar que accedió a la sala de
servidores.

Recomendación: Recomendamos a la Administración la realización de


una bitácora de accesos a la sala de servidores lo que permitirá llevar a
cabo un registro y control de las personas que acceden al centro de datos.
También permitirá controlar los trabajos realizados dentro de la sala de
servidores.

El personal altamente autorizado de acuerdo a criterio o necesidades que


se encuentran en su conocimiento permitirá o denegara el acceso al
solicitante.

Caso 28

28. No existe una listado de servidores.

Descripción del problema: Se ha hallado que no existe una lista de


servidores.

Riesgo: Alto

Descripción del riesgo: Al no existir una lista de servidores del centro de


datos es imposible identificar a los tipos de servidores y sus respectivas
funciones.

Recomendación: Recomendamos a la Administración la elaboración de


una lista de servidores del centro de datos para que se pueda tener la
información del tipo, función y estado de cada uno de los servidores,
también es aplicable si se cuenta con un solo servidor por que a medida
que se vayan añadiendo más servidores la lista de servidores será muy útil.
P á g i n a | 99

Caso 29

29. No existe un servidor espejado.

Descripción del problema: Se ha detectado que no existe un servidor de


tipo espejado fuera del local principal o del centro de datos.

Riesgo: Alto

Descripción del riesgo: Al no contar con un servidor espejado fuera del


recinto principal aumenta el riesgo de no poder acceder a la información
cuando haya fallas en el servidor principal por que no tendremos un réplica
de la misma en otro lugar. Inclusive en casos de catástrofes en el local del
servidor se corre el riesgo de perder toda la información contenida y no
poder recuperarla.

Recomendación: Recomendamos a la Administración la incorporación de


un servidor espejado fuera del recinto principal del ente, de acuerdo a
estándares de seguridad el servidor espejo es recomendable que este
mínimamente a un kilómetro del recinto principal. El servidor espejo
facilitara el acceso a los datos en caso de fallas del servidor principal,
porque la sincronización periódica entre ambos principal – espejo
mantendrá integro los datos.

Caso 30

30. No existe arquitectura servidor – clon.

Descripción del problema: Se ha detectado que no existe un servidor clon


dentro o fuera del recinto principal.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de un servidor clon ocasiona


que no se puede dar continuidad al servicio que presta el ente o negocio,
porque en caso de siniestro del servidor principal no se tendría un servidor
con las mismas funcionalidades y los mismos datos.
P á g i n a | 100

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la adquisición de un nuevo
servidor para ser usado como clon del servidor principal para que en caso
de siniestro u otro evento similar se pueda dar continuidad del negocio,
porque el servidor clon se pondrá en marcha en forma automática
igualando todos los servicios del servidor principal, conste además que los
usuarios no se darán cuenta de que el servidor principal sufrió una falla
catastrófica.

Caso 31

31. No existe Rack de protección.

Descripción del problema: Se ha constatado que en el centro de datos


no existe un rack de protección protegido con llave.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de un armario o rack de


protección protegido y cerrado con llave de los servidores situados dentro
o fuera del centro de datos se corre el riesgo de que personas
malintencionadas tengan más facilidad para perpetrar hechos contra el
ente.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos a la Administración la adquisición
de armarios o rack de protección a la altura de los estándares de seguridad
por ejemplo obligatoriamente deben contar con protección con llave. Al
contar con estos armarios se puede imponer políticas de acceso al centro
de dato, porque por ejemplo personales de limpieza pueden ocasionar
daños graves por desconocimiento al desenchufar un servidor principal
para enchufar la aspiradora.
P á g i n a | 101

Caso 32

32. No existe Certificación del cableado de red.

Descripción del problema: Se ha constatado que el ente no cuenta con


certificados de cableado de red que autentiquen el correcto funcionamiento
del cableado.

Riesgo: Medio

Descripción del riesgo: Sin la certificación de cableado de red no se sabe


el rendimiento de transmisión de datos a través del cableado lo que puede
ocasionar graves problemas de comunicación entre los dispositivos.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos a la Administración certificar el
cableado de red para garantizar la calidad de los componentes, la
instalación y que los enlaces de datos proporcionen el resultado deseado.
A través de la certificación de cableado se diagnosticaran los enlaces que
fallan y se realizaran acciones correctivas y volverán a ser testadas.

Caso 33

33. No existe Disponibilidad de detectores de humo y calor.

Descripción del problema: Se ha detectado que no existen aparatos de


seguridad como detectores de humo y calor.

Riesgo: Alto

Descripción del riesgo: Al no dispones de detectores de humo y calor es


más propenso que en caso de principio de incendio no haya una señal de
aviso del inminente peligro.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos a la Administración la adquisición
P á g i n a | 102

de estos aparatos de seguridad para que en caso de peligro de incendios


haya una señal acústica avisando, estos detectores detectan humo y el
cambio de temperatura en el lugar donde está colocado. Cabe mencionar
que estos aparatos requieren de un constante mantenimiento para su
correcto funcionamiento.

Caso 34

34. Inexistencia de extintores para computadoras

Descripción del problema: Se ha detectado fallas en el sistema de


seguridad físicas al no disponer de extinguidores contra incendios para las
computadoras.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de extintores para equipos


informáticos aumenta el riesgo de ocurrir incidentes dentro de la entidad,
ya que no se podrán controlar algún indicio de incendios, poniendo en
riesgo todas las aplicaciones de hardware, software y medios de
comunicaciones.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica debe tener
un plan de contingencias de cualquier naturaleza, recomendamos la
implementación de un plan de riesgos dentro de la Municipalidad, de modo
que se tengan extintores especiales para las computadoras y que se
realicen medidas de control.

Caso 35

35. No se dispone del Sistema de puesta a tierra en el Data Center

Descripción del problema: Se ha detectado fallas en el sistema de


seguridad físicas al no disponer de instalación de sistema puesta a tierra,
en el Data Center principalmente.
P á g i n a | 103

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de un sistema de puesta a


tierra aumenta el riesgo de ocurrir incidentes dentro de la entidad, ya que
si existe una gran descarga de electricidad golpeará directamente a las
computadoras y al Data Center que podría quemar los dispositivos y dejar
de funcionar el servidor principal, poniendo en riesgo todas las aplicaciones
de hardware, software y medios de comunicaciones.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica debe tener
un plan de contingencias de cualquier naturaleza, recomendamos la
implementación de un plan de riesgos dentro de la Municipalidad, de modo
que se instale un sistema de puesta a tierra para todos los equipos
informáticos y en el Data Center principalmente.

Caso 36

36. No existe generador de electricidad.

Descripción del problema: Se ha detectado que el ente no cuenta con un


sistema de generación de electricidad, que suministre energía eléctrica
ante posible caída de la ANDE.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de una generador de


electricidad provoca que en caso de corte del suministro eléctrico proveída
por la ANDE no se pueda continuar por mucho tiempo la continuidad del
servicio, cabe señalar que los UPS tiene un tiempo limitado de
funcionamiento.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos a la Administración la adquisición
de un generador de electricidad para que en caso de corte del suministro
P á g i n a | 104

de electricidad proveído por la ANDE se pueda seguir brindando el servicio


con toda normalidad.

Caso 37

37. Fallas en el resguardo de la información.

Descripción del problema: Se ha detectado que las copias de seguridad


de la base de datos se realiza cada cuatro meses.

Riesgo: Alto

Descripción del riesgo: Al realizar la copia de seguridad de la base de


datos cada cuatro meses se corre un inmenso riesgo que en entre la última
realización de la copia hasta llegar a los cuatro meses de que ocurra
catástrofes o fallas en los servidores principales y alternativos
imposibilitando recuperar la base de datos a través de copias de seguridad.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos a la Administración la realización
de la copia de seguridad de la base de datos de forma diaria como todos
sabemos uno de los puntos críticos dentro de cualquier plan de
contingencia en Sistemas de Información es dar de cara a la continuidad
de la organización.

Caso 38

38. No existe un Registro de Planilla de control de copias de respaldo.

Descripción del problema: Se ha detectado que no existe un registro de


planillas de control de copias de seguridad realizadas.

Riesgo: Medio

Descripción del riesgo: Al no contar con una planilla de control de copias


de seguridad realizadas es imposible determinar quién lo hizo, la fecha, la
hora y donde se almaceno o el medio de almacenamiento.
P á g i n a | 105

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos a la Administración la confección
e implementación de una planilla de registro de copias de seguridad o
respaldo para transparentar la acción e individualizar responsabilidades. El
profesional encargado del centro de datos o la sala de servidores debe
verificar en la planilla de registro de copias de seguridad el código del
dispositivo de almacenamiento y registrar la fecha de ejecución.

Caso 39

39. Falta de un encargado de mantenimiento a las computadoras

Descripción del problema: Se ha detectado que en la Municipalidad no


existe un encargado del mantenimiento a las computadoras que puedan
proporcionar la seguridad de todo el hardware, ya que los personales de la
caja, liquidación, tránsito y administración los realizan de forma empírica.

Riesgo: Bajo

Descripción del riesgo: La falta de un encargado de mantenimiento a las


computadoras, puede ocasionar un riesgo de que los personales de caja,
liquidación, tránsito y administración no puedan solucionar un problema
determinado o en caso contrario al intentar solucionar puede dañar el
equipo, ya que no están capacitados para este trabajo.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la contratación de un encargado
de mantenimientos capacitado que pueda mantener seguros a las
computadoras de la Municipalidad, evitando cualquier contratiempos por
problemas de hardware.
P á g i n a | 106

Caso 40

40. Inexistencia de un plan de seguridad contra catástrofes

Descripción del problema: Se ha detectado que no existe un plan de


contingencias en caso de que ocurra catástrofes naturales o provocados
por el hombre.

Riesgo: Alto

Descripción del riesgo: La no existencia de planes de contingencias para


que la Municipalidad pueda seguir operando en caso de que ocurra
catástrofes, puede ocasionar la perdida de información y cuentas de los
contribuyentes, cuentas bancarias y otros, ya que en el mundo actual el
activo más importante de las organizaciones son las informaciones.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos la creación e implementación de
un plan de riesgos dentro de la empresa, de modo que se pueda tener
copias de respaldo diario en un lugar físico de por lo menos un kilómetro
de distancia de la entidad.

Caso 41

41. Inexistencia de una copia de respaldo fuera del local

Descripción del problema: Se ha constatado que no existe una copia


alternativa de respaldo diario que sean resguardados fuera del local o fuera
de la caja fuerte donde se guardan actualmente.

Riesgo: Alto

Descripción del riesgo: La no existencia de una copia de respaldo diario


fuera de la empresa, puede ocasionar un riesgo enorme si es que se llega
a ocurrir algún accidente o catástrofes que pueda dañar todo el edificio, de
P á g i n a | 107

modo que se pueden perder todas las informaciones sin una forma de
recuperarla.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que debe existir un plan de contingencias
de cualquier naturaleza, recomendamos que se tenga copias de respaldo
diario alternativo que sean resguardados fuera de la empresa de por lo
menos un km de distancia.

Caso 42

42. Inexistencia de una protección para el servidor

Descripción del problema: Se ha detectado que los servidores no se


están protegidos suficientemente, el cableado está directamente sobre la
superficie, no se dispone rack de protección para los servidores, no se
dispone de detectores de humo y calor.

Riesgo: Alto

Descripción del riesgo: La no disponibilidad de un plan de contingencias


para proteger a los servidores aumenta el riesgo de ocurrir incidentes que
pueden dañar al servidor y por ende al sistema mismo.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, establece que cualquier área tecnológica de TI debe
tener un plan de contingencias de cualquier naturaleza, recomendamos la
implementación de un plan de riesgos dentro de la entidad, de modo que
se mantenga protegido el servidor, ya sea de personas no autorizadas,
como incidentes con el cableado e indicios de incendios.

Caso 43

43. Inexistencia de un control de perfiles de usuarios

Descripción del problema: Se ha constatado que los puertos USB se


encuentran activadas, y los perfiles de usuarios del sistema operativo
P á g i n a | 108

Windows, no tiene cuentas limitadas, es decir se encuentran configurados


como administradores.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de cuentas limitadas para los


usuarios existe un riesgo de que los usuarios de Windows pueden realizar
modificaciones dentro del sistema operativo, como instalación de
programas sin autorización, realizar actualizaciones, insertar virus a las
computadoras por medio de dispositivos móviles USB, entre otros. Lo cual
afectaría al sistema informático de la Municipalidad como lentitud en el
procesamiento.

Recomendación: Recomendamos que la administración se encargue de


los permisos para los diferentes usuarios, de modo que los mismos
accedan al sistema operativo Windows como invitados y no como
administrador, así evitar que se instalen programas innecesarias que
podrían dañar al sistema, y que los puertos USB sean activados solamente
a personas con mayor rango y responsabilidad como el administrador y
otros que necesariamente deban utilizarlas.

5. Identificar las documentaciones pertinentes utilizadas por el


Departamento de Tecnología Informática.

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio Ref.
ENTIDAD:
Oviedo P.T.
PERIODO: 2015 :
V – DOCUMENTACIONES DE TI
Objetivo de control:
 El propósito de este formulario es obtener conocimiento de los documentos
aplicado por la entidad, en lo referente a sistemas y gestión, así como la
evaluación de proyectos tecnológicos.
R INDICADORES DE RELEVAMIENTO NCI Riesgo
EVALUACIÓN
E (Describa la situación √ - N/A 3=Alto
observada)
P á g i n a | 109

F 2=Medio
1=Bajo

5.1 - DOCUMENTACIÓN DE FUNCIONES Y PROCEDIMIENTOS

5.1.1 Manual de cargos y X


funciones:

a) Disponible
b) Aprobado por la
Alta Gerencia
c) Actualizado
d) Definido
claramente las
responsabilidade
s
5.1.2 Manual de X
procedimientos:

a) Disponible
b) Aprobado por la
Alta Gerencia
c) Actualizado
d) Definido
claramente los
procedimientos
5.1.3 Definición de X
propietario de datos,
determinación de
responsabilidades
sobre las principales
tablas

5.1.4 Otras observaciones X

5.2 – RELEVAMIENTO DE INVENTARIOS Y MANUALES TÉCNICOS

5.2.1 Manuales de usuarios X


– impresos –
interactivos

5.2.2 Manuales DFD, UML, X


AOO – disponibles -
actualizados
P á g i n a | 110

5.2.3 Manuales de ER – X
disponibles -
actualizados

5.2.4 Disponibilidad de X
Inventario de activos –
hardware –
actualizado

5.2.5 Disponibilidad de X
inventario de activos -
software – actualizado

5.2.6 Otras observaciones X

5.3 - EVALUACIÓN DE LA ADMINISTRACIÒN DE PROYECTOS

5.3.1 Definición y esquema X


de administración de
proyectos de TI

5.3.2 Participación de X
usuario en el inicio del
Proyecto

5.3.3 Formación del Equipo X


de Proyecto y
Asignación de
Responsabilidades

5.3.4 Estudio de Viabilidad X


Tecnológica

5.3.5 Estudio de Viabilidad X


Económica

5.3.6 Aprobación de Fase X


de proyecto

5.3.7 Plan Maestro del X


Proyecto

5.3.8 Plan de Control de X


Calidad de Sistemas
P á g i n a | 111

5.3.9 Planificación de X
Métodos de Seguridad

5.3.10 Plan de Pruebas del X


Proyecto

5.3.11 Plan de Entrenamiento X

5.3.12 Metodología de X
Desarrollo de
Sistemas

5.3.13 Coordinación y X
Comunicación en la
ejecución del proyecto

5.3.14 Selección de software X


de base

5.3.15 Normas de X
documentación de
programas

5.3.16 Normas de pruebas de X


programas

5.3.17 Normas respecto a la X


prueba de sistemas

5.3.18 Normas respecto a las X


pruebas Piloto o en
Paralelo

5.3.19 Otras observaciones X

5.4 – EVALUACIÓN DEL CUMPLIMIENTO DE CONTRATO

5.4.1 Descripción del X


contrato - alcance

5.4.2 Definición del X


administrador del
contrato

5.4.3 Definición de fiscales X


del contrato
P á g i n a | 112

5.4.4 Evidencia de solicitud X


de prórroga

5.4.5 Solicitud de reajustes X

5.4.6 Solicitud de recepción X


técnica provisoria

5.4.7 Solicitud de recepción X


técnica definitiva

5.4.8 Contrato de X
mantenimiento
hardware-
vencimiento-
cronograma

5.4.9 Contrato de X
mantenimiento de
software - vencimiento

5.4.10 Contrato de suministro X


de Internet,
vencimiento

5.4.11 Contrato de licencias X


de software propietario

5.4.12 Contrato de seguro de X


equipos
computacionales -
servidores

5.4.13 Otras observaciones X

Observación

La no existencia de gerenciamiento de TI, impide que se pueda evaluar las


documentaciones de TI. Por lo tanto no se podrá obtener conocimiento de
los documentos aplicados por la entidad, en lo referente a sistemas y
gestión, así como la evaluación de proyectos tecnológicos. No se podrá
evaluar los siguientes: documentación de funciones y procedimientos,
P á g i n a | 113

relevamiento de inventarios y manuales técnicos, evaluación de la


administración de proyectos, y evaluación del cumplimiento de contrato

6. Evaluar la adecuada capacitación de los usuarios en las


operaciones de los módulos del sistema informático.

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD: Ref.
Oviedo
P.T.:
PERIODO: 2015
VI – EVALUACIÓN DE RR.HH.
Objetivo de control:
 Maximizar las contribuciones del personal vinculado a los procesos de
tecnologías de la información en los diferentes escenarios del ambiente
tecnológico.
Procedimientos generales:

1. Entrevistas con el personal vinculado a las tecnologías de información.


2. Aplicación de cuestionarios.
3. Revisión de Manuales de Organización Cargos y Funciones del sector de
tecnologías. Responsabilidades.
4. Revisión de las políticas de reclutamiento del personal del área.
5. Revisión del Plan Anual de Capacitación del sector de tecnologías, así
como la aprobación y ejecución del mismo.
6. Revisión de los requerimientos de calificaciones, evaluación objetiva y
medible del desempeño.
R INDICADORES DE RELEVAMIENTO NCI Riesgo
EVALUACIÓN
E (Describa la situación √ - N/A 3=Alto
observada)
F 2=Medio
1=Bajo

6.1 - Administración de los Recursos Humanos – Evaluación del


desempeño

6.1.1 ¿Existen políticas La no existencia de un X


diseñadas para el departamento de TI,
reclutamiento del no se puede evaluar
personal de las políticas diseñadas
tecnologías? (verificar para el reclutamiento
requerimientos de
P á g i n a | 114

calificaciones, del personal de


capacitación, tecnología
experiencia,
entrenamientos,
currículo, etc.)

6.1.2 ¿Existen No se cuentan con X 1


requerimientos de requerimientos de
calificaciones, calificaciones ni de
experiencia y experiencia para
conocimientos básicos integrar la cartera de
en aquellos empleados usuarios en la
que no pertenecen al Municipalidad, sin
área de tecnologías y embargo se requiere
que integran la cartera de conocimientos
de usuarios de la básicos para el puesto
entidad? (se pide curriculum
vitae)

6.1.3 ¿Existe el reglamento No se puede evaluar, X


interno de tecnologías debido a que no se
de la información y cuenta con personales
esté es entregado para de TI
su conocimiento a todo
el personal de la
entidad en el momento
de su aprobación
como empleado?

6.1.4 ¿Es evaluado el No se puede evaluar, X


personal de debido a que no se
tecnologías de la cuenta con personal
información como de TI
mínimo una vez al año
a través de una
evaluación objetiva del
desempeño?

6.1.5 ¿Existe la metodología No existe una X 1


de evaluación del metodología de
personal empleado, evaluación del
que muestre los personal
P á g i n a | 115

criterios adoptados por


la organización?

6.1.6 Otras observaciones X

6.2 - Capacitación y entrenamiento

6.2.1 ¿Existe el plan anual No se puede evaluar. X


de capacitación para el No se cuenta con el
área de tecnologías de área de TI
la información?
6.2.2 ¿Es aprobado por la No se puede evaluar. X
alta dirección de la No existe un plan
entidad el plan anual anual ya que no se
de capacitación al cuenta con el
sector de tecnologías? departamento de TI

6.2.3 ¿Se controla el No se puede evaluar. X


cumplimiento del plan No se cuenta con el
de capacitación anual área de TI y Recursos
por el área de Humanos
tecnologías y recursos
humanos?
6.2.4 ¿La capacitación y No se puede evaluar. X
entrena-miento No se cuenta con el
referida a la área de TI
implementación de
sistemas de
información,
participación en
talleres, conferencias,
etc. es controlada por
el área de sistemas y
esto se incluyen en la
ficha o evaluación del
personal?
6.2.5 ¿Existe un plan La Municipalidad no X 2
general de cuenta con un plan
entrenamiento y general de
desarrollo para entrenamiento y
usuarios con objetivos desarrollo para los
específicos sobre usuarios del sistema,
concientización y que permita la
P á g i n a | 116

actualización en concientización y
materia de actualización en
informática? materia de informática

Caso 44

44. Inexistencia de requerimientos de calificaciones y experiencia para


integrar la cartera de usuarios de la Municipalidad

Descripción del problema: Se ha detectado que en la Municipalidad no


existen requerimientos de calificaciones y experiencia para integrar la
cartera de usuarios, por lo que no se sabe la verdadera capacidad de los
nuevos funcionarios para su contratación.

Riesgo: Bajo

Descripción del riesgo: La no disponibilidad de un sistema de calificación


y experiencia para la contratación de un nuevo funcionario puede ocasionar
que se contrate personas con poca experiencia y no esté calificado para el
puesto, esto a su vez podría llevar a una deficiencia en el servicio que
presta la entidad.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, recomendamos a la Municipalidad que se implemente
una políticas de recursos humanos en la que se establezca los
requerimientos de calificaciones y experiencia para las nuevas
contrataciones que van a integrar la cartera de usuarios de la entidad.

Caso 45

45. No existe una metodología de evaluación del personal

Descripción del problema: Se ha detectado que en la Municipalidad no


existe una metodología de evaluación del personal empleado, por lo que
no se tiene los criterios adoptados por la entidad.

Riesgo: Bajo
P á g i n a | 117

Descripción del riesgo: La no disponibilidad de una metodología de


evaluación del personal empleado, no se podrá conocer el rendimiento de
mismo, por lo que no se puede hacer proyecciones a futuros sobre los
criterios para las nuevas contrataciones del personal y las necesidades en
la cartera de usuarios.

Recomendación: De manera a cumplir con los requisitos de las normas


COBIT y del MCIIEF, recomendamos a la Municipalidad que se implemente
una política de recursos humanos en la que se establezca una metodología
de evaluación del personal empleado, que muestre los criterios adoptados
por la entidad.

Caso 46

46. Inexistencia de un plan general de entrenamiento y desarrollo para


usuarios

Descripción del problema: Se ha constatado que no existe un plan


general de entrenamiento y desarrollo para usuarios con objetivos
específicos sobre la concientización y en la actualización sobre el tema de
informática.

Riesgo: Medio

Descripción del riesgo: La no disponibilidad de un plan de entrenamiento


y desarrollo para usuarios en la Municipalidad, existe el riesgo de que los
usuarios queden a la antigua y se resistan a las nuevas tecnologías y puede
existir un conflicto a la hora de actualizarse en materia de informática. Lo
cual afectaría en el uso correcto del sistema y los equipos informáticos.

Recomendación: De manera a cumplir con normas COBIT y el MCIIEF,


recomendamos que la administración y finanzas realicen un plan general
de entrenamiento y desarrollo para usuarios con objetivos específicos
sobre concientización y actualización en materia de informática. De esta
forma tener capacitados a los usuarios de la entidad y puedan hacer frente
P á g i n a | 118

a las nuevas tecnologías, en el buen uso y manejo de los sistemas de


información y de los equipos informáticos.
CAPITULO V – CONCLUSIONES Y
RECOMENDACIONES

V.1 Conclusiones

A partir de las informaciones obtenidas de las distintas tareas de


investigación se pudo realizar un análisis y relevamiento de datos concreto
en el que se detallan todas las características de la Municipalidad, su
funcionamiento y la situación actual, así como las herramientas a utilizar
como las notas de control interno de Tecnología Informática y las normas
estándares COBIT y el MCIIEF que son utilizadas para la Auditoría
Informática en el ente.

Posteriormente, se realizó las notas de control interno de Tecnología


Informática utilizando los estándares COBIT y MCIIEF, de esta forma se
pudieron recopilar todos los problemas o riesgos de seguridad física y
lógica del área informática, el sistema de información, las documentaciones
de TI y recursos humanos, de ahí se pudieron describir el problema o
riesgo, las vulnerabilidades que tiene el área informática, el nivel del riesgo
y las recomendaciones pertinentes para cada caso práctico.

En base a la labor realizada, en el marco de la auditoría del área informática


se observaron situaciones que son necesarios informar a la intendencia.
Los procedimientos y funciones que actualmente no son considerados en
P á g i n a | 120

el área informática, así como los temas observados, junto con sus
recomendaciones para su corrección, son detallados en este proyecto.

Existen muchas falencias en el área informática, ya sea por la falta de


conocimientos o el presupuesto mismo de la municipalidad para
implementar sistemas de seguridad que pueden ayudar en la fiabilidad y
eficiencia del sistema de información.

De este modo la Auditoría Informática llega a cumplir con todos los


requerimientos y objetivos que se plantearon al principio del proyecto y por
ende podría llegar a dar solución a los distintos problemas o
vulnerabilidades encontradas en la Municipalidad.

V.2 Recomendaciones

Con todo lo indicado se recomienda a la Municipalidad presupuestar y dar


cumplimiento a las recomendaciones para la seguridad física y lógica en el
sistema de información detallado en el informe.

Además se sugiere formar un Departamento de TI y Gerenciamiento para


la buena gestión de los recursos informáticos, y comprar el código fuente
del proveedor externo, de esta forma para no depender de una persona o
empresa para la continuidad del software y los mantenimientos de los
equipos informáticas.
P á g i n a | 122

BIBLIOGRAFÍA

 Alonso Rivas, G., 1998. Auditoria Informática. Díaz de Santos. Madrid


 Auditores y Consultores Asociados, 2005. Programa de Auditoría
Informática. Procedimientos y Técnicas, AYCA.
 Auditoria de Sistemas. Informe de Auditoría. Extraído el 10 de Marzo
de 2015, de
http://audisistemasremington.blogspot.com/2010/06/ejemplo-informe-
de-auditoria.html
 Benal R., Coltell O. 1996. Auditoría de los Sistemas de Información.
Servicio de Publicaciones de la Universidad Politécnica de Valencia,
Valencia.
 Borja Ortiz, D. (2009). Los trabajos de investigación para conclusión de
Carrera. Paraguay: Litocolor.
 COBIT: Modelo para Auditoría y Control de Sistemas de Información.
Extraído el 10 de Marzo de 2015, de
http://www.hacienda.go.cr/cifh/sidovih/spaw2/uploads/images/file/COB
IT%20audit%20y%20ctrol%20sists%20inf.pdf
 Corte Suprema de Justicia. 2001. Código Penal de la República del
Paraguay Ley Nº 1160/97. Tomo I. Asunción-Paraguay
 Etchenique, J. A., 1999, Auditoría Informática, México, Editorial
Prentice Hall
 Hernández Sampieri, R., Fernández Collado, C., Del Pilar Baptista
Lucio, M. (2010). Metodología de la investigación (5ª Ed.). México:Mc
Graw Hill.
 Information Systems audit. And Control Association, 2005. Manual de
Información Técnica CISA de la ISACA.
 Poder Legislativo. 2008. Ley Nº 4439 Que modifica y amplía varios
artículos de la Ley Nº 1160/97 “Código Penal”. Asunción-Paraguay
P á g i n a | 123

 Superintendencia de Bancos del Banco Central del Paraguay, 2002.


Manual de Control Interno Informático para Entidades Financieras
(MCIIEF) establecida por Resolución SB. SG. Nro.: 188/2002
 Thorin, Marc, 1989. La Auditoría Informática: métodos, reglas, normas.
Ed. Masson, S.A.
P á g i n a | 124

ANEXO

Anexo 1. Parte Complementaria

Cronograma
P á g i n a | 125

Diagrama de Gantt
P á g i n a | 122

Presupuesto
P á g i n a | 123

Anexo 2. Papeles de Trabajo de Controles Generales de TI

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


ENTIDAD: Municipalidad Raúl Arsenio Oviedo Ref.
T.I.
PERIODO: 2015 P.T.:
I - ESTRUCTURA DE TI Y GERENCIAMIENTO
Objetivo de control:

 El propósito de este formulario es obtener conocimiento de la estructura


administrativa del área de Tecnología de la Información, determinando la buena
gestión de gerenciamiento.

R INDICADORES DE EVALUACIÓN RELEVAMIENTO NCI Riesgo

E (Describa la √- 3=Alto

situación observada) N/A 2=Medio


F 1=Bajo

1.1 – ESTRUCTURA DEL ÁREA DE TI

1.1.1 Ubicación Estructural del Área de


Servicios de TI

1.1.2 Organigrama de TI – disponible y


actualizado

1.1.3 Otras observaciones

1.2 – ORGANIZACIÓN DE LA ESTRUCTURA DE TI

1.2.1 Gerente/Jefe/Encargado de TI

1.2.2 Responsable de la
Administración de BD

1.2.3 Responsable de la
Administración de Redes

1.2.4 Responsable de la
Administración de Sistemas
P á g i n a | 124

1.2.5 Soporte técnico/Estructura

1.2.6 Desarrolladores

1.2.7 Responsables de la
Administración de la Seguridad

1.2.8 Separación de funciones -


Identificación del Personal Clave
de Tecnología de Información

1.2.9 Otras observaciones

1.3 - EVALUACIÓN DE GESTIÓN DE TI – Gerenciamiento

1.3.1 Plan de TI a largo plazo, enfoque


y estructura, aprobación

1.3.2 Plan de TI a corto plazo,


planificación de la capacidad de
la infraestructura tecnológica

1.3.3 Cambios al plan de TI a largo


plazo – Aprobación

1.3.4 Evaluación permanente del Plan


Estratégico de Tecnología de
Información

1.3.5 Metodología de control de


adquisiciones - procedimientos

1.3.6 Otras observaciones


P á g i n a | 125

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


ENTIDAD: Municipalidad de Raúl Arsenio Oviedo Ref.
PERIODO: 2015 P.T.:
II - SISTEMAS DE INFORMACIÓN
Objetivo de control:

 El propósito de este formulario es obtener conocimiento del sistema de


información automatizado del cliente y dejar documentado en el archivo
permanente.

R INDICADORES DE RELEVAMIENTO NCI Riesgo


EVALUACIÓN
E (Describa la situación √- 3=Alto

observada) N/A 2=Medio


F 1=Bajo

2.1 - RELEVAMIENTO DEL SISTEMA DE INFORMACIÓN DEL CLIENTE

2.1.1 Identificación del sistema,


describir el nombre del
sistema, la plataforma de
base de datos, lenguaje de
programación

2.1.2 Proveedor (interno -


externo), describir si el
sistema fue adquirido de
terceros o desarrollado
internamente

2.1.3 Descripción de los


módulos, detallar los
módulos que comprende

2.1.4 Objetivo de los módulos,


describir la funcionalidad
de cada módulo

2.1.5 Integración de módulos –


ERP, (identificación de los
módulos no integrados a
la contabilidad),
identificar los módulos no
P á g i n a | 126

integrados y las razones


de la no integración

2.1.6 Asientos manuales


realizados, debido a la no
automatización – Ajustes,
describir si existen casos
de asientos manuales
desarrollados, así como el
motivo de dichos asientos

2.1.7 Tipo de software


(propietario – libre),
versiones, describir la
plataforma del sistema, si
opera bajo sistema
propietario o no, y la
funcionalidad en el
servidor

2.1.8 Disponibilidad de fuentes,


detallar si se dispone los
programas fuentes y si se
ha certificado la
actualización de la versión

2.1.9 Control de versiones del


código fuente y
autorización para el
traspaso al entorno de
producción, describir
procedimiento

2.1.10 Pruebas del sistema en


forma paralela antes del
traspaso a producción,
describir procedimiento

2.1.11 Prueba de aceptación final


antes del traspaso a
producción, describir
procedimiento
P á g i n a | 127

2.1.12 Estructura de desarrollo


paralelo – servidor
independiente, describir
estructura

2.1.13 Procedimientos aplicados


ante la eventual caída del
sistema , describir
procedimiento

2.1.14 Mecanismo para el cierre


diario del sistema –
Participantes –
Aprobación

2.1.15 Mecanismo de conciliación


con los demás módulos
del sistema – libros
auxiliares – saldos
contables

2.1.16 En casos de ajustes


eventuales de registros ya
procesados, ¿cómo se
realiza y quien autoriza?

2.1.17 Otras observaciones

2.2 - EVALUACIÓN DEL DESARROLLO Y MANTENIMIENTO DE SISTEMAS -


Equipo interno

2.2.1 Procedimientos controles


de seguridad aplicados en
la etapa de análisis y
diseño del sistema,
determinar si en la etapa
de diseño se ha
considerado los
procedimientos de
seguridad

2.2.2 Seguridad en los Sistemas


de Aplicación, validación
de datos de entrada,
P á g i n a | 128

detallar los criterios de


validación aplicado en
cada dato de entrada
(manual y automático)

2.2.3 Política de utilización de


controles criptográficos,
encriptación, evaluar si la
base de datos aplica
códigos de encriptación,
principalmente para el
resguardo de las
contraseñas

2.2.4 Protección de los datos de


prueba del sistema,
aplicación de otras BD
para pruebas, evaluar si
las pruebas a nivel de base
de datos son aplicados en
una base de datos paralelo

2.2.5 Control de cambios a


datos operativos,
manipulación de datos a
través de un MGBD,
evaluar si existe la
posibilidad que un usuario
ingresa a la base de datos
conociendo el password y
si a través de dicho
ingreso es posible alterar
datos de producción

2.2.6 Mecanismo, registro y


control de acceso a las
bibliotecas de programas
fuentes, evaluar si quienes
tienen acceso a los
programas fuentes,
inclusive a las versiones
anteriores
P á g i n a | 129

2.2.7 Otras observaciones

2.3 - EVALUACIÓN DEL DESARROLLO Y MANTENIMIENTO DE SISTEMAS –


Consultoría externa

2.3.1 Acuerdos de licencias,


propiedad de código y
derechos conferidos.

2.3.2 Requerimientos
contractuales con respecto
a la calidad del código y la
existencia de garantías.

2.3.3 Procedimientos de
certificación de la calidad,
que incluyan auditorías
internas de sistemas.

2.3.4 Acuerdos de custodia de


las fuentes del software.

2.3.5 Otras observaciones


P á g i n a | 130

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD: Ref.
Oviedo
P.T.:
PERIODO: 2015
III – SEGURIDAD LÓGICA
Objetivo de control:
Evaluar si los sistemas de información cumplen con los siguientes objetivos principales:
 Integridad: garantizar que los datos sean los que se supone que son.
 Confidencialidad: asegurar que sólo los individuos autorizados tengan acceso a
los recursos que se intercambian.
 Disponibilidad: garantizar el correcto funcionamiento de los sistemas de
información.
 Evitar el rechazo: garantizar de que no pueda negar una operación realizada.
 Autenticación: asegurar que sólo los individuos autorizados tengan acceso a los
recursos.
R INDICADORES DE RELEVAMIENTO NCI Riesgo
EVALUACIÓN 3=Alto
E (Describa la situación √-
observada) N/A 2=Medio
F 1=Bajo

3.1 - APLICACIÓN DE CONTRASEÑAS – LAN (Red de Área Local)

3.1.1 Requerimiento de
contraseñas - LAN

3.1.2 Aplicación de usuarios


únicos, no genéricos

3.1.3 Expiración de
contraseñas, en forma
automática

3.1.4 Contraseña diferenciada a


la identificación del
usuario

3.1.5 Bloqueo por intento de


accesos con claves
erróneas

3.1.6 Documentación aplicado


para alta – baja y
modificación de usuarios
P á g i n a | 131

3.1.7 Habilitación de los


registros históricos y/o
logs de auditorías que
reporten sobre intentos de
usuarios mal
intencionados

3.1.8 Restricción de accesos a


otras unidades de discos
desde una estación de
trabajo

3.1.9 Documento firmado por


los usuarios señalando
que comprenden y
aceptan las condiciones
para el acceso a la red de
área local y determinación
de confidencialidad

3.1.10 Protección de acceso a


internet, documento de
autorización para el
acceso

3.1.11 Restricciones de accesos


por horario en la red LAN -
limitación del horario de
conexión

3.1.12 Otras observaciones

3.2 - APLICACIÓN DE CONTRASEÑAS – Sistema aplicativo

3.2.1 Requerimiento de
contraseñas - LAN

3.2.2 Expiración de
contraseñas, en forma
automática

3.2.3 Aplicación correcta de


perfiles de usuarios
P á g i n a | 132

3.2.4 No repetición de
contraseñas en los
sistemas de gestión

3.2.5 Aplicación de contraseña


diferente a la
identificación de usuario

3.2.6 Desconexión del sistema


por tiempo muerto –
Desactivación del código
de usuario

3.2.7 Registro en el sistema de


acceso de usuarios, para
auditoría

3.2.8 Bloqueo por intento de


claves erróneas

3.2.9 Documentación y
procedimiento aplicado
para la alta – baja y
mantenimiento de
usuarios

3.2.10 Documento firmado por


los usuarios señalando
que comprenden y
aceptan las condiciones
para el acceso a los
sistemas y determinación
de confidencialidad

3.2.11 Control de programación


de pistas de auditoría
interna a través del
sistema de aplicación -
Registro y Revisión de
Eventos

3.2.12 Uso de medios de


almacenamiento externo
P á g i n a | 133

USB, en tareas críticas –


política de restricción

3.2.13 Revisión de los de


derechos de acceso de
usuarios, por parte de los
propietarios de datos

3.2.14 Otras observaciones

3.3 - ADMINISTRACIÓN DE CLAVES – SISTEMAS DE INFORMACIÓN Y LAN

3.3.1 Vencimiento de
contraseñas
administradores de Red
LAN

3.3.2 Vencimiento de
contraseñas
administradores de BD

3.3.3 Vencimiento de
contraseñas
administradores de
Sistemas

3.3.4 Resguardo en sobre


lacrado, con conocimiento
de la Alta Gerencia

3.3.5 Otras observaciones

3.4 – EVALUACIÓN DE PROTECCIÓN CONTRA SOFTWARE MALICIOSO

3.4.1 Controles aplicados para


la prevención de software
malicioso - Virus
P á g i n a | 134

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD Ref.
Oviedo
P.T.:
PERIODO: 2015
IV – SEGURIDAD FÍSICA
Objetivo de control:
 Determinar si la Gerencia de TI, ha obtenido una evaluación real y efectiva sobre
los posibles riesgos físicos, identificando la vulnerabilidad de los bienes
tangibles y personales.
 Evaluar si la Gerencia de TI ha implantado los planes de acción, mecanismos de
respuesta y sistemas para controlar y reducir hasta donde sea posible los riesgos
identificados y minimizar o eliminar los daños o consecuencias.
R INDICADORES DE RELEVAMIENTO NCI Riesgo
EVALUACIÓN
E (Describa la √- 3=Alto

situación observada) N/A 2=Medio,


F 1=Bajo

4.1 - PLANES DE CONTINUIDAD DEL NEGOCIO

4.1.1 Disponibilidad de los Planes


de Continuidad de las
actividades de TI (Plan de
contingencia)

4.1.2 Ensayo, mantenimiento y


evaluación de los planes de
Continuidad de TI

(Pruebas)

4.1.3 Aprobación por la Alta


Gerencia del plan de
contingencias

4.1.4 Disponibilidad del Plan de


Seguridad TI

4.1.5 Aprobación del Plan de


Seguridad TI

4.1.6 Otras observaciones


P á g i n a | 135

4.2 - EVALUACIÓN DE LA SALA DE SERVIDORES – DATA CENTER Y ALTA


DISPONIBILIDAD

4.2.1 Sala de servidores


independiente y restricción
de accesos, Controles de
Acceso Físico

4.2.2 Restricción de accesos a la


sala de servidores, Bitácora
de accesos

4.2.3 Evidencia del mantenimiento


de equipos preventivos

4.2.4 Lista de servidores

4.2.5 Servidor espejado - fuera del


recinto principal

4.2.6 Arquitectura servidor – clon

4.2.7 Sistema operativo Server –


propietario – Libre

4.2.8 Rack de protección,


protegido con llave

4.2.9 Cableado de red ordenado,


identificado por usuarios

4.2.10 Certificación del cableado de


red

4.2.11 Identificación de materiales


inflamables, en el recinto del
Data Center

4.2.12 Disponibilidad de detectores


de humo y calor
P á g i n a | 136

4.2.13 Extintores especiales contra


incendios

4.2.14 Licencias de los sistemas


operativos de redes

4.2.15 Disponibilidad del Sistema de


puesta a tierra

4.2.16 Suministros de energía


eléctrica, UPS

4.2.17 Suministros de energía


eléctrica, Generador de
electricidad

4.2.18 Otras observaciones

4.3 - EVALUACIÓN DEL RESGUARDO DE LA INFORMACIÓN - Copias de respaldos

4.3.1 Medio (dispositivo) de


realización

4.3.2 Cantidad de copias


4.3.3 Lugar de almacenamiento,
interno/externo

4.3.4 Datos que se respaldan

4.3.5 Software de realización

4.3.6 Responsable de realización


Registro de Planilla de
4.3.7 control de copias
4.3.8 Otras observaciones
P á g i n a | 137

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD: Ref.
Oviedo
P.T.:
PERIODO: 2015
V – DOCUMENTACIONES DE TI
Objetivo de control:
 El propósito de este formulario es obtener conocimiento de los documentos
aplicado por la entidad, en lo referente a sistemas y gestión, así como la
evaluación de proyectos tecnológicos.
R INDICADORES DE RELEVAMIENTO NCI Riesgo
EVALUACIÓN 3=Alto
E (Describa la situación √-
observada) N/A 2=Medio
F 1=Bajo

5.1 - DOCUMENTACIÓN DE FUNCIONES Y PROCEDIMIENTOS

5.1.1 Manual de cargos y


funciones:

e) Disponible
f) Aprobado por la
Alta Gerencia
g) Actualizado
h) Definido
claramente las
responsabilidades
5.1.2 Manual de
procedimientos:

e) Disponible
f) Aprobado por la
Alta Gerencia
g) Actualizado
h) Definido
claramente los
procedimientos
5.1.3 Definición de
propietario de datos,
determinación de
responsabilidades
sobre las principales
tablas
P á g i n a | 138

5.1.4 Otras observaciones

5.2 – RELEVAMIENTO DE INVENTARIOS Y MANUALES TÉCNICOS

5.2.1 Manuales de usuarios –


impresos – interactivos

5.2.2 Manuales DFD, UML,


AOO – disponibles -
actualizados

5.2.3 Manuales de ER –
disponibles -
actualizados

5.2.4 Disponibilidad de
Inventario de activos –
hardware – actualizado

5.2.5 Disponibilidad de
inventario de activos -
software – actualizado

5.2.6 Otras observaciones

5.3 - EVALUACIÓN DE LA ADMINISTRACIÒN DE PROYECTOS

5.3.1 Definición y esquema


de administración de
proyectos de TI

5.3.2 Participación de
usuario en el inicio del
Proyecto

5.3.3 Formación del Equipo


de Proyecto y
Asignación de
Responsabilidades

5.3.4 Estudio de Viabilidad


Tecnológica

5.3.5 Estudio de Viabilidad


Económica
P á g i n a | 139

5.3.6 Aprobación de Fase de


proyecto
5.3.7 Plan Maestro del
Proyecto
5.3.8 Plan de Control de
Calidad de Sistemas
5.3.9 Planificación de
Métodos de Seguridad
5.3.10 Plan de Pruebas del
Proyecto
5.3.11 Plan de Entrenamiento
5.3.12 Metodología de
Desarrollo de Sistemas
5.3.13 Coordinación y
Comunicación en la
ejecución del proyecto
5.3.14 Selección de software
de base
5.3.15 Normas de
documentación de
programas
5.3.16 Normas de pruebas de
programas
5.3.17 Normas respecto a la
prueba de sistemas
5.3.18 Normas respecto a las
pruebas Piloto o en
Paralelo
5.3.19 Otras observaciones
5.4 – EVALUACIÓN DEL CUMPLIMIENTO DE CONTRATO
5.4.1 Descripción del
contrato - alcance
5.4.2 Definición del
administrador del
contrato
5.4.3 Definición de fiscales
del contrato
5.4.4 Evidencia de solicitud
de prórroga
5.4.5 Solicitud de reajustes
P á g i n a | 140

5.4.6 Solicitud de recepción


técnica provisoria
5.4.7 Solicitud de recepción
técnica definitiva
5.4.8 Contrato de
mantenimiento
hardware-
vencimiento-
cronograma
5.4.9 Contrato de
mantenimiento de
software - vencimiento
5.4.10 Contrato de suministro
de Internet,
vencimiento
5.4.11 Contrato de licencias de
software propietario
5.4.12 Contrato de seguro de
equipos
computacionales -
servidores
5.4.13 Otras observaciones
P á g i n a | 141

PROGRAMA DE AUDITORÍA DE EVALUACIÓN DE TI


Municipalidad de Raúl Arsenio
ENTIDAD: Ref.
Oviedo
P.T.:
PERIODO: 2015
VI – EVALUACIÓN DE RR.HH.
Objetivo de control:
 Maximizar las contribuciones del personal vinculado a los procesos de
tecnologías de la información en los diferentes escenarios del ambiente
tecnológico.
Procedimientos generales:

7. Entrevistas con el personal vinculado a las tecnologías de información.


8. Aplicación de cuestionarios.
9. Revisión de Manuales de Organización Cargos y Funciones del sector de
tecnologías. Responsabilidades.
10. Revisión de las políticas de reclutamiento del personal del área.
11. Revisión del Plan Anual de Capacitación del sector de tecnologías, así
como la aprobación y ejecución del mismo.
12. Revisión de los requerimientos de calificaciones, evaluación objetiva
y medible del desempeño.
R INDICADORES DE RELEVAMIENTO NCI Riesgo
EVALUACIÓN 3=Alto
E (Describa la situación √-
observada) N/A 2=Medio
F 1=Bajo

6.1 - Administración de los Recursos Humanos – Evaluación del desempeño

6.1.1 ¿Existen políticas


diseñadas para el
reclutamiento del
personal de tecnologías?
(verificar requerimientos
de calificaciones,
capacitación, experiencia,
entrenamientos, currículo,
etc.)

6.1.2 ¿Existen requerimientos


de calificaciones,
experiencia y
conocimientos básicos en
aquellos empleados que
P á g i n a | 142

no pertenecen al área de
tecnologías y que integran
la cartera de usuarios de la
entidad?

6.1.3 ¿Existe el reglamento


interno de tecnologías de
la información y esté es
entregado para su
conocimiento a todo el
personal de la entidad en
el momento de su
aprobación como
empleado?

6.1.4 ¿Es evaluado el personal


de tecnologías de la
información como mínimo
una vez al año a través de
una evaluación objetiva
del desempeño?

6.1.5 ¿Existe la metodología de


evaluación del personal
empleado, que muestre los
criterios adoptados por la
organización?

6.1.6 Otras observaciones

6.2 - Capacitación y entrenamiento

6.2.1 ¿Existe el plan anual de


capacitación para el área
de tecnologías de la
información?
6.2.2 ¿Es aprobado por la alta
dirección de la entidad el
plan anual de capacitación
al sector de tecnologías?
6.2.3 ¿Se controla el
cumplimiento del plan de
capacitación anual por el
P á g i n a | 143

área de tecnologías y
recursos humanos?
6.2.4 ¿La capacitación y
entrena-miento referida a
la implementación de
sistemas de información,
participación en talleres,
conferencias, etc. es
controlada por el área de
sistemas y esto se incluyen
en la ficha o evaluación del
personal?
6.2.5 ¿Existe un plan general de
entrenamiento y
desarrollo para usuarios
con objetivos específicos
sobre concientización y
actualización en materia
de informática?
P á g i n a | 144

Anexo 3. Propuesta de Servicios

15 de marzo de 2015

Señores
Municipalidad de Raúl A. Oviedo

Dirección

Calle 7 de Octubre y Sinforiano Bogarín.

De nuestra consideración:

Por el presente tenemos a bien presentarle nuestra propuesta técnica y


económica de prestación de servicios profesionales de auditoría informática.

Objetivo

Nuestra intervención como profesionales independientes tendrá como objeto


realizar un examen de auditoría que nos permita emitir nuestro informe
profesional sobre el estado actual del ambiente informático de la
Municipalidad.

Nuestro plan buscará asegurar que los objetivos de auditoría se cumplan en


tiempo y de una manera eficiente.

Aspectos relevantes del plan de auditoría

Comentaremos a continuación los aspectos más relevantes de nuestro plan


de auditoría:

 Análisis de la organización actual: En esta etapa se analizará la


organización actual, ubicación del área informática dentro de la entidad,
los centros de decisión, funciones y procedimientos.

 Análisis de los procesamientos actuales: En esta etapa se analizarán los


distintos tipos de procesamientos, manuales y automatizados; estudios de
documentaciones, estudios de archivos y definición de volúmenes.
P á g i n a | 145

recursos humanos, hardware y software, seguridad e integridad de datos,


posibilidad de manipuleo de datos.

 Diagnóstico de la situación Actual: Informe de la situación actual en que


se encuentra el ambiente informático de la institución.

Alcance de los Servicios

Para cumplir con los objetivos trazados inicialmente, nuestro examen


comprenderá, entre otros los siguientes procedimientos:

 Relevamiento organizacional: Análisis del área informática recursos


humanos, hardware, software y comunicaciones.

 Auditoría a programas y usos de tablas: Seguimiento a la auditoría de


programas y tablas

 Sistemas de archivos: Seguridad respecto a la posibilidad de recuperación


de los archivos dañados por corte de energía eléctrica, contaminación de
virus etc. Evaluación de los usuarios que acceden a las bases de datos.

 Evaluación de la seguridad: Del ambiente informático, de los distintos


niveles de accesos a los menús de los sistemas, confidencialidad de los
datos, seguridad de acceso físico al centro de cómputo, procedimientos a
seguir en casos de imprevistos; políticas sobre copias de seguridad y
resguardo de información, políticas sobre mantenimiento de hardware y
software.

 Evaluación de los procedimientos: administrativos, segregación de


funciones, ciclo de vida de desarrollo de sistemas.

 Auditoria de Base de Datos: Control de estructura, diseño lógico y físico,


control de Integridad referenciales y consistencia de datos, revisión de
políticas de acceso y control de claves (debilidad de claves, permisos de
manipulación de tablas, caducidad de claves, periodicidad de cambio de
claves), estabilidad del motor de base, rendimiento del motor (perfomance
P á g i n a | 146

por accesos concurrentes), políticas de backup del motor de base de


datos.

 Auditoria de Estructura de Red: Revisión de la estructura física del


montado de la red, revisión de los equipos concentradores y routers,
verificación del dominio (disponibilidad de políticas de dominio).

Metodología

Nuestra tarea será realizada de acuerdo a un cronograma que elaboraremos


una vez aceptada nuestra propuesta, ajustándonos a sus requerimientos. El
trabajo se realizará básicamente en dos etapas:

 La primera: Relevamiento general de los recursos disponibles y controles


internos aplicados, verificación de todos los sistemas informáticos.

 La segunda: Estudio riguroso sobre la situación actual, para su posterior


sugerencia y recomendaciones tendientes a mejorar el ambiente
informático de la entidad.

Presentación de Informes

Como resultado de nuestro examen presentaremos los siguientes informes:

1- Informe sobre el resultado del trabajo realizado.

2- Informe sobre las sugerencias y recomendaciones tendientes a mejorar el


control interno del área informática.

Validez de la Oferta

Esta oferta tiene validez hasta 30 días de haber sido presentada la propuesta.

Honorario y Forma de Pago

El costo del servicio asciende a Guaraníes Cinco millones (Gs. 5.000.000) El


importe no incluye el Impuesto al Valor Agregado.

Anexo 3. Carta Gerencial


P á g i n a | 147

05 de octubre de 2015

Señor
Intendente
Eddy Neufeld Hildebrand

Ciudad
Raúl A. Oviedo

De nuestra consideración:

Hemos efectuado la revisión sobre el actual procedimiento que se lleva a cabo


en el Departamento de informática del El cliente.

Objetivo general

Realizar una Auditoría Informática en la Municipalidad, permitiendo de esta


manera desarrollar los objetivos básicos de control definidos en las normas
estándares de Auditoría Informática COBIT y el MCIIEF.

Objetivos específicos

 Verificar la estructura organizativa y las normas vigentes en el


Departamento de Informática, poniendo especial énfasis en la
adecuada segregación de funciones.

 Evaluar que las normas y procedimientos vigentes en el Departamento


de Informática se encuentren preparados para minimizar riesgos de
cambios a programas y evitar modificaciones no autorizadas a los
sistemas informáticos.

 Evaluar que las políticas de seguridad de datos vigentes en el


Departamento de Informática estén elaborados para minimizar la
posibilidad de accesos no autorizados a los datos y programas.

 Evaluar los planes de contingencias desarrollados por el Departamento


de Informática a efectos de asegurar la continuidad del procesamiento
P á g i n a | 148

de la información en caso de interrupciones en los servicios, originados


por desastres u otras contingencias.

 Controlar las aplicaciones de herramientas de auditoría a través del


sistema operativo de red y sistemas corporativos implementados en el
Departamento de Informática, a efectos de analizar los parámetros de
seguridad de los sistemas y la adecuación de los mismos a las políticas
de seguridad vigentes.

 Evaluar los sistemas informáticos basados en el enfoque de


confiabilidad de las informaciones que son utilizadas en las
operaciones de los sistemas corporativos, la flexibilidad que
proporcionan y el grado de satisfacción que brindan a los usuarios.

 Evaluar la adecuada capacitación de los usuarios en las operaciones


de los módulos.

 Evaluar la planificación estratégica de informática desarrollada por el


Departamento de Informática.

En base a la labor realizada, en el marco de la auditoria del área observamos


situaciones que hemos considerado conveniente informar a la Intendencia.
Los procedimientos y funciones que actualmente no son considerados en el
Departamento de Informática, así como los temas observados, junto con sus
recomendaciones para su corrección, son detallados en el presente informe.

Aprovechamos la oportunidad para expresar nuestro agradecimiento por la


cooperación recibida del personal de la municipalidad durante el transcurso
del trabajo.

Atentamente,

La consultora