Mimbela em

Universidad Nacional Mayor de San Marcos
Universidad del Perú. Decana de América

Facultad de Ingeniería de Sistemas e Informática
Escuela Académico Profesional de Ingeniería de Sistemas
Diseño de un sistema experto de apoyo a los procesos

de auditoría informática basado en COBIT: caso
práctico auditoría de base de datos (Proceso PO2)
TESINA
Para optar el Título Profesional de Ingeniero de Sistemas
AUTORES
Medalith Ingrid MIMBELA ESTRADA
Ralph Guido PALOMINO GUTIÉRREZ
ASESOR
José Antonio PÉREZ QUITANILLA
Lima, Perú
2010
Reconocimiento - No Comercial - Compartir Igual - Sin restricciones adicionales
https://creativecommons.org/licenses/by-nc-sa/4.0/
Usted puede distribuir, remezclar, retocar, y crear a partir del documento original de modo no
comercial, siempre y cuando se dé crédito al autor del documento y se licencien las nuevas
creaciones bajo las mismas condiciones. No se permite aplicar términos legales o medidas
tecnológicas que restrinjan legalmente a otros a hacer cualquier cosa que permita esta licencia.
Referencia bibliográfica
Mimbela, M. & Palomino, R. (2010). Diseño de un sistema experto de apoyo a los

procesos de auditoría informática basado en COBIT: caso práctico auditoría de
base de datos (Proceso PO2). Tesina para optar el título profesional de Ingeniero
de Sistemas. Escuela Académico Profesional de Ingeniería de Sistemas, Facultad de
Ingeniería de Sistemas e Informática, Universidad Nacional Mayor de San Marcos,
Lima, Perú.
Diseño de un Sistema Experto de Apoyo a los Procesos de Auditoria Informática 2010
Dedicado a nuestras familias, por

orientarnos, por apoyarnos, por
creer en nosotros y ayudarnos a
ser mejores personas cada día.
FISI-UNMSM Página 2 de 147

AGRADECIMIENTOS
Nuestro agradecimiento a los profesores de la UNMSM por ser una guía para
nuestro desarrollo personal y profesional durante nuestro paso por la
universidad.
Al profesor José Pérez por su apoyo, orientación, paciencia y dedicación

para lograr que este trabajo cumpla las expectativas y objetivos trazados.
A nuestros amigos de la universidad, por darnos ánimos cuando más lo

necesitábamos, por estar ahí cuando se necesitaba estudiar y más aún
cuando necesitábamos divertirnos.
Y muy especialmente el agradecimiento a nuestros padres por su apoyo

incondicional y por ser forjadores de todo lo que somos ahora, por darnos el
camino a seguir desde nuestros primeros pasos, de ahora en adelante todo
depende de nosotros. Muchas gracias, todo su esfuerzo se ve reflejado en lo
que hoy somos.
Gracias a nuestras familias porque siempre estuvieron a nuestro lado siendo

nuestro soporte cuando las fuerzas se nos agotaban, sabemos que siempre
estarán a nuestro lado para ofrecernos su mano cuando lo necesitemos
aunque no se lo pidamos.
Gracias a Dios, por la vida y por los sueños que poco a poco se van
haciendo realidad.

Ficha catalográfica
Mimbela Estrada, Medalith Ingrid
Palomino Gutiérrez, Ralph Guido
Diseño de un Sistema Experto de Apoyo a los Procesos de Auditoría basado en
COBIT: Caso Práctico Auditoría de Base de Datos (Proceso PO2)
Seguridad y Auditoría Informática
(Lima 2010)
(UNMSM, Pregrado, Ingeniería de Sistemas e Informática)
Tesina, Universidad Nacional Mayor de San Marcos, Facultad de Ingeniería de

Sistemas e Informática

RESUMEN
El presente trabajo de investigación representa la conclusión de los estudios

realizados sobre el campo de la Auditoría de Sistemas. La investigación
surge a raíz de la necesidad creciente de las organizaciones por contar con
herramientas automatizadas que permitan administrar la información de
forma oportuna y confiable. Sin embargo debido a esta necesidad, los
sistemas son cada vez más complejos, integrados y relacionados. Esto hace
que sea cada vez más necesario en todas las organizaciones garantizar el
cumplimiento de normas y procedimientos relacionados con la gestión de
las tecnologías de información.
El resultado del trabajo es el diseño de un software de apoyo a la auditoría,

basado en el marco de referencia Cobit, que permita a sus usuarios obtener
el nivel de madurez del área de TI mediante una metodología sencilla: la
validación del nivel de madurez mediante: cuestionarios, un esquema de
pesos por opción seleccionada, un plan de actividad de auditoría y
recomendaciones para mejorar el nivel de madurez en el área de TI.
El diseño propuesto representa una herramienta ampliamente flexible que

permita acoplar nuevos estándares de evaluación mediante la actualización
de la base de conocimiento en cada objetivo de control de Cobit. Además es
de fácil mantenimiento, flexible y sencilla. Mediante este trabajo se busca
acercar a las organizaciones a los procedimientos de mejora continua, a las
recomendaciones internacionales y, de esa forma, mantener un mejor
control del software y las actividades relacionadas con este.
El trabajo se divide de la siguiente manera: El capítulo 1 presenta el

problema planteado y los objetivos de la investigación. El capítulo 2 da a
conocer los conceptos de auditoría, el marco de referencia utilizado: Cobit y
teoría de Sistemas Expertos. El capítulo 3 da a conocer el estado del arte y
los distintos proyectos desarrollados en el área de auditoría. El capítulo 4
expone el planteamiento teórico del proceso de auditoría que será
soportado por el sistema diseñado, además del esquema de evaluación del
nivel de madurez, los cuestionarios, resultados y plan de actividad por cada
objetivo de control para el proceso “Definir la Arquitectura de Información”
(PO2). El capítulo 5 muestra la arquitectura del sistema propuesto mediante
diagramas UML. Finalmente se presenta la conclusión y los trabajos futuros.
Palabras claves:
Auditoría, Cobit, Sistema Experto, Estándar, Diseño Sistemas.

ABSTRACT
This research work represents the completion of the studies carried out on
the field of Systems Auditing. The investigation arises as a result of the
growing need of organizations have automated tools that allow managing
information in a timely and reliable. However due to this need, the systems
are increasingly complex, integrated and related. This makes it increasingly
necessary in all organizations ensure compliance with established rules and
procedures related with the management of information technologies.
The result of this work is designing software to support the audit, based on
the of best practices (framework) for IT: COBIT, which allows its users to
obtain the level of maturity in the IT area using a simple method: validation
the level of maturity through questionnaires, through weighting scheme, a
plan of audit activity and recommendations for improving the level of
maturity in the IT area.
The proposed design represents a flexible tool that allows coupling widely
new evaluation standards by updating the knowledge base in each COBIT
control objective. It is also easy to maintain, flexible and simple. Through
this work aims to bring an organization to continuous improvement
procedures, the recommendations and, thus, maintain better control of
software and activities related thereto.
The work is divided in the following manner: Chapter 1 introduces the

problem and the objectives of the research. Chapter 2 gives audit to
understand the concepts, the framework used: Cobit and expert systems
theory. Chapter 3 makes known the state of the art and various projects in
the audit area. Chapter 4 sets out the theoretical approach of the audit
process that will be supported by the system also designed the scheme to
assess the level of maturity, questionnaires, results and business plan for
each control objective for the process "Defining the Information
Architecture” (PO2). Chapter 5 shows the proposed system architecture
using UML diagrams. Finally we present the conclusion and future work.
Keywords:
Audit, Cobit, Expert System, Standard, Systems Design.

INDICE
AGRADECIMIENTOS ....................................................................................... 3
RESUMEN ..................................................................................................... 5
ABSTRACT .................................................................................................... 6
INDICE ......................................................................................................... 7
INTRODUCCION ........................................................................................... 11
CAPITULO I .................................................................................................. 12
ANTECEDENTES ........................................................................................... 12
DEFINICION DEL PROBLEMA .......................................................................... 14
PROPUESTA ................................................................................................. 14
OBJETIVOS DEL TRABAJO .............................................................................. 15
1. Objetivo General............................................................................... 15
2. Objetivos Específicos ......................................................................... 15
JUSTIFICACION ............................................................................................ 16
ALCANCES ................................................................................................... 16
LIMITACIONES ............................................................................................. 16
CAPITULO II ................................................................................................ 17
MARCO TEORICO .......................................................................................... 17
1. Marcos de Referencia Para Auditoría ........................................................ 17
1.1 Objetivos de Control para Información y Tecnología (COBIT) ................. 17
1.2 Objetivos de Control y auditoria de Bases de Datos .............................. 19
2. Conceptos de Auditoria ...................................................................... 23
3. Auditoria y Seguridad en Servidores de Base de Datos .......................... 26
3.1 Seguridad y auditoria en Base de Datos Oracle .................................... 27
3.2 Seguridad y auditoria en un entorno de SQL Server .............................. 27
3.3 Seguridad y auditoria en un entorno de Base de datos DB2 ................... 28
3.4 Seguridad y auditoria en un entorno de Base de datos MySQL ............... 28
4. Sistemas Expertos ............................................................................ 29
Aspectos técnicos de un sistema experto ..................................................... 29
Tipos de Sistemas Expertos ....................................................................... 33
Tecnologías de Sistemas Expertos .............................................................. 34
Métodos de Validación de Un Sistema Experto para auditoria ......................... 35
Validación de un sistema experto ................................................................ 35
CAPITULO III ............................................................................................... 37
ESTADO DEL ARTE ........................................................................................ 37
I. Contexto ......................................................................................... 37
II. Sistemas desarrollados ...................................................................... 37
A. AUDES ............................................................................................ 37
B. Planning Advisor. .............................................................................. 41
C. Sistema Experto para auditoria de Plantas nucleares ............................. 43
D. Oracle Internal Controls Manager [OICM] ............................................ 46
E. DENDRAL......................................................................................... 48
F. MILK ............................................................................................... 49
G. Jasper II .......................................................................................... 51
H. DIAMS ............................................................................................. 52
I. El modelo KLC .................................................................................. 52
J. El Proyecto MDKT ............................................................................. 53
K. Acquisition Solution Knowledge Center ............................................... 54
L. Meycor Cobit Suite. ........................................................................... 54
BENCHMARK ................................................................................................ 56
Benchmarking Marcos de Referencia para Auditoría de TI .............................. 56
Benchmarking Sistemas apoyo a la Auditoría y Sistemas Expertos. ................. 58
CAPITULO IV ................................................................................................ 60
APORTE TEORICO ......................................................................................... 60
MAPA DE PROCESOS COBIT PARA BASE DE DATOS ....................................... 64

DETALLE DE PROCESOS DE EVALUACION ..................................................... 68

Planificar y Organizar ................................................................................. 68
PO2 Definir la Arquitectura de TI................................................................ 68
PO4. Definir los procesos, organización y relaciones de TI .............................. 89
PO9 Evaluar y administrar los riesgos de TI .................................................. 98
CAPITULO V ............................................................................................... 109
APORTE PRÁCTICO ..................................................................................... 109
I. Estructura de la solución .................................................................. 109
II. Tecnología ..................................................................................... 111
Microsoft .Net C#® ................................................................................. 111
Oracle 10g R2 ® ..................................................................................... 111
III. Modelo de Casos de Uso .................................................................. 112
3.1 Casos de Uso del Negocio (CUN) ......................................................... 112
3.2 Casos de Uso del Sistema (CUS) – Diagrama de Paquetes ...................... 116
3.3 Diagrama de Casos de Uso por Paquetes .............................................. 117
3.4 Especificación de Casos de Uso por Paquetes ........................................ 119
3.4.1 Auditoría y entrenamiento ............................................................... 119
CUS001. INICIAR SESIÓN ................................................................. 119
CUS002. INICIAR PROCESO DE AUDITORIA ......................................... 121
CUS003. REALIZAR ENCUESTA ........................................................... 123
CUS004. GENERAR REPORTE DE NIVEL DE MADUREZ ........................... 125
CUS005. GENERAR PLAN DE TRABAJO ................................................ 127
CUS006. REGISTRAR RESULTADO DE LA EVALUACIÓN .......................... 129
CUS007. REGISTRAR PROCESO DE AUDITORIA .................................... 131
CUS008. INGRESAR INFORMACIÓN DE LA ORGANIZACIÓN ................... 133
CUS009. REALIZAR MANTENIMIENTO DE REGLAS ................................ 135
IV. Diagrama de clases ......................................................................... 137
V. Arquitectura (esquema de componentes) ........................................... 138
VI. Arquitectura (esquema de despliegue) .............................................. 139
VII. Arquitectura Desktop ...................................................................... 139
CONCLUSIONES Y TRABAJOS FUTUROS ........................................................ 140
ANEXO I .................................................................................................... 142
GLOSARIO DE TÉRMINOS ............................................................................ 142
BIBLIOGRAFIA ........................................................................................... 145

Índice de Ilustraciones
Ilustración 1. Productos de COBIT 4.1 [COBIT4] ............................................... 19

Ilustración 2. Esquema de los elementos de una Base de Datos [Adaptación del
diagrama de SGBD, 2004] ............................................................................. 26
Ilustración 3. Esquema de componentes de un sistema experto.......................... 29
Ilustración 4. Proceso de carga de Base de Conocimiento .................................. 30
Ilustración 5. Proceso de Carga de la base de Hechos ....................................... 31
Ilustración 6. Proceso de validación de un hecho .............................................. 32
Ilustración 7. Proceso de deducción de un sistema experto ................................ 33
Ilustración 8 Actualización de los criterios de evaluación y los valores asociados
[Advisorv5] .................................................................................................. 42
Ilustración 9 Actualización de recursos para la auditoria [Advisorv5] ................... 42
Ilustración 10. Planificación de tiempo y costos para la auditoría [Advisorv5] ...... 43
Ilustración 11. Diagrama de bloques del sistema experto de Auditoria [ANPP] ...... 44
Ilustración 12. Modelo de obtención y representación de datos de DENDRAL ........ 49
Ilustración 13. Entorno y arquitectura de MILK [MILK1]..................................... 50
Ilustración 14. Diagrama de alineamiento Cobit, ISO e ITIL ............................... 62
Ilustración 15. Esquema de resultados del sistema. .......................................... 63
Ilustración 16. Matriz RACI Proceso PO2 .......................................................... 69
Ilustración 17. Diagrama de bloques del sistema ............................................ 110
Ilustración 18. Modelo de paquetes CUN ........................................................ 112
Ilustración 19. CUN Directorio/Alta gerencia .................................................. 113
Ilustración 20. CUN Área de auditoría............................................................ 113
Ilustración 21. CUN Área de seguridad .......................................................... 114
Ilustración 22. CUN Desarrollo de aplicaciones ............................................... 114
Ilustración 23. CUN Soporte ......................................................................... 115
Ilustración 24. CUN Redes y comunicaciones .................................................. 115
Ilustración 25. CUN Infraestructura y hardware .............................................. 116
Ilustración 26. Diagrama de paquetes de CUS. ............................................... 116
Ilustración 27. CUS Auditoría y entrenamiento ............................................... 117
Ilustración 28. CUS Administración de la aplicación ......................................... 117
Ilustración 29. CUS Reportes ....................................................................... 118
Ilustración 30. Diagrama de secuencia CUS001 .............................................. 120
Ilustración 31. Diagrama de Colaboración CUS001 .......................................... 120
Ilustración 33. Diagrama de colaboración CUS002 .......................................... 122
Ilustración 48. Diagrama de clases de la aplicación ......................................... 137
Ilustración 49. Diagrama de componentes ..................................................... 138
Ilustración 50. Diagrama de despliegue ......................................................... 139
Ilustración 51. Diagrama arquitectura Desktop ............................................... 139

Índice de Tablas
Tabla 1. Recomendaciones por nivel de madurez [COBIT4] ................................ 23

Tabla 2. Estándares para el Gobierno de TI. ..................................................... 57
Tabla 3. Benchmarking de Sistemas de apoyo a la Auditoría. ............................. 59
Tabla 4. Mapa de Procesos Cobit Planificar y Organizar ...................................... 64
Tabla 5. Mapa de Procesos Cobit Adquirir e Implantar ....................................... 65
Tabla 6. Mapa de Procesos Cobit Entregar y Dar Soporte ................................... 66
Tabla 7. Mapa de procesos Cobit Monitorear y Evaluar ...................................... 67
Tabla 8. Objetivos de la Auditoría para el Proceso PO2 ...................................... 68
Tabla 9. Tabla de Consultas Objetivo de Control: PO2.1 .................................... 73
Tabla 10. Niveles de Madurez para el Objetivo de Control PO2.1 ......................... 74
Tabla 11. Plan de Actividades y Recomendaciones para el Objetivo de Control P2.1
.................................................................................................................. 75
Tabla 12. Tabla de consultas Objetivo de Control: PO2.2 ................................... 78
Tabla 14. Plan de Actividades y Recomendaciones para el Objetivo de Control PO2.2
.................................................................................................................. 80
Tabla 15. Tabla de Consultas Objetivo de Control: PO2.3 ................................... 82
.................................................................................................................. 84
.................................................................................................................. 88
Tabla 22. Tabla de consultas del Objetivo de Control PO4.8 ............................... 93
Tabla 23. Tabla de consultas del Objetivo de Control PO4.9 ............................... 95
Tabla 24. Tabla de consultas del Objetivo de Control PO4.11............................. 97
Tabla 25. Tabla de consultas del Objetivo de Control PO9.2 ............................. 100
Tabla 30. Especificación del CUS001 Iniciar sesión .......................................... 119
Tabla 31. Especificación del CUS002 Iniciar Proceso de Auditoría ...................... 121
Tabla 32. Especificación del CUS003 Realizar encuesta .................................... 123
Tabla 33. Especificación del CUS004 Generar reporte de madurez. ................... 125
Tabla 34. Especificación del CUS005 Generar plan de trabajo. .......................... 127
Tabla 35. Especificación del CUS006 Registrar resultado de la evaluación .......... 129
Tabla 36. Especificación del CUS007 Registrar proceso de auditoría .................. 131
Tabla 37. Especificación del CUS008 Ingresar información de la organización ..... 133
Tabla 38. Especificación del CUS009 realizar mantenimiento de reglas .............. 135

INTRODUCCION
El actual estado de desarrollo, administración y mantenimiento de los

sistemas de información conlleva a que los mismos sean más complejos,
integrados y relacionados. Esto hace que sea cada vez más necesario en
todas las organizaciones y no solo en las grandes, el controlar y garantizar
el cumplimiento de las normas y procedimientos establecidos para la
implementación de las políticas relacionadas con la Tecnología de la
Información.
Una herramienta de control es la auditoría de sistemas, la cual aporta

métodos, técnicas y procedimientos que permiten controlar y asegurar el
uso eficaz y eficiente de los sistemas de información.
La palabra auditoría etimológicamente significa “oír”, y en los orígenes la

función del auditor de sistemas estaba relacionada con detectar errores en
los procedimientos relacionados con el procesamiento de la información a
través del uso de ordenadores. En la actualidad adicionalmente se entiende
al auditor como un consultor especializado en los riesgos que emergen del
procesamiento de datos, los cuales son determinantes, en este nuevo
contexto caracterizado por los constantes cambios que se producen en esta
verdadera revolución tecnológica en la que estamos sumergidos.
Es por los riesgos y el gran avance de las tecnologías de información (TI),

entre otras razones por las que ahora los auditores respaldan sus
evaluaciones con estándares y marcos de referencia. Al respecto, podemos
afirmar que casi la totalidad de los procesos de auditoría de sistemas están
soportados por normas, estándares, marcos de referencia, arquitecturas y
todo un flujo de trabajo, pero muchas veces los usuarios, administradores y
auditores de las TI no disponen de herramientas de software que les facilite
la evaluación o el aseguramiento de los niveles en los cuales se tienen
implementados los controles vinculados a las TI.
Lo expresado en el párrafo anterior es uno de los motivos por los que se

plantea una solución, la cual motiva el presente trabajo de investigación y
consiste en el diseño de un sistema basado en reglas de evaluación para
monitorear los niveles de seguridad y prácticas de control existentes en una
organización. Esperamos que esta solución pueda servir de gran apoyo a los
auditores y en general de aquellas personas encargadas de la evaluación de
las TI dentro de las organizaciones. Con la finalidad de darle un alcance
amplio, se ha tenido especial cuidado en que el diseño presentado, pueda
modelar cualquier proceso de evaluación y validación que se pueda ajustar
al marco de referencia COBIT.

CAPITULO I
ANTECEDENTES
Los antecedentes de la auditoría podemos encontrarlos en civilizaciones

interesadas en controlar los gastos y los ingresos del Estado, para vigilar el
manejo de los fondos por los funcionarios asignados. Entre estas
civilizaciones tenemos la cultura egipcia.
Se afirma que el término "auditor" procede de la persona que efectuaba
estos controles, quien escuchaba las relaciones de cuentas de los
funcionarios de viva voz, puesto que éstos carecían de la instrucción
necesaria para presentarlas en forma escrita.
Las actuales asociaciones profesionales de auditores tuvieron sus
precursores en los Consejos Londinenses de Londres (1310), el Colegio de
Contadores de Venecia (1581), el Tribunal de Cuentas de París (1640) y la
"Academia dei Ragioneri" de Milán y Bolonia (1658).
Así mismo, en sus inicios la auditoría estuvo ampliamente relacionada al
control en el manejo económico, a raíz del surgimiento con los fracasos
financiero-económicos de las sociedades de acciones nacidas de la
revolución industrial, en la segunda mitad del siglo XVIII. La falta de
seriedad y de profesionalidad en sus gestores provocó la quiebra de un gran
número de empresas. Esta situación dio lugar a la imposición tácita, y
posteriormente legal, de revisiones de la situación financiera de las
empresas a cargo de contables independientes. Inglaterra, como una de las
pioneras en la revolución industrial, fue también una de las pioneras en el
desarrollo de la profesión de auditor, entendida en el sentido mencionado
anteriormente. El gobierno británico aprobó oficialmente la creación del
Instituto de Auditores Titulados de Inglaterra y Gales, en 1880, y ese
mismo año nace el “Institute of Chartered Accountants of England and
Wales” que continua en la actualidad. [ICAEW, 2010]
Con la aparición de los ordenadores, los sistemas informáticos y el rápido

desarrollo de esta industria pronto, estos se volvieron pieza clave en las
organizaciones. En base a este contexto, nacieron los estándares cuyo
objetivo principal era presentar un conjunto de acuerdos o lineamientos
documentados que contienen especificaciones técnicas u otros criterios
precisos para ser usados constantemente en el desarrollo, diseño,
implementación y control de software.
Uno de los primeros organismos que impulsaron el desarrollo de estándares
en los procesos de software fue el Departamento de Defensa de los Estados
Unidos con la formación del Software Engineering Institute (SEI) y el
desarrollo en el SEI del Modelo de Capacidad de Madurez (CMM).
Después de la presencia del SEI en el desarrollo del conjunto de prácticas
CMM, La International Organization for Standarization (ISO) fue la primera
empresa encargada en crear un estándar en cuanto a creación de software
se refiere: ISO 9001:1994 [ISO 9001].

En el año 1996 el Information Systems Audit and Control Association

(ISACA) lanza la primera versión de Cobit (Control Objectives for
Information and related Technology) que consistiría en un conjunto de
buenas prácticas destinadas al gobierno de los sistemas informáticos en
cualquier tipo de organización, este conjunto de prácticas ha mejorado en el
tiempo desde su primera versión hasta las versiones actuales más recientes
(como la 4.1 utilizada en este proyecto de investigación) que incorporan al
modelo grupos de procesos orientados a soportar los requerimientos
actuales.

DEFINICION DEL PROBLEMA
Actualmente, debido al incremento de las tecnologías de información como

herramientas de soporte para el logro de los objetivos de negocio de las
organizaciones existe una gran necesidad de controlar su eficacia, eficiencia
y nivel de seguridad implementado. Sin embargo, en muchas de esas
organizaciones no hay un rol destinado a realizar estas evaluaciones o no se
dispone de personal idóneo para realizar esta tarea.
El trabajo de evaluación y auditoría tiene debido al gran avance de las

tecnologías de información y los estándares existentes un alto grado de
sofisticación y especialización. Este aspecto se sumamente importante sobre
todo en la etapa de planificación de la auditoria, que es la etapa en la cual
el auditor en base a su experiencia tiene que definir las pruebas que se
deben realizar para garantizar que el trabajo de evaluación corresponderá a
los objetivos y alcances previstos.
Un aspecto a resaltar es que difícilmente se dispone de una herramienta

capaz de interpretar el resultado de encuestas de auditoría, que también
sea capaz de organizar las actividades del auditor para así facilitarle un
trabajo mejor organizado, basándose en la experiencia de los mismos
auditores (base de conocimiento experto), y que adicionalmente le permita
disponer de un plan de trabajo detallado, genere reportes de resultado y
realice una evaluación previa del sistema o área a auditar, además de
permitirle guardar en un repositorio sus evidencias, análisis y resultados
después de realizar la auditoria.
Es por eso que el problema del presente trabajo de investigación se podría

definir como la falta de una herramienta de apoyo para la evaluación y
control de procesos (auditoría), que le permita a los auditores una adecuada
y detallada planificación de las actividades a realizar, capacidad para
realizar una autoevaluación previa a la auditoria, capacidad de registro de
los resultados de auditoría y explotación de los resultados. Tal herramienta
estará diseñada conforme a estándares y marcos de procesos y buenas
prácticas, de reconocimiento internacional.
PROPUESTA
El presente proyecto propone el diseño de un sistema experto de apoyo a la

auditoría informática basado en el marco de referencia Cobit, como un
marco completo. Además se propone un modelo de evaluación basado en
encuestas con pesos para las alternativas de cada pregunta, el nivel de
madurez se obtendrá del cálculo de todas las alternativas seleccionadas.

OBJETIVOS DEL TRABAJO
1. Objetivo General
El objetivo del presente trabajo de investigación es el diseño de una

herramienta de apoyo para la evaluación y control de procesos de auditoría,
que faciliten a los diversos involucrados como es el caso del Auditor, Jefes o
responsables de las áreas auditadas, desarrollar una adecuada planificación,
detallando las actividades a realizar para la evaluación y soportando
actividades especificas como la capacidad de autoevaluación del nivel de
implementación de los controles vinculados a las tecnologías de
información, explotación de reportes y recomendaciones basadas en
estándares y reglas emanadas del conocimiento de expertos y de marcos de
referencia reconocidos.
2. Objetivos Específicos
Los objetivos específicos del presente trabajo son:
 Servir de apoyo para los procesos de auditoría interna desarrollando

el mapeo de los procesos de COBIT aplicables para la auditoría, la
lista de consultas, pasos a seguir y respuesta acerca del nivel de
madurez existente después de la evaluación, usando como caso
práctico la evaluación en la seguridad del SGBD.
 Diseño de una arquitectura base, que permita soportar los procesos

estándares de evaluación, basándonos en COBIT, para la evaluación
y planificación de tareas de auditoría.
 Desarrollar una demo que analice uno de los grupos de proceso de

COBIT y retorne el resultado del análisis.
 Mostrar en el trabajo de investigación la definición completa de los

casos de uso, arquitectura y diagramas de apoyo para un desarrollo
posterior.
 Desarrollo del esquema de base de datos con el repositorio con la

base reglas, resultados de análisis, seguridad y administración del
sistema experto.
 Investigación de la fórmula para la presentación de resultados por

cada juego de respuestas.
 Estudio de tareas a realizar y recomendaciones básicas que servirán

como base del sistema para los resultados y recomendaciones para
los usuarios.

JUSTIFICACION
El presente proyecto se justifica técnicamente porque el diseño consistirá en

una herramienta ampliamente flexible y de fácil uso que proporcionará
mediante sus mecanismos de análisis y la estructura de su base de
conocimientos se puede actualizar la base de reglas y ampliarla a diferentes
tipos de procesos de auditoría.
El proyecto se justifica económicamente, porque al ser una herramienta que
proporciona resultados en base a un análisis previo, puede disminuir los
tiempos originales de ejecución de una auditoría en una ejecución estándar.
Además la organización puede mejorar la base de conocimientos del
sistemas agregando nuevas reglas con la información que proporcionen los
auditores expertos de la organización, de esta manera la organización
poseerá un repositorio con el conocimiento de sus expertos, lo cual
equivaldría a mantener en la organización la lógica de análisis de los
auditores aunque el personal cambie.
ALCANCES
Presentar el marco teórico con la información del marco de trabajo de

auditoría, realizar un análisis a acerca de los principios de los sistemas
expertos y un marco de referencia para la auditoría de sistemas
informáticos.
Mostrar los proyectos realizados anteriormente en sistemas expertos y
software de apoyo a la auditoría de software.
Presentar el modelo teórico de análisis que utilizará el sistema y los
modelos de encuestas que tendrá la base de conocimientos del caso que
será implementado.
Finalmente los modelos de diseño y definición de los casos de uso del
sistema.
LIMITACIONES
El proyecto de investigación no tendrá como objetivo principal el desarrollo

e implantación de un software. Se presentará una demostración en software
que consistirá en la implementación del proceso PO2 orientado a la
auditoría de base de datos,
Se mostrará el modelo de trabajo basado en Cobit y se presentará de forma
teórica la posibilidad de ampliar el sistema hacia los diferentes marcos de
referencia (ISO, ITIL) sin embargo no se entregará información explicita
acerca de mejora de la base de conocimientos usando dichos marcos de
referencia.

CAPITULO II
MARCO TEORICO
El presente marco teórico presenta en primer lugar las perspectivas teóricas

desde las cuales se sustentan las metodologías de Auditoria, para poder
comprender cuales son los procesos del marco de referencia elegido que
será sistematizado.
Para este proyecto de investigación se presentará como base un conjunto

de estándares y mejores prácticas que son los más aplicados para los
procesos de auditoría en el país. A partir de cada uno de ellos se podrá
entender a profundidad la finalidad del proyecto.
1. Marcos de Referencia Para Auditoría
1.1 Objetivos de Control para Información y Tecnología (COBIT)
COBIT es un estándar de la industria desarrollado por IT Governance

Institute. COBIT brinda buenas prácticas a través de un marco de
referencia de dominios y procesos, y presenta una lista de objetivos de
control en una forma estructurada y orientada a los procesos de la
organización. Las buenas prácticas de COBIT representan el consenso de los
expertos. Están enfocadas fuertemente en el control y menos en la
ejecución. Estas prácticas y recomendación es de referencia ayudarán a
optimizar las inversiones facilitadas por la Tecnología de Información (TI),
asegurarán la entrega del servicio y brindarán una medida contra la cual
comparar el estado actual de cumplimiento del software y el nivel que se
desea alcanzar [COBIT 4].
COBIT da soporte al gobierno de TI al brindar un marco de trabajo que

garantiza que:
• TI está alineada con el negocio.
• TI capacita el negocio y maximiza los beneficios.
• Los recursos de TI se usen de manera responsable.
• Los riesgos de TI se administren apropiadamente.
COBIT se enfoca en qué se requiere para lograr una administración y un

control adecuado de TI, enfocándose en una estructura estándar de tres
niveles para otorgar soporte a:
• Administración y consejos ejecutivos.
• Administración del negocio y de TI.
• Profesionales en Gobierno, aseguramiento, control y seguridad.

PROCESOS DE TRABAJO DE COBIT
Las actividades o procesos definidos para COBIT v.4.1 son las siguientes:
PLANEAR Y ORGANIZAR (PO)

Se requiere una planeación estratégica de TI para administrar y dirigir todos
los recursos de TI de acuerdo con la estrategia del negocio y las
prioridades. La función de TI y los participantes del negocio son
responsables de garantizar que se materialice el valor óptimo de los
portafolios de proyectos y servicios. El plan estratégico debe mejorar el
entendimiento de los interesados clave respecto a las oportunidades y
limitaciones de TI, evaluar el desempeño actual y aclarar el nivel de
inversión requerido. La estrategia de negocio y las prioridades se deben
reflejar en los portafolios y deben ser ejecutadas por los planes tácticos de
TI, los cuales establecen objetivos, planes y tareas específicas, entendidas y
aceptadas tanto por el negocio como por TI.
ADQUIRIR E IMPLEMENTAR (AI)

Se requiere una planeación estratégica de TI para administrar y dirigir todos
los recursos de TI de acuerdo con la estrategia del negocio y las
prioridades. La función de TI y los participantes del negocio son
responsables de garantizar que se materialice el valor óptimo de los
portafolios de proyectos y servicios. El plan estratégico debe mejorar el
entendimiento de los interesados clave respecto a las oportunidades y
limitaciones de TI, evaluar el desempeño actual y aclarar el nivel de
inversión requerido. La estrategia de negocio y las prioridades se deben
reflejar en los portafolios y deben ser ejecutadas por los planes tácticos de
TI, los cuales establecen objetivos, planes y tareas específicas, entendidas y
aceptadas tanto por el negocio como por el área de TI.
ENTREGAR Y DAR SOPORTE (DS)

Contar con una definición documentada y un acuerdo de servicios de TI y de
niveles de servicio, hace posible una comunicación efectiva entre la gerencia
de TI y los clientes de negocio respecto de los servicios requeridos. Este
proceso también incluye el monitoreo y la notificación oportuna a los
participantes sobre el cumplimiento de los niveles de servicio. Este proceso
permite la alineación entre los servicios de TI y los requerimientos de
negocio relacionados.
MONITOREAR Y EVALUAR (ME)

Una efectiva administración del desempeño de TI requiere un proceso de
monitoreo. El proceso incluye la definición de indicadores de desempeño
relevantes, reportes sistemáticos y oportunos de desempeño y tomar
medidas expeditas cuando existan desviaciones. El monitoreo se requiere
para garantizar que las cosas correctas se hagan y que estén de acuerdo
con el conjunto de direcciones y políticas.

1.2 Objetivos de Control y auditoria de Bases de Datos
Para el desarrollo de este proyecto de tesis se investigaron los objetivos de

control que enfoca COBIT y se evaluó en que producto de este estándar se
debe centrar el desarrollo del Sistema, es así que primero se muestra los
productos de COBIT [COBIT4]:
Ilustración 1. Productos de COBIT 4.1 [COBIT4]
De la lista de productos de Cobit se usarán para el proyecto los siguientes:

Objetivos de Control, el Modelo de madurez y el Marco de Trabajo Cobit.
CONTROLES PARA AUDITORIA: Seguridad de información en Base

de Datos
Los controles incluidos en las aplicaciones del proceso de negocios se

conocen por lo general como controles de aplicación. Ejemplos:
• Integridad (Completitud)
• Precisión
• Validez
• Autorización
• Segregación de funciones
COBIT asume que el diseño e implementación de los controles de aplicación

automatizados son responsabilidad de TI, y están cubiertos en el dominio
de Adquirir e Implementar, con base en los requerimientos de negocio

definidos, usando los criterios de información de COBIT. La responsabilidad

operacional de administrar y controlar los controles de aplicación no es de
TI, sino del propietario del proceso de negocio [COBIT4].
TI entrega y da soporte a los servicios de las aplicaciones y a las bases de

datos e infraestructura de soporte.
Por lo tanto, los procesos de TI de COBIT abarcan a los controles generales

de TI, pero no los controles de las aplicaciones, debido a que son
responsabilidad de los dueños de los procesos del negocio, y como se
describió anteriormente, están integrados en los procesos de negocio.
La siguiente lista muestra un conjunto recomendado de objetivos de control

de las aplicaciones identificados por ACn (por sus siglas en inglés), número
de Control de Aplicación [COBIT4]
A partir de esta lista se obtienen las directrices base para la elaboración de

un cuestionario de consultas que debe realizar el auditor para la evaluación
del caso de seguridad en base de datos:
Controles de origen de datos/ autorización
AC1 Procedimientos de preparación de datos

Los departamentos usuarios implementan y dan seguimiento a los
procedimientos de preparación de datos. En este contexto, el diseño de los
formatos de entrada asegura que los errores y las omisiones se minimicen.
Los procedimientos de manejo de errores durante la generación de los
datos aseguran de forma razonable que los errores y las irregularidades son
detectados, reportados y corregidos.
AC2 Procedimientos de autorización de documentos fuente

El personal autorizado, actuando dentro de su autoridad, prepara los
documentos fuente de forma adecuada y existe una segregación de
funciones apropiada con respecto a la generación y aprobación de los
documentos fuente.
AC3 Recolección de datos de documentos fuente

Los procedimientos garantizan que todos los documentos fuente autorizados
son completos y precisos, debidamente justificados y transmitidos de
manera oportuna para su captura.
AC4 Manejo de errores en documentos fuente

Los procedimientos de manejo de errores durante la generación de los
datos aseguran de forma razonable la detección, el reporte y la corrección
de errores e irregularidades.
AC5 Retención de documentos fuente

Existen procedimientos para garantizar que los documentos fuente
originales son retenidos o pueden ser reproducidos por la organización
durante un lapso adecuado de tiempo para facilitar el acceso o
reconstrucción de datos así como para satisfacer los requerimientos legales.

Controles de entrada de datos
AC6 Procedimientos de autorización de captura de datos

Los procedimientos aseguran que solo el personal autorizado capture los
datos de entrada.
AC7 Verificaciones de precisión, integridad y autorización

Los datos de transacciones, ingresados para ser procesados (generados por
personas, por sistemas o entradas de interfaces) están sujetos a una
variedad de controles para verificar su precisión, integridad y validez. Los
procedimientos también garantizan que los datos de entrada son validados
y editados tan cerca del punto de origen como sea posible.
AC8 Manejo de errores en la entrada de datos

Existen y se siguen procedimientos para la corrección y re-captura de datos
que fueron ingresados de manera incorrecta.
Controles en el Procesamiento de datos
AC9 Integridad en el procesamiento de datos

Los procedimientos para el procesamiento de datos aseguran que la
separación de funciones se mantiene y que el trabajo realizado de forma
rutinaria se verifica. Los procedimientos garantizan que existen controles de
actualización adecuados, tales como totales de control de corrida-a-corrida,
y controles de actualización de archivos maestros.
AC10 Validación y edición del procesamiento de datos

Los procedimientos garantizan que la validación, la autenticación y la
edición del procesamiento de datos se realizan tan cerca como sea posible
del punto de generación. Los individuos aprueban decisiones vitales que se
basan en sistemas de inteligencia artificial.
AC11 Manejo de errores en el procesamiento de datos

Los procedimientos de manejo de errores en el procesamiento de datos
permiten que las transacciones erróneas sean identificadas sin ser
procesadas y sin una indebida interrupción del procesamiento de otras
transacciones válidas.
Controles de salida de datos
AC12 Manejo y retención de salidas

El manejo y la retención de salidas provenientes de aplicaciones de TI
siguen procedimientos definidos y tienen en cuenta los requerimientos de
privacidad y de seguridad.
AC13 Distribución de salidas

Los procedimientos para la distribución de las salidas de TI se definen, se
comunican y se les da seguimiento.
AC14 Cuadre y conciliación de salidas

Las salidas cuadran rutinariamente con los totales de control relevantes. Las
pistas de auditoría facilitan el rastreo del procesamiento de las
transacciones y la conciliación de datos alterados.
AC15 Revisión de salidas y manejo de errores

Los procedimientos garantizan que tanto el proveedor como los usuarios
relevantes revisan la precisión de los reportes de salida. También existen
procedimientos para la identificación y el manejo de errores contenidos en
las salidas.
AC16 Provisión de seguridad para reportes de salida

Existen procedimientos para garantizar que se mantiene la seguridad de los
reportes de salida, tanto para aquellos que esperan ser distribuidos como
para aquellos que ya están entregados a los usuarios.
Controles de límites
AC17 Autenticidad e integridad

Se verifica de forma apropiada la autenticidad e integridad de la información
generada fuera de la organización, ya sea que haya sido recibida por
teléfono, por correo de voz, como documento en papel, fax o correo
electrónico, antes de que se tomen medidas potencialmente críticas.
AC18 Protección de información sensitiva durante su transmisión y

transporte.
Se proporciona una protección adecuada contra accesos no autorizados,
modificaciones y envíos incorrectos de información sensitiva durante la
transmisión y el transporte.
INDICADORES DE MEDICION (MODELO DE MADUREZ)
Mediante las recomendaciones de COBIT para cada nivel de información se

puede realizar un análisis acerca del nivel de madurez en el que se
encuentran los procesos de TI en la organización.

Tabla 1. Recomendaciones por nivel de madurez [COBIT4]
2. Conceptos de Auditoria
Principio de Autenticidad
El principio fundamental de la Auditoría es el de autenticidad. El auditor
tiene que analizar todos los elementos informativos de la empresa con dos
objetivos principales: comprobar la corrección de lo realizado (calidad), y
que la información presentada refleja la situación verdadera sin
ambigüedades (fiabilidad). [AUDIT]

2.1 Clases de Auditoría [AUDIT]

La Auditoría puede clasificarse desde diversos puntos de vista, según el
sujeto que la efectúa, según el contenido y los fines, por su amplitud y por
su frecuencia. De acuerdo a diferentes aspectos se puede clasificar:
Por el sujeto que la efectúa:

- Auditoría interna: Está a cargo de empleados de la propia empresa,
encuadrados en un departamento directamente dependiente de la
dirección general.
- Auditoría externa: Está a cargo de auditores profesionales, ajenos a
la empresa y totalmente independientes.
Por su contenido y fines:

- Auditoría de gestión: Afecta a la situación global de la empresa.
- Auditoría organizativa: Analiza si la estructura organizativa de la
empresa es la adecuada, según las necesidades y problemas de la
misma.
- Auditoría operacional: Para determinar hasta qué punto una
organización, una unidad o función dentro de una organización, está
cumpliendo los objetivos establecidos por la gerencia; así como
identificar las condiciones que necesiten mejora.
- Auditoría financiera: Examen y verificación de los estados financieros
de la empresa, para emitir una opinión fundada sobre el grado de
fiabilidad de dichos estados.
- Auditoría contable: Analiza la adecuación de los criterios empleados
para recoger los hechos derivados de la actividad de la empresa y su
representación, mediante apuntes contables, en los estados
financieros.
- Auditoría informática: Examen y verificación del correcto
funcionamiento y control del sistema informático de la empresa.
Por su amplitud:
- Auditoría total: Afecta a todos los elementos de la empresa.
- Auditoría parcial: Se concentra en determinados elementos de la
empresa.
Por su frecuencia:
- Auditoría permanente: Se realiza periódicamente a lo largo del
ejercicio económico.
- Auditoría ocasional: Se realiza de forma esporádica.
2.2 Auditoria Informática
2.2.1 Principios
1. Todos los auditores tendrán que tener conocimientos informáticos

que les permitan trabajar en el cada vez más cambiante entorno de
las tecnologías de la información dentro de las organizaciones. Este
aspecto no eliminará la necesidad de especialistas en auditoría
informática, es más, los especialistas necesitarán cada vez más

unos conocimientos muy específicos que, de la misma forma que a

los especialistas en sistemas de información, les sirva para ser
expertos en las diferentes ramas de la tecnología informática: redes
y comunicaciones, bases de datos, seguridad, internet, comercio
electrónico, etc.
2. El auditor informático deberá ser un profesional formado y titulado
en auditoría informática que tendrá a su alcance diferentes medios
de formación y, además, formar parte de una red de conocimientos
compartidos con otros profesionales, de su misma organización y de
otras organizaciones. [AUDIT]
2.2.2 Tipos
- Auditoría informática como soporte a la auditoría tradicional.

- Auditoría informática con el concepto anterior, añadiendo la función
de auditoría de la función de gestión del entorno informático.
- Auditoría informática como función independiente, enfocada hacia la
obtención de la situación actual de un entorno de información e
informático en aspectos de seguridad y riesgo, eficiencia y
veracidad e integridad.
- Las acepciones anteriores desde un punto de vista interno y externo
- Auditoría como función de control dentro de un departamento de
sistemas. [AUDIT]
2.2.2 Actividades de Auditoria
- Verificación del control interno, tanto de las aplicaciones como de

los sistemas informáticos, centrales y periféricos.
- Análisis de la gestión de los sistemas de información desde un
punto de vista de riesgo de seguridad, de gestión y de efectividad
de la gestión-
- Análisis de la integridad, fiabilidad y certeza de la información a
través del análisis de las aplicaciones. Esta función, que la vienen
desempeñando los auditores informáticos, están empezando ya a
desarrollarla los auditores financieros.
- Auditoría del riesgo operativo de los circuitos de información.
- Análisis de la gestión de los riesgos de la información y de la
seguridad implícita.
- Verificación del nivel de continuidad de las operaciones (a realizar
conjuntamente con los auditores financieros)
- Análisis del Estado del Arte tecnológico de la instalación revisada y
de las consecuencias empresariales que un desfase tecnológico
pueda acarrear.
- Diagnóstico sobre el grado de cobertura que dan las aplicaciones a
las necesidades estratégicas y operativas de información de la
organización. [AUDIT]

3. Auditoria y Seguridad en Servidores de Base de Datos
El proceso de auditoría en Servidores de Base de Datos no solo está

orientado al despliegue del Sistema Gestor de Base de Datos, al ser un
sistema debe ser controlado a través de todo su ciclo de vida desde el
planteamiento y los entregables involucrados para la creación del modelo de
datos hasta las actividades involucradas en al afinamiento, pistas de
auditoría técnica, implementación de procesos de seguridad a nivel de
usuarios, reglas o políticas de acceso, seguridad en las conexiones al
servidor, control de acceso a los servidores físicos y desde aplicaciones
autorizadas, gestión de actualizaciones e inserción de nuevos objetos sobre
el servidor.
Los Servidores de Base de Datos son cada vez más complejos y no solo se
limitan a la instalación de un repositorio de datos o Sistema Gestor de Base
de Datos (SGBD), por el contrario poseen una serie de herramientas y
características que también deben ser analizadas. Un SGBD posee distintos
elementos los cuales se presentan de forma detallada en el siguiente
esquema.
SGBD
Protocolo y
servicios de red
Diccionario y NUCLEO -
Sistema Operativo
catalogo de KERNEL
Datos
Software para
Recuperación
(backups)
Lenguaje de 4 Mecanismos de
Aplicaciones, generación Administración
adaptadores,
librerías
Middlewares y
protocolos
Software o Gestión de
paquetes de Usuarios
Auditoria
Ilustración 2. Esquema de los elementos de una Base de Datos [Adaptación

del diagrama de SGBD, 2004]

3.1 Seguridad y auditoria en Base de Datos Oracle
Oracle es la base de datos con mayor documentación en el mercado y entre

tareas que se deben incluir para mantener segura una base de datos Oracle
se deben seguir los siguientes pasos [SECBD, 2005]:
- Mantener en un lugar físicamente seguro el servidor donde se almacena

de la Base de Datos Oracle.
- En un entorno de Windows, no instalar el software de Oracle sobre un
controlador de dominio.
- Crear una cuenta para cada DBA que accede al servidor, no otorgar la
misma cuenta a todos los usuarios.
- Bloquear la cuenta del dueño del software, no usarla para administrar la
base de datos (usuario del SO)
- Verificar que el usuario Oracle tiene todos los permisos necesarios y
suficiente sobre la carpeta $ORACLE_HOME/bin
- Oracle tiene muchas opciones y paquetes de funcionalidad, instalar solo
lo necesario para el funcionamiento de la base de datos.
- Limitar la entrega del privilegio “With Grant options”.
- Revisar los privilegios del sistema que han sido otorgados.
- No es necesario entregar los privilegios “resource” y “connect” a todos
los usuarios.
- Auditar que los desarrolladores no tengan acceso al entorno de
producción.
3.2 Seguridad y auditoria en un entorno de SQL Server
- El servidor en el cual se encuentra la base de datos SQL Server debe

ser físicamente seguro.
- Aplicar todos los paquetes necesarios para el sistema operativo y el
Software Gestor de Base de Datos.
- Asegurarse que todos los data file y archivos del sistema se encuentran
en una partición NTFS con los permisos adecuados para cada archivo.
- Utilice una cuenta con pocos privilegios para iniciar los servicios de SQL
Server, no utilice las cuentas: LocalSystem o Administrador.
- Verificar que la cuenta “sa” tiene un password seguro.
- Eliminar todos los usuarios y bases de datos de ejemplo.
- Eliminar al usuario invitado de todas las bases de datos excepto de
master y temdb.
- Identificar que roles y privilegios han sido otorgados, de ser necesario
eliminar los privilegios de los usuarios hasta los más mínimos.
- No habilite los accesos remotos o conexiones de red hacia el servidor.
- Desinstale librerías de red que no estén en uso.
- Deshabilitar el coordinador de transacciones distribuidas de Microsoft,
siempre y cuando su aplicación no lo requiera.
- Habilitar las opciones de auditoría. [SECBD, 2005]

3.3 Seguridad y auditoria en un entorno de Base de datos DB2
- El servidor en el cual se encuentra la base de datos DB2 debe ser

físicamente seguro.
- No ejecutar los servicios del DB2 como usuario root, ejecútelos con un
usuario de menores privilegios.
- Eliminar las cuentas instaladas por defecto que no son usadas.
- Habilitar los perfiles de contraseñas (bloqueo y expiración).
- Verificar las contraseñas asignadas por defecto.
- Nunca use el tipo de autenticación CLIENT. Use SERVER_ENCRYPT,
DCE_ENCRYPT o KRB_SERVER_ENCRYPT si es posible.
- Cierre los puertos y servicios innecesarios.
- Restrinja a quienes tengan el privilegio SYSADM. Durante la instalación
se otorga este privilegio a muchos usuarios por defecto, es importante
que lo deshabilite.
- Si esta sobre un entorno Windows, cambia el usuario sobre el cual se
ejecuta el servicio DAS usando db2admin setid<username>
<password>. No use el utilitario, porque algunos de los accesos
requeridos no son asignados a la nueva cuenta.
- Audite a los desarrolladores y verifique los accesos al servidor en
producción. [SECBD, 2005]
3.4 Seguridad y auditoria en un entorno de Base de datos MySQL
- El servidor en el cual se encuentra la base de datos MySQL debe ser

físicamente seguro.
- No use la opción “skip Grant tables mysqldb”.
- No use la opción “enable named pipe” en Windows use acceso a red
TCP.
- No otorgue los privilegios PROCESS, FILE o SUPER a usuarios que no
sean administradores.
- Asegúrese de tener una contraseña segura para el usuario root.
- Limite los privilegios de la función Load_file.
- Deshabilite el control total del servidor otorgado por defecto a usuarios
locales.
- Deshabilite los permisos de conexión remota al servidor.
- Limite los accesos de los usuarios desarrolladores al servidor en
producción.
- Habilite las opciones de auditoría.
- Evalúe adecuadamente el uso de una versión de MySQL mayor a 4.1.x
existen muchas vulnerabilidades relacionadas con las los protocolos de
autenticación del servidor. [SECBD, 2005]

4. Sistemas Expertos
En la actualidad los sistemas expertos están siendo ampliamente

investigados e implementados, la razón, es que están basados en
algoritmos de inteligencia artificial lo cual otorga al usuario un mejor nivel
de interacción y un porcentaje de acción más cercano a la realidad, son
sistemas que almacenan información y presentan distintas alternativas
basadas en el conocimiento humano acerca de un tema especifico. El uso
más común de estos sistemas es el soporte a las actividades del ser
humano, en muchos casos las personas no contamos con el conocimiento
suficiente, la práctica y el nivel de instrucción necesarios para realizar una
tarea de forma optima, es así que un sistema experto simula la capacidad
de razonamiento del ser humano para otorgar las respuestas o soluciones
más adecuadas de acuerdo a un determinado contexto.
Comúnmente, este tipo de sistemas contiene una base de conocimientos

que contiene la experiencia acumulada por expertos en el área de estudio y
un conjunto de normas para la aplicación de la base de conocimientos a
cada situación particular que se describe en el programa. Los sistemas
expertos sofisticados se pueden mejorar con adiciones a la base de
conocimientos o para el conjunto de normas.
Aspectos técnicos de un sistema experto
Componentes de un sistema experto
 Base de hechos
 Base de conocimientos
 Motor de inferencia
 Módulos de comunicación o de entrada-salida que se subdivide en:
 Módulo de consulta o del usuario
 Módulo de trabajo o del experto
O sea que podemos esquematizar un sistema experto de la siguiente

manera:
Base de Motor de Base de

Hechos inferencia Conocimiento
Usuario Experto
Ilustración 3. Esquema de componentes de un sistema experto.

PROCESO LOGICO DE CARGA DE LA BASE DE CONOCIMIENTO

En esta fase se determinan las reglas y se incorporan a la base de
conocimientos [JCScarabino, 2000]
INICIO
Determina una
regla NO
Es
correcta
La regla se
incorpora a la
Base de
Conocimiento
SI
Más
Reglas
FIN
Ilustración 4. Proceso de carga de Base

de Conocimiento
PROCESO LOGICO DE CARGA DE LA BASE DE HECHOS

En esta fase se detectan los hechos y se incorporan a la base de hechos.
Si no existe al menos una regla que contenga ese hecho debemos
determinarla ya que de no ser así, ese hecho estaría de más en la base de
hechos [JCScarabino, 2000].

INICIO
Detecta un
hecho
SI NO
Es
correcto
El hecho se
incorpora la
base de hechos
NO
Existe Se determina
regla para una regla
este hecho
SI NO
Más
hechos
FIN
Ilustración 5. Proceso de Carga de la base de Hechos
VERIFICACIÓN DE UN HECHO
En este proceso, una vez tomado un hecho, se produce el encadenamiento
hacia atrás. Es decir, se parte de la premisa para llegar a los datos
[JCScarabino, 2000].

INICIO
Incorporo el
hecho
Encadenamien
to hacia atrás
Se Veré A Ingreso
FIN verifica? todos los de reglas
hechos?
SI SI
A Ingreso
Veré
de Hechos
todas las
reglas?
SI
Ilustración 6. Proceso de validación de un hecho
DEDUCCIÓN DE UN HECHO
En este proceso, primero se requieren los datos para analizar la premisa. O
sea, partimos del:
IF < condición >
Para tomar luego la decisión de continuar o no con él:
THEN < conclusión >
La conclusión de una regla puede constituirse en condición de la premisa

necesaria para otra regla y seguir así sucesivamente. Hasta llegar al
resultado final de la inferencia [JCScarabino, 2000].

INICIO
Encadenamiento
hacia adelante
SI Se SI Usé todos A Ingreso

FIN deduce? los de reglas
hechos?
SI A Ingreso
Usé todas
de Hechos
las
reglas?
Ilustración 7. Proceso de deducción de un sistema experto
Tipos de Sistemas Expertos
Los Sistemas Expertos pueden ser clasificados de acuerdo a muchos

criterios: uso, industria, modelo de trabajo, modelo de solución de
problemas, etc. En este proyecto la clasificación seleccionada ha sido de
acuerdo al modelo de trabajo u objetivo del sistema. Tipos:
Adquisición e interpretación de datos. En esta categoría se incluyen

sistemas encargados de realizar tareas como: recuperar, analizar, filtrar y
restablecer la pérdida de datos, así como minería de datos, transformar los
datos en otro formato, etc.
Apoyo a la toma de decisiones. En esta categorías se incluyen las

siguientes sub-categorías: Gestión de decisiones, optimización de
decisiones, administración de cuentas y clientes, gestión del fraude,
modelos de predicción, gestión de riesgos, etc.
Diseño y gestión de soluciones. Después de examinar un gran número

de parámetros variables para la solución de tareas de innovación, que
permite la optimización del diseño y encontrar las mejores decisiones de
gestión, de acuerdo a los objetivos y planes de las empresas.
Control y Monitoreo. En esta categoría se consideran los sistemas que se

encargan de ayudar a supervisar el funcionamiento y el control de ciertas

funciones de un proceso o actividades especificas. Muchas empresas que

han desarrollado sistemas de Vigilancia y Control de Adquisición de Datos
(SCADA), utilizan los sistemas expertos para los distintos niveles de control
de plantas industriales. Aquí hay empresas como: Emerson Process
Management, Matricon, REDUCT & Technologies Lobbe, etc.
Predicción. Esta categoría permite prever los posibles resultados de

situaciones observables. He aquí la previsión meteorológica, puntuación y
elaboración de modelos de predicción, gestión de riesgos y otros
compromisos financieros de previsión.
Marketing y gestión del comercio. Un uso clave de la inteligencia

artificial para determinar el potencial de comercialización y oportunidades
de negocio. Características de un sistema experto de esta categoría:
Optimizador de campaña, Vista previa presentación de informes, cartógrafo
de Oportunidades, etc. Marketing de bases de datos de diseño, desarrollo,
gestión y servicios de alojamiento para los clientes que buscan externalizar
sus múltiples canales de comercialización al cliente y gestión de datos.
Human Resource Management Systems (HRMS). El uso de la

tecnología de IA para encontrar talento técnico humanos, evaluación de
personal y perfiles.
Tecnologías de Sistemas Expertos
Las tecnologías usadas en los sistemas expertos son típicamente basadas

en tipos específicos de bases de conocimiento o matemáticas (lógica), estos
modelos son utilizados para la resolución de problemas con la ayuda de
motores de inferencia. Estos son algunos ejemplos de diferentes tipos de
tecnologías:
Modelo Basado en el Razonamiento: Usa un entorno de modelado de datos

para explorar, crear algoritmos, y la creación de reglas personalizadas que
ofrecen ideas y principios de ventajas competitivas.
• En este campo MATLAB ®, Simulink ®, Stateflow ®, etc. (Mathworks

Inc.) se han convertido en las herramientas fundamentales para la
ingeniería y los trabajos científicos. MATLAB integra la computación
matemática, visualización, y un lenguaje potente para proporcionar un
entorno flexible para explorar datos, crear algoritmos, y crear
herramientas personalizadas que proporcionan ideas y principios de
ventajas competitivas. Simulink es una herramienta interactiva para
modelado, simulación y análisis dinámico, dominio de múltiples
sistemas. Stateflow es una herramienta de diseño interactivo para el
modelado y la simulación de evento impulsado por los sistemas.
• Opal-RT Technologies Inc. se especializa en nuevas PC de bajo costo

y gran escala de simulación, control rápido de prototipos, y el software
o los sistemas de pruebas con el hardware-in-the-loop.

Razonamiento basado en casos (CBR): Un sistema CBR compara el

problema con casos anteriores y, a continuación, sugiere la línea de acción
más exitosa. Además de ser construido manualmente los sistemas CBR,
también utilizan métodos de minería de datos.
Modelo evolutivo razonamiento: Un algoritmo evolutivo es una clase de

algoritmos que se encuentra a la aproximación de soluciones difíciles de
resolver problemas. Ellos se inspiran en los mecanismos de la evolución
biológica, como la selección natural, mutación y recombinación para
encontrar la mejor configuración para un sistema específico dentro de
limitaciones específicas.
Razonamiento mediante Lógica Difusa: La Lógica difusa es la emulación del

razonamiento humano en los ordenadores. Los conceptos clave en la lógica
difusa son la lingüística y la composición variable de la función. Una
variable lingüística es una variable cuyo valor es una palabra. (Por ejemplo,
la variable lingüística "temperatura" podría tener los valores: "normal",
"alto", "frío", "enorme", "peligro", "congelación", y así sucesivamente). Una
función de pertenencia lingüística describe estos valores en términos de
números. Por ejemplo, para describir la palabra "frío", podemos decir: "Si
la temperatura está por debajo de 40 grados, podemos decir que
definitivamente el frío." Las variables lingüísticas y sus miembros funciones
permiten lógica difusa para llevar a cabo la imprecisión, no realiza
razonamiento numérico de la misma manera que los seres humanos.
Tecnologías híbridas. Muchos sistemas expertos industriales combinar

diferentes tecnologías, aprovechando las fortalezas de cada tecnología.
Métodos de Validación de Un Sistema Experto para auditoria
Los Sistemas expertos pueden ser de gran ayuda para el planeamiento o

soporte de un proceso de auditoría sin embargo si su desarrollo no es
controlado y validado puede implicar la obtención de un sistema que brinde
estrategias incorrectas.
Un proceso de validación es crítico durante las fases de diseño e
implementación de un sistema, este tipo de procedimientos aseguran que la
base teórica, el nivel de experiencia usado en su implementación sean los
adecuados y evalúa la confiabilidad de las decisiones tomadas por él.
Un plan de validación de un sistema experto debe asegurar que sean
cubiertas todas las características que hacen único a un Sistema Experto de
otros tipos de software.
Validación de un sistema experto
El desarrollo, diseño e implementación de los sistemas expertos requiere un

análisis de la base de conocimientos y la capacidad de tomar decisiones del
sistema. Este tipo de procesos, con una actividad de validación, requiere:

1. Una lista de lo que el sistema conoce, lo que no conoce y lo que

conoce de forma incorrecta.
2. Conocer el nivel de experiencia del sistema.
3. Conocer si el si el sistema está basado en una teoría para tomar
decisiones en un dominio en particular.
4. Determinar la confiabilidad del sistema.
Métodos de validación
De acuerdo a los puntos mencionados líneas arriba, los puntos a considerar

ya están planteados, sin embargo, ¿cuáles son los pasos a seguir para
asegurarlos? Esta pregunta plantea una nueva herramienta, el uso de un
marco y métodos de validación.
- Exactitud de la Base de conocimientos: La exanimación directa es

particularmente utilizada para analizar la base de conocimiento. Sin
embargo debido al tamaño y complejidad de algunas bases de
conocimiento la exanimación directa puede ser muy difícil de ejecutar.
El uso de probabilidades o formulas matemáticas para evaluar la
viabilidad de las reglas, es recomendable dependiendo el tipo de reglas
implementadas
- Revisión exhaustiva de la Base de conocimientos: en este tipo de
procedimientos se evalúa el sistema para obtener si alguna regla no ha
sido considerada por el sistema, se pude realizar usando técnicas como
un sistema de inducción y contingencia de tablas.
- Peso de la base de conocimientos: Se deben establecer prioridades
especificas para los diferentes tipos de reglas de la base de
conocimientos, de esta manera se puede usar funciones estadísticas
para el análisis de las reglas.
- Motor de Inferencia: La ingeniería de inferencia es el algoritmo que se
encarga de procesar y evaluar la base de conocimientos, para validar
este aspecto se puede usar una prueba de rastro de datos, mediante
esta prueba se puede conocer si el algoritmo utilizado para la
evaluación de las reglas es el correcto.
- Comparación condición-decisión: Se realiza esta prueba para conocer el
rango de condiciones que puede efectuar la base de reglas mediante el
uso de un mapa de ruta.
- La respuesta correcta para las razones correctas: Esta prueba es usada
para validar la precisión de la decisión obtenida por un conjunto de
reglas.
- Validar el sistema para la adición de nuevo conocimiento: Se evalúa
esta característica mediante pruebas exhaustivas después de adicionar
nuevas reglas y como afecta al sistema actual.

CAPITULO III
ESTADO DEL ARTE
I. Contexto
El uso de sistemas expertos para los procesos de auditoría no es reciente, e

inclusive ha sido recomendado por el Instituto de Auditores Internos desde
el año 1991 [IAI, 1991] como una herramienta fundamental para este tipo
de procesos debido a muchos factores que lo hacen muy útil: su bajo costo,
el alto nivel de confiabilidad, su eficiencia y su interfaz altamente intuitiva
de fácil uso para el usuario.
Sin embargo a pesar de este tipo de referencias de tantos años atrás, en

nuestro país la realidad acerca de las auditorias es muy diferente, el uso de
herramientas de apoyo al auditor a nivel técnico es bastante útil y
adaptable sin embargo el uso de un sistema experto implica otro nivel de
investigación acerca de los procedimientos y estándares adaptados a los
procedimientos de software de las organizaciones nacionales. Un sistema
Experto de Auditoria, no es una herramienta CASE más o un software para
consolidar reportes, es un sistema que contiene información a detalle de los
procedimientos y mejores práctica, y a través de ellas elabora conjeturas y
evaluaciones a nivel de cada uno de los objetivos de control de los Procesos
evaluados.
El nivel de investigación y desarrollo de los sistemas expertos es alto, existe

una amplia gama de sistemas expertos de auditoría para distintas áreas y
giros de negocio, desde medicina hasta sistemas de auditoría financiera.
Entre los sistemas que se mostraran en este capítulo correspondiente al

estado del arte figuran aplicaciones que no necesariamente trabajan como
sistemas expertos, sino que básicamente son herramientas de soporte para
el trabajo de auditoría y que entre sus características pueden ser de gran
ayuda para la implementación del sistema.
II. Sistemas desarrollados
A. AUDES
AudEs es un Sistema experto en el área de Auditoría y Seguridad de

Información. Este sistema trabaja con la información de un Auditor de
sistemas y un software de control de acceso a recursos (Resource Access
Control Facility o sus siglas RACF1) un mecanismo muy popular usado en
sistemas Mainframes de IBM. [AUDES]
1
RACF: Es un producto de IBM, consiste en una plataforma de seguridad que proporciona
control para z/OS y z/VM.

Este proyecto ha sido realizado con la finalidad de automatizar las tareas de

auditoría y control de seguridad en un sistema y para aliviar de cierta
manera el complejo trabajo de los auditores.
Actualmente muchos procedimientos de seguridad y auditoria del tipo RACF

son soportados mediante procedimientos ejecutados manualmente que
escudriñan el sistema generando “logs” e identificando potenciales
violaciones de seguridad. Este tipo de procedimientos pueden ser
considerados intrusivos, debido a que la seguridad es una actividad
altamente sensible que necesariamente requiere de la experiencia humana.
Sin embargo cuando los volúmenes de información y la data en sí misma es
amplia y de diversa naturaleza entonces se debe sacrificar el tiempo del
auditor para que sea analizada de forma adecuada.
A.1 Diseño
Para evaluar la aplicación de este sistema primero se necesitaron

identificar qué tipo de procedimientos se deben automatizar. El evento
más importante para este sistema es Auditar la seguridad e identificar
las posibles violaciones de seguridad. El ciclo de vida de una violación de
seguridad es representado mediante la siguiente secuencia de eventos.
Ocurrencia Detección  Seguimiento  Archivado
De cada una de estas etapas las que son más importantes son las
siguientes:
A.1.1 Detección
La detección de violaciones de seguridad implica muchas veces analizar

una secuencia de eventos de forma aislada, compara ciertos patrones e
identifica los procedimientos de seguimiento adecuados. Cuando se
ejecuta esta tarea de forma manual puede consumir mucho tiempo,
además de ser extremadamente tediosa, ya que las violaciones tienden
a ser solo una pequeña fracción de los datos de auditoría que un Auditor
debe manejar.
El primer gran cambio que se debe efectuar para automatizar la

detección de intrusos consiste en proveer una representación robusta de
los patrones de detección, la secuencia de actividades que constituye
una violación. Una Violación puede ser determinada por muchos
patrones. Por ejemplo:
TIPO DE VIOLACION: Umbrales y acciones de seguimiento que

diferencian distintos tipos de violaciones.
TIPO DE USUARIO: Cada tipo de usuario es tratado de forma diferente.

Por ejemplo, el criterio de violación de los usuarios externos debe ser
más severo que el de los usuarios internos.

LUGAR: la localización y el tiempo en que el ataque fue realizado son

aspectos de gran importancia para las decisiones del auditor.
DIA/TIEMPO: El momento del día y las fechas pueden ser importantes

para identificar eventos sospechosos.
UMBRAL: Cada acción ejecutada puede considerarse una violación

dependiendo el tipo y el rango de umbrales que hayan sido establecidos.
Otro Aspecto a considerarse está relacionado con el volumen de datos de

los registros de auditoría. Como primer vistazo se puede pensar que este
componente no es de gran importancia para el diseño del sistema, pero
en realidad es esta característica es tan importante que distingue a una
aplicación del dominio de Auditoria y Seguridad. En este tipo de sistemas
él algoritmo a seguir para analizar los registros de Auditoria sería el
siguiente:
1. Mientras se encuentren mas registros

i. Leer todas las filas por usuario
ii. Analizar las filas por todos los tipos de violaciones
2. Ir al paso 1
3. Procesar todas las estadísticas.
AudEs fue implementado para disminuir las tareas y rutinas de análisis

de grandes bancos de registros de auditoría mediante la construcción de
una rutina (no basa en reglas) que realiza las tareas fuera de la base de
conocimientos.
A.1.2. Seguimiento
El seguimiento es la secuencia de eventos que se ejecutan después de

una detección, a diferencia de una detección esta actividad requiere un
enfoque más activo. En otras palabras el auditor debe de:
- Comunicarse con el sospechoso.

- Comunicarse con el Jefe del sospechoso.
- Notificar a los dueños de los recursos vulnerados.
- Enviar una alerta de seguridad, etc.
En suma, envuelve mucho papeleo, comunicación y tiempo por parte del

auditor, tiempo que puede ser reducido si este proceso es automatizado.
A.1.3. Archivado y verificación
El propósito principal de esta actividad es verificar que los

procedimientos prescritos por el Auditor han sido ejecutados e
incorporados a las guías de seguridad de la organización. Un proceso de
este tipo realizado por un sistema RACF es efectuado seleccionando
incidentes de forma aleatoria, luego es rastreado para verificar si han
sido tomadas las acciones apropiadas. Por este propósito, los antiguos

reportes RACF pueden ser difíciles de analizar, además de ocasionar

numerosos documentos que pueden volverse imposibles de mantener.
Con el proceso de detección automatizado, el proceso de verificación

puede ser ejecutado fácilmente validándolo con las reglas
implementadas en el sistema. Además, la cantidad de papeleo será
reducida si de todos los registros que maneja la base de datos de RACF,
el sistema experto archiva solo los registros sospechosos de violación.
A.2 Entorno de Desarrollo
La herramienta adoptada por el equipo de desarrollo de AudEs es Expert

System Enviroment (ESE), es un producto comercialmente disponible y ha
sido aplicado a muchas tareas incluyendo predicción, diagnostico,
planeamiento y toma de decisiones, en una variedad de dominios de
aplicación.
Las reglas y comandos de ESE están estructuradas en una sintaxis muy

parecida al inglés que puede ser entendida incluso por no-programadores.
Esta herramienta detecta errores de forma automática y soporta edición en
tiempo de ejecución. Además de estas características, ESE provee una
interfaz para la implementación de procedimientos externos.
A.3 Adquisición de conocimiento
En la mayor parte del desarrollo del proyecto, las guías del sistema y otros
documentos usados por los auditores de seguridad no han sido escritos por
los programadores. Las personas responsables de escribir a documentación
son en general, profesionales calificados en trabajos de seguridad. En
términos generales la estructura de los procesos de violación de seguridad
es la siguiente, primero la acción es ignorada hasta un umbral, si sobrepasa
ese umbral se inician acciones de rastreo y luego acciones correctivas. Por
ejemplo para el caso de “violación parcial de inicio de sesión” la secuencia
fue documentada de la siguiente manera:
1. Tres fallas en el inicio de sesión constituyen un periodo de gracias.

2. cuatro fallas ocasionan una pérdida del ID del usuario.
3. Las siguientes fallas de inicio de sesión son ignoradas pero
almacenadas (aun si el usuario ingreso la contraseña correcta).
A.4 Despliegue y Beneficios
Antes de reemplazar los procedimientos manuales de Auditoria, AudEs fue

probado exhaustivamente para asegurar la validez de las reglas. Por un
periodo de ocho meses fue usado en paralelo con el sistema existente.
Durante este periodo se obtuvo información por parte de los Auditores para
mejorar aspectos del sistema como: interfaz de usuario, performance,
estructura de los reportes e auditoria. AudEs fue desplegado en 20 a 25

Mainframes sobre la base de los reportes generados por sistemas RACF y

los beneficios encontrados en su uso se pueden resumir en los siguientes:
- Reducción del tiempo de trabajo del Auditor.

- Alta consistencia del trabajo de Auditoria.
- Detección y seguimiento oportunos de infracciones de seguridad.
- Reducción de costos en documentación.
- Fácil configuración de los requerimientos del lugar.
- Reducción del tiempo de entrenamiento de los auditores en la
herramienta.
B. Planning Advisor.
Es un software desarrollado por Methodware de apoyo a la auditoria que
automatiza el proceso de planificación permitiendo al usuario definir los
grupos de proceso a evaluar y mostrándole las actividades a realizar,
además permite mantener un diccionario de datos y la lista de riesgos a
evaluar. El software permite adaptar el plan a la organización actualizando
información como: nombre de los recursos, áreas involucradas, definición
de los términos y tiempo de ejecución.
Esta herramienta está basada en riesgos, al aplicar este enfoque permite
aplicar los recursos de la auditoría a las áreas con mayor exposición
potencial. [Advisorv5].
Planning Advisor incluye entre sus diferentes módulos: Reportes y
diagramas indicando las unidades o áreas de proceso auditadas y los niveles
alcanzados, de acuerdo a la información ingresada por el auditor.
Esta herramienta contiene todos los procesos y los objetivos de control de
Cobit en su tercera versión.

Ilustración 8 Actualización de los criterios de evaluación y los valores

asociados [Advisorv5]
Ilustración 9 Actualización de recursos para la auditoria [Advisorv5]

Ilustración 10. Planificación de tiempo y costos para la auditoría

[Advisorv5]
C. Sistema Experto para auditoria de Plantas nucleares

El Departamento de Seguridad Nuclear de Taipower está a cargo de las
auditorías anuales de las tres centrales nucleares en funcionamiento en
Taiwán. En esta planta Nuclear se realizaron auditorias a las áreas de
funcionamiento, gestión básica, química radiactiva, mantenimiento,
seguridad industrial, salud física, protección contra las radiaciones, la
gestión de residuos radiactivos, formación, etc. Los materiales relacionados
con la auditoría son las especificaciones de funcionamiento, manual de
garantía de la calidad, procedimientos de operación, requisitos de
regulación, las políticas de empresa, etc. Antes de cada auditoría, los
auditores tienen que pasar mucho tiempo para estudiar esos materiales y
preparar listas de comprobación. Con el fin de reducir el tiempo de
preparación Taipower y el Instituto de Investigación de Energía Nuclear
(INER) inicio el proyecto para desarrollar un sistema experto la auditoría.
C.1. Estructura y diseño del sistema
Al inicio del proyecto, los requisitos de la estructura del sistema de base de

datos y software se discutieron a fondo por los trabajadores de Taipower e

INER. Con el fin de familiarizarlos con los trabajos de auditoría, los

trabajadores de INER-Taipower se unieron a un equipo de auditoría a
Chinshan Nuclear Power Plant. Después de varios debates, la estructura de
este sistema experto de auditoría fue creada. Contenía tres subsistemas y
dos bases de datos.
Ilustración 11. Diagrama de bloques del sistema experto de Auditoria

[ANPP]
C.2. de Inteligencia Artificial motor
En el diagrama de funciones del sistema, los subsistemas relacionados con

este sistema experto de auditoría incluyen subsistemas expertos en
búsqueda de auditoría y subsistemas expertos en entrenamiento de
auditoría. El motor de inteligencia artificial se muestra en la esquina
superior derecha del diagrama está diseñado para ser añadido en la
segunda fase del proyecto para mejorar el rendimiento.
La experiencia acumulada de los auditores de Taipower es muy valiosa

para el establecimiento de este sistema experto. Por lo tanto las estructuras
de los distintos lenguajes se probaron y se creó una base de de datos
adecuada para el almacenamiento de datos. El subsistema experto en
búsqueda de auditoría no sólo es conveniente para la búsqueda de datos,
sino también adecuado para la acumulación de las experiencias de los
auditores.
El núcleo del subsistema experto de auditoría es el entrenamiento conjunto

de los auditores de la educación es un conjunto de bases de datos
computarizado portátil. Cada auditor puede crear su propio bloc de notas o
recoger de otros auditores en su computadora. Las funciones de "notebook"
incluye el registro de notas de lectura para encontrar datos, preparación de

listas de comprobación y edición de informes de auditoría. Para los nuevos

auditores, esta aplicación puede ser de gran ayuda para su formación. Las
experiencias de los expertos pueden ser captadas mediante esta vía.
Después de un período de uso, el sistema de analizadores analizará la

información registrada en el bloc de notas. Analizando las condiciones de
uso y tiempo de lectura de los datos, que puede llegar a la conclusión de
expertos normas de conocimiento artificial inteligente motor.
C.3. Diseño del programa
En la etapa de planificación de este proyecto, muchas de las bases de datos

comerciales y programas de ordenador fueron encuestados para la
adecuación de este sistema con los requisitos previstos por los auditores de
Taipower. La encuesta encontró que las funciones de estos programas se
limitan a la inscripción de datos. No se disponía de interfaces hombre-
máquina inteligente y subsistema de entrenamiento. Por lo tanto, este
proyecto tomó la decisión de escribir su propio programa. Delphi fue
seleccionado como lenguaje de programación. Delphi es un lenguaje de
programación visual que implementa el medio ambiente y el desarrollo de
orientación con el objeto de desarrollar aplicaciones con interfaz grafica.
Ofrece muchas herramientas que pueden utilizarse para desarrollar
potentes base de datos aplicaciones con un menor número de códigos
fuente y menos tiempo en desarrollo.
C.4. Funciones de los Subsistemas
Con el fin de simplificar la administración del sistema, el software se divide

en administrador de edición y administración de usuarios. El administrador
sólo tiene que concentrarse en la seguridad y el mantenimiento.
Las funciones de los tres subsistemas se describen más detalladas de la

forma siguiente:
c.4.1 Base de Datos de Edición y Mantenimiento del Subsistema

Este subsistema se compone de la base de datos de la edición de interfaz
hombre-máquina y la función de mantenimiento de bases de datos de
interfaz hombre-máquina.
El objetivo principal de la base de datos de interfaz hombre-máquina

función es la de editar la información tablas de la base de datos más rápida
y cómoda. Puede copiar fácilmente una sección deseada de una base de
datos dentro del sistema de lectura, y puede ayudar editor para asignar la
categoría de datos.
El mantenimiento de bases de datos de interfaz hombre-máquina está
diseñado para ayudar a los auditores de Taipower para el mantenimiento de
bases de datos. Los trabajos de mantenimiento incluyen la adición de datos,
revisar y actualizar. Sólo el administrador del sistema puede realizar esta
tarea.

c.4.2 Subsistema experto de búsqueda de auditoría

Es uno de los marcos de búsqueda de auditoría. Este subsistema se
compone de tres métodos de búsqueda y sus combinaciones. Estos tres
métodos son el apartado de búsqueda, la búsqueda y la estructura
completa de documentos búsqueda.
c.4.3 Apartado de Búsquedas

El auditor puede buscar el contenido de un párrafo específico en la base de
datos. Puede seleccionar el nombre de centrales nucleares, objeto de la
auditoría y la entrada de la ID apartado deseado antes de buscar.
c.4.4 Estructura de Búsquedas

El auditor puede realizar una búsqueda siguiendo la estructura de los
niveles de base de datos. Por ejemplo, puede realizar inspecciones
periódicas de estructuras mayor nivel a inferior nivel, como la secuencia:
mantenimiento - mecánica - inspecciones periódicas.
c.4.5 Buscando el documento íntegro

El auditor puede utilizar palabras clave o una sección del documento para la
búsqueda. Puede ajustar el nombre de centrales nucleares, objeto de
auditoría y varias palabras clave antes de buscar.
c.4.6 Subsistema de entrenamiento de expertos

El objetivo de este subsistema se ha mencionado más arriba. Es una
imagen típica de un sistema Experto para mantenimiento y auditoria. Tiene
tres funciones principales: la edición, la búsqueda y el mantenimiento. La
función de edición puede servir para modificar lecturas, listas de verificación
y auditoría de informes. Usando la función de búsqueda puede ingresar en
el contenido público del bloc de notas de los auditores y copiar el contenido
de los cuadernos.
D. Oracle Internal Controls Manager [OICM]
Oracle Internal Controls Manager es una herramienta completa de Gestión

de cumplimiento financiero para documentar, probar y certificar el
cumplimiento de controles internos, Normas Internacionales de Información
Financiera, la Ley Sarbanes-Oxley y la presentación de informes
relacionados con los requerimientos de normas más reconocidos alrededor
del mundo. Define riesgos, controles y procesos de negocio. Administra los
procesos de auditoría, incluidos los resultados, soluciones y los problemas
detectados. Refuerza la separación de deberes en el acceso y gestión de los
datos. El beneficio principal es el de definir de manera rápida y certificar de
forma confiable tanto los procesos de negocio y los estados financieros. Los
beneficios incluyen un mayor control de la eficiencia, la mejora de la
confianza de evaluación de riesgos, y reducir los gastos de auditoría
externa.
Los beneficios de Oracle Internal Controls Manager son los siguientes:

D.1. Definir y gestionar los procesos, riesgos y controles
OICM le permite crear documentación de procedimiento y definir procesos

de negocio. También trabaja con frameworks de cumplimiento y control de
procesos y riesgo como COSO, ISO, COBIT.
El uso de Oracle Tutor, que se entrega como parte de OICM, permite crear
descripciones de procesos utilizando una interfaz de procesamiento de texto
además genera automáticamente diagramas de proceso correspondiente.
Oracle Tutor también ofrece procesos pre-definidos para la documentación
de Oracle E-Business Suite.
OICM proporciona una biblioteca que almacena los riesgos, controles,
procedimientos de auditoría, así como a sus asociaciones para los procesos
de negocio. OICM le permite asociar cada proceso con una cuenta
importante de estado financiero. También puede añadir atributos
personalizados a los riesgos, controles y procedimientos de auditoría.
Además de los tipos pre-definidos de riesgos para la ley Sarbanes-Oxley y
Basilea II, OICM le permite crear otras nuevas para apoyar a otros
reglamentos.
D.2. Detectar y reducir las violaciones de seguridad mediante la

Segregación de funciones (SOD)
La separación de funciones reduce el fraude y la prevención de errores de

un solo individuo contra el desempeño de funciones incompatibles para un
proceso de negocio o transacción financiera. Apalancamiento el usuario
modelo de seguridad dentro de la Oracle E-Business Suite, OICM permite a
los auditores para definir una lista de funciones incompatibles y las
responsabilidades o limitaciones de carga recomendada de riesgo de
auditoría o las empresas de seguros. Proceso de Auditores y
Administradores de violaciones puede monitorear y tomar medidas
correctivas.
D.3. Supervisar los controles de aplicación
En el puesto de la ley Sarbanes-Oxley mundo, las empresas dependen cada

vez más automatizados a los controles de aplicación para garantizar el
cumplimiento con reglamentación y las políticas de la compañía. La Oracle
E-Business Suite ofrece un conjunto completo de controles de aplicación
automática, como parámetros de configuración. Controles de aplicación son
fundamentales para el entorno global de control porque los cambios que les
podría afectar a la fiabilidad y la integridad de los procesos de presentación
de informes financieros, así como la disponibilidad de las aplicaciones de
negocio.
OICM permite a los administradores de TI vigilar continuamente los cambios
de parámetros de configuración a través de casos con el fin de detectar
cambios no autorizados, ayudar a prevenir el fraude, y minimizar la
interrupción de los sistemas de misión crítica. En la búsqueda de cambios
en los controles de aplicación utilizando diferentes criterios, el administrador
de TI puede ver los cambios en la configuración de parámetros, la persona
que realizó el cambio, junto con la fecha y la hora del cambio, el actual,

antes y los valores recomendados. Estos resultados se pueden ver a través

de múltiples instancias de solicitud, lo cual es especialmente útil para la
solución de problemas de problemas de configuración.
D.4. Gestionar auditorías y pruebas.
El uso de herramientas de autoevaluación, los empresarios y auditores

pueden asignar la responsabilidad de evaluar los controles a las personas
responsables de las actividades importantes de una entidad. OICM permite
a los auditores administrar las etapas de riesgos y registro de sus
procedimientos. Con Oracle Scripting, la herramienta incluye una encuesta
con OICM, usted puede crear rápidamente los cuestionarios, identificar
fácilmente los participantes en la encuesta, desplegar las encuestas por
correo electrónico, y permitir el llenado de los cuestionarios a través de la
Web. Además, Oracle posee secuencias de comandos que le permite
proporcionar un mecanismo de información confidencial para cumplir con
algunas disposiciones de la ley Sarbanes-Oxley.
E. DENDRAL
El proyector DENDRAL tuvo sus orígenes en 1965, cuando Feighembaum,
tras instalarse en la Universidad de Stanford, comenzó a trabajar con el
profesor Joshua Lederberg, especializado en Química Molecular. Ambos
investigadores, compartían la misma inquietud: la posibilidad de usar los
ordenadores para modelar el pensamiento científico. [DENDRAL1]
E.1 Motivación
Una molécula se pude considerar como un grafo donde cada nodo
representa un átomo y cada eje que une dos nodos, la unión química que
existe entre ambos.
Para conocer la estructura de una molécula, se utiliza un espectrómetro
másico que permite, a través de un haz de electrones, dividir la molécula en
distintos iones. Estos iones o fragmentos son acelerados y medidos unos
por uno, ordenándose por su número másico. El análisis de estos
fragmentos, tal y como se explica posteriormente, da lugar al conocimiento
de la estructura inicial de la molécula. El principal problema que aparece en
dicho estudio es la aleatoriedad que se produce en la fragmentación de
moléculas complejas, no siempre se produce del mismo modo; se considera
que el bombardeo de electrones es una fuerza no determinista. Entonces,
¿cómo se pueden obtener los resultados deseados?
Un programa que permitiera enumerar todas las estructuras posibles que se
ajustan a los datos de partida, datos obtenidos del espectrómetro másico, y
que elimine aquellos que no cumplen las restricciones, lograría análisis más
eficientes de moléculas complejas, ya que este tipo de problemas son de
complejidad exponencial.
E.2. Fases de diseño

J. Lederber, en un documento oficial publicado en su página Web realiza la
descripción autobiográfica del desarrollo de este sistema. A lo largo de este
documento se distinguen dos fases de diseño bien diferenciadas que se
detallan a continuación.

Primera Fase Consistía en calcular todos los compuestos que podían dan
lugar al número másico de la molécula inicial, teniendo en cuenta el número
másico de cada uno de los átomos en los que se dividía el compuesto y las
restricciones de valencia. Estas restricciones permitieron podar el árbol de
posibles soluciones rápidamente, reduciendo el coste computacional de la
búsqueda exhaustiva que se estaba realizando.
Segunda Fase Intentaba modelar el procedimiento inferencial del experto

químico para encontrar la estructura molecular de la combinación que se
consideraba solución: representar dicha estructura en forma de grafo.
Ilustración 12. Modelo de obtención y representación de datos de

DENDRAL
F. MILK
Sistema MILK Multimedia Interaction for Learning and Knowing, propuesto

por Agostini et al. , apoya a comunidades de interés creadas o que están
emergiendo y las integra con la estructura organizacional oficial. Asocial el
conocimiento con comunidades, personas y conocimiento informal.
Además se integra con las actividades del día a día. Entre sus principales
características se destacan: 1) permitir acceder al conocimiento por todos
los miembros de la organización con intereses similares y no solos por los
miembros de un proyecto, 2) ofrecer un ambiente para acceder
conocimiento ya sea con documentos u otros artefactos y 3) integrar
espacios personales y compartidos con actividades y proyectos, permitiendo
la colaboración a la vez que mantiene la privacidad del trabajo [SISGC].
Tiene tres componentes principales: 1)Manejador de Interacciones:

diferentes mecanismos e interfaces para ambientes de trabajo cambiante
como PC, dispositivos móviles o pantallas interactivas, 2) Manejador de

conocimiento: Componente principal Metadata Management System (MMS)

se encarga de la captura y organización de perfiles de conocimiento, 3)
Sistema de archivos: BSCW (Basic Support for Cooperative Work),
comparte ambientes de trabajo, integra servicios de colaboración,
características de documentos, entre otros.
MILK integra elementos como documentos, personas, comunidades y

proyectos y es capaz de desarrollar relaciones de diferentes tipos y
mantener perfiles basados en tres categorías:
1) Metadata genérica, para personas,

2) Metadata de contenidos para elementos que capturan conocimiento
3) Metadata calificativo para la relevancia de un elemento basado en uso y
tiempo.
El sistema permite crear comunidades que se organizan en torno a

ontologías y el sistema provee un modulo de administración de ontologías.
El Sistema MILK no pretende buscar información, sino descubrirla. Este

mecanismo se llama View With Context (VWC). Permite asociar diferentes
piezas de conocimiento con elementos de diferente naturaleza. Asociar
descripciones y elementos permite a MILK incluir cualquier tipo de
elemento en un proceso de conocimiento. Estos son los documentos, que
para el sistema no son solo archivos, pueden ser colecciones de archivos y
versiones, en conjunto información sobre relevancia y popularidad que
califican los elementos de acuerdo a su utilidad e importancia.
Ilustración 13. Entorno y arquitectura de MILK [MILK1]

G. Jasper II
El sistema Jasper II busca almacenar y organizar información, en ambientes

de conocimiento compartido, mediante el uso de agentes. Jasper II
almacenan solo la meta-información relevante y luego esta es usada como
índice cuando una consulta para recuperar información se presenta. Jasper
II es esencialmente una matriz de términos y documentos. Para cada
usuario del sistema se tiene un agente personal que crea y mantiene su
perfil basado en palabras o frases que modelan la información y sus
intereses.
Las características del sistema son: 1) Despliegue y entrega: cuando un

usuario encuentra información de interés para compartir con su comunidad
envía una tarea a Jasper II. El usuario realiza una anotación a cerca de la
importancia, contenido o razones para compartir la información. Las tareas
de los agentes de Jasper II son crea un resumen de la información útil y
cuando se necesita recuperar grandes cantidades de información remota.
Los agentes analizan el contenido de la página y la relacionan con los
usuario, si el perfil y el documento están altamente relacionados el sistema
envía una alerta vía coreo electrónico. Sugiere frases para unir los
documentos al perfil del usuario y genera una entrada al sistema por cada
documento con el URL, nombre del usuario y la fecha. 2) Consultas: el
sistema recupera las páginas más cercanas a las consultas almacenadas en
su sistema junto con sus anotaciones y un conjunto de páginas de la
intranet de la organización y de Internet. Con esta respuesta el usuario
puede retroalimentar al sistema indicándole cuales páginas no son de su
interés para reacomodar su perfil, y el sistema puede mostrar los usuarios
interesados en la misma área. Además tiene una funcionalidad que permite
a un usuario consultar lo más recientemente almacenado que coincida con
su perfil. 3) Captura y codificación de conocimiento explícito: tienen en
cuenta el entorno en el cual se obtuvo el conocimiento, este es importante
para quienes trabajan en contextos similares a quien produce el
conocimiento pero para trabajadores en otros contextos esto puede ser
confuso, de acuerdo con esta similitudes presenta o no el contexto
[SISGC].
Jasper II permite la práctica de comunidades virtuales: cuando se recupera

un artefacto de Jasper II, se comparte el juicio de quien lo produjo. Es un
mecanismo que facilita reutilizar el conocimiento, permite entrar los
artefactos en comunidades y las subsecuentes anotaciones en ellos actúan
como un mecanismo de contexto. Actúa como
substrato para la evolución del conocimiento compartido, permite el

desarrollo de grupos de interés, tiene una serie de características que la
apoyan, como que la gente que usa el sistema se comunica más
fácilmente, el sistema permite contactar a personas que tengan recursos
de información en un área particular, las anotaciones se convierten en una
memoria de la comunidad. El sistema no captura conocimiento tácito, pero
genera un ambiente en donde esto es posible.

H. DIAMS
DIAMS es un sistema distribuido, diseñado para compartir información en la

Web. El sistema cuenta con múltiples agentes personales que ayudan a sus
dueños a encontrar la información más relevante de acuerdo a sus
necesidades. Mediante el uso de agentes los usuarios pueden acceder,
manejar, compartir e intercambiar información de alta calidad, bien
organizada en repositorios locales de acuerdo a necesidades particulares.
Los Agentes DIAMS se concentran en encontrar información relevante para
los usuarios, organizarla para pode acceder a ella en diferentes contextos y
la administran de manera que se pueda entender y así colaborar en
aprendizaje. Los agentes aprenden cual es la información relevante de
consultas exitosas. Las consultas permiten obtener información por
categorías o por palabras del índice.
Para el manejo de los repositorios de información DIAMS crea índices con

múltiples categorías que pueden estar en cualquier nivel de la jerarquía de
una colección. Esta jerarquía es flexible y se integra con una búsqueda
indexada de consultas para permitir un efectivo acceso a la información.
DIAMS usa los criterios de frecuencia de un término para darle un peso al
documento y la entropía como una medida de respaldo para la frecuencia.
Los repositorios de información están orientados por objetos, pero el
agente personal crea una vista virtual para que su dueño maneje los
repositorios de manera dinámica. El sistema DIAMS implementa un sistema
de apuntadores que se organizan localmente y permiten un rápido acceso
a la información que está organizada de acuerdo con el estándar de
metadata de la W3C Resource Description Framework. Con este sistema
de apuntadores los agentes automáticamente pueden indexar la
información recuperada y establecer conexiones entre los usuarios con
intereses y experiencias similares proporcionando los servicios necesarios
para que los usuarios aprendan y compartan información usando la Web y
las colecciones de URL’s personales de los usuarios. [SISGC]
I. El modelo KLC
Knowledge Liquidization & Crystallization (KLC) es un modelo de proceso

para la creación del conocimiento basado en los aspectos dinámicos del
conocimiento [14]. Es un sistema de representación de la información
recuperada de archivos multimedia de acuerdo al proceso cognitivo de las
personas.
El modelo KLC tiene un sistema llamado Knowledge Nebula Cristallizer,

KNC, para manejar archivos sin separarlos del contexto en el que se
generaron y crear conocimiento en el proceso de autoría. KNC, tiene un
repositorio llamado “Knowledge Nebula” este es una colección de pequeñas
piezas no estructuradas.
Las operaciones esenciales de KNC son cristalización y liquidación. En la

cristalización se seleccionan y estructuran piezas de información de acuerdo
con un contexto, como resultado se tiene un nuevo artefacto. En la

liquidación un artefacto es dividido en piezas que se adicionan a la

nebulosa. [SISGC]
KNC tienen dos componentes principales: Dynamic Concept Base (DCB) y la

interface, esta difiere en cada aplicación. DCB es un componente que realiza
la liquidación del conocimiento y realiza la cristalización, es decir, que
reestructura la relación entre las piezas de información, define
dinámicamente la similitud entre piezas de información y sus interacciones
en la nebulosa. KNC se usa para soportar procesos de composición basada
en tiempo como video clips y pieza musicales.
J. El Proyecto MDKT
El proyecto Management and Dissemination of Knowledge in

Telecommunication (MDKT) trabaja en el uso de ontologías para empresas
y dominios del conocimiento. El sistema integra el manejo y difusión de
documentos con la recuperación de información. Para esto hace uso de
agentes que buscan contribuir a una mejor personalización del
conocimiento a compartir teniendo en cuenta una adaptación de
contenidos.
Se apoya en herramientas de semántica Web para generar conocimiento

sobre el contexto en el cual actúan los agentes, aprovechando que el
funcionamiento de la semántica Web esta unido al acceso de
computadores a colecciones de información estructurada y conjuntos de
reglas de inferencia que conduzcan a un razonamiento automatizado. El
sistema define un lenguaje basado en XML para representar el
conocimiento que puede ser procesado por el computador y hace uso de
ontologías que describen el dominio del conocimiento, permiten producir
anotaciones semánticas en documentos Web y definen búsquedas que
tienen en cuenta las anotaciones.
La arquitectura del Sistema está conformada por herramientas de edición y

mantenimiento, servicios operacionales y un modelo del conocimiento que
está construido en tres capas, la primera es la capa de meta estructura que
define el "concepto". La segunda es la estructura que describe el
conocimiento e implementa las ontologías que son seis: PAT (Process,
Activity and Task), Dominio del conocimiento, Documentos, Competencias,
Empleados y Compañía, y los axiomas. La tercera es la capa de datos,
describe la compañía y sus empleados. Los conceptos y los recursos, como
Documentos HTML o PDF, entre otros, referencias a libros y a personas
expertas están en esta capa.
Para generar y utilizar el conocimiento generado con MDKT se usan tres

herramientas que son: 1) el modelo de competencias, que describe la
habilidad y experiencia de una persona a través de cuatro relaciones:
analogía, generalización, agregación y desviación. 2) el concepto de "Zone
of proximal development" que permite determinar la capacidad de una
persona para ser entrenada en un campo específico. 3) el Razonamiento
Semántico que se obtienen de las relaciones implícitas y explicitas entre
clases y entidades representadas en ontologías.

K. Acquisition Solution Knowledge Center
Acquisition Solution Knowledge Center, ASKC, es un sistema propietario,

construido como un marco para la convergencia del conocimiento. En él se
capturan tanto el conocimiento tácito proveniente de la experiencia de las
personas como el conocimiento explicito que se obtiene de la información.
El sistema permite tomar las mejores decisiones y proveer las mejores
soluciones para generar valor hacia empleados, clientes y la organización.
Este sistema tiene, cuatro características: 1) Procesos de aprendizaje:
Aprender de los pares con experiencia y compartir el conocimiento,
Aprender durante la realización de proyectos, aprender después, en
retrospectiva que se hizo bien y que se puede mejorar. 2) Comunidades de
práctica: grupos con intereses y objetivos comunes. 3) Activos de
conocimiento: repositorios de guías, listas de chequeo, prácticas efectivas,
índices electrónicos de bibliotecas y personas expertas. 4) Tecnología:
Infraestructura de IT.
El sistema tiene un Jefe de conocimiento (CKO, por su sigla en inglés). Este

a su vez tiene administradores de conocimiento. La captura y uso del
conocimiento adquirido se realiza principalmente en niveles operacionales.
El acceso se puede dar desde las unidades de negocio o desde afuera. Se
promociona el uso de herramientas de Gestión de Conocimiento (knowledge
Management) y se aseguran de capturar el conocimiento generado por las
unidades de negocio y compartirlo luego.
L. Meycor Cobit Suite.
Es una suite desarrollada por DATASEC, el software está formado por 5

módulos que permiten implementar y evaluar el buen gobierno de TI dentro
de una organización basado en Cobit 4.1:
• Meycor COBIT CSA (Control Self Assessment)

• Meycor COBIT MG (Management Guidelines)
• Meycor COBIT AG (Audit Guidelines)
• Meycor COBIT KP (Knowledge Provider)
• Meycor COBIT Delphos
La suite también incluye un Módulo Central (Meycor COBIT Route Finder)

que incluye una guía metodológica para implantar buen gobierno de TI
basado en el Roadmap de la segunda edición del IT Governance
Implementation Guide. [Meycor Isaca]
El módulo permite:
 Adaptar la guía metodológica de uso del producto e inclusive tener

varias guías.
 Acceder a los distintos módulos de la suite.
 Definir permisos de acceso a cada módulo.
 Mantener la base de conocimiento basada en COBIT.

 Realizar el mantenimiento de los centros de análisis.

 Ingresar información de los centros de análisis: organigrama,
procesos de negocio, objetivos de negocio, objetivos de TI y recursos
de TI.
 Generar mapas de calor por recursos de TI, criterios de información y
procesos de COBIT.
 Ver de forma centralizada los informes que han sido generados en
cada módulo de la suite.
 Ver de forma centralizada las recomendaciones que se generan en los
módulos Meycor COBIT CSA y Meycor COBIT MG.
 Organizar las recomendaciones en planes de acción.
 Controlar el avance de los planes de acción.
El módulo Meycor COBIT MG incluye cuestionarios que permiten sugerir el

nivel actual en el que se encuentra la organización de acuerdo a los niveles
del Modelo de Maduración, lo que facilita su evaluación.
Genera automáticamente las recomendaciones de las acciones que deberán
ser llevadas a cabo para lograr el nivel objetivo deseado, a las cuales
además se les puede asignar un importe numérico, que sirve para
cuantificarlas.
Las recomendaciones pueden ser agrupas en proyectos que facilitan la
administración y seguimiento del proceso de implementación de las
mismas.
Permite evaluar grandes corporaciones con recursos de TI distribuidos en

diferentes ubicaciones, a través de la creación de varios centros de análisis,
con la posibilidad de consolidar los resultados en forma global o local.
Permite una revisión periódica de la evolución de las decisiones efectuadas
por la Dirección a través de gráficas de comparación de los diagnósticos de
los diferentes períodos evaluados. [Meycor]
Funcionalidades
 El Modelo de Maduración.
 Acceso multi-usuario y sincronización de respuestas para
evaluaciones efectuadas fuera de línea (off-line).
 Gráficas de la evaluación del Modelo de Maduración, los Proyectos y
las Recomendaciones.
 Reportes detallados del Modelo de Maduración y los Proyectos en
formato RTF, XLS y HTML.
 Formularios para la evaluación del Modelo de Maduración en formato
HTML, que pueden ser evaluados en cualquier momento, enviados vía
e-mail al Administrador del producto y luego incorporados al
software.
 Ayuda en línea.
 El módulo utiliza Microsoft Access.

BENCHMARK
Benchmarking Marcos de Referencia para Auditoría de TI
Un marco de referencia consiste en un conjunto de recomendaciones,

procesos y controles aceptados en consenso, por expertos, para mejorar los
procesos de TI dentro de las organizaciones. A través de un marco de
referencia se obtiene la lista de niveles que debe alcanzar para considerar
que una organización otorga un servicio de calidad o que sus procesos
generan valor y mejora continua dentro de la empresa.
Los atributos que se usarán para el benchmark serán los siguientes:
 Adaptabilidad al tipo de organización auditada.

 Implementación del estándar.
 Función principal.
 Detalle para aplicación.
 Especializado en TI.
 Procesos o dominios abarcados.
Los acrónimos para identificar cada uno de los estándares evaluados:
 Modelo de Capacidad de Madurez CMMI (CM)

 ISO 27002 (ISO)
 Cobit 4.1 (CO)
 Information Technology Infrastructure Library (ITIL)
 PMBOK (PM)
Escala de evaluación de 1 (puntaje mínimo), 10 (puntaje máximo)

Categoría Indicadores CM ISO CO ITIL PM
Los procesos o recomendaciones del
Adaptabilidad al tipo
estándar deben ser adaptables y
de organización 6 7 7 6 9
representar la estructura de una
auditada.
organización en general.
La aplicación, recomendaciones y
Implementación del
actividades del estándar están orientadas 4 8 9 6 4
estándar.
a un proceso de auditoría.
El objetivo principal del estándar está
orientado a la mejora continua y
Función principal. evaluación de acuerdo a un conjunto de 7 8 10 7 6
niveles de referencia reconocidos
internacionalmente.
Nivel de detalle de las actividades y
Detalle para aplicación 8 9 7 8 7
tareas a auditar.
El estándar debe estar orientado al
Especializado en TI. gobierno de TI en sus diferentes 10 10 10 10 4
procesos.

Complejidad del estándar en relación a

los grupos o dominios que abarca el
Procesos o dominios
análisis, en especial si se orienta a toda la 5 5 8 5 8
abarcados.
organización y no solo a procesos
específicos.
Puntaje 40 47 51 42 38
Tabla 2. Estándares para el Gobierno de TI.
La elección de Cobit como marco de referencia para auditoría se debe a que

entre sus muchas características es un estándar completo de realiza un
análisis de todos los procesos de TI dentro de la organización además de su
interacción con las áreas más importantes como; dirección, gerencia,
soporte, servicios, etc. Además al ser Cobit un marco tan amplio, puede
incluir los estándares o marcos de trabajo mencionados y mapearlos en sus
grupos de procesos para obtener mayor detalle en las actividades que serán
auditadas.

Benchmarking Sistemas apoyo a la Auditoría y Sistemas Expertos.
Un sistema puede evaluarse de dos formas para comprobar que cumple sus
atributos de calidad:
 Atributos observables durante la ejecución:

o ¿Cómo se comporta el sistema durante la ejecución?
o ¿Entrega los resultados esperados?
o ¿Entrega información para planificación de la auditoría?
o ¿Cómo realiza el proceso de auditoría?
o ¿El proceso de auditoría está basado en un estándar
reconocido?
o ¿Entrega reportes?
 Atributos no observables en la ejecución:
o ¿Cuán fácil es aplicar y modificar el sistema?
o ¿El sistema es flexible e integrable con otros estándares
además del original?
o ¿Es un sistema experto o solo una aplicación de apoyo?
o ¿El diseño, arquitectura y base de conocimientos son
modificables?
Los atributos de calidad que se usarán para el benchmark son:
 Flexibilidad.
 Usabilidad.
 Funcionalidad.
 Adaptabilidad.
 Seguridad.
Los acrónimos para identificar cada una de los sistemas a evaluar son:
 Oracle Internal Controls Manager (OICM).

 Sistema Experto para Plantas Nucleares (SEP).
 Methodware Planning Advisor (PA).
 Sistema experto en el área de Auditoría y Seguridad de Información
(AUDES).
 Meycor Cobit MG (MG).
 Sistema de Apoyo al Proceso de Auditoría (SAPA) – Nuestra
solución.

Categoría Indicadores OIC SEP PA AUD MG SAPA

Atributos de Calidad
Flexibilidad Arquitectura del sistema simple y expandible. 1
Definición: Medida de la Capacidad para amoldarse a los requerimientos
1 1 1 1
capacidad del sistema de la organización.
para resistir los cambios o Capacidad de integración con otros sistemas de 1 1 1 1 1
actualizaciones para ser Capacidad del modelo de datos para soportar
adecuado a un propósito, modificaciones y nuevos procesos de auditoria 1 1
realizando el menor con el tiempo.
esfuerzo e impacto sobre
Adaptable y acoplable a diferentes estándares. 1 1 1
el software existente.
Puntaje 3 1 2 1 4 4
Usabilidad. Comprensibilidad 1 1 1 1 1
Definición: Es la facilidad Facilidad de aprendizaje 1 1 1 1
con que las personas capacidad del producto software para permitirle
1 1
pueden utilizar una al usuario su operación y control
herramienta de software Capacidad del software para ser agradable al 1 1 1 1 1
Eficiencia 1 1 1
Conformidad de uso. 1 1 1
Puntaje 3 3 3 3 5 5
Funcionalidad. Eficacia en la resolución de tareas. 1 1 1 1
Definición: Habilidad de Ejecución de las funciones solicitadas. 1 1 1
un sistema para hacer la Distribución adecuada de los módulos y
1 1 1 1
tarea para la cual fue funcionalidades del sistema.
creado. Exactitud en los resultados proporcionados por
1 1 1
el sistema.
Tiempo oportuno de respuesta a las funciones
1 1 1 1 1 1
solicitadas.
Puntaje 4 2 3 3 4 4
Adaptabilidad de la funcionalidad a los
1 1 1 1 1 1
Adaptabilidad. requerimientos del usuario.
Definición: Es la
capacidad del producto Capacidad de adquirir nuevo conocimiento a
1
software para adaptarse a partir de las auditorias
diferentes ambientes sin
aplicar acciones o medios
distintos a los ofrecidos Diseño de componentes integrables con nuevos
1 1 1
para este propósito por el módulos o funcionalidades
software considerado.
Puntaje 2 2 1 1 2 2
Registros de auditoría de accesos al sistema 1 1 1
Seguridad.
Definición: Medida de la
Seguridad de acceso a la base de datos 1 1 1
capacidad del sistema
para resistir intentos de Control de accesos por perfil 1 1 1 1 1
uso y negación de
servicios a usuarios no Impide impostor IP 1
autorizados sin restar
servicios a los usuarios Control de actualizaciones no autorizadas 1 1 1 1 1
autorizados. Puntaje 4 2 2 4 1 4
Tabla 3. Benchmarking de Sistemas de apoyo a la Auditoría.

CAPITULO IV
APORTE TEORICO
El desarrollo de un software de este tipo implica un estudio de la situación

actual de los procedimientos de auditoría y cómo las organizaciones están
afrontando los diferentes tipos de auditoría, cabe resaltar que los
estándares son un pieza importante para el desarrollo del proyecto pero no
clave, de todos los componentes involucrados el más importante será la
forma en que las empresas peruanas están adoptando el estándar para sus
organizaciones, esta realidad definirá los puntos clave para la evaluación de
una auditoria.
ESQUEMA DE EVALUACIÓN
Para el esquema de trabajo de auditoría se tomará cada objetivo de control

de cada Proceso de Cobit y se realizaran una serie de consultas destinadas
a evaluar ese objetivo.
Existen dos tipos de preguntas: de selección única y de selección múltiple.

En el caso de las preguntas de selección única: el valor de la pregunta
corresponderá al peso de la alternativa seleccionada. El peso de las
alternativas varía de 0 a 10, siendo 10 el valor de la alternativa “óptima” y
0 de la última alternativa. Existen algunas alternativas que permiten
“abrir” una o más preguntas del objetivo de control, estas alternativas no
tendrán un peso asignado, es decir su peso será cero, porque su peso final
corresponderá a los pesos alcanzados por todas las consultas que “abrió”
(sin importar si además cerro otras preguntas), esto se realizará de esta
manera debido a que este tipo de alternativas que abren preguntas no
tienen un valor en sí mismas sino que el valor se encuentra en el detalle de
las preguntas siguientes. Además las demás alternativas tendrán el peso
que les corresponde en la escala, por ejemplo si una pregunta tiene 6
alternativas (lo cual indica que en la escala las alternativas tendrán los
pesos 10, 8, 6, 4, 2 y 0), si la primera alternativa abre una o más preguntas
su peso será cero y las siguientes continúan teniendo el peso que les
corresponde (de la siguiente manera: 0, 8, 6, 4, 2, 0) solo para este tipo de
alternativas no se aplica en la pregunta la regla de escala de 0 a 10.
En el caso de las preguntas de selección múltiple: el valor de la
pregunta corresponde a la suma de los pesos de todas las alternativas
seleccionadas. El peso de cada alternativa es equivalente a: 10 ÷ Cantidad
de alternativas. En este tipo de preguntas incluyen una última alternativa
que será de valor 0 y si es seleccionada “cierra” todas las alternativas
anteriores y en algunos casos cierra algunas preguntas del objetivo de
control.
Cuando se resuelto todo el cuestionario de un objetivo de control, el

sistema indicará el resultado de la auditoría del objetivo de control
evaluado, mediante los siguientes componentes:

- Puntaje final: mostrará la suma de puntos obtenida después de la

auditoria de acuerdo al esquema de pesos asignado a cada una de las
alternativas.
- Los niveles de madurez: son 6 (obtenidos de acuerdo al
mecanismo de niveles de madurez de Cobit) y varían de 0 a 5. Cada
uno de estos niveles muestra el estado de cumplimiento de la
organización orientado al proceso y objetivos de control auditados.
- Recomendaciones: Se mostrará una lista de recomendaciones que
debe aplicar el área de TI o la empresa para alcanzar el siguiente
nivel de madurez o mantener el nivel alcanzado (para organizaciones
con niveles de madurez 4 o 5).
- Plan de Actividades: el plan de actividades es de apoyo para el
auditor, mediante él, el auditor encargado podrá validar si el nivel de
madurez obtenido mediante las encuestas es correcto y obtener un
nivel de madurez final. Mientras mayor sea el nivel de madurez
mostrado por el sistema, se mostrarán más actividades en el plan
debido a que el auditor debe realizar una validación más exhaustiva
por el alto puntaje alcanzado por la organización o área auditada.
El mecanismo de obtención del nivel de madurez se realizará de la siguiente

manera:
Variables
- Puntaje máximo.
- Puntaje mínimo.
El puntaje máximo y mínimo definirán el rango entre los cuales puede variar
el puntaje final que se puede obtener en una auditoría, luego todo ese
rango será divido en 6 intervalos:
Puntaje Mínimo Puntaje Máximo
Nivel 0 Nivel 1 Nivel 2 Nivel 3 nivel 4 Nivel 5
Nivel de madurez = Ubicación en el rango (Pesos por alternativa

seleccionada)

MODELO DE LA SOLUCIÓN
Si bien el análisis inicial de este proyecto es la utilización de COBIT para su

estudio y aplicación en el sistema, debemos tomar en cuenta que en un
proceso de auditoría se puede hacer uso de otros estándares para la
evaluación de procesos, es por esto que en este proyecto se plantea una
solución flexible que se pueda ajustar a la necesidad de los usuarios.
Los procesos de Cobit se pueden complementar mediante un mapeo de los

objetivos de control con las Guías de Implementación de ITIL y los
controles de ISO [Aligning Cobit], de esta manera el mecanismo de
cuestionarios se mejora soportado en base al detalle que tienen los
estándares mencionados y que en algunos casos no proporciona Cobit al ser
un margen tan genérico.
ISO COBIT ITIL
Dominios Libros
Áreas Procesos Tópicos
Controles Objetivo de Referencias

Control
Ilustración 14. Diagrama de alineamiento Cobit, ISO e ITIL
Entonces, el elemento nuclear de la evaluación en las auditorias tenemos a

los objetivos de control que como se explicó anteriormente, cuentan con un
puntaje que depende de las respuestas otorgadas en la encuesta realizada,
estos puntajes los sitúan en un nivel de madurez que dará como resultado
al usuario (auditor experto o usuario común) un plan de trabajo, que son
las actividades a realizar para la validación del resultado, así como también
recomendaciones a seguir para mejorar dichos niveles de madurez, estas
recomendaciones son aquellas existentes en los estándares dependiendo de
los resultados obtenidos.
Otra parte importante de este modelo son las actividades, las actividades a
realizar son aquellas tareas que el sistema escoge para organizar un plan de
trabajo para los usuarios, estas actividades son seleccionadas por el sistema
gracias al nivel de madurez obtenido tras las encuestas, pero también son
actividades que están relacionadas a cada objetivo de control, es así que si
en alguno de los procesos de auditoría se detecta la no necesidad de
realizar una encuesta y el plan de trabajo depende solo de validaciones de

los usuarios, estas actividades son entregadas al usuario como un plan de

actividades a realizar por defecto.
Nivel de
Madurez
Objetivo de Plan de
Control Trabajo
Actividades Recomenda
ciones
Ilustración 15. Esquema de resultados del sistema.
Posteriormente se mostrará la lista de cuestionarios para el caso práctico:

Caso de Auditoría de Seguridad de Información en base de datos, sin
embargo el siguiente modelo sólo es una referencia para el sistema de
demostración que será desarrollado, este esquema se puede extender y ser
aplicable a un caso de auditoría más complejo usando todos los procesos y
objetivos de Control de Cobit.

MAPA DE PROCESOS COBIT PARA BASE DE DATOS
PO Planear y Organizar
PO2 Definir la arquitectura de TI

PO2.1 Modelo de Arquitectura de información empresarial.
PO2.2 Diccionario de datos empresarial y reglas de sintaxis de datos
PO2.3 Esquema de clasificación de datos
PO2.4 IT Administración de la integridad
PO4 Definir los procesos, organización y relaciones de TI
PO4.6 Roles y responsabilidades
PO4.8 Responsabilidad sobre el riesgo, la seguridad y el cumplimiento
PO4.9 Propiedad de datos y de sistemas
PO4.11 Segregación de funciones
PO9 Evaluar y administrar los riesgos de TI
PO9.2 Establecimiento del contexto del riesgo
PO9.3 Identificación de eventos
PO9.4 IT Evaluación de riesgos
PO9.5 Respuesta a los riesgos
PO9.6 Mantenimiento y monitoreo de un plan de acción de riesgos
Tabla 4. Mapa de Procesos Cobit Planificar y Organizar

AI Adquirir e Implantar
AI1 Identificar soluciones automatizadas

Definición y Mantenimiento de los requerimientos técnicos y
AI1.1 funcionales del negocio
AI1.2 Reporte de Análisis de riesgos
AI1.4 Requerimientos, decisión de factibilidad y aprobación
AI2 Adquirir y mantener software aplicativo
AI2.3 Control y auditabilidad de las aplicaciones
AI2.4 Seguridad y disponibilidad de las aplicaciones
AI2.6 Actualizaciones importantes en sistemas existentes
AI2.8 Aseguramiento de la Calidad de Software
AI3 Adquirir y Mantener infraestructura tecnológica
AI3.1 Plan de adquisición de infraestructura tecnológica
AI3.2 Protección y disponibilidad del recurso de infraestructura
AI3.3 Mantenimiento de la Infraestructura
AI3.4 Ambiente de prueba de factibilidad
AI5 Adquirir Recursos de TI
AI5.4 Adicción de software
AI5.6 Adquisición de infraestructura, instalaciones y servicios relacionados
AI7 Instalar y acreditar soluciones y cambios
AI7.2 Plan de prueba
AI7.3 Plan de implantación
AI7.4 Ambiente de prueba
AI7.5 Conversión de sistema y datos
AI7.6 Prueba de cambios
AI7.7 Prueba final de aceptación
AI7.8 Transferencia producción
AI7.11 Registro y rastreo de cambios
AI7.12 Revisión posterior a la implantación
Tabla 5. Mapa de Procesos Cobit Adquirir e Implantar

DS Entregar y dar Soporte
DS4 Garantizar la continuidad de los servicios

DS4.1 IT Marco de trabajo de continuidad
DS4.2 Planes de continuidad de IT
DS4.3 Recursos de TI
DS4.4 Mantenimiento del plan de continuidad de TI
DS4.5 Pruebas del plan de continuidad de TI
DS4.6 Entrenamiento del plan de continuidad de TI
DS4.7 Distribución del plan de continuidad de TI
DS4.8 Recuperación y reanudación de los servicios de TI
DS4.9 Almacenamiento de respaldos fuera de las instalaciones
DS4.10 Revisión post-reanudación
DS5 Garantizar la seguridad de los sistemas
DS5.1 Administración de la seguridad de TI
DS5.2 Plan de seguridad de TI
DS5.3 Administración de Identidad
DS5.4 Administración de cuentas de usuario
DS5.5 Pruebas, vigilancia y monitoreo de Seguridad
DS5.6 Definición de incidente de seguridad
DS5.7 Protección de la tecnología de seguridad
DS5.11 Intercambio de datos sensitivos
DS10 Administración de problemas
DS10.1 Identificación y clasificación de problemas
DS10.2 Rastreo y resolución de problemas
DS10.3 Cierre de problemas
Integración de las administraciones de cambios,
DS10.4 configuraciones y problemas
DS11 Administración de la información
DS11.1 Requerimientos del negocio para la administración de datos
DS11.2 Acuerdos de almacenamiento y conservación
DS11.3 Sistema de administración de librerías de medios
DS11.4 Eliminación
DS11.5 Respaldo y restauración
DS11.6 Requerimientos de seguridad para la administración de datos
DS12 Administración del ambiente físico
DS12.1 Selección y diseño del centro de datos
DS12.2 Medidas de seguridad física
DS12.3 Acceso Físico
DS12.4 Protección contra factores ambientales
DS12.5 Administración de instalaciones físicas
Tabla 6. Mapa de Procesos Cobit Entregar y Dar Soporte

ME MONITOREAR Y EVALUAR
ME2 Monitorear y evaluar el control interno

ME2.1 Monitorear el marco de trabajo de control interno
ME2.2 Revisiones de auditoria
ME2.3 Excepciones de control
ME2.4 Auto-evaluación de control
ME2.5 Aseguramiento de control interno
ME2.7 Acciones correctivas
ME3 Garantizar el cumplimiento regulatorio
Identificar las leyes y regulaciones con impacto potencial sobre
ME3.1 TI
ME3.2 Optimizar la respuesta a requerimientos regulatorios
ME3.3 Evaluación del cumplimiento con requerimientos regulatorios
ME3.4 Aseguramiento positivo del cumplimiento
ME3.5 Reportes integrados
ME4 Proporcionar gobierno de TI
ME4.1 Establecer un marco de trabajo para gobierno de TI
ME4.4 Administración de recursos
ME4.5 Administración de riesgos
ME4.6 Medición del desempeño
Tabla 7. Mapa de procesos Cobit Monitorear y Evaluar

DETALLE DE PROCESOS DE EVALUACION
Todos los siguientes procedimientos de auditoría están basados en los

estándares de COBIT [COBIT 4, COBIT G, COBIT C, COBIT I] y en las
recomendaciones de las diferentes versiones de este estándar de auditoría.
Planificar y Organizar
PO2 Definir la Arquitectura de TI.
Objetivos Primarios
- Eficiencia
- Integridad
Objetivos secundarios
- Efectividad
- Confidencialidad
Lista de Objetivos que serán mostrados en el sistema (modificables)
OBJETIVOS/METAS DE LA AUDITORIA
Optimizar el uso de información
Tener en cuenta y proteger los activos de TI
Proteger el logro de los objetivos de TI
Establecer la claridad del impacto de negocio de los riesgos a los objetivos y Recursos de TI
Dar soporte efectivo a la administración de información
Agilizar la respuesta a los requerimientos, proporcionar información confiable y

consistente, para integrar de forma transparente las aplicaciones dentro de los procesos del
negocio
Tabla 8. Objetivos de la Auditoría para el Proceso PO2
Proceso de control: Definir la arquitectura de TI
Requisito de negocio cubierto: agilizar la respuesta a los requerimientos,

proporcionar información confiable y consistente, para integrar de forma
transparente las aplicaciones dentro de los procesos del negocio
Pasos para lograrlo:

- El aseguramiento de la exactitud de la arquitectura de la información y
del modelo de datos
- La asignación de propiedad de datos
- La clasificación de la información usando un esquema de clasificación
acordado
Variables de medición
- El porcentaje de elementos de datos redundantes / duplicados

- El porcentaje de aplicaciones que no cumplen con la arquitectura de la

información
- La frecuencia de actividades de validación de datos
Áreas del gobierno de TI:
Primarias
- Alineación estratégica
- Administración de recursos
Secundarias
- Entrega de valor
- Administración de riesgos
Recursos de TI
- Aplicaciones
- Información
Entradas
P01 - Planes estratégicos y tácticos de TI
AI1 - Estudio de factibilidad de requerimientos del negocio
AI7 - Revisión post-implantación
DS3 - Información de desempeño y capacidad
ME1 - Entrada de desempeño a planeación de TI
Salidas
Esquema de clasificación de datos (Salidas: AI2)
Plan de sistemas de negocio optimizado (Salidas: PO3, AI2)
Diccionario de datos (Salidas: AI2, DS11)
Arquitectura de información (Salidas: P03, DS5)
Clasificaciones asignadas de datos (Salidas: DS1, DS4, DS5, DS11, DS12)
Procedimientos y herramientas de clasificación (Salida externa a COBIT)
Ilustración 16. Matriz RACI Proceso PO2
PO2.1 Modelo de Arquitectura de Información empresarial.
Establecer y mantener un modelo de información empresarial que facilite el

desarrollo de aplicaciones y las actividades de soporte a la toma de
decisiones, consistente con los planes de TI como se describen en P01. El

modelo facilita la creación, uso y transferencia óptimas de la información

por parte del negocio de una manera que conserva la integridad y es
flexible, funcional, rentable oportuna segura y tolerante a fallas.
Reducido al entorno relacionado con una Base de Datos, se muestra la tabla

con la lista de consultas y el peso de cada una de las alternativas:
Enlazado con
PO2.1 Modelo de Arquitectura de Información empresarial. Peso la Pregunta
1 ¿La organización elabora un Modelo de Arquitectura de información?

abre todo
Si 0 menos 3 - 6
No 0 cierra todo
¿La elaboración de este Modelo está a cargo de una persona o equipo
2 de personas? 3-6 , 8
Un equipo con mayoría de miembros especializados en el tema (más Abre: 4-6.
del 50%) 0 cierra:3
Un equipo con pocos miembros especializados en el tema (menos del Abre: 4-6.
50%) 0 cierra:3
Abre: 3 -
Una persona, especialista en arquitectura (con un cargo especifico) 0 cierra: 4-6
abre: 3 - cierra:
Una persona, no especialista (con un cargo especifico) 0 4-7
abre: 3 - cierra:
Una persona, especialista en arquitectura (sin cargo especifico definido) 0 4-8
abre: 3 - cierra:
Una persona, no especialista (sin cargo especifico definido) 0 4-9
No definido 0 cierra: 3-6,8
De ser una Persona: ¿Cuál es el rol o puesto de la persona encargada de
3 elaborar el Modelo de Arquitectura de Información? cierra 5
Arquitecto de TI 10
Especialista de TI 8.5
Jefe de sistemas 7
Jefe de proyecto (puesto permanente) 5.5
Jefe de proyecto (puesto temporal) 4
Analista de Sistemas 2.5
Desarrollador 1
Otro 0
4 De ser un equipo: ¿Por cuantas personas está formado este equipo?
más de 4 10
4 7
3 4
2 0
5 ¿Cuál es el rol o puesto del líder del equipo?
Arquitecto de TI 10
Especialista de TI 8.5
Jefe de sistemas 7
Jefe de proyecto (puesto permanente) 5.5

Jefe de proyecto (puesto temporal) 4

Desarrollador 1
Otro 0
6 ¿El equipo de arquitectura de TI es permanente o temporal?
Permanente 10
Temporal: se Reúnen para procesos de evaluación 6.65
Temporal: se reúnen por requerimiento de la Dirección/Gerencia u otra
área. 3.3
No está especificado 0
¿Cada cuanto tiempo se actualiza este Modelo de Arquitectura de
7 información?
Frecuentemente, con periodicidad (cada semana –mes) 10
Frecuente, con periodicidad (cada mes – tres meses) 8.625
Poco frecuente, con periodicidad ( cada tres meses –seis meses) 7.25
Escasamente frecuente, con periodicidad (seis meses – Anualmente) 6.875
Muy Frecuente, sin periodicidad (semana –mes) 5.5
Frecuente, sin periodicidad (mes – tres meses) 4.125
Poco frecuente, sin periodicidad (tres meses –seis meses) 2.75
Escasamente frecuente, sin periodicidad (meses – Anualmente) 1.375
No es frecuente (0) 0
¿Cuál es el lapso de tiempo que utiliza la persona o equipo de personas
8 encargados de elaborar este Modelo?
Una semana – un mes (definido en un cronograma o documento) 10
Un mes – tres meses (definido en un cronograma o documento) 8.75
Tres meses – seis meses (definido en un cronograma o documento) 7.50
Seis meses – un año (definido en un cronograma o documento) 6.25
Una semana – un mes (sin cronograma o documento especifico) 5.00
Un mes – tres meses (sin cronograma o documento especifico) 3.75
Tres meses – seis meses (sin cronograma o documento especifico) 2.50
Seis meses – un año (sin cronograma o documento especifico) 1.25
No hay tiempo definido (no está documentado o no ha sido
identificado) 0
¿La estructura de este Modelo es elaborada mediante una plantilla
9 estandarizada por la organización?
Si, en su totalidad (100%-80%) 10
Si, se ajusta a la plantilla (80%-60%) 7.5
Sí, pero se permite cambiar la estructura (60%-40%) 5
Sí, pero se ajusta muy poco a la plantilla indicada (40%-20%) 2.5
No, es elaborada a criterio del equipo (20%-0%) 0
¿Este Modelo de Arquitectura es consultado de forma constante por el
10 personal de TI encargado de las aplicaciones de Base de Datos?
Si, es el documento único de referencia 10
Sí, pero hay otros documentos o criterios que son usados 6.65
No, se consulta el criterio de desarrollo interno (del personal) 3.3
No es usado 0
11 ¿Este documento es entregado en sus diferentes versiones de forma

oportuna a los interesados?

¿Existe algún mecanismo de restricción de acceso a este documento? (o
12 puede ser accedido de forma pública)
Si, usuarios y contraseñas 10
Si, privilegios de acceso 6.65
Si, red interna 3.3
No es protegido 0
¿El Modelo de Arquitectura contiene información acerca de los
13 procesos de soporte para Base de Datos?
Si, contiene todos los procesos de soporte (100%-80%) 10
Si, contiene los procesos de soporte (80%-60%) 7.5
Sí, pero está parcialmente identificado (60%-40%) 5
Si, escasamente definido (40%-20%) 2.5
No está identificado (20%-0%) 0
¿El Modelo contiene información acerca de la Arquitectura de Base de
14 Datos actual?
Si, está representada en su totalidad (100%-80%) 10
Si, está representada (80%-60%) 7.5
Sí, pero está parcialmente representada (60%-40%) 5
Si, escasamente representada (40%-20%) 2.5
¿El Modelo contiene información acerca de la tendencia o
15 modificaciones a la Arquitectura actual de Base de Datos?
Si, contiene toda la información e indicadores necesarios (100%-80%) 10
Si, contiene la información necesaria (80%-60%) 7.5
¿El Modelo contiene información acerca de planes o tareas de
16 seguridad para la Base de Datos?
Si, contiene toda la información e indicadores necesarios (100%-80%) 10
Si, contiene la información necesaria (80%-60%) 7.5
¿El Modelo contiene información acerca de planes de
17 contingencia/continuidad de negocio para Base de Datos?
Si, contiene todos los planes necesarios (100%-80%) 10

Si, contiene los planes necesarios (80%-60%) 7.5

¿El Modelo contiene información acerca de planes de alta
18 disponibilidad para Base de Datos?
Si, contiene todos los planes necesarios (100%-80%) 10
Si, contiene los planes necesarios (80%-60%) 7.5
¿El Modelo contiene información acerca de estándares de rendimiento
19 para Base de Datos?
Si, contiene todos los indicadores necesarios (100%-80%) 10
Si, contiene los indicadores necesarios (80%-60%) 7.5
Sí, pero están parcialmente definidos (60%-40%) 5
No está definido (20%-0%) 0
¿El Modelo contiene requerimientos mínimos acerca de normalización
20 de modelos de datos?
Si, contiene todos los requerimientos necesarios (100%-80%) 10
Si, contiene los requerimientos necesarios (80%-60%) 7.5
¿El Diagrama de datos actual cumple con las especificaciones
21 planteadas en el Modelo de Arquitectura de información?
Si, cumple totalmente (100%-80%) 10
Si, cumple con las especificaciones (80%-60%) 7.5
Sí, pero cumple de forma parcial (60%-40%) 5
No cumple con las especificaciones (20%-0%) 0
Tabla 9. Tabla de Consultas Objetivo de Control: PO2.1

Salidas
Nivel 0 No existe conciencia de la importancia de la arquitectura de información para la organización.
La gerencia reconoce la necesidad de una arquitectura de información. El desarrollo de los componentes de una
Nivel 1 arquitectura de información ocurre de manera ad hoc.
Surge un proceso de arquitectura de información y existen procedimientos similares, aunque intuitivos e informales,
que se siguen por distintos individuos dentro de la organización. Las personas obtienen sus habilidades al construir la
Nivel 2 arquitectura de información por medio de experiencia práctica y la aplicación repetida de técnicas.
La importancia del modelo de arquitectura se entiende y se acepta, y la responsabilidad de su aplicación se asigna y se
comunica de forma clara. Los procedimientos, herramientas y técnicas relacionados, aunque no son sofisticados, se han
estandarizado y documentado. Se han desarrollado políticas básicas de arquitectura de información, incluyendo algunos
requerimientos estratégicos, aunque el cumplimiento de políticas y herramientas no se refuerza de manera
Nivel 3 consistente.
Se da soporte completo al desarrollo e implantación de la arquitectura de información por medio de métodos y técnicas
formales. La responsabilidad sobre el desempeño del proceso de desarrollo de la arquitectura se refuerza y se mide el
Nivel 4 éxito de la arquitectura de información. El proceso de definición de arquitectura de información es proactivo.
El valor del modelo de arquitectura de la información para el negocio se enfatiza de forma continua. El personal de TI
cuenta con la experiencia y las habilidades necesarias para desarrollar y dar mantenimiento a una arquitectura de
Nivel 5 información robusta. La arquitectura de la información se encuentra en un proceso de mejora continua.
Tabla 10. Niveles de Madurez para el Objetivo de Control PO2.1
Plan de Actividades y Recomendaciones

Nivel Recomendaciones
Nivel 0
Identificar las actividades e información requeridos para la creación del documento de
No se realizan validaciones adicionales a las consultas arquitectura de TI
del sistema Asignar roles y/o personal asociado con la creación del documento de Arquitectura de TI
Alinear el documento a los requerimientos estratégicos de la organización
Nivel 1
Validar la existencia del documento de arquitectura de TI

Incrementar la frecuencia de actualización de los documentos de Arquitectura de TI
Validar que se realicen reuniones esporádicas para la
definicion del Plan de Arquitectura de TI Asignar los roles o personas para la creacion de los documentos.
Validar que existe comunicación entre el área de TI y el Mantener la consistencia entre documentos y arquitectura actual de TI
equipo de decisión de la empresa para elaborar el
modelo de arquitectura
Nivel 2
Validar que existe comunicación entre el área de TI y el

equipo de decisión de la empresa para elaborar el Definir y comunicar procesos, metas y objetivos específicos, medibles, accionables, reales,
modelo de arquitectura orientados a resultado y en tiempo para la ejecución efectiva de cada proceso de TI. Asegurando
que están enlazados a las metas de negocio y se soportan por métricas adecuadas
Validar la frecuencia con que se realizan las reuniones Mantener la consistencia entre documentos y arquitectura actual de TI
de definicion o actualización de la arquitectura de TI.
Validar que se realicen actualizaciones al documento de
definición de la arquitectura de TI, por solicitud de la
jefatura/gerencia.


Nivel 3
Validar la consistencia entre los documentos de
integridad de información y las actividades realizadas
por el personal de TI Mantener la consistencia entre documentos y arquitectura actual de TI
Validar que existan modelos de referencia para la Diseñar y establecer cada proceso clave de TI de tal manera que sea repetible y consecuentemente
arquitectura, definición de datos. produzca los resultados esperados. Proveer una secuencia lógica pero flexible y escalable de
actividades que lleve a los resultados deseados y que sea lo suficientemente ágil para manejar las
excepciones y emergencias. Usar procesos consistentes, cuando sea posible, y ajustarlos sólo
cuando no se pueda evitar.
Validar que se aplican de forma adecuada y constante Enfatizar el uso de políticas y estandares para la arquitectura de TI como generador de valor dentro
las indicaciones del documento de arquitectura de de la organización.
información
Validar la consistencia entre el modelo de TI y la
arquitectura existente en la organización
Validar que existe personal de TI asignado y capacitado
para la documentacion de la arquitectura.
Validar que el modelo de arquitectura de TI es

entregados de forma oportuna a los interesados.
Validar la existencia de políticas básicas de arquitectura

de información
Nivel 4
Validar que el cumplimiento de políticas, estándares y el

uso de herramientas se refuerza de manera constante.
Mantener de forma continua el documento y el diseño de la arquitectura de TI.
Validar que el proceso de aplicación del modelo de
arquitectura de TI es medible y se realiza de manera
constante. Mantener la consistencia entre documentos y arquitectura actual de TI
Validar la frecuencia de las reuniones de definición o Enfatizar el uso de políticas y estandares para la arquitectura de TI como generador de valor dentro
actualización del modelo de arquitectura de TI de la organización.
Validar la existencia de las políticas de arquitectura de
información
Validar que el proceso de definición y actualización de la
arquitectura de infrmación se realiza de manera
continua y proactiva.
Validar la existencia de métricas o variable de medición
para el cumplimiento de las políticas o recomendaciones
indicadas en el modelo de arquitectura de información
Validar que el uso del plan de arquitectura de TI agiliza

la comunicación entre el personal de sistemas y la
direccion de la organización para la inserción de nuevos
sistemas en la arquitectura
Nivel 5
Validar la exactitud entre la arquitectura de información
y del modelo de datos
Validar la frecuencia de actualización del modelo
evaluado.
arquitectura y los procesos ejecutados por el personal de
TI.
Validar que se realiza un proceso de mejora continua
para el cumplimiento de las políticas o recomendaciones Mantener de forma continua el documento y el diseño de la arquitectura de TI.
indicadas en el modelo de arquitectura de información
Validar el rol del personal encargado de elaborar o
actualizar el modelo de arquitectura de TI
Validar que el uso del plan de arquitectura de TI agiliza

la comunicación entre el personal de sistemas y la
direccion de la organización para la inserción de nuevos
sistemas en la arquitectura.
Tabla 11. Plan de Actividades y Recomendaciones para el Objetivo de

Control P2.1


Mantener un diccionario de datos empresarial que incluya las reglas de
sintaxis de datos de la organización. El diccionario facilita la compartición de
elementos de datos entre las aplicaciones y los sistemas, fomenta un
entendimiento común de datos entre los usuarios de TI y del negocio, y
previene la creación de elementos de datos incompatibles.
Enlazado con
PO2.2 Diccionario de datos empresarial y reglas de sintaxis de datos Peso la pregunta
1 ¿La organización cuenta con un Diccionario de datos empresarial?
abre: 2-8 , 9
siempre se
Si cuenta con un diccionario de datos 0 muestra
cierra 2-8,
No cuenta con un diccionario de datos 0 directo a la 9
¿Cuál es el rol de la persona o equipo encargados de crear/modificar
2 el diccionario de datos?
Jefe de TI 10
Arquitecto de Sistemas 8.3
Oficial de Seguridad (analista de seguridad de Información) 6.6
DBA 4.9
Desarrollador 1.5
Otro rol interno 0
¿Cada cuanto tiempo se realiza un proceso de actualización del
3 Diccionario de datos?
¿El diccionario de Datos de la organización es un documento válido
4 para el personal encargado de la(s) Base(s) de Datos?
Si, es útil en su totalidad (100%-80%) 10
Si, es útil (80%-60%) 7.5
Parcialmente es útil (60%-40%) 5
Escasamente útil (40%-20%) 2.5
No es útil (20%-0%) 0
¿Se realiza un proceso de verificación/control de calidad del
5 diccionario elaborado/modificado?
Si se ejecuta un proceso optimo de control de calidad 10
Se ejecuta un proceso de control de calidad 7
Se realiza un proceso mínimo de control de calidad 4

No se efectúa un proceso de control de calidad 0

¿El diccionario de datos es presentado de forma oportuna al personal
6 que ejecuta trabajos sobre el (los) servidores de Base de Datos?
¿La información contenida en el Diccionario de datos es consistente
con la realidad actual de los modelos de Datos manejados en los
7 servidores de producción?
Si, se ajusta a la realidad (80%-60%) 7.5
Si, parcialmente (60%-40%) 5
Sí, pero de forma muy escasa (40%-20%) 2.5
No, es muy diferente (20%-0%) 0
¿El diccionario contiene definiciones de todos los datos existentes en
8 los servidores?
Si, se ajusta la mayoría de datos (80%-60%) 7.5
Sí, pero de forma muy parcial (60%-40%) 5
9 ¿La organización cuenta con reglas de sintaxis de datos?
Si cuenta con reglas de sintaxis 0 abre: 10 - 15
No 0 cierra: 10 - 15
¿Cuál es el rol de la persona o líder del equipo encargado(s) de
10 crear/modificar las reglas de sintaxis de datos?
Jefe de TI 10
Arquitecto de Sistemas 8
DBA 6
Analista de Sistemas 4
Desarrollador 2
Otro. 0
¿Las reglas de sintaxis de la organización son un documento útil para
11 el personal encargado de la(s) Base(s) de Datos?
Si, es útil (80%-60%) 7.5
Es parcialmente es útil (60%-40%) 5
Escasamente útil (40%-20%) 2.5
No es útil (20%-0%) 0
¿Se realiza un proceso de verificación/control de calidad de reglas de
12 sintaxis elaboradas/modificadas?

Si se ejecuta un proceso optimo de control de calidad 10

Se ejecuta un proceso de control de calidad 7
Se realiza un proceso mínimo de control de calidad 4
No se efectúa un proceso de control de calidad 0
¿Las reglas de sintaxis de datos son presentadas de forma oportuna al
personal que ejecuta trabajos sobre el (los) servidores de Base de
13 Datos?
14 ¿Las reglas definidas siguen estructuras consistentes?
Si, cumple con las reglas de consistencia (80%-60%) 7.5
Si, parcialmente consistente (60%-40%) 5
Si, poco consistente (40%-20%) 2.5
No, carece de consistencia (20%-0%) 0
¿En la práctica, existe correspondencia entre las reglas de sintaxis de
datos definidas y los datos contenidos en el(los) repositorio(s) de
15 Base(s) de Datos?
Si, se ajusta la mayoría de datos (80%-60%) 7.5
Sí, pero de forma muy parcial (60%-40%) 5
Tabla 12. Tabla de consultas Objetivo de Control: PO2.2

Salidas

Nivel 0 No existe conciencia de la importancia del diccionario de datos empresarial para la organización.
Las definiciones del diccionario empresarial abarcan datos en lugar de información. Se reconoce la existencia de reglas
Nivel 1 de sintaxis de datos.
Existe un proceso de definición del diccionario de datos el cual se ejecuta de manera intuitiva e informal , es realizada
Nivel 2 por individuos sin un rol específico dentro de la organización.
Se cuenta con un modelo de datos empresarial el cual es elaborado por un responsable con los conocimientos
Nivel 3 necesarios, el documento actualizado y se reconoce la necesidad de realizarlo de forma continua.
El responsable de crear el diccionario de datos y las definiciones tiene un rol asociado con la tareas que realiza. El
proceso de actualización del diccionario y las reglas de sintaxis de datos se realiza de manera continua, es evaluado de
Nivel 4 acuerdo a la reglas de calidad de la organización.
Se reconoce la creación de un dicccionario de datos como un documento que genera valor y aporta a la arquitectura de
TI .El documento y actualizado de forma proactiva, es validado de acuerdo a las reglas de calidad y estandares de la
Nivel 5 organización. El documento representa de forma completa el estado real de la información de TI

Nivel 0
Identificar las actividades e información requeridos para la creación del diccionario de Datos
empresarial
No se realizan validaciones adicionales a las consultas
Asignar roles y/o personal asociado con la creación del diccionario de datos empresarial
del sistema
Identificar los elementos que deben ser incluidos en el Diccionario de datos
Identificar la necesidad de un diccionario de datos empresarial y las reglas de sintaxis de datos
Nivel 1
Validar la existencia del Diccionario de datos
empresarial Mantener el diccionario de datos y las reglas de maneara mas continúa
Validar que existe comunicación entre los involucrados y
el personal clave para la elaboración del diccionario de
datos. Asignar roles y/o personal asociado con la creación del diccionario de datos empresarial
Validar que se realicen reuniones esporádicas para la Identificar la importancia del diccionario de datos como un elemento generador de valor.
definición del Diccionario de Datos
Nivel 2
Validar que existe comunicación entre el área de TI y el Definir y comunicar procesos, metas y objetivos específicos, medibles, accionables, reales,
equipo de decisión de la empresa para la definición del orientados a resultado y en tiempo para la ejecución efectiva de cada proceso de TI. Asegurando
diccionario de datos que están enlazados a las metas de negocio y se soportan por métricas adecuadas
Validar que existe un documento de definición del Mantener la consistencia entre documentos y las reglas de sintaxis existentes.
Diccionario de datos
Validar que el documento es actualizado o mejorado.
Nivel 3
Validar la consistencia entre el diccionario de datos y Diseñar un proceso estandarizado de definición de datos y reglas de sintaxis . Evaluar la asignación
las entidades que forman parte del sistema. de una persona o equipo encargados del objetivo y de su mejora.
Definir un modelo estandarizado y frecuente para representar los cambios en el ambiente real.
Validar que existan modelos de referencia para la

definición del diccionario y las reglas de sintaxis de
datos.
Validar que existe personal de TI asignado y capacitado

para la documentacion del modelo de definición de
datos.
Validar que los documentos de referencia de TI son
entregados de forma oportuna a los interesados
Validar la frecuencia de las reuniones de definición o
actualización de los documentos de referencia de TI


Nivel 4
Enfatizar el uso de políticas y estandares para la generación de valor del proceso de definición de
datos.
Validar que el proceso de definición y actualización de la Mantener de forma continua la definición del diccionario y reglas de sintaxis para mantener la
arquitectura de infrmación se realiza de manera consistencia con el sistema de base de datos.
indicadas en el plan de arquitectura de información
Asegurar que la información se retiene a aquellos que no
tienen acceso.
Validar que el uso de las reglas de sintaxis de datos
permite mantener un estandar en los sistemas de TI y por
lo tanto agilizan la curva de aprendizaje y la integración.
Nivel 5
Validar que el esquema de clasificacion de datos use un
esquema de clasificacion adecuado: Estandar / acordado
en la organización.
Validar la consistencia entre el diccionario de datos y
las reglas de sintaxis vs. La información y funcionalidad Mantener de forma continua la definición del diccionario y reglas de sintaxis para mantener la
en el sistema de base de datos. consistencia con el sistema de base de datos.
tienen acceso.
Control PO2.2


Establecer un esquema de clasificación que aplique a toda la empresa,
basado en que tan crítica y sensible es la información (esto es, pública,
confidencial, secreta) de la empresa. Este esquema incluye detalles acerca
de la propiedad de datos, la definición de niveles apropiados de seguridad y
de controles de protección, y una breve descripción de los requerimientos
de retención y destrucción de datos, además de qué tan críticos y sensibles
son. Se usa como base para aplicar controles como el control de acceso,
archivo o encriptación.
Enlaza con
PO2.3 Esquema de clasificación de datos Peso Pregunta
1 ¿La organización cuenta con Esquemas de clasificación de datos?
Si 0 abre: 2- 7
No 0 cierra: 2- 7
¿El Esquema de clasificación de datos cuenta con reglas/sugerencias
2 para controlar y proteger la información clasificada?
Si cuenta con reglas 10
No tiene reglas definidas 0
¿Cuál es el rol de la persona o equipo encargados de crear/modificar los
3 esquemas de clasificación de datos?
Jefe de TI 10
Oficial de Seguridad (analista de seguridad de Información) 8.3
Arquitecto de sistemas 6.6
DBA 4.9
Desarrollador 1.5
Otro rol interno 0
¿Los esquemas de clasificación de datos de la organización son un
4 documento útil para el personal encargado de la(s) Base(s) de Datos?
Si, es útil (80%-60%) 7.5
Si, es parcialmente es útil (60%-40%) 5
Se, escasamente útil (40%-20%) 2.5
No es útil (20%-0%) 0
¿El esquema definido por la organización sigue un estándar de la
5 industria?
Si, un estándar internacional 10
Si, un estándar interno 5
No sigue un estándar especifico 0
¿Con que frecuencia se actualizan los Esquemas de clasificación de
6 datos?


¿Estos esquemas son compartidos de forma oportuna con el personal
7 de TI que interactúa con servidores de Base de Datos?

Salidas
Nivel 0 No existe conciencia de la importancia de la clasificación de datos para la organización
La organización reconoce la utilidad de la clasificación de la información en la organización .La clasificación de datos es

Nivel 1 realizado por personal con poca experiencia. El esquema no refleja la clasificacion real de los datos en el área de TI.
La organización reconoce tiene un esquema de clasificación de datos realizado de forma intuitiva e informal por
Nivel 2 personal no especializado . El esquema de clasificación es compartido con el personal involucrado.
La organización reconoce y utiliza el esquema como un modelo de referencia para la información que maneja. El
Nivel 3 esquema de clasificacion de datos es compartido de forma oportuna con el personal.
La clasificación de datos se realiza de acuerdo a un essquema aceptado por la industria. Las actualizaciones son
realizadas de manera continua por una persona o equipo con los conocimientos necesarios para la tarea. Se reconoce la
Nivel 4 necesidad de comunicar el esquema a los involucrados.
La clasificación de datos es realizada por personal idóneo en la organización .Se comuncian las actualizaciones y mejoras
del esquema de clasificación a los interesados de forma proactiva. La organización identifica la necesidad de clasificar la
Nivel 5 información y mantenerla restringida a los interesados.


Nivel 0
Identificar las actividades e información requeridos para la creación de un esquema de
clasificación de datos
Identificar la importacia de definir una escala de clasificación de información como un mecanismo
No se realizan validaciones adicionales a las consultas de control para la entrega de datos no autorizada.
del sistema Asignar los roles asociados a la definición del esquema de clasificación
Nivel 1
Validar que el área de TI reconoce la importancia de
definir un esquema de clasificación de datos Aplicar los controles de acuerdo a la clasificación definida.
Validar la existencia de un esquema de clasificación de Asignar los roles asociados a la definición del esquema de clasificación
datos
Validar que existan procedimientos de manejo de la
clasificacion de información
Validar que existe comunicación entre el área de TI y el
equipo de decisión de la empresa para la definición del
esquema de clasificación
Nivel 2
Validar la frecuencia con que se realizan las reuniones
para actualizar y validar la aplicación del esquema de Mantener la consistencia entre el esquema de clasificación aprobado por el área de TI y el aplicado
clasificación de datos. para el SGBD.
Definir un proceso estandarizado de clasificación de información el cual debe ser comunicado al
Validar que se actualiza el esquema de clasificación de
personal de TI que interactúe con la Base de Datos.
datos, por solicitud de la jefatura/gerencia.
Nivel 3
Validar la aplicación del esquema de control de Mantener la consistencia entre el esquema de clasificación aprobado por el área de TI y el aplicado
información para el SGBD.
Validar el personal o equipo encargado de establecer el Enfatizar el uso de esquemas de información como un control de la información crítica dentro de la
esquema de información y validarlo. base de datos.
Validar que el esquema y sus actualizaciones son
compartidos de forma oportuna con los interesados.
Nivel 4
Validar que se utiliza un esquema de clasficación
respaldado por un estándar internacional. Enfatizar el uso de esquemas de clasificación de datos estándar.
Asegurar que la información se retiene a aquellos que no Mantener y validar de forma continua el cumplimiento del esquema de clasificación.
tienen acceso.
Validar que el uso del del esquema de clasificación como
herramienta de control para la entrega de información en
el servidor de Base de Datos.
Validar la ultilidad del esquema de clasificación
Validar la frecuencia de actualización o validación del
esquema de clasificación.
Nivel 5
Identificar propietarios de datos Mantener y validar de forma continua el cumplimiento del esquema de clasificación.
Validar que el esquema de clasificacion de datos use un
esquema de clasificacion adecuado: Estandar / acordado
en la organización.
tienen acceso.
Validar que se brinde información confiable, útil y
consistente para la aplicación del esquema de
clasificación.
Control PO2.3


Definir e implantar procedimientos para garantizar la integridad y
consistencia de todos los datos almacenados en formato electrónico, tales
como bases de datos, almacenes de datos y archivos.
Enlaza con
PO2.4 IT Administración de la integridad Peso Pregunta
¿Los procedimientos de administración de integridad se encuentran
1 definidos y documentados?
Plan definido, documentado (100%-80%) 0 abre: 2-7
Plan parcialmente definido, documentado (80%-60%) 0 abre: 2-7
Plan definido, no documentado (60%-40%) 5 cierra: 2 - 7
Plan parcialmente definido, no documentado (40%-20%) 2.5 cierra: 2 - 7
El plan no está definido (20%-0%) 0 cierra: 2 - 7
¿Los procedimientos de integridad contienen información importante
2 para el personal de TI que usa el servidor de Base de Datos?
Si incluye (80%-60%) 7.5
Sí, pero es muy escasa la información (40%-20%) 2.5
No incluye (20%-0%) 0
¿Los procedimientos de administración de integridad siguen un
3 estándar de la organización?
Si, se ajusta a la plantilla (80%-60%) 7.5
¿Los procesos de validación de datos utilizados en el servidor cumplen
4 el estándar establecido?
Si, se ajusta al estándar (80%-60%) 7.5
Sí, pero parcialmente (60%-40%) 5
Sí, pero se ajusta muy poco al estándar (40%-20%) 2.5
No, no se ajusta al estándar (20%-0%) 0
¿Existe(n) un procedimiento(s) para garantizar la consistencia de los
5 datos del servidor?
Si, está definido y documentado (100%-80%) 10
Si, está definido pero no documentado (80%-60%) 7.5
Parcialmente definido, documentado (60%-40%) 5
Parcialmente definido, no documentado (40%-20%) 2.5
El procedimiento no está definido (20%-0%) 0
¿Cada cuanto tiempo se actualizan los procedimientos de
6 administración de integridad?

¿El documento es entregado/actualizado de forma oportuna para su
7 uso cotidiano?

Salidas

Nivel 0 No existe conciencia de la importancia de la administración de Tecnología de Información para la organización
El plan de administración de integridad se encuentra definido de forma intuitiva. No existe documentación o esta no
Nivel 1 es consistente con la información que existe en el servidor de base de datos.
El plan de administración de integridad se encuentra definido dentro de forma intuitiva. Existe documentación y esta es
Nivel 2 creada o actualizada por personal con poca experiencia o con habilidades diferentes a las requeridas.
Se reconoce la utilidad de la administración de integridad, la cual se realiza de manera continua. El proceso de
administración estandarizado de acuerdo a un modelo de referencia. El personal encargado de realizar el proceso
Nivel 3 obtiene sus habilidades de la ejecución continua.
La administración de integridad es documentada y actualizada de forma continua por personal asignado

especificacmente para la tarea. El plan de administración es documentado basado en una plantilla de referencia.
Nivel 4 Existen procedimientos y técnicas para mantener la consistencia de la información documentada y la actual.
La administración de la integridad de la información es documentada y mantenida de forma continua, se maneja un
estándar de referencia óptimo. El personal de TI encargado de la administración es personal cuenta con la experiencia
Nivel 5 requerida para realizar la tarea.


Nivel 0
Identificar la necesidad de administrar la integridad y consistencia de los datos almacenados en el

servidor
No se realizan validaciones adicionales a las consultas
Identificar el rol que será encargado de ejecutar el proceso de administración
del sistema
Nivel 1
Validar que existan procedimientos de manejo de Definir el proceso de administración de integridad y aplicarlo. Asignar el rol encargado de la tarea
integridad de datos de administración.
Validar que existe comunicación entre el área de TI y el Aplicar y documentar los procesos de administración de integridad y consistencia de datos.
equipo de decisión de la empresa para la definición
inicial del proceso de administración de integridad.
Validar que se reonoce la necesidad de administrar la
integridad de las TI.
Nivel 2
Validar el mantenimiento de la integridad de los datos,
por solicitud de la jefatura/gerencia. Incrementar la frecuencia de ejecucion del proceso de control y administración de integridad.
Validar el procedimiento de control y consistencia de Especializar y capacitar al personal encargado de la tarea. Establecer un documento o plantilla de
datos en el servidor. referencia interna para el control de la consistencia de datos en el Servidor.
Validar el rol del personal encargado de administrar la
integridad y validar las recomendaciones.
Nivel 3
Definir un proceso estándar para el proceso de administración de integridad. Identificar la
importancia de su aplicación y actualización. Indentificar el rol encarga de la ejecución,
Validar la consistencia entre los documentos de actualización y mejora del proceso de administración de integridad.
por el personal de TI
Validar que los documentos de referencia de TI son

entregados de forma oportuna a los interesados
Validar la frecuencia de las reuniones de definición o

actualización del documento de administración de
integridad.
Validar la existencia de un formato o plantilla para
documentar la administración de integridad
Nivel 4

Administrar de forma continua y mejorar los procesos de administración de integridad.
Validar la consistencia entre los documentos de Enfatizar el uso de políticas y estandares para la administración de integridad
Validar que la gestión de integridad es continua y
proactiva.
Validar que el proceso de definición y actualización de la
arquitectura de infrmación se realiza de manera
Validar la existencia de métricas o variables de medición
indicadas en los procesos de administración de
integridad
Nivel 5
Validar que la gestión de integridad es continua y
proactiva.
Administrar de forma continua y mejorar los procesos de administración de integridad.
Validar que se brinde información confiable y
consistente para la administración de integridad.
Control PO2.4

PO4. Definir los procesos, organización y relaciones de TI
Objetivos primarios:
- Efectividad
- Eficiencia
Proceso de control: Definir los procesos, organización y relaciones de TI
Requisito de negocio cubierto: agilizar la respuesta a las estrategias del

negocio mientras al mismo tiempo cumple con los requerimientos de
gobierno y se establecen puntos de contacto definido y competente.

- La definición de un marco de trabajo de procesos de TI
- El establecimiento de un cuerpo y una estructura organizacional
apropiada
- La definición de roles y responsabilidades
- Variables de medición
- El porcentaje de roles con descripciones de puestos y autoridad
documentados
- El número de unidades/procesos de negocio que no reciben soporte de
TI y que deberían recibirlo, de acuerdo a la estrategia
- Número de actividades clave de TI fuera de la organización de TI que no
son aprobadas y que no están sujetas a los estándares organizacionales
de TI
Áreas del gobierno de TI
Primarias
- Administración de recursos
- Administración de riesgos
Secundarias
- Alineación Estratégica
Recursos de TI
- Personas
Entradas
P01 - Planes estratégicos y tácticos de TI
P07 - Políticas y procedimientos de TI y RH, matriz de habilidades de TI,
descripciones de puestos
P08 - Actividades de mejoramiento de calidad
P09 - Planes de actividades para corregir riesgos relacionados con TI
ME1 - Planes de acciones correctivas
ME2 - Reportar la efectividad de los controles de TI
ME3 - Catálogo de requerimientos legales y regulatorios relacionados con
los servicios de TI
ME4 - Mejoras al marco de procesos

Salidas
Marco de trabajo para el proceso de TI (Salidas: ME4)
Propietarios de sistemas documentados (Salidas: AI7, DS6)
Organización y relaciones de TI (Salidas: P07)
Marco de procesos, roles documentados y responsabilidades de TI (Salidas:
Todos)
Roles y responsabilidades documentados (Salidas: PO7)
PO4.6 Roles y responsabilidades

Definir y comunicar los roles y las responsabilidades para todo el personal
en la organización con respecto a los sistemas de información para permitir
que ejerzan los roles y responsabilidades asignados con suficiente
autoridad. Crear y actualizar periódicamente la descripción de roles. Estas
descripciones deben estar alineadas con la responsabilidad y la autoridad
incluyendo definiciones de habilidades y experiencia necesarias en cada
posición y que serán aplicables en el uso y evaluación del desempeño.
Enlazado con
PO4.6 Roles y Responsabilidades Peso la Pregunta
1 ¿La organización elabora un Manual de roles y responsabilidades?
Plan definido, no documentado (60%-40%) 5 cierra: 2-5
Plan parcialmente definido, no documentado (40%-20%) 2.5 cierra.2-5
El plan no está definido (20%-0%) 0 cierra: 2-5
2 ¿Cada cuanto tiempo es actualizado este manual?
¿La estructura de este Manual es elaborada mediante una plantilla
3 estandarizada por la organización?
Si se ajusta a la plantilla (80%-60%) 7.5
¿Este manual incluye especificaciones requeridas para el personal
4 encargado de trabajar con Bases de Datos?
Si incluye (80%-60%) 7.5


¿El manual es entregado de forma periódica y oportuna al personal de
5 TI?
Escasamente frecuente, sin periodicidad (seis meses – Anualmente) 1.25
¿Este manual es el documento único requerido para la evaluación de
6 desempeño de personal relacionado con tareas de BD?
Si incluye (80%-60%) 7.5
¿Los roles y responsabilidades desarrollados por el personal del área
de Bases de Datos corresponden con los definidos en el manual de la
7 organización?
Coincide en su totalidad (100%-80%) 10
Coincide (80%-60%) 7.5
Refleja parcialmente (60%-40%) 5
Escasamente reflejado (40%-20%) 2.5
No corresponde (20%-0%) 0

PO4.8 Responsabilidad sobre el riesgo, la seguridad y el

cumplimiento
Incluir la propiedad y la responsabilidad de los riesgos relacionados con TI a
un nivel senior apropiado. Definir y asignar roles críticos para administrar
los riesgos de TI, incluyendo la responsabilidad específica de la seguridad de
la información, la seguridad física y el cumplimiento. Establecer
responsabilidad sobre la administración del riesgo y la seguridad a nivel de
toda la organización para manejar los problemas a nivel de toda la
empresa. Puede ser necesario asignar responsabilidades adicionales de
administración de la seguridad a nivel de sistema específico para manejar
problemas relacionados con seguridad. Obtener orientación de la alta
dirección con respecto al apetito de riesgo de TI y la aprobación de
cualquier riesgo residual de TI.
Enlaza con
PO4.8 Responsabilidad sobre el riesgo, la seguridad y el cumplimiento Peso la Pregunta
1 ¿Existe un plan de riesgos para el área de TI?
Plan definido, no documentado (60%-40%) 5 cierra: 2-5
Plan parcialmente definido, no documentado (40%-20%) 2.5 cierra.2-5
El plan no está definido (20%-0%) 0 cierra: 2-5
2 ¿Con que frecuencia es actualizado este plan de riesgos?
Escasamente frecuente, sin periodicidad (seis meses – Anualmente) 1.25
¿Este plan de riesgos incluye acciones para eventualidades a nivel de
3 servidores de Base de Datos?
Incluye la mayoría de eventos de riesgo para un servidor de Base de Datos
(100%-80%) 10
Incluye los eventos de de riesgo para un servidor de Base de Datos (80%-
60%) 7.5
Incluye parcialmente los eventos de de riesgo para un servidor de Base de
Datos (60%-40%) 5
Incluye escasamente los eventos de de riesgo para un servidor de Base de
Datos (40%-20%) 2.5
4 ¿Los riesgos son manejados de acuerdo al plan definido?
En su mayoría se documenta y trabaja de acuerdo al plan (100%-80%) 10
Son manejados de acuerdo al plan (80%-60%) 7.5
Son manejados guiándose parcialmente del plan (60%-40%) 5
Son manejados guiándose escasamente del plan (40%-20%) 2.5
No se consulta el plan ante un evento de riesgo o no existe plan 0

¿El plan de riesgos incluye políticas de seguridad a nivel de Base de

5 Datos?
Incluye políticas de control acceso a usuarios 10
Incluye políticas de separación de funciones 8.75
Incluye políticas de privilegios sobre elementos de la Base de Datos 7.50
Incluye políticas de seguridad en las comunicaciones 6.25
Incluye políticas de contingencia (continuidad de negocio) 5.00
Incluye políticas de restauración y respaldo 3.75
Incluye políticas ante corrupción o error humano sobre la información 2.50
Incluye otro tipo políticas internas de seguridad 1.25
No incluye 0
Tabla 22. Tabla de consultas del Objetivo de Control PO4.8

PO4.9 Propiedad de datos y de sistemas

Proporcionar al negocio los procedimientos y herramientas que le permitan
enfrentar sus responsabilidades de propiedad sobre los datos y los sistemas
de información. Los propietarios toman decisiones sobre la clasificación de
la información y de los sistemas y sobre cómo protegerlos de acuerdo a
esta clasificación.
- Los datos pertenecen a los usuarios
Enlaza con la
PO4.9 Propiedad de datos y de sistemas Peso Pregunta
¿Se tiene definida la propiedad (dueños) de los datos almacenados en
1 el servidor?
Definido, documentado (100%-80%) 0 abre: 2-5 y 10
Parcialmente definido, documentado (80%-60%) 0 abre: 2-5 y 10
Definido, no documentado (60%-40%) 5 cierra: 2-5 y 10
Parcialmente definido, no documentado (40%-20%) 2.5 cierra: 2-5 y 10
No está definido (20%-0%) 0 cierra: 2-5 y 10
2 ¿Con que frecuencia se actualiza esta información?
Muy Frecuente con periodicidad (cada semana –mes) 10
Frecuente con periodicidad (cada mes – tres meses) 8.75
Poco frecuente con periodicidad ( cada tres meses –seis meses) 7.50
Escasamente frecuente con periodicidad (seis meses – Anualmente) 6.25
Muy Frecuente sin periodicidad (semana –mes) 5.00
Frecuente sin periodicidad (mes – tres meses) 3.75
Poco frecuente sin periodicidad (tres meses –seis meses) 2.50
Escasamente frecuente sin periodicidad (meses – Anualmente) 1.25
¿La propiedad de datos está definida relacionándola con
3 responsabilidades y obligaciones para los dueños de los datos?
Definido, documentado (100%-80%) 10
Definido, no documentado (80%-60%) 7.5
Parcialmente definido, documento (60%-40%) 5
Parcialmente definido, no documento (40%-20%) 2.5
4 ¿Los datos están clasificados de acuerdo a un criterio específico?
Si, clasificados de acuerdo a uno o más de los siguientes criterios:
confidencialidad, importancia, dueño de la información,
tiempo/antigüedad 10
Si, clasificados de acuerdo a un criterio interno 6
No, están clasificados de forma arbitraria 4
No están clasificados 0
¿El documento o plan de propiedad de datos refleja la situación actual
5 de la información contenida en el servidor de base de datos?
Esta actualizado en su mayoría (100%-80%) 10
Actualizado (80%-60%) 7.5
Parcialmente actualizado (60%-40%) 5
Escasamente actualizado (40%-20%) 2.5
No actualizado (20%-0%) 0

¿Existe un mecanismo tecnológico asociado al cumplimiento de este

6 objetivo?
Tiene instalado un software adquirido (cumple a totalidad el objetivo) 0 abre: 7
Tiene instalado un software adquirido (cumple parcialmente el
objetivo) 0 abre: 7
Tiene configurado un software/proceso desarrollado internamente
(cumple a totalidad el objetivo) 0 abre: 7
Tiene configurado un software/proceso desarrollado internamente (
cumple parcialmente el objetivo) 0 abre: 7
Es manejado a nivel de la aplicación 2 cierra: 7
No tiene un mecanismo tecnológico 0 cierra: 7
¿Los mecanismos de responsabilidad y protección de datos están
7 habilitados?
Habilitados completamente (100%-80%) 0 abre: 8
Habilitados (80%-60%) 0 abre: 8
Habilitado parcialmente (60%-40%) 0 abre: 8
Escasamente habilitados (40%-20%) 0 abre: 8
No habilitados (20%-0%) 0 cierra:8
¿Estos mecanismos tecnológicos pertenecen al motor de base de
8 datos o son herramientas externas?
Tiene instalado un software del fabricante del software 10
Tiene instalado un software externo al fabricante 7.5
Tiene configurado un software/proceso desarrollado internamente 5
Tiene configurado un software/proceso desarrollado internamente 2.5
No tiene un mecanismo tecnológico 0
¿El proceso de actualización y asignación de datos es realizado con
9 frecuencia?
¿El proceso de desarrollo utiliza estas recomendaciones de propiedad
10 y protección de datos en el servidor de BD auditado?
Utilizado en su mayoría (100%-80%) 10
Utilizado (80%-60%) 7.5
Utilizado parcialmente, en algunos casos (60%-40%) 5
Escasamente utilizado (40%-20%) 2.5
No utilizado (20%-0%) 0

PO4.11 Segregación de funciones

Implantar una división de roles y responsabilidades que reduzca la
posibilidad de que un solo individuo afecte negativamente un proceso
crítico. La gerencia también se asegura de que el personal realice solo las
tareas autorizadas, relevantes a sus puestos y posiciones respectivas.
Enlaza con
PO4.11 Segregación de funciones Peso la Pregunta
¿Se tiene definido el proceso de segregación de funciones en el servidor
1 de BD auditado?
Se conoce, se aplica y se documenta bajo estándares (al 100%-80%) 0 abre: 2-5
Se conoce, se aplica y se documenta sin estándares (80%-60%) 0 abre: 2-5
Se conoce, se aplica pero no se documenta (60%-40%) 0 abre: 2-5
Se conoce pero no se aplica adecuadamente (40%-20%) 0 abre: 2-5
No se conoce (20%-0%) 0 cierra: 2-5
¿El concepto de Segregación de funciones, se está cumpliendo de forma
2 efectiva?
Se cumple a totalidad de forma organizada y documentada (100%- 80%) 10
Se cumple totalmente sin documentación (80%-60%) 7.5
Se cumple parcialmente con documentación (60%-40%) 5
Se cumple parcialmente sin documentación (40%-20%) 2.5
No se cumple, o se realiza de forma inadecuada (20%-0%) 0
¿Cada cuanto tiempo se realiza un proceso de monitoreo de segregación
3 de funciones?
¿Existe un mecanismo tecnológico asociado al cumplimiento de este
4 objetivo?
Tiene instalado un software adquirido (cumple a totalidad el objetivo) 0 abre 5
Tiene instalado un software adquirido (cumple parcialmente el objetivo) 0 abre 5
Tiene configurado un software/proceso desarrollado internamente
(cumple a totalidad el objetivo) 0 abre 5
Tiene configurado un software/proceso desarrollado internamente (
cumple parcialmente el objetivo) 0 abre 5
Es manejado a nivel de la aplicación 2 cierra 5
No tiene un mecanismo tecnológico 0 cierra 5
5¿Qué tipo de software es este mecanismo tecnológico?
Parte del SGBD 10
Aplicación de proveedor externo (desarrollo por terceros) 7

Desarrollo interno. 4
Aplicación propietaria de otro fabricante (software propietario) 0

PO9 Evaluar y administrar los riesgos de TI
Objetivos Primarios:
- Confidencialidad
- Integridad
- Disponibilidad
- Objetivos Secundarios:
- Efectividad
- Eficiencia
- Cumplimiento
- Confiabilidad
Requisito de negocio cubierto: analizar y comunicar los riesgos de TI y su

impacto potencial sobre los procesos y metas de negocio

- La garantía de que la administración de riesgos está incluida
completamente en los procesos administrativos, tanto interna como
externamente, y se aplica de forma consistente
- La realización de evaluaciones de riesgo
- Recomendar y comunicar planes de acciones para mitigar riesgos
- Variables de medición:
- Porcentaje de objetivos críticos de TI cubiertos por la evaluación de
riesgos
- Porcentaje de riesgos críticos de TI identificados con planes de acción
elaborados
- Porcentaje de planes de acción de administración de riesgos aprobados
para su implantación
Áreas de gobierno de TI:

Primarias:
- Alineación estratégica
- Administración de Riesgos
Recursos de TI
- Aplicaciones
- Información
- Infraestructura
- Personas
Entradas
PO1 - Planes estratégicos y tácticos de TI, portafolio de servicios de TI
P010 - Plan de administración de riesgos de proyectos
DS2 - Riesgos de proveedores
DS4 - Resultados de pruebas de contingencia
DS5 - Amenazas y vulnerabilidades de seguridad
ME1 - Tendencias y eventos de riesgos históricos
ME4 - Apetito empresarial de riesgos de TI

Salidas
Evaluación de riesgos (Salidas: P01, DS4, DS5, DS12, ME4)
Reporte de riesgos (Salidas: ME4)
Directrices de administración de riesgos relacionados con TI (Salidas: P06)
Planes de acciones correctivas para riesgos relacionados con TI (Salidas:
P04, AI6)
PO9.2 Establecimiento del contexto del riesgo

Establecer el contexto en el cual el marco de trabajo de evaluación de
riesgos se aplica para garantizar resultados apropiados. Esto incluye la
determinación del contexto interno y externo de cada evaluación de riesgos,
la meta de la evaluación y los criterios contra los cuales se evalúan los
riesgos.
Enlaza con la
PO9.2 Establecimiento del contexto del riesgo Peso Pregunta
¿La organización tiene identificados los riesgos que se pueden presentar a
1 nivel de plataformas de bases de datos?
Perdida de servicio por falla de hardware 0.83
Perdida de servicio por error humano 0.83
Acceso no autorizado 0.83
Filtrado de información en la red 0.83
El puntaje de
Filtrado de información por usuarios autorizados 0.83
esta consulta
Filtrado de información por usuarios no autorizados 0.83 es la suma de
Perdida de datos por modificación indebida (con posibilidad de todas las
recuperación) 0.83 opciones
Perdida de datos por falla de hardware (sin posibilidad de recuperación 0.83 seleccionadas
Perdida de datos por modificación indebida (sin posibilidad de por el usuario
recuperación) 0.83
Perdida de datos por falla de hardware (con posibilidad de recuperación 0.83
Mal uso de información clasificada 0.83
Perdida de archivos de contingencia 0.83
Cierra todas
las opciones
anteriores.
No identificado 0 Cierra: 2
¿Los riesgos identificados abarcan todas las áreas vulnerables de los
2 servidores de Base de Datos?
Transmisión en la red 2 El puntaje de
Acceso de usuarios (Privilegios, permisos, contraseñas) 2 esta consulta
es la suma de
Seguridad de almacenamiento 2 todas las
opciones
Comunicaciones con aplicaciones 2 seleccionadas
Identifica otras áreas no listada en las opciones 2 por el usuario
No identifica riesgos 0 cierra: 4 y 5
¿A nivel de organización este proceso de evaluación de riegos está alineado
3 con el análisis de riegos de la organización?

Esta mejor definido aunque No cumple con el estándar de la empresa 10

Esta mejor definido y cumple con el estándar de la empresa 7
No está definido de forma adecuada pero cumple con el estándar de la
organización 4
No está definido de forma adecuada y No cumple con el estándar de la
empresa 0
Además de ser identificados los riesgos ¿estos tienen definidos bajo qué
4 criterios un evento es considerado de riesgo?
Definido de forma detallada en un documento 0 abre 5
Definido de forma general en un documentado 0 abre 5
Definido de forma general pero no documentado 4 cierra 5
No definido 0 cierra 5
Además de ser identificados y documentados ¿estos riesgos son evaluados
5 por los encargados del área?
Son evaluados de manera formal con indicadores de ocurrencia en fechas
establecidas 10
Son evaluados de manera informal (sin indicadores o un plan definido) en
fechas establecidas 7.5
Son evaluados de manera formal con indicadores de ocurrencia sin fechas
programadas 5
Son evaluados de manera informal (sin indicadores o un plan definido) sin
fechas programadas 2.5
No se evalúa los riesgos 0
¿Los procesos de evaluación implican un proceso de retro alimentación y
6 mejora?
Después de un proceso de evaluación de ocurrencia de riegos se implantan
nuevos procesos o software para disminuir las incidencias. 10
Después de un proceso de evaluación de ocurrencia de riegos no se realizan
acciones para disminuir las incidencias. 5
No se evalúan los riegos ocurridos. 0

PO9.3 Identificación de eventos

Identificar todos aquellos eventos (amenazas y vulnerabilidades) con un
impacto potencial sobre las metas o las operaciones de la empresa,
aspectos de negocio, regulatorios, legales, tecnológicos, de sociedad
comercial, de recursos humanos y operativos. Determinar la naturaleza del
impacto – positivo, negativo o ambos – y dar mantenimiento a esta
información.
Enlaza con la
PO9.3 Identificación de eventos Peso Pregunta
¿Los eventos se encuentran identificados de forma adecuada en el área
1 de TI?
Identificado, documentado (100%-80%) 10
Identificado, no documentado (80%-60%) 7.5
Parcialmente identificado, documentado (60%-40%) 5
Parcialmente identificado, no documentado (40%-20%) 2.5 cierra 2 - 4
No está identificado (20%-0%) 0 cierra 2 - 4
2 Seleccionar los eventos identificados por el área de TI
El software de base de datos está instalado sobre un controlador de
dominio 1
La organización tiene la última versión del fabricante de SGBD 1
Están limitados los privilegios de sistema a los usuarios administradores 1
Los permisos del sistema operativo están limitados a los requerimientos
mínimos de la base de datos (no permisos de administrador) 1 El puntaje de
El equipo de desarrollo no tiene acceso directo al entorno de Base de esta consulta
datos de producción 1 es la suma de
Los usuarios de la base de datos tienen los privilegios mínimos para todas las
trabajar. 1 opciones
Las opciones de auditoría para base de datos están habilitadas seleccionadas
(procedimientos, paquetes, disparadores) 1 por el usuario
La autenticación, control o conexión remotos no están activados en el
servidor (a nivel de Sistema Operativo o SGBD) 1
El Software del SGBD se encuentra instalado en una versión certificada
(aprobada por el fabricante) 1
Otros 1
Cierra todas
las opciones
anteriores.
No se identifica ningún tipo de eventos 0 Cierra: 3
Del grupo de eventos identificados se encuentra definido el impacto de
3 una brecha de seguridad o incumplimiento
Definido de forma completa 10
Parcialmente definido 5
No definido 0
4 Esta información es actualizada y mantenida con frecuencia



PO9.4 IT Evaluación de riesgos

Evaluar de forma recurrente la posibilidad e impacto de todos los riesgos
identificados, usando métodos cualitativos y cuantitativos. La posibilidad e
impacto asociados a los riesgos inherentes y residuales se debe determinar
de forma individual, por categoría y con base en el portafolio.
Enlaza con la
PO9.4 Evaluación de riesgos Peso Pregunta
1 ¿Cada uno de los grupos de riesgos se encuentra documentados?
Si 10
No 0
¿Dentro de la documentación se encuentra definido el impacto de cada

2 evento de riesgo?
Definido 10
Parcialmente definido 5
No definido 0
¿Cuál es la posibilidad de que ocurra un evento de riesgo negativo? de
3 tipo: Perdida de servicio
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
4 tipo: Caída del servidor por falla de hardware
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
5 tipo: Perdida de datos por falta de archivos de contingencia
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
6 tipo: Falla irrecuperable del servicio
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
tipo: Perdida de archivos físicos del SO (eliminación, borrado, corrupción
7 de archivo)

Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
tipo: Perdida de archivos físicos del SO (eliminación, borrado, corrupción
8 de archivo)
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
tipo: Perdida de archivos físicos del SGBD (eliminación, borrado,
9 corrupción de archivo)
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
10 tipo: Perdida de servicio por acceso no autorizado al SGBD
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
11 tipo: Filtrado de información por acceso no autorizado al SGBD
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
12 tipo: Problemas de acceso por falla en la red
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
13 tipo: Modificación errónea de datos por la aplicación
Muy probable 10
poco probable 7.5
probable 5

imposible 2.5
No es monitoreado 0
14 tipo: Modificación errónea de datos por usuarios autorizados
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
15 tipo: Perdida de servicio por acceso no autorizado al SO
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
16 tipo: Filtrado de información por acceso no autorizado al SO
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
17 tipo: Vista de información por usuarios no autorizados
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
18 tipo: Vista de información por usuarios autorizados pero no asignados
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0
19 tipo: Perdida total del servidor por evento de la naturaleza
Muy probable 10
poco probable 7.5
probable 5
imposible 2.5
No es monitoreado 0

PO9.5 Respuesta a los riesgos

Identificar los propietarios de los riesgos y a los dueños de procesos
afectados, y elaborar y mantener respuestas a los riesgos que garanticen
que los controles rentables y las medidas de seguridad mitigan la exposición
a los riesgos de forma continua. La respuesta a los riesgos debe identificar
estrategias de riesgo tales como evitar, reducir, compartir o aceptar. Al
elaborar la respuesta, considerar los costos y beneficios y seleccionar
respuestas que limiten los riesgos residuales dentro de los niveles de
tolerancia de riesgos definidos.
- Revisar los manuales de riesgo y los planes de acción

- Los asignados a dar repuesta a un riesgo deben estar definidos por
puestos de trabajo y no por personas
- Un riesgo es mejor manejado si está definido de forma cuantitativa
Enlaza con la
PO9.5 Respuesta a los riesgos Peso Pregunta
¿Cada uno de los grupos de eventos y los riesgos negativos poseen un
1 plan de respuesta?
Si, está documentado 0 abre 2
Se documenta después de ocurrido 0 abre 2
Si, no está documentado 3 cierra 2
No 0 cierra 2-4
¿El plan de riesgos tiene definidos las personas o áreas encargadas de
2 brindar respuesta al evento?
Los responsables están definidos, documentado (100%-80%) 10
Definido, no documentado (80%-60%) 7.5
Parcialmente definido, documentado (60%-40%) 5
Parcialmente definido, no documentado (40%-20%) 2.5
3 ¿El plan garantiza una adecuada reacción ante un riesgo?
Si 10
No en su totalidad 5
No
¿Las estrategias de riesgo están alineadas con el estándar de la
4 organización?
Alineadas en su mayoría (100%-80%) 10
Alineadas (80%-60%) 7.5
Parcialmente alineadas (60%-40%) 5
Escasamente alineadas (40%-20%) 2.5

PO9.6 Mantenimiento y monitoreo de un plan de acción de riesgos

Asignar prioridades y planear las actividades de control a todos los niveles
para implantar las respuestas a los riesgos, identificadas como necesarias,
incluyendo la identificación de costos, beneficios y la responsabilidad de la
ejecución. Buscar la aprobación para las acciones recomendadas y la
aceptación de cualquier riesgo residual, y asegurarse de que las acciones
comprometidas son propiedad del dueño (s) de los procesos afectados.
Monitorear la ejecución de los planes y reportar cualquier desviación a la
alta dirección.
Enlaza con la
PO9.6 Mantenimiento y monitoreo de un plan de acción de riesgos Peso Pregunta
¿Los eventos son comunicados de forma adecuada al personal
1 encargado?
Es muy rápido 10
Es rápido 7
Es un proceso lento 4
Es muy lento el proceso 0
¿El proceso de inicio, atención y cierre de un evento es administrado
2 adecuadamente?
Adecuado y mejorado (documentado) 10
Adecuado no mejorado (no documentado) 8 cierra 3
Efectuado (documentado) 6
Efectuado (no documentado) 4 cierra 3
Inadecuado (documentado) 2
Inadecuado (no documentado) 0 cierra 3
3 ¿Con que frecuencia se actualizan los planes de respuesta a riesgos?
¿Existe un área o persona encargado de monitorear la correcta
4 atención del evento?
Si es un especialista 10
Si es una persona encargada 7.5
Es una persona temporal 5
No identifica quien es el encargado 2.5
No 0
¿Después de ser atendido el evento de riego se realiza un seguimiento
5 para evitar cualquier riesgo residual?
Sí, siempre se realiza 10
Si, en algunos casos 7
Nunca se realiza 4

No conoce el procedimiento 0

CAPITULO V
APORTE PRÁCTICO
I. Estructura de la solución
La estructura del sistema que se plantea presenta tres grandes

componentes debido a la necesidad de independizar las tareas que se
pueden realizar con un sistema de este tipo, haciendo una distribución de
responsabilidades según el tipo de usuario que haga uso del sistema. Los
componentes que se plantean son:
a. Edición de Base de Datos y Mantenimiento
El objetivo de este subsistema es el mantenimiento de las tablas

maestras para el registro y actualización de información general del
sistema como también para el mantenimiento de los procesos, objetivos
de control y la base de reglas.
Este módulo permitirá a los auditores realizar un mantenimiento de los

procesos del negocio a auditar, así como también afinar el
funcionamiento del sistema para la obtención de resultados haciendo un
mantenimiento de la base de reglas.
Por otro lado existen sub-módulos para el mantenimiento de tablas

maestras, esta función está reservada para el administrador del sistema
quien será responsable del registro de información del negocio, pero no
será responsable del mantenimiento del motor experto del sistema.
b. Modulo experto de auditoría
Este módulo se compone de los métodos de cálculo y obtención de

resultados. El diseño que contiene reglas de producción, estas reglas
deben ser dadas por un experto y almacenadas en el repositorio de
datos, la regla de producción se basa en el alcance de puntajes para la
determinación de un resultado, entonces se cumple la forma básica de
reglas de producción "Si (condición) entonces" teniendo una base de
conocimientos factual dado por el usuario experto.
El elemento nuclear de la evaluación en las auditorias son los objetivos

de control los cuales cuentan con un puntaje que depende de las
respuestas otorgadas en la encuesta, estos puntajes los sitúan en un
nivel de madurez que dará como resultado al usuario un plan de trabajo,
que son las actividades a realizar para la validación del resultado, así
como también recomendaciones a seguir para mejorar dichos niveles de
madurez, estas recomendaciones son aquellas existentes en los
estándares dependiendo de los resultados obtenidos.

c. Modulo de reportes
Para un mejor trabajo con el sistema se debe permitir generar reportes

para el usuario. Estos reportes pueden ser reportes informativos que
sirven para entregar al usuario los resultados de las diferentes
evaluaciones realizadas.
También este módulo permite generar el plan de trabajo para el auditor

y los reportes con las recomendaciones, los cuales dependen de los
resultados obtenidos por el sistema.
Base de Datos
Interfaz con base de datos
Edición de Modulo Modulo de

Base de experto de reportes
Datos y auditoría
Mantenimi
ento
Ilustración 17. Diagrama de bloques del sistema

II. Tecnología
Microsoft .Net C#®
C# (pronunciado "si sharp") es un lenguaje de programación orientado a

objetos desarrollado y estandarizado por Microsoft como parte de su
plataforma .NET, que después fue aprobado como un estándar por la ECMA
e ISO.
Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la

plataforma.NET el cual es similar al de Java aunque incluye mejoras
derivadas de otros lenguajes (entre ellos Delphi).
El símbolo # viene de sobreponer "++" sobre "++" y eliminar las

separaciones, indicando así su descendencia de C++.
C#, como parte de la plataforma.NET, está normalizado por ECMA desde

diciembre de 2001 (ECMA-334 "Especificación del Lenguaje C#"). El 7 de
noviembre de 2005 salió la versión 2.0 del lenguaje que incluía mejoras
tales como tipos genéricos, métodos anónimos, iteradores, tipos parciales y
tipos anulables. El 19 de noviembre de 2007 salió la versión 3.0 de C#
destacando entre las mejoras los tipos implícitos, tipos anónimos y el LINQ
(Language Integrated Query).
Aunque C# forma parte de la plataforma.NET, ésta es una interfaz de

programación de aplicaciones; mientras que C# es un lenguaje de
programación independiente diseñado para generar programas sobre dicha
plataforma. Ya existe un compilador implementado que provee el
Framework de DotGNU - Mono que no genera programas para dicha
plataforma, sino para una plataforma diferente como Win32 o UNIX / Linux.
Oracle 10g R2 ®
Plataforma de Base de Datos Relacional con características de tecnología

distribuida y administración Web.
Oracle 10g es la primera base de datos diseñada para grid computing, la
más flexible y rentable forma de gestionar la información empresarial. Se
reduce los costos de gestión al mismo tiempo la mayor calidad posible de
servicio.
Además de proporcionar calidad y numerosas mejoras en el desempeño, la
base de datos Oracle 10g reduce significativamente los costos de la gestión
del entorno de TI, con una simplificación de la instalación, reducido en gran
medida la configuración y gestión de requisitos, y el rendimiento diagnóstico
automático y afinación de SQL.
Estas y otras capacidades de gestión automatizada ayudar a mejorar la DBA

y desarrollador de la productividad y la eficiencia. Y con el módulo 2, Oracle
centrará en la mejora de la eficiencia y reducir el costo de la gestión de la
información continúa.

III. Modelo de Casos de Uso
Los modelos de caso de uso no representan el proceso de auditoría en su

totalidad de un área de TI están reducidos a los procesos involucrados con
las actividades de un Servidor de Base de Datos
3.1 Casos de Uso del Negocio (CUN)
Modelo de Paquetes
Area de TI
Area de Seguridad de Infraestructura y

Informacion/ Procesos hardware
Directorio/ Alta
Gerencia Desarrollo y Redes y
aplicaciones comunicaciones
Area de soporte
Area de Auditoria/
cumplimiento de TI
Ilustración 18. Modelo de paquetes CUN

Directorio/ Alta gerencia
Informe de
negocio, no
informe tecnico
Analizar informe de Auditoria
Gerencia/Direccion
Ejecutar acciones correctivas y de

mejora
Mejorar procedimientos y planes de

TI
Ilustración 19. CUN Directorio/Alta gerencia
Área de Auditoria
Elaborar Informe final Auditar documentacion
Auditor Jefe
Auditor de procedimientos
Planificar proceso de Auditoria
Auditar procesos e involucrados
Deifinir Areas de auditoria
Entregar informe parcial

Auditor de aplicaciones Analizar riesgos y seguridad
Auditar desarrollo
Entregar Informe parcial Auditar soft/hw de red
Analizar riesgos y seguridad Auditar software adquirido Auditar comunicaciones

Auditor de redes y
comunicaciones
Software de Base de,
Desarrollos externos,
software propietario
Datos
Analizar riesgos y seguridad
Entregar informe parcial

Ilustración 20. CUN Área de auditoría

Área de TI
Área de Seguridad
Analizar opciones de seguridad de

Informacion
(from Desarrollo y aplicaciones)
Oficial/Equipo de seguridad
(f rom Area de TI)
Definir niveles de informacion
(from Area de T I)
Definir acciones de aseguramiento

de comunicaciones
Elaborar plan de riesgos
Identificar puestos clave en el area
Recomendar configuraciones
minimas de seguridad
Ilustración 21. CUN Área de seguridad

Desarrollo de Aplicaciones
Analizar opciones de seguridad de

Informacion
(from Desarroll o y aplicaciones)
Oficial/Equipo de seguridad
(f rom Area de TI)
Definir niveles de informacion
(from Area de T I)
Definir acciones de aseguramiento

de comunicaciones
Elaborar plan de riesgos
Identificar puestos clave en el area
Recomendar configuraciones
minimas de seguridad
Ilustración 22. CUN Desarrollo de aplicaciones

Soporte

Elaborar plan de atencion de

Jefe de area de soporte
incidencias
Documentar incidencias,
Jefe de area de TI
seguimiento y solucion
(f rom Area de TI)
Realizar proceso de mejora

Equipo de soporte
despues de incidencias
(f rom Area de TI)
Ilustración 23. CUN Soporte
Redes y Comunicaciones
Elaborar plan de riesgos de redes

Jefe de area de TI
(f rom Area de TI)
Elaborar plan de contingencia y

respuesta
Jefe de Redes de
Comunicaciones
(f rom Area de TI)
Controlar accesos de usuarios
Equipo de redes Controlar servicio de red al servidor

(f rom Area de TI) (from Area de TI)
Ilustración 24. CUN Redes y comunicaciones

Infraestructura y hardware
Analizar adquisicion de HW
Jefe de area de TI
certificado
(f rom Area de TI)
Analizar Plataforma de SO para

Equipo de hardware
Servidores
Analizar requrimientos de HW y SW
DBA
(f rom Area de TI)
Analizar requisitos de red

Equipo de redes
(f rom Area de TI)
Ilustración 25. CUN Infraestructura y hardware
3.2 Casos de Uso del Sistema (CUS) – Diagrama de Paquetes
Auditoria y Reportes
Entrenamiento
Administración
de la Aplicación
Ilustración 26. Diagrama de paquetes de CUS.

3.3 Diagrama de Casos de Uso por Paquetes
Auditoría y entrenamiento
CUS009 Realizar mantenimiento de Auditor Jefe

Reglas CUS001 Iniciar sesión
(f rom Area de Auditoria
...) Encuestado
<<extend>>
CUS002 Iniciar proceso de Auditoria CUS003 Realizar Encuesta
Evaluador
...)
CUS004 Generar Reporte de Nivel

de Madurez
CUS008 Ingresar informacion de la

CUS006 Registrar resultado de
organización
evaluación
CUS005 Generar Plan de Trabajo
CUS007 Registrar proceso de

auditoria
Ilustración 27. CUS Auditoría y entrenamiento
Administración de la aplicación
CUS015 Crear usuario
CUS016 Administrar perfiles

Administrador de
la aplicacion
CUS017 Configurar vistas por

usuario
CUS018 Definir politicas de

aplicacion
Ilustración 28. CUS Administración de la aplicación

Reportes
CUS010 Crear reporte de

Recomendaciones
Auditor Jefe
...) CUS011 Crear reporte final de
auditoria de BD
CUS012 Crear reporte por grupo de

objetivos de control
Evaluador
...)
CUS013 Crear reporte de Madurez
CUS014 Crear reporte final de

validación
Ilustración 29. CUS Reportes

3.4 Especificación de Casos de Uso por Paquetes
3.4.1 Auditoría y entrenamiento
CUS001. INICIAR SESIÓN
CÓDIGO CUS001
NOMBRE Iniciar Sesión
DESCRIPCIÓN Permite al usuario el ingreso a la aplicación
ACTORES Todos los usuarios
El usuario debe tener habilitada su cuenta.

PRE –
El sistema está conectado en la red la base de datos objetivo.
CONDICIONES
La PC cliente cuenta con acceso al aplicativo de auditoría.
POST –
El usuario ingresa al sistema con sus opciones cargadas.
CONDICIONES
ESCENARIO El usuario tiene habilitada su cuenta, cuenta con un usuario y una
PRIMARIO contraseña.
DESCRIPCIÓN DEL FLUJO
ACTOR SISTEMA
1. El usuario ejecuta la aplicación. 2. El sistema muestra la pantalla de Login.
4. El sistema valida los datos. El sistema
3. El usuario ingresa su Id de usuario y su
carga los menús y botones según el rol del
contraseña
usuario.
Las credenciales de usuario no son
EXCEPCIONES
correctas
Viene del paso 3 en el flujo básico
1. El sistema valida los datos. El sistema

retorna al usuario un mensaje indicando
que no se puedo realizar la conexión
debido a que el usuario o contraseña
ingresados son erróneos.
En caso de no encontrar resultados se debe mostrar el mensaje “Usuario o
contraseña no validos”.
RESULTADO
En caso de presentarse un error se debe mostrar el mensaje “El servicio no
se encuentra disponible. Por favor intente más tarde.”
Este caso de uso se ejecuta a pedido del
FRECUENCIA
usuario
REQ. NO
FUNCIONALES No aplica
ASOCIADOS
CASOS DE USO
No aplica
RELACIONADOS
Tabla 30. Especificación del CUS001 Iniciar sesión

Diagrama de Secuencia
: Aplicacion : Ctrl Validacion : Ctrl Acceso Datos : BD

: Usuarios
Ingresar datos
Validar datos
Datos correctos
Validar usuario
Obtener usuario
Datos usuario
Usuario correcto
Obtener perm isos
Consultar permisos por rol
Permisos
Opciones por rol
Menú de trabajo
Ilustración 30. Diagrama de secuencia CUS001
Diagrama de Colaboración
1: Ingresar datos 2: Validar datos

: Aplicacion
12: Menú de trabajo 3: Datos correctos

: Usuarios : Ctrl Validacion
7: Usuario correcto
11: Opciones por rol
4: Validar usuario
8: Obtener permisos 5: Obtener usuario
9: Consultar permisos por rol
6: Datos usuario
: Ctrl Acceso Datos 10: Permisos : BD
Ilustración 31. Diagrama de Colaboración CUS001

CUS002. INICIAR PROCESO DE AUDITORIA
CÓDIGO CUS002
NOMBRE Iniciar proceso de auditoria
DESCRIPCIÓN Permite al usuario iniciar un nuevo proceso de evaluación o auditoría
ACTORES Evaluador

PRE –
CONDICIONES
POST – El usuario tiene listo el ambiente para comenzar la evaluación, generar
CONDICIONES plan de trabajo o empezar la encuesta.
ESCENARIO
El usuario tiene acceso a la opción “Iniciar Auditoría” del menú principal.
PRIMARIO
ACTOR SISTEMA
1. El usuario tiene abierta la aplicación
2. El sistema muestra la pantalla de
y selecciona la opción “Nueva Auditoría”
“Registro de nueva auditoría”.
en el menú principal.
3. El usuario selecciona la organización 4. El sistema carga la lista de áreas
a auditar existentes en la organización.
5. El usuario selecciona el área a 6. El sistema muestra los posibles tipos de
auditar auditoría a realizar.
8. El sistema busca en la base de datos
los procesos y objetivos de control
relacionados al tipo de auditoría y los
muestra al usuario la lista de objetivos a
7. El usuario selecciona el tipo de
evaluar, el sistema le da la opción al
auditoría
usuario de editar esta lista, agregar o
quitar objetivos de control. El sistema le da
la opción al usuario de habilitar o inhabilitar
la encuesta asociada.
10. El sistema registra los datos de la
9. El usuario presiona el botón “Iniciar nueva auditoría y comienza el proceso. El
auditoría” sistema muestra el mensaje “La auditoría
ha iniciado”
Las credenciales de usuario no son
EXCEPCIONES
correctas
1. El usuario agrega o elimina objetivos de

control a evaluar. El usuario habilita o
inhabilita la encuesta asociada.
Continúa en el paso 9 en el flujo básico.

En caso de presentarse un error se debe
mostrar el mensaje “El servicio no se
RESULTADO
encuentra disponible. Por favor intente más
tarde.”
FRECUENCIA
usuario
REQ. NO FUNCIONALES ASOCIADOS No aplica
CASOS DE USO RELACIONADOS No aplica
Tabla 31. Especificación del CUS002 Iniciar Proceso de Auditoría


: Usuarios
Ingresar datos y tipo de auditoria
Validar datos
Datos correctos
Obtener procesos y objetivos de control
Obtener procesos por tipo auditoria
Procesos y objetivos
Procesos y objetivos
Lista procesos y objetivos
Editar y guardar procesos y encuesta
Validar datos
Datos validos
Guardar datos
Registrar
Resultado
Comunicar resultado
Mostrar resultado

1: Ingresar datos y tipo de auditoria 2: Validar datos
9: Editar y guardar procesos y encuesta 10: Validar datos
: Aplicacion
8: Lista procesos y objetivos 3: Datos correctos

: Usuarios : Ctrl Validacion
16: Mostrar resultado 11: Datos validos
7: Procesos y objetivos
15: Comunicar resultado
4: Obtener procesos y objetivos de control 5: Obtener procesos por tipo auditoria

13: Registrar
12: Guardar datos
6: Procesos y objetivos
: Ctrl Acceso Datos 14: Resultado : BD
Ilustración 33. Diagrama de colaboración CUS002

CUS003. REALIZAR ENCUESTA
CÓDIGO CUS003
NOMBRE Realizar encuesta
DESCRIPCIÓN Permite al usuario responder las encuestas de la auditoría
ACTORES Encuestado

PRE –
CONDICIONES
El auditor habilito la encuesta relacionada a los objetivos de control
seleccionados.
POST – El usuario tiene listo el resultado de las encuestas, esto permite generar
CONDICIONES el reporte de nivel de madurez y el plan de trabajo.
ESCENARIO El usuario tiene acceso al sistema y tiene habilitada la opción de
PRIMARIO “Encuestas” en el menú principal.
ACTOR SISTEMA
1. El usuario tiene abierta la aplicación 2. El sistema muestra la pantalla de
y selecciona la opción “Encuestas” en el “Encuestas” mostrando una lista de las
menú principal. encuestas pendientes por el usuario.
3. El usuario selecciona la encuesta que 4. El sistema muestra la pantalla con la
va resolver y presiona el botón primera pregunta de la evaluación con sus
“Siguiente”. respectivas alternativas
6. El sistema registra la respuesta a la
5. El usuario selecciona la(s) pregunta y muestra la siguiente pregunta
alternativas como respuesta a la con sus alternativas.
pregunta y presiona el botón “Siguiente”
Continúa en el paso 3.
Ya no existen más preguntas en la
EXCEPCIONES
encuesta.
1. El sistema muestra la última pregunta al

usuario y habilita el botón “Finalizar”.
2. El usuario selecciona la(s) alternativas 3. El sistema registra las respuestas,

como respuesta a la pregunta y presiona muestra el mensaje “Encuesta finalizada”
el botón “Finalizar”. y cierra la ventana de preguntas.
EXCEPCIONES El usuario no puede terminar la encuesta

2. El sistema registra las respuestas.
1. El usuario presiona el botón “Guardar”.
3. El usuario presiona el botón “Salir”. 4. El sistema cierra la ventana de encuestas.

RESULTADO
tarde.”
FRECUENCIA
usuario
Tabla 32. Especificación del CUS003 Realizar encuesta

: Aplicacion : Ctrl Acceso Datos : BD
: Encuestado
Seleccionar encuesta
Obtener encuesta
Obtener pregunta y alternativas
Retornar preguntas y alternativas
Preguntas
Mostras preguntas y alternativas
Responder preguntas
Guardar y finalizar
Registrar respuestas
Registrar
Resultado
Comunicar resultado
Mostrar resultado
1: Seleccionar encuesta
7: Responder preguntas 2: Obtener encuesta
8: Guardar y finalizar 9: Registrar respuestas
: Aplicacion
6: Mostras preguntas y alternativas 5: Preguntas

: Encuestado 12: Comunicar resultado : Ctrl Acceso Datos
13: Mostrar resultado
4: Retornar preguntas y alternativas

11: Resultado
3: Obtener pregunta y alternativas

10: Registrar
: BD

CUS004. GENERAR REPORTE DE NIVEL DE MADUREZ
CÓDIGO CUS004
NOMBRE Generar reporte de nivel de madurez
Permite al usuario conocer el resultado de las encuestas y tener una idea
DESCRIPCIÓN
del nivel de madurez en la que se encuentra la organización.
ACTORES Evaluador

PRE – La PC cliente cuenta con acceso al aplicativo de auditoría.
CONDICIONES El auditor habilito la encuesta relacionada a los objetivos de control
seleccionados.
La encuesta relacionada ya fue respondida por los encuestados.
POST – El usuario tiene listo el resultado de las encuestas, y un nivel de madurez
CONDICIONES calculado por el sistema.
PRIMARIO “Reporte de nivel de madurez” en el menú principal.
ACTOR SISTEMA
“Reporte de nivel de madurez” y muestra
y selecciona la opción “Reporte de nivel
una lista de las auditorias que tienen nivel
de madurez” en el menú principal.
de madurez calculado.
4. El sistema genera el reporte de nivel
3. El usuario selecciona la auditoría que de madurez junto con las
desea evaluar. recomendaciones.
EXCEPCIONES No aplica
RESULTADO
tarde.”
FRECUENCIA
usuario
Tabla 33. Especificación del CUS004 Generar reporte de madurez.

: Aplicacion : Ctrl Validacion : Ctrl Generador : Ctrl Acceso Datos : BD

Reportes
: Evaluador
Seleccionar auditoria
Validar encuesta resuelta
Encuenta completa
Generar reporte
Obtener resultado encuesta
Obtener resultados
Resultado encuesta
Resultado nivel madurez
Generar reporte
Mostrar reporte nivel madurez
Mostrar reporte nivel de madurez
1: Seleccionar auditoria 2: Validar encuesta resuelta
11: Mostrar reporte nivel de madurez 3: Encuenta com pleta

: Evaluador : Aplicacion : Ctrl Validacion
4: Generar reporte
9: Generar reporte
10: Mostrar reporte nivel madurez
7: Resultado encuesta 8: Resultado nivel madurez
6: Obtener resultados 5: Obtener resultado encuesta

: BD : Ctrl Acceso Datos : Ctrl Generador Reportes

CUS005. GENERAR PLAN DE TRABAJO
CÓDIGO CUS005
NOMBRE Generar plan de trabajo
Permite al usuario responder conocer el resultado de las encuestas y
DESCRIPCIÓN tener una idea del nivel de madurez en la que se encuentra la
organización.
ACTORES Evaluador

PRE – El sistema está conectado en la red la base de datos objetivo.
CONDICIONES La PC cliente cuenta con acceso al aplicativo de auditoría.
El evaluador registró los datos de la auditoría
POST – El usuario tiene lista su plan de trabajo para la validación del nivel de
CONDICIONES madurez o para realizar una evaluación inicial.
ESCENARIO El usuario tiene acceso al sistema y tiene habilitada la opción de “Plan de
PRIMARIO trabajo” en el menú principal.
ACTOR SISTEMA
“Plan de trabajo” y muestra una lista de
y selecciona la opción “Plan de trabajo”
las auditorias que tienen listo el plan de
en el menú principal.
trabajo.
4. El sistema genera el plan de trabajo y
3. El usuario selecciona la auditoría que lo muestra al usuario, este plan de trabajo
desea evaluar. es usado para realizar la evaluación del
área.
EXCEPCIONES No aplica
RESULTADO
tarde.”
FRECUENCIA
usuario
Tabla 34. Especificación del CUS005 Generar plan de trabajo.

: Aplicacion : Ctrl Validacion : Ctrl Generador : Ctrl Acceso Datos : BD

Reportes
: Evaluador
Validar existencia nivel madurez
Resultado validacion
Generar plan de trabajo
Obtener actividades segun nivel de madurez o objetivo control
Obtener actividades
Resultado encuesta
Actividades
Generar reporte
Mostrar plan de trabajo
1: Seleccionar auditoria 2: Validar existencia nivel madurez
11: Mostrar plan de trabajo 3: Resultado validacion

4: Generar plan de trabajo
9: Generar reporte
10: Mostrar plan de trabajo
7: Resultado encuesta 8: Actividades
6: Obtener actividades 5: Obtener actividades segun nivel de madurez o objetivo control

: BD : Ctrl Acceso Datos : Ctrl Generador Reportes

CUS006. REGISTRAR RESULTADO DE LA EVALUACIÓN
CÓDIGO CUS006
NOMBRE Registrar resultado de la evaluación.
DESCRIPCIÓN Permite al usuario registrar los resultados de su evaluación.
ACTORES Evaluador

PRE –
CONDICIONES
El evaluador registró los datos de la auditoría y generó el plan de
trabajo
POST – El usuario tiene el reporte final de la auditoría junto con las
CONDICIONES recomendaciones dadas por el sistema.
PRIMARIO “Registrar resultados” en el menú principal.
ACTOR SISTEMA
“Registrar resultados” y muestra una
y selecciona la opción “Registrar
lista de las auditorias que tienen listo el
resultados” en el menú principal.
plan de trabajo.
4. El sistema muestra el plan de
trabajo generado anteriormente junto
3. El usuario selecciona la auditoría
con campos editables donde se registra
que desea evaluar.
el resultado de cada una de las
actividades.
6. El sistema registra el resultado de la
5. El usuario registra el resultado de evaluación, genera el reporte final de
cada actividad y presiona el botón auditoría y finalmente muestra el
“finalizar” para terminar el proceso. mensaje “Proceso de auditoría
finalizada”.
EXCEPCIONES El usuario no puede terminar el registro
1. El usuario registra el resultado de cada

2. El sistema registra los resultados.
actividad y presiona el botón
“Guardar”.
4. El sistema cierra la ventana de registro

3. El usuario presiona el botón “Salir”.
de resultados.
RESULTADO
tarde.”
FRECUENCIA
usuario
Tabla 35. Especificación del CUS006 Registrar resultado de la evaluación


: Evaluador
Validar plan de trabajo
Resultado validación
Registrar resultados
Validar datos
Registrar datos
Registrar
Resultado
Comunicar resultado
Mostrar resultado registro
1: Seleccionar auditoria 2: Validar plan de trabajo

5: Registrar resultados 6: Validar datos
4: Mostrar plan de trabajo 3: Resultado validación

: Evaluador 12: Mostrar resultado registro : Aplicacion 7: Resultado validación : Ctrl Validacion
8: Registrar datos 9: Registrar
10: Resultado
: Ctrl Acceso Datos : BD

CUS007. REGISTRAR PROCESO DE AUDITORIA
CÓDIGO CUS007
NOMBRE Registrar proceso de auditoria
DESCRIPCIÓN Permite al usuario registrar los procesos para realizar una auditoría.
ACTORES Auditor

PRE –
CONDICIONES
POST –
El usuario cuenta con procesos para realizar auditoría.
CONDICIONES
PRIMARIO “Mantenimiento de Procesos” en el menú principal.
ACTOR SISTEMA
1. El usuario tiene abierta la aplicación 2. El sistema muestra la pantalla de
y selecciona la opción “Mantenimiento de “Mantenimiento de procesos” y muestra la
procesos” en el menú principal. lista de dominios existentes.
4. El sistema habilita el control para
3. El usuario selecciona el dominio al registrar el proceso incluyendo el nombre
cual pertenece el proceso. y una tabla en la cual insertar los
objetivos de control.
5. El usuario ingresa los datos del
6. El sistema valida los datos ingresados
proceso y los objetivos de control
y los registra, finalmente muestra el
pertenecientes al proceso, finalmente
mensaje “Registro realizado con éxito”.
presiona el botón “Guardar”.
El sistema encuentra los datos
EXCEPCIONES
incorrectos durante la validación
Viene del paso 5 del flujo principal.
1. El sistema valida los datos ingresados y

los encuentra incorrectos, el sistema
marca los campos que son incorrectos y
muestra el mensaje de error “Datos
incorrectos”.
2. El usuario acepta el mensaje, corrige los
datos y presiona el botón “Guardar”.
Continúa en el paso 6 del flujo principal.

RESULTADO
tarde.”
FRECUENCIA
usuario
Tabla 36. Especificación del CUS007 Registrar proceso de auditoría

: Auditor : Aplicacion : Ctrl Validacion : Ctrl Acceso Datos : BD
Seleccionar dominio
Obtener procesos y objetivos de control
Obtener procesos y OC.
Retornar datos
Cargar procesos y objetivos de control
Mostrar datos
Seleccionar proceso
Ingresar nuevo proceso
Editar objetivos de control
Registrar
Validar datos
Registrar datos
Registrar
Resultado
Comunicar resultado
Mostrar resultado registro

1: Seleccionar dominio
7: Seleccionar proceso
8: Ingresar nuevo proceso
9: Editar objetivos de control
10: Registrar 11: Validar datos
6: Mostrar datos 12: Resultado validación

: Auditor 17: Mostrar resultado registro : Aplicacion : Ctrl Validacion
5: Cargar procesos y objetivos de control

2: Obtener procesos y objetivos de control

13: Registrar datos
3: Obtener procesos y OC.
14: Registrar
4: Retornar datos

CUS008. INGRESAR INFORMACIÓN DE LA ORGANIZACIÓN
CÓDIGO CUS008
NOMBRE Ingresar información de la organización
DESCRIPCIÓN Permite al usuario registrar los datos de la organización a auditar.
ACTORES Evaluador

PRE –
CONDICIONES
POST –
El usuario cuenta con empresas para realizar auditoría.
CONDICIONES
PRIMARIO “Mantenimiento de Organizaciones” en el menú principal.
ACTOR SISTEMA
y selecciona la opción “Mantenimiento de
“Mantenimiento de Organizaciones”.
Organizaciones” en el menú principal.
3. El usuario ingresa los datos de la
4. El sistema valida los datos ingresados
organización incluyendo las áreas
y los registra, finalmente muestra el
existentes dentro de ella, finalmente
mensaje “Registro realizado con éxito”.
presiona el botón “Guardar”.
EXCEPCIONES

incorrectos”.

RESULTADO
tarde.”
FRECUENCIA
usuario
Tabla 37. Especificación del CUS008 Ingresar información de la
organización

: Evaluador : Aplicacion : Ctrl Validacion : Ctrl Acceso Datos : BD
Ingresar organización y areas
Validar datos
Registrar datos
Registrar datos
Resultado
Comunicar resultado
Mostrar resultado

1: Ingresar organización y areas 2: Validar datos
8: Mostrar resultado 3: Resultado validación

4: Registrar datos
5: Registrar datos
6: Resultado
: Ctrl Acceso Datos : BD

CUS009. REALIZAR MANTENIMIENTO DE REGLAS
CÓDIGO CUS009
NOMBRE Realizar mantenimiento de reglas
Permite al usuario modificar o registrar nuevas reglas para el cálculo del
DESCRIPCIÓN
nivel de madurez.
ACTORES Evaluador

PRE –
CONDICIONES
POST –
El usuario cuenta con reglas actualizadas.
CONDICIONES
PRIMARIO “Mantenimiento de Reglas” en el menú principal.
ACTOR SISTEMA
y selecciona la opción “Mantenimiento de
“Mantenimiento de Reglas”.
Reglas” en el menú principal.
4. El sistema carga una lista con los
3. El usuario selecciona el proceso a objetivos de control existentes, también
modificar carga una lista con los niveles de madurez
relacionados a los objetivos de control.
5. El usuario registra los nuevos valores 6. El sistema valida los datos ingresados
para calcular el nivel de madurez. y los registra, finalmente muestra el
Finalmente presiona el botón “Registrar” mensaje “Registro realizado con éxito”.
EXCEPCIONES

incorrectos”.

RESULTADO
tarde.”
FRECUENCIA
usuario
Tabla 38. Especificación del CUS009 realizar mantenimiento de reglas

: Evaluador : Aplicacion : Ctrl Validacion : Ctrl Acceso Datos : BD
Seleccionar proceso
Obtener objetivos de control
Obtener objetivos de control
Retornar objetivos de control
Comunicar objetivos de control
Mostrar objetivos de control
Ingrresar datos de madurez y evaluación
Validar datos
Registrar datos
Registrar datos
Resultado
Comunicar resultado
Mostrar resultado

1: Seleccionar proceso
7: Ingrresar datos de madurez y evaluación 8: Validar datos
6: Mostrar objetivos de control 9: Resultado validación

: Evaluador 14: Mostrar resultado : Aplicacion : Ctrl Validacion
5: Comunicar objetivos de control

2: Obtener objetivos de control

10: Registrar datos 3: Obtener objetivos de control
11: Registrar datos
4: Retornar objetivos de control


IV. Diagrama de clases
Dominio
Nivel de Madurez
Tipo de Auditoria
0..*
1..n Proceso de Control
1..n Recomendaciones
Pregunta Objetivo de Control
1 Resultado
Alternativa 1..n
1..*
Actividad
Respuesta
Plan de Trabajo Area
Persona
Auditoria Organizacion
Usuario
Ilustración 48. Diagrama de clases de la aplicación

V. Arquitectura (esquema de componentes)
Sistema de Auditoria (main)

Administracion de la aplicacionAdministrar usuarios
Base de Datos
Reportes
Auditoria
Administrar politicas
Reporte por proceso
Plan de trabajo Administrar perfiles
Reglas de madurez
Busqueda de procesos por organizacion Reporte de Nivel de Madurez
Reporte final de auditoría

Validación Recomendaciones
Encuestas
Ilustración 49. Diagrama de componentes

VI. Arquitectura (esquema de despliegue)
Red Interna
Servidor de
Aplicacion solo Aplicaciones Servidor
de uso interno de BD
PC's auditor
PC Directivo/Gerente experto
Cliente de la
aplicacion
PC
instalado para
Evaluador
vista de reportes
PC usuarios
Administrador de la
encuestados
aplicación
Ilustración 50. Diagrama de despliegue
VII. Arquitectura Desktop
DESKTOP PRESENTACION
ENTIDADES
DE LOGICA DE
CONTROLADORAS
NEGOCIO NEGOCIO
COMPONENTES ACCESO A
LOGICOS DATOS
BASE
DE
DATOS
Ilustración 51. Diagrama arquitectura Desktop

CONCLUSIONES Y TRABAJOS FUTUROS
El diseño y posterior desarrollo de una herramienta capaz de facilitar la

tarea de planeamiento y ejecución de auditoría, permitirá a los auditores de
sistemas y responsables de áreas de TI organizar, evaluar y obtener
resultados y recomendaciones para mejorar sus procesos. Con este
proyecto de investigación se espera que los procesos y sistemas auditados
comiencen una mejora progresiva y constante, siempre haciendo un
seguimiento de la madurez de los procesos.
Antes de hacer uso de un estándar se debe evaluar entre los ya existentes

para encontrar cual es el que se adapta mejor a las necesidades y
estructura de organizacional, además, es necesario conocer la importancia y
los beneficios de su aplicación.
Mediante un adecuado seguimiento y control, los sistemas de información,

pueden otorgar ventajas competitivas para una empresa. Además, una
gestión de TI respaldada por un estándar internacional otorga un nivel de
referencia acerca de la calidad con que los procesos de TI son efectuados,
soportados y desarrollados.
Antes de empezar un proceso de auditoría se debe pensar cuál es el

objetivo de estudio de la auditoría, si es una evaluación de rutina sobre el
nivel de madurez de los procesos o si es un análisis para identificar el nivel
inicial de la organización; lo más importante a tomar en cuenta serán las
recomendaciones sobre las acciones a tomar para una mejora futura, en el
caso de que sea una evaluación exhaustiva de los procesos o sistemas lo
más importante será la planificación de tareas, evaluación de los resultados
y las recomendaciones.
Siempre se debe tomar en cuenta que las perspectivas y finalidades de un

sistema experto de apoyo es la flexibilidad, para mantener su base de
reglas actualizada, es por eso que los sistemas que apunten a obtener
resultados basados en reglas deben siempre tener la posibilidad de ser
flexibles ante las necesidades de los distintos usuarios, esto permitirá a los
sistemas ser mantenibles y adaptables.
Finalmente es importante para la correcta aplicación de este sistema que se

establezcan roles de forma adecuada y se realice una evaluación a
conciencia del estado real de los procesos de TI dentro de la organización,
de tal manera que siempre se obtengan los resultados y las
recomendaciones precisos.

TRABAJOS FUTUROS
Al tener una arquitectura base flexible y ampliamente expandible se puede

llegar a estudiar y modelar todos los procesos de COBIT, una vez evaluada
esa posibilidad se puede alimentar el sistema y soportar todos sus procesos
y objetivos de control, esto permitirá que la herramienta sea de apoyo
completo a la evaluación de cualquier organización o área de TI que lo
requiera.
En vista que los procesos y objetivos de control del COBIT pueden ser
complementados por otros estándares, se pueden adaptar dichos
estándares (Por Ejemplo: ISO) para la complementación de tareas, siempre
adaptado al modelo de trabajo y estandarizado al modelo de evaluación
planteado: Encuestas por objetivo de control, actividades y
recomendaciones por nivel de madurez.
Mediante el alineamiento de los objetivos de control con otros estándares se

puede mejorar la precisión de los resultados para aquellos procesos que no
poseen el detalle necesario que alguna organización puede requerir.

ANEXO I
GLOSARIO DE TÉRMINOS
Auditoría: La Auditoría de Software es un término general que se refiere a

la investigación y al proceso de entrevistas que determina cómo se
adquiere, distribuye y usa el software en la organización.
Base de conocimientos: es un tipo especial de base de datos para la gestión

del conocimiento. Provee los medios para la recolección, organización y
recuperación computarizada de conocimiento. Contiene conocimiento
modelado extraído del diálogo con un experto
Base de Datos: es un conjunto de datos pertenecientes a un mismo

contexto y almacenados sistemáticamente para su posterior uso.
SGBD: Sistema Gestor de Base de Datos, software de comunicación entre la

base de datos y el usuario.
Base de hechos: es un catálogo que contiene los hechos sobre un problema

que se ha descubierto durante el análisis.
Base de Reglas: es un catalogo que contiene las reglas de inferencia para la

solución de un problema o situación determinados. Se obtiene a partir del
diálogo con un experto.
Cobit: Objetivos de Control para la información y Tecnologías relacionadas

es un conjunto de mejores prácticas para el manejo de información creado
por la Asociación para la Auditoría y Control de Sistemas de Información en
1992.
COSO: Committee of Sponsoring Organizations, esta entidad emitió en

1992 un marco de control interno que es conocido actualmente como COSO.
El Control Interno — Marco Integrado, al que con frecuencia se hace
referencia como "COSO" brinda una base sólida para establecer los sistemas
de control interno y determinar su eficacia.
Diccionario de Datos: Un diccionario de datos es un conjunto de metadatos

que contiene las características lógicas y puntuales de los datos que se van
a utilizar en el sistema que se programa, incluyendo nombre, descripción,
alias, contenido y organización.
Framework: estructura conceptual y tecnológica de soporte definida,

normalmente con artefactos o módulos de software concretos, con base en
la cual otro proyecto de software puede ser organizado y desarrollado.
Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje
interpretado entre otros programas para ayudar a desarrollar y unir los
diferentes componentes de un proyecto.

Gobierno de TI: Es una estructura de relaciones y procesos para dirigir y

controlar la empresa con el objeto de alcanzar los objetivos de la empresa y
añadir valor mientras se equilibran los riesgos y el retorno sobre TI y sus
procesos.
ISACA: Asociación para la Auditoría y Control de Sistemas de Información

(en inglés Information Systems Audit and Control Association)
ISO: International Organization for Standardization, es el organismo

encargado de promover el desarrollo de normas internacionales de
fabricación, comercio y comunicación para todas las ramas industriales a
excepción de la eléctrica y la electrónica. Su función principal es la de
buscar la estandarización de normas de productos y seguridad para las
empresas u organizaciones a nivel internacional.
ITIL: es un marco de trabajo de las buenas prácticas destinadas a facilitar la

entrega de servicios de tecnologías de la información.
Matriz RACI: La matriz de la asignación de responsabilidades (RACI por sus

siglas en inglés) se utiliza generalmente para relacionar actividades con
recursos (individuos o equipos de trabajo). De esta manera se logra
asegurar que cada uno de los componentes del alcance esté asignado a un
individuo o a un equipo.
Metadata: datos estructurados y codificados que describen características

de instancias conteniendo informaciones para ayudar a identificar,
descubrir, valorar y administrar las instancias descritas.
Middleware: es un software de conectividad que ofrece un conjunto de

servicios que hacen posible el funcionamiento de aplicaciones distribuidas
sobre plataformas heterogéneas. Funciona como una capa de abstracción de
software distribuida, que se sitúa entre las capas de aplicaciones y las capas
inferiores (sistema operativo y red)
PMBOK: es un estándar en la gestión de proyectos desarrollado por el

Project Management Institute (PMI). La misma comprende dos grandes
secciones, la primera sobre los procesos y contextos de un proyecto, la
segunda sobre las áreas de conocimiento específico para la gestión de un
proyecto.
Sarbanes-Oxley: es una ley de Estados Unidos también conocida como el

Acta de Reforma de la Contabilidad Pública de Empresas y de Protección al
Inversionista, nace en Estados Unidos con el fin de monitorear a las
empresas que cotizan en bolsa, evitando que las acciones de las mismas
sean alteradas de manera dudosa, mientras que su valor es menor. Su
finalidad es evitar fraudes y riesgo de bancarrota, protegiendo al inversor.
Sistema Experto: es un software desarrollado para emular el

comportamiento de un experto en un dominio concreto y en ocasiones son
usados por éstos. Con los sistemas expertos se busca una mejor calidad y

rapidez en las respuestas dando así lugar a una mejora de la productividad

del experto.
UML: Unified Modeling Language o Lenguaje Unificado de Modelado, es un

lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema. UML ofrece un estándar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos de negocio
y funciones del sistema, y aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases de datos y componentes
reutilizables.

BIBLIOGRAFIA
[COBIT 4] COBIT 4.1 (versión en Español)

IT Gobernance Institute, 2007
[COBIT G] COBIT guías de auditoría (versión en inglés)

[COBIT C] COBIT curso de auditoría (versión en portugués)

IT Gobernance Institute Chapter Brazil, 2006
[COBIT I] COBIT Implementation Tool Set (versión en inglés)

[ASanchez, 1991]Aplicación de los sistemas Externos en contabilidad

Antonio Sánchez Tomás, Año 1991
Departamento de Contabilidad, Universidad de Valencia. (España)
http://ciberconta.unizar.es/Biblioteca/0002/Sanchez95.html#AUDITORIA
[CBrown, 1991] Expert systems for internal auditing

Carol E. Brown, Año 1991
Instituto de Auditores Internos.
http://findarticles.com/p/articles/mi_m4153/is_n4_v48/ai_11106029
[JCScarabino, 2000] Sistemas Expertos: Aspectos técnicos

Juan Carlos Scarabino, Año 2000
Universidad Nacional de Rosario (Argentina)
http://ciberconta.unizar.es/LECCION/sistexpat/INICIO.HTML
[DLeary, 1986] Validation of Expert Systems

Daniel E. O’Leary, Año 1986
University of Southern California
DLeary, 1986] Methods of Validation Expert Systems

Daniel E. O’Leary, Año 1986
University of Southern California
[ANPP]An Expert System for Auditing of NPP Maintenance

Hung-Fa Shyu, Tsing-Tyan Yang, Charler Chang, Chuan-Heng King, Fang-
Jung Hsu - Institute of Nuclear Energy Research
Ming-Ho Lee, Yung-Fu Wu - Taiwan Power Company.
[AUDES] AudEs – An Expert System for Security Auditing

Gene Tsudik - IBM Zurich Research Laboratory, Suiza
Rita Summers IBM Centro Científico de los Ángeles
[AEthics]Dillard Yuthas - A Responsibility Ethics for Audit Expert Systems

Journal of Business Ethics

http://www.ingentaconnect.com/content/klu/busi/2001/00000030/0000000
4/00236430
[AUDIT] Apuntes de Auditoria Informática

Fco. Javier Nava Garcia
Universidad Rey Juan Carlos
http://www.escet.urjc.es/~ai/T1Apuntes.pdf
[OICM] Oracle Internal Controls Manager

Oracle
http://www.oracle.com
[DENDRAL1] Sistema Experto de Análisis Molecular

Ruth Santana Tejero
Dendral – El primer sistema basado en conocimiento
http://www.it.uc3m.es/jvillena/irc/practicas/estudios/DENDRAL.pdf
[SISGC] Sistemas de Gestión del Conocimiento

Yamile Adriana Jaime Arias
Magíster en Ingeniería de Sistemas y Computación – Universidad Nacional
de Colombia
[MILK1] MULTIMEDIA INTERACTION FOR LEARNING AND KNOWING

Universita Degli Studi di Trento
http://www.unitn.it/agenda/allegato.php?id=408
[Convera] Convera Retrieval Wire

http://yamile.jaime.googlepages.com/converaretrievalware
[ROSE, 2003] Rational Rose 2003

Rational Software Corporation
[SECBD, 2005] Implementing Database Security and Auditing

Ron Ben Natan, ELSEVIER DIGITAL PRESS USA
[SGBD, 2004] Sistemas Gestores de Base de Datos, Instituto Geográfico

Agustín Codaci.
http://www.igac.gov.co:8080/igac_web/UserFiles/File/ciaf/TutorialSIG_200
5_26_02/paginas/ctr_sistemasdegestiondebasededatos.htm#Componentes
%20de%20un%20Sistema%20de%20Gestión%20de%20Base%20de%20D
atos
[Advisorv5] Planning Advisor v.5 – Methodware

http://www.methodware.com/planning-advisor/
[Meycor Isaca] Meycor Cobit Suite

http://www.isaca.org/Template.cfm?Section=Espanol&template=/Ecommer
ce/ProductDisplay.cfm&ProductID=963
[Meycor] Meycor Cobit 4.1 MG

http://www.taringa.net/posts/downloads/2996453/Software-d-Auditoria-
Informatica,-Planeacion-y-Riesgos-de-TI.html

[DATASEC] Meycor Cobit Autoevaluación de Controles

http://www.datasec-soft.com/sp/content/view/7/12/
[Aligning Cobit] Aligning Cobit 4.1, ITIL v3 and ISO 27002 for Business
Benefit
IT Governance Institute, Office of Government Commerce © 2008 ITGI.
http://www.isaca.org/Content/ContentGroups/Research1/Deliverables/Align
ing_COBIT,ITILV3,ISO27002_Bus_Benefit_12Nov08_Research.pdf
[ICAEW]
http://www.icaew.com/index.cfm/route/158423/icaew_ga/en/Home/Institut
e_of_Chartered_Accountants_in_England_and_Wales
[ISO 9001] http://www.normasycertificaciones.com/iso-9001

Mimbela em

Cargado por

Copyright:

Formatos disponibles

Mimbela em

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Mimbela em

Cargado por

Copyright:

Formatos disponibles

Universidad Nacional Mayor de San Marcos

Universidad del Perú. Decana de América

Diseño de un sistema experto de apoyo a los procesos

Para optar el Título Profesional de Ingeniero de Sistemas

Mimbela, M. & Palomino, R. (2010). Diseño de un sistema experto de apoyo a los

Dedicado a nuestras familias, por

FISI-UNMSM Página 2 de 147

Al profesor José Pérez por su apoyo, orientación, paciencia y dedicación

A nuestros amigos de la universidad, por darnos ánimos cuando más lo

Y muy especialmente el agradecimiento a nuestros padres por su apoyo

Gracias a nuestras familias porque siempre estuvieron a nuestro lado siendo

FISI-UNMSM Página 3 de 147

(UNMSM, Pregrado, Ingeniería de Sistemas e Informática)

Tesina, Universidad Nacional Mayor de San Marcos, Facultad de Ingeniería de

FISI-UNMSM Página 4 de 147

El presente trabajo de investigación representa la conclusión de los estudios

El resultado del trabajo es el diseño de un software de apoyo a la auditoría,

El diseño propuesto representa una herramienta ampliamente flexible que

El trabajo se divide de la siguiente manera: El capítulo 1 presenta el

FISI-UNMSM Página 5 de 147

The work is divided in the following manner: Chapter 1 introduces the

FISI-UNMSM Página 6 de 147

FISI-UNMSM Página 7 de 147

DETALLE DE PROCESOS DE EVALUACION ..................................................... 68

FISI-UNMSM Página 8 de 147

Ilustración 1. Productos de COBIT 4.1 [COBIT4] ............................................... 19

FISI-UNMSM Página 9 de 147

Tabla 1. Recomendaciones por nivel de madurez [COBIT4] ................................ 23

FISI-UNMSM Página 10 de 147

El actual estado de desarrollo, administración y mantenimiento de los

Una herramienta de control es la auditoría de sistemas, la cual aporta

La palabra auditoría etimológicamente significa “oír”, y en los orígenes la

Es por los riesgos y el gran avance de las tecnologías de información (TI),

Lo expresado en el párrafo anterior es uno de los motivos por los que se

FISI-UNMSM Página 11 de 147

Los antecedentes de la auditoría podemos encontrarlos en civilizaciones

Con la aparición de los ordenadores, los sistemas informáticos y el rápido

FISI-UNMSM Página 12 de 147

En el año 1996 el Information Systems Audit and Control Association

FISI-UNMSM Página 13 de 147

DEFINICION DEL PROBLEMA

Actualmente, debido al incremento de las tecnologías de información como

El trabajo de evaluación y auditoría tiene debido al gran avance de las

Un aspecto a resaltar es que difícilmente se dispone de una herramienta

Es por eso que el problema del presente trabajo de investigación se podría

El presente proyecto propone el diseño de un sistema experto de apoyo a la

FISI-UNMSM Página 14 de 147

OBJETIVOS DEL TRABAJO

El objetivo del presente trabajo de investigación es el diseño de una

Los objetivos específicos del presente trabajo son:

 Servir de apoyo para los procesos de auditoría interna desarrollando

 Diseño de una arquitectura base, que permita soportar los procesos

 Desarrollar una demo que analice uno de los grupos de proceso de

 Mostrar en el trabajo de investigación la definición completa de los

 Desarrollo del esquema de base de datos con el repositorio con la

 Investigación de la fórmula para la presentación de resultados por

 Estudio de tareas a realizar y recomendaciones básicas que servirán

FISI-UNMSM Página 15 de 147

El presente proyecto se justifica técnicamente porque el diseño consistirá en