|1UNIVERSIDAD NACIONAL DEL SANTA

FACULTAD DE INGENIERIA

Escuela Profesional de Ingeniería de Sistemas e Informática

CURSO:
Auditoría de Sistemas
TEMA:
Auditoria de aplicaciones y base de datos
DOCENTE:
Ing. Lizbeth Briones Pereyra
INTEGRANTES:
 Avila Capristan, Diana
 Chamache Pereda, Vanesa.
 Chapa Carranza, Kathiusca.
 Cruz Cadillo, Mabel.
 Jara Espinoza, Jhoselyn.
 Lecca Reyna, Edison.
 Pasión Rodriguez, Karolay.
CICLO:
X

Octubre, 2019.
Nuevo Chimbote, Perú.
 ÍNDICE

1. ÁREA DE AUDITORIA: UNIVERSIDAD NACIONAL DEL SANTA ..................... 4

1.1. MISIÓN ................................................................................................................... 4

1.2. VISIÓN .................................................................................................................... 4

1.3. OBJETIVO .............................................................................................................. 4

1.4. OBJETIVOS ESTRATÉGICOS INSTITUCIONALES ......................................... 4

1.5. ORGANIGRAMA DE UDEMSI ............................................................................ 8

1.6. RECURSOS MATERIALES Y HUMANOS EN UDEMSI ................................... 9

1.6.1. Recursos Materiales.......................................................................................... 9

1.6.2. Recursos Humanos ........................................................................................... 9

1.7. REGLAMENTOS EXTERNOS RELACIONADOS A UDEMSI ......................... 9

1.7.1. MOF DE LA UNS................................................................................................ 9

1.7.2. ROF DE LA UNS ................................................................................................ 9

1.7.3. ESTATUTO DE LA UNS ................................................................................. 10

1.7.4. REGLAMENTOS INTERNOS RELACIONADOS A UDEMSI ..................... 10

1.7.4.1. Manual de procedimientos de la Unidad de Desarrollo, Evaluación y

Mantenimiento de Sistemas de Información .................................................................... 10

1.7.4.2. Manual de Organización y Funciones de la Unidad de Desarrollo, Evaluación

y Mantenimiento de Sistemas de Información ................................................................. 17

2. METODOLOGIA ......................................................................................................... 18

3. DESARROLLO DE LA METODOLOGIA ................................................................ 18

3.1. ETAPA DE DIAGNOSTICAR ............................................................................. 19

3.4.1 Descripción: ................................................................................................... 19

3.4.2 Procesos y herramientas: ............................................................................. 19

3.2. ETAPA DE PLANEAR ......................................................................................... 22

 3.2.1 Descripción .............................................................................................................. 22

3.2.2 Herramientas ............................................................................................................ 23

3.2.2.1 Objetivos de control COBIT............................................................................. 23

3.2.2.2 Matriz de riesgo ................................................................................................ 24

3.2.2.3 Evaluación de Impacto y de Probabilidad ........................................................ 24

3.2.2.4 Diseño de pruebas de cumplimiento................................................................. 25

3.2.2.5 Matrices de control ........................................................................................... 25

3.2.3 Aplicación de la metodología: Matriz de riesgo ...................................................... 26

3.3 ETAPA DE EJECUTAR ....................................................................................... 29

3.4 ETAPA DE REVISAR .......................................................................................... 30

3.4.1 Descripción ..................................................................................................... 30

3.4.2 Conceptos ....................................................................................................... 30

3.4.3 Herramientas ................................................................................................... 32

3.4.4 Aplicación de la metodología: Verificación de controles .............................. 35

3.5 ETAPA DE CONSERVAR ................................................................................... 38

3.5.1. Descripción ..................................................................................................... 38

3.5.2. Concepto ......................................................................................................... 38

3.5.3. Herramientas ................................................................................................... 38

3.5.4. Aplicación de la Metodología......................................................................... 39

4. PROBLEMA Y ESTRATEGIAS ................................................................................. 40

4.1. Hallazgos y recomendaciones ................................................................................... 40

5. BIBLIOGRAFIA .......................................................................................................... 44

6. ANEXOS ...................................................................................................................... 45

Anexo N° 1: Entrevista ..................................................... Error! Bookmark not defined.

1. ÁREA DE AUDITORIA: UNIVERSIDAD NACIONAL DEL
SANTA
1.1. GENERALIDADES
1.1.1. UBICACIÓN
Av. Universitaria, Nuevo Chimbote 02712

1.1.2. MISIÓN
Brindar formación profesional humanística, científica y tecnológica a los estudiantes,
con calidad y responsabilidad social y ambiental.

1.1.3. VISIÓN
Todos desarrollan su potencial desde la primera infancia, acceden al mundo
letrado, resuelven problemas, practican valores y saben seguir aprendiendo, se
asumen ciudadanos con derechos y responsabilidades y contribuyen al desarrollo
de sus comunidades y del país combinando su capital cultural y natural con
avances mundiales.

1.1.4. OBJETIVO
Establecer los lineamientos y procedimientos que regulen los servicios para el
desarrollo, evaluación y mantenimiento de sistemas de información, y que
garanticen a los usuarios la disponibilidad de los diferentes módulos del Sistema
de Información Integral de Gestión Académica y Administrativa de la
Universidad Nacional del Santa (SIIGAA-UNS), para mejorar la eficiencia de la
operación de las diversas áreas de la Institución.

1.1.5. OBJETIVOS ESTRATÉGICOS INSTITUCIONALES

Construir un sistema educativo de calidad donde todos los estudiantes tengan las
oportunidades para desarrollar al máximo su potencial (Considerando la misión
planteada anteriormente, y los objetivos del PESEM 2016 – 2021 del MINEDU).
Con la finalidad de orientar la acción de la Universidad Nacional del Santa hasta
esta meta, se han definido cinco objetivos estratégicos institucionales y 17
acciones estratégicas institucionales, las cuales deben orientar el accionar de las
unidades académicas y/o administrativas en los próximos cuatro (04) años. Los
cinco (05) objetivos estratégicos institucionales definidos son:

 Mejorar la formación profesional de los estudiantes universitarios

 Fortalecer la investigación científica y tecnológica en la comunidad
universitaria.
 Promover las actividades de extensión cultural y de proyección social para la
comunidad universitaria.
 Fortalecer la Gestión Institucional
 Fortalecer la Gestión de Riesgos de Desastres
1.1.6. ORGANIGRAMA DE LA UNS
1.1.7. ORGANIGRAMA DE VICERRECTORADO ACADEMICO

VICERRECTORADO ACADEMICO

DIRECCION DE INFORMATICA Y
DOCUMENTACIÓN (DID)

OFICINA DE TECNOLOGÍAS DE
OFICINA DE NORMALIZACION Y OFICINA DE PROYECTOS DE INNOVACION
INFORMACIÓN Y COMUNICACIONES OFICINA DEL SITEMA DE BIBLIOTECAS
GOBIERNO CORPORATIVO TECNOLOGICA
(OTIC)

UNIDAD DE DESARROLLO, UNIDAD DE GOBIERNO DE UNIDAD DE SERVICIOS DE UNIDAD DE SERVICIOS DE

EVALUACIÓN Y TI BIBLIOTECA BIBLIOTECA
MANTENIMIENTO DE
SISTEMAS DE INFORMACIÓN
(UDEMSI)

UNIDAD DE
UNIDAD DE PROCESOS UNIDAD DE PROCESOS
UNIDAD DE ESTANDARIZACION Y
TECNICOS TECNICOS
INFRAESTRUCTURA DE GESTIÓN DE PROCESOS
COMUNICACIONES,
EQUIPAMIENTO Y
SOPORTE INFORMÁTICO
UICESI
UNIDAD DE SEGURIDAD
DE LA INFORMACION

UNIDAD DE CENTRAL
TELEFONICA UCA
UNIDAD DE GESTION DE
SERVICIOS DE TI

UNIDAD DE SERVIUCIOS
ACADEMICOS USA UNIDAD DE CALIDAD DE
SW Y AUDITORIA DE TI
1.2. DATOS DE UDEMSI (UNIDAD DE DESARROLLO, EVALUACIÓN Y
MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN)
1.2.1. MISIÓN
Planear, desarrollar e implementar software para agilizar los procesos institucionales de
administración, académica e investigación de la universidad Nacional del Santa.

1.2.2. VISIÓN
Nuestra unidad proporcionando sus servicios y mejorando nuestros procesos, tiene una
visión clara de implementar una ERP.

1.2.3. OBJETIVO
Establecer los lineamientos y procedimientos que regulen los servicios para el desarrollo,
evaluación y mantenimiento de sistemas de información, y que garanticen a los usuarios
la disponibilidad de los diferentes módulos del Sistema de Información Integral de
Gestión Académica y Administrativa de la Universidad Nacional del Santa (SIIGAA-
UNS), para mejorar la eficiencia de la operación de las diversas áreas de la Institución.

1.2.4. ORGANIGRAMA DE UDEMSI

Coordinador de
Sistemas

Administrador Analista y Asistente

de Base de Datos diseñador de documentador y
y Seguridad sistemas probador

Programador Programador Programador

(Administrador) (Académico) (Servicios)
1.3. RECURSOS MATERIALES Y HUMANOS EN UDEMSI
1.3.1. Recursos Materiales
 Impresora
 Teléfono IP
 7 Computadoras de Escritorio
 Router
 Switch

1.3.2. Recursos Humanos

 Coordinador
 Administrador de Base de Datos
 Documentador
 Encargado del área de Desarrollo

1.4. REGLAMENTOS EXTERNOS RELACIONADOS A UDEMSI

1.4.1. MOF DE LA UNS
En el Manual de Organización y Funciones del Vicerrectorado Académico de la
Universidad Nacional del Santa no se encontró algún reglamento específico acerca de
UDEMSI, sin embargo, sí se identificó una función del Vicerrectorado Académico que se
relaciona o tiene relación indirectamente con UDEMSI, y esta es: “Organizar, dirigir,
ejecutar, coordinar y controlar el sistema académico de la Universidad de conformidad
con la normatividad vigente” (MOF del Vicerrectorado Académico). Dicha función nos
explica que se debe tener una ejecución y control permanente de los sistemas académicos,
por ende, el SIGGA del cual se encarga UDEMSI es uno de ellos y este debe ser
controlado para su buen funcionamiento.

1.4.2. ROF DE LA UNS

En el reglamento de Organización y funciones de la Universidad Nacional del Santa no
se encontró algún reglamento específico acerca de UDEMSI,

Sin embargo, si se encontró funciones del Vicerrectorado Académico que guardan

relación indirectamente con UDEMSI y son:

- Organizar, actualizar y mantener la custodia de los historiales académicos

relacionados con los sílabos, actas finales de notas de las asignaturas y
currículos;
 - Elaborar y adecuar permanentemente a los fines y realidad institucional, el
sistema de evaluación docente y la del desarrollo y evaluación curricular, así
como el sistema único de evaluación del estudiante

1.4.3. ESTATUTO DE LA UNS

En el estatuto de la Universidad Nacional del Santa no se encontró un reglamento
específico sobre la UDEMSI, pero se menciona como parte de las oficinas de
asesoramiento, control y apoyo de la universidad. La cual indica una de las funciones que
debe cumplir.

Art.52° Las Oficinas de la Universidad Nacional del Santa estarán encargadas de:

a. Ejecutar las políticas específicas que acuerden los órganos de alta dirección y
los órganos de gobierno, de conformidad con el presente Estatuto y Reglamento;

b. Brindar apoyo, control y asesoramiento a la Universidad en general;

c. Agilizar el flujo de información, así como los procesos y operaciones entre las
dependencias de la Universidad; y

d. Dar la orientación necesaria para la conformación de un sistema funcional en

cada sector administrativo.

1.4.4. REGLAMENTOS INTERNOS RELACIONADOS A UDEMSI

1.4.4.1. Manual de procedimientos de la Unidad de Desarrollo, Evaluación y
Mantenimiento de Sistemas de Información

PROCEDIMIENTO
NOMBRE: Procesamiento de información de Base de Datos
OBJETIVO: Brindar, de la base de datos, la información que generan las áreas de la
UNS como resultado de los trabajos diarios, y que no estén contemplados
en algún reporte del SIIGAA-UNS, y lograr la emisión e información
actualizada que permita la oportuna toma de decisiones.
FRECUENCIA: Eventual
NORMAS

Las solicitudes para el procesamiento de información de la base de datos que las áreas
de la UNS requieran, deberán ser registradas en el formato de Control de Actividades,
 además deben presentarse por escrito y tener la aprobación del jefe inmediato superior de
la UDEMSI.

La solicitud de información de base de datos debe estar acompañada de un formato

específico elaborado por parte del solicitante, de manera que se pueda brindar la
información correctamente por parte de la UDEMSI.

La información solicitada será entregada al área solicitante en forma impresa si el reporte

no consta a más de 10 hojas y en formato A5, de lo contrario será enviada en formato
PDF a través del correo institucional o grabada en un CD.

ACTIVIDAD DESCRIPCIÓN
1 Recibe la solicitud de procesamiento de información de las áreas de la UNS con
la aprobación del jefe de OTIC.
2 Completa el formato de Control de Actividades en original, con los datos
necesarios para atender las solicitudes recibidas por las áreas de la UNS (el
formato del reporte por parte del área solicitante debe ir acompañado al Control
de Actividades)
¿Es comprensible el formato?
2A En caso de que el formato no es comprensible:
Se comunica o acude al área solicitante y realiza entrevistas al personal para
conocer los requerimientos del procesamiento de la información.
3 En caso de que el formato es compresible:
Analiza y determina los procesos a desarrollar que atiendan las necesidades de
las áreas de la UNS.
4 En caso de que el reporte sea menor a 10 hojas, se procede a imprimir el reporte
solicitado o de lo contrario se transforma en formato pdf, respetando el formato
que del área solicitante ha entregado.
5 Envía al área solicitante el reporte (impreso o en CD), también se le envía a su
buzón del correo institucional una copia en formato PDF.
 6 El área solicitante debe evaluar el contenido de la información proporcionada
por parte de la UDEMSI
¿Es correcto el procesamiento de información?
6A En caso de no ser correcta el procesamiento de información:
Realiza las correcciones de la información con las especificaciones de las áreas
de la UNS.
Continua con la actividad numero 4
7 En caso de ser correcto el procesamiento de información:
Recaba firma de conformidad de las áreas de la UNS en el formato de Control
de Actividades en original y lo archiva de manera cronológica permanente.

PROCEDIMIENTO

NOMBRE: Desarrollo de nuevos módulos del SIIGAA-UNS

OBJETIVO: Atender las necesidades de desarrollo de nuevos módulos del SIIGAA-UNS

en las diversas áreas de la UNS, a manera de atender las necesidades y requerimientos de
procesamiento de información actuales.

FRECUENCIA: Eventual

NORMAS

La solicitud de creación de nuevos módulos del SIIGAA-UNS se recibirá de las áreas de

la UNS por escrito o vía telefónica; así mismo deberá ser registrada en el formato de
CONTROL DE ACTIVIDADES en la UDEMSI y firmada por el personal solicitante.

El tiempo de creación del nuevo módulo del SIIGAA-UNS dependerá de la cantidad y

complejidad de los procesos a sistematizar.

La UDEMSI proporcionará la capacitación y orientación al personal usuario sobre el nuevo

módulo del SIIGAA-UNS.
La creación del nuevo módulo del SIIGAA-UNS se realizará con base en la información
que proporcionan las áreas usuarias del mismo, a través de entrevistas con el personal
involucrado, normatividad vigente y reportes con los cuales realiza su trabajo a
sistematizar. El formato para la creación de tablas viene dado por un prefijo de tres letras
que identifican al módulo involucrado (por ejemplo, el módulo de notas tiene el prefijo
nta_xxx)

El nombre de los formatos utilizados en el procedimiento se integra por las abreviaturas

de la Oficina de dependencia, la abreviatura de la Unidad, iniciales de documento y
objetivo que cumple en el mantenimiento y documentación de sistemas, por lo que se
explica a continuación:

 El formato UDEMSI-01: OTIC-UDEMSI-DOC-ERS es relativo a Oficina-

Unidad-Documentación-Especificación de Requerimientos de Software.

 El formato UDEMSI-02: OTIC-UDEMSI-DOC-DFP es relativo a Oficina-

Unidad-Documentación-Diagrama de Flujo de Procesos

 El formato UDEMSI-03: OTIC-UDEMSI-DOC-DMP es relativo a Oficina-

Unidad-Documentación-Descripción de Métodos y Procedimientos.

 El formato UDEMSI-04: OTIC-UDEMSI-DOC-DIT es relativo a Oficina-Unidad-

Documentación-Diccionario de Tablas.

 El formato UDEMSI-05: OTIC-UDEMSI-DOC-DID es relativo a Oficina-

Unidad-Documentación-Diccionario de Datos.

 El formato UDEMSI-06: OTIC-UDEMSI-DOC-DIR es relativo a Oficina-

Unidad-Documentación-Diagrama de Relaciones.

 El formato UDEMSI-07: OTIC-UDEMSI-DOC-DFD es relativo a Oficina-

Unidad-Documentación-Diagrama de Flujo de Datos.

 El formato UDEMSI-08: OTIC-UDEMSI-DOC-ESS es relativo a Oficina-

Unidad-Documentación-Entradas y Salidas del Sistema

 El formato UDEMSI-09: OTIC-UDEMSI-MAN-USU es relativo a Oficina-

Unidad-Manual-Usuario.
ACTIVIDAD DESCRIPCIÓN

1
Recibe de las áreas de la UNS, la solicitud para crear nuevos módulos del
SIIGAA-UNS de acuerdo a sus necesidades actuales en el manejo de datos.

2
Completa el formato de CONTROL DE ACTIVIDADES en original, para
indicar la actividad a realizar y establecer el periodo de atención.

3
Acude al área solicitante del nuevo módulo del SIIGAA-UNS y realiza
entrevistas con los usuarios, a fin de recopilar información que permita
determinar las necesidades.

4
Completa la solicitud de control estableciendo compromisos y recopila
información adicional necesaria para realizar el nuevo módulo SIIGAA-
UNS, elabora el documento de Especificación de Requisitos de Software.

5 Complementa el diagrama de flujo de procesos en el formato OTIC-

UDEMSI-DOC-DFP en original, para determinar los movimientos de entrada
y salida de información que requiera el módulo del SIIGAA-UNS

6 Elabora la descripción de métodos y procedimientos en el formato OTIC-

UDEMSI-DOC-DMP en original, con el objetivo de completar la
información que permita la creación del nuevo módulo del SIIGAA-UNS.

7 Elabora el diccionario de tablas en el formato OTIC-UDEMSI-DOC-DIT en

original, para modificar la base de datos del SIIGAA-UNS y crear las nuevas
tablas necesarias para el módulo.

8 Elabora el diccionario de datos de cada una de las tablas en el formato OTIC-

UDEMSI-DOC-DID en original, para crear los campos de las nuevas tablas
de la base de datos.

9 Elabora el diagrama de relaciones en el formato OTIC-UDEMSI-DOC-DIR

en original, para determinar la conexión que existe entre las tablas de la base
de datos del SIIGAA-UNS con las nuevas tablas del módulo nuevo.

10 Elabora el diagrama de flujo de datos en el formato OTIC-UDEMSI-DOC-

DFD en original, para determinar el comportamiento de la creación de los
nuevos datos del SIIGAA-UNS.
11 Elabora el formato OTIC-UDEMSI-DOC-ESS y determina las fuentes y
productos del SIIGAA-UNS en creación.

12 Realiza la programación del nuevo módulo del SIIGAA-UNS. Incluyendo la

creación de nuevas tablas o la modificación de las existentes de ser necesario.

13 Realiza pruebas de funcionalidad y operación del módulo y verifica su

correcto arranque y funcionamiento.

¿Existen fallas en el Modulo?

13A En caso de existir fallas:

Corrige las fallas detectadas en la verificación realizada al modulo

Continua con la actividad numero 13

14 En caso de no existir fallas:

Crea el Manual de Usuario en original, haciendo uso del formato OTIC-

UDEMSI-MAN-USU, detallando el procedimiento y generalidades para la
operación del módulo.

15 Presenta al área de la UNS solicitante, el módulo creado e instruye a los

usuarios sobre el funcionamiento del mismo, además entrega el Manual de
Usuario.

¿El Usuario está conforme?

15A En caso el Usuario no este Conforme:

Se toman los criterios para la corrección del módulo en base a las

observaciones del Usuario.

Continúa con la actividad número 12.

16 En caso el Usuario está conforme:

Firma la hoja de Control de Actividades de la UDEMSI, dando conformidad

al funcionamiento y operatividad del nuevo módulo.

17 Archiva de manera cronológica permanente en expediente la documentación

técnica del módulo, los formatos en original de lo siguiente:
 - OTIC-UDEMSI-DOC-ERS

- OTIC-UDEMSI-DOC-DFP

- OTIC-UDEMSI-DOC-DMP

- OTIC-UDEMSI-DOC-DIT

- OTIC-UDEMSI-DOC-DID

- OTIC-UDEMSI-DOC-DIR

- OTIC-UDEMSI-DOC-DFD

- OTIC-UDEMSI-DOC-ESS

- OTIC-UDEMSI-MAN-USU

FIN DEL PROCEDIMIENTO

1.4.4.2. Manual de Organización y Funciones de la Unidad de Desarrollo, Evaluación y

Mantenimiento de Sistemas de Información
Administrador de Base de datos y Seguridad
- Apoya y asesora durante el proceso de adquisición del sistema de gestión de base
de datos.
- Define la información que contendrán la base de datos institucional.
- Mantiene la relación y comunicación estrecha con el analista y documentador.
- Implementa, dar soporte y gestionar bases de datos institucional
- Modela, crea, configura y optimiza la base de datos, utilizando las técnicas
requeridas para ello.
- Diseña, despliega y monitoriza los servidores de bases de datos
- Diseña las estructuras de almacenamiento y estrategias de acceso al base de
datos.
- Define estándares y procedimientos para respaldar y recuperar la información
que contiene las bases de datos.
- Proporciona asesoría técnica al documentador, analista y programadores que se
encuentran desarrollando aplicaciones que crean y/o accedan a la base de datos.
- Establece el diccionario de datos
 - Mantiene al día las copias de Seguridad de la Información en la Institución.
- Mantiene la integridad de los datos y la disponibilidad.
- Diseña base de Datos de prueba para ambientes de desarrollo
- Garantiza la seguridad de las bases de datos, incluyendo Backup y recuperación
de desastres
- Produce diagramas de entidades relacionales y diagramas de flujos de datos,
normalización esquemática, localización lógica y física de bases de datos y
parámetros de tablas

2. METODOLOGIA
La metodología para auditar bases de datos, propuesta por Sandra Saucedo Mejía, Luis Alberto
Gutiérrez Díaz de León, Alejandro Ayala López y Jorge Lozoya Arandia, se fundamenta en 5
etapas las cuales se desarrollaron con base en el modelo de madurez de COBIT, cada etapa
contiene puntos de control que deben ser cubiertos y éstos están sustentados en los controles de
seguridad del estándar de seguridad ISO/IEC.

3. DESARROLLO DE LA METODOLOGIA
El modelo sobre el cual se fundamenta la metodología, en cada etapa se definen las tareas
específicas de la auditoría de base de datos acorde a los objetivos de control de ISO/IEC 27001-
27002 y COBIT, y al conjunto de directrices de "mejores prácticas" de ITIL, como se puede
observar en la siguiente figura.
3.1. ETAPA DE DIAGNOSTICAR
3.1.1. Descripción:
El objetivo general de esta etapa es obtener un panorama del estado actual de la
organización y para ello se utiliza el modelo de madurez de COBIT. El modelo considera
5 niveles de madurez que tienen asignado un valor en un rango que oscila entre 0 y 1, esto

significa que el nivel más bajo está asociado al valor 0 mientras que el nivel más alto se
asocia al valor 1.

3.1.2. Procesos y herramientas:

3.1.2.1. Método de evaluación

Para generar la información que permita cuantificar el grado de madurez

fundamentada en los objetivos de control se utiliza el método de la entrevista con
cada individuo del área de base de datos para realizar una serie de preguntas que
tienen como objetivo recabar información en un formulario previamente diseñado
para posteriormente extraerla y concentrarla de tal manera que apoyado en la
ponderación de las preguntas y las respuestas a éstas se obtenga el nivel de madurez
que presenta la organización.

Estas preguntas se definieron 5 categorías o dominios:

 Seguridad
  Responsabilidades
 Controles de la información
 Documentación de procedimientos
 Legislación en materia de uso de la información

Cada categoría contiene una serie de preguntas que van en función del número de
objetivos de control referenciados en ISO/IEC 27001-27002, que se adaptan a las
actividades específicas de la base de datos. En cada conjunto de preguntas se busca
medir que tan de acuerdo o desacuerdo están los entrevistados con los
planteamientos indicados y con base en ello se determinará el nivel de cumplimiento
de cada categoría.

3.1.2.2. Método de evaluación de preguntas

Para el cálculo del nivel de conformidad asociado a las respuestas de cada una de
las preguntas de la entrevista se ha propuesto la ponderación que se muestra en la
siguiente figura.

3.1.2.3. Cálculo del grado de madurez por categoría

Al recabar todas las respuestas de la entrevista:

 Se contabiliza el número de respuestas obtenidas para cada uno de los 3

niveles de conformidad y se anota el dato en la fila denominada “Número de
Casillas”.
 La cantidad obtenida se debe multiplicar por el valor de cumplimiento
asociado a cada casilla con la finalidad de obtener un puntaje global por nivel
de conformidad.
  Finalmente, para alcanzar la evaluación general de la categoría se suman los
puntajes globales de los 3 niveles de conformidad y se divide la sumatoria
entre el número total de preguntas de la categoría. El resultado obtenido es

el nivel de madurez de la categoría evaluada.

Después de obtener el grado de madurez por cada una de las 5 categorías y el valor
asignado a éstas, se calcula el promedio general sumando dichos valores y
dividiendo el total entre el número de categorías, el resultado obtenido es el grado
de madurez general de la organización y se llena en la siguiente ficha.
3.2. ETAPA DE PLANEAR
3.2.1 Descripción
La planeación va en función del nivel de madurez adquirido, una vez que se obtiene
el resultado de la ponderación se realiza la proyección considerando los puntos no
alcanzados para obtener el grado de madurez. Para fines de la metodología se
desarrollan las 5 categorías y en cada una de ellas se menciona de forma general lo
más importante que se debe de cumplir de acuerdo al estándar ISO/IEC 27001-
27002.
A partir de los resultados obtenidos en la primera etapa del modelo ya se conoce el
grado de madurez que tiene la organización en cada una de las 5 categorías
establecidas, de manera que la etapa de planeación deberá abarcar solamente las
tareas de aquellas categorías que aún no alcanzan el grado de madurez óptimo que
corresponden a objetivos de control no satisfechos. Las tareas de planeación se
definen de forma agrupada para cada una de las 5 categorías y son las siguientes:

A) Seguridad

La importancia que tiene la seguridad de la información y el poder que implica

manejar información es un tema muy delicado por ello las organizaciones deben
demostrar que realizan una gestión competente y efectiva de la seguridad de los
recursos y datos que gestionan como es la implementación de políticas de
seguridad, acuerdos de confidencialidad internos, acuerdos de confidencialidad
con terceros, gestión de privilegios tanto a usuarios internos como externos,
concientización del uso de la información y auditorías continuas

B) Responsabilidades

Se deben identificar los procesos relacionados con las actividades que

desarrollan los integrantes del área de bases de datos y de otras áreas que
intervienen directa o indirectamente en el manejo de la información contenida
en las bases de datos y los niveles de responsabilidad que conllevan dichas
actividades, entre los mismos.
 C) Controles de la Información

La organización debe definir un proceso para el control de los documentos y

registros, la documentación definida debe ser adecuada a la actividad y tamaño
del área, a la complejidad de los procesos y a la competencia del personal, el
control de los documentos debe permitir una gestión eficaz y eficiente de los
procesos

D) Documentación de Procedimientos

Uno de los principales inconvenientes en las organizaciones es que sus

miembros hacen las cosas de diferentes maneras sin seguir una metodología
única y uniforme, para evitar estas diferencias la práctica más habitual y que
mejores resultados ha dado globalmente es la documentación de
procedimientos y procesos de cada sector para conformar un Manual de
Procedimientos o Manual de Calidad.

E) Legislación en materia de uso de información

La organización tiene la libertad de calificar como confidencial, cualquier

documento o información que a su juicio influya directa o indirectamente en la
operación del área: métodos de negocio, documentos contractuales, propiedad
intelectual, patentes, desarrollo de nuevos productos, entre otros.
3.2.2 Herramientas
3.2.2.1 Objetivos de control COBIT
En cobit los principales objetivos de control relacionados con la base de
datos son los siguientes
Controles de origen de datos/autorización
 AC1 Procedimientos de preparación de datos
 AC2 Procedimientos de autorización de documentos fuente
 AC3 Recolección de datos de documentos fuente
 AC4 Manejo de errores en documentos fuente
Definir la Arquitectura de Información
 P02.1 Modelo Corporativo de Arquitectura de Información
 P02.2 Diccionario de Datos Corporativo y Reglas de Sintaxis de Datos
  P02.3 Esquema de clasificación de datos
 P02.4 Gestión de integridad
Gestionar Datos
 DS 11.1 Requisitos de Negocio para la Gestión de Datos
 DS 11.2 Planes de Almacenamiento y Retención de datos
 DS 11.3 Sistema de Gestión de Biblioteca de Medios
 DS 11.4 Eliminación de Datos
 DS 11.5 Copia de respaldo y restauración
 DS11.6 Requisitos de seguridad para gestión de datos
3.2.2.2 Matriz de riesgo
Es una herramienta con el cual se logra evidenciar y explotar los principales
riesgos que pueden afectan a la organización, generar consciencia de las
afecciones que podría tener y sobre todo el contar con planes de acción que
mitiguen dichos eventos.
Análisis de Riesgos
Identificación y Valoración de Riesgos
Categoría Actividad Nombre de Descripción Impacto Probabilidad Control
riesgo

categoría
categoría

Peso

Peso

3.2.2.3 Evaluación de Impacto y de Probabilidad

Luego de identificar los riesgos se valora cada uno asignándoles un peso de
acuerdo a su impacto y probabilidad, valores establecidos previamente.
Finalmente se identifican los controles que se aplican a cada riesgo
 Esto permite hacer una evaluación sencilla y rápida, donde se preste más
atención a los riesgos más relevantes (zona roja), y menos a los poco
relevantes (zona verde).
3.2.2.4 Diseño de pruebas de cumplimiento
Las pruebas a los controles tienen como objetivo evaluar la eficiencia,
eficacia y desarrollo de los controles, los cuales evitan que el riesgo se
materialice y busca verificar el cumplimiento de los procedimientos y
estándares establecidos en la organización. Se ejecuta una prueba por cada
control evaluar; el formato de la prueba incluye un objetivo para esa prueba,
la descripción paso a paso de la prueba, el desarrollo de la prueba en el cual
se presentan imágenes y gráficas que dan evidencia del proceso y finalmente
se documenta el resultado obtenido.

3.2.2.5 Matrices de control

Es una herramienta surgida de la imperiosa necesidad de accionar
CONTROLES DE SEGURIDAD
DATOS PREVENTIVOS DETECTIVOS CORRECTIVOS
Transacciones
de entrada
Registros de
Base De Datos
proactivamente a los efectos de suprimir y /o disminuir significativamente
la multitud de riesgos a los cuales se ven afectadas las organizaciones.
3.2.3 Aplicación de la metodología: Matriz de riesgo
Listado de riesgos
 RSA1-01: Perdida de integridad por permitir acceso a usuarios no
autorizados al BD
 RSA1-02: Divulgación de información
 RIA1- 01: Falta de disponibilidad debido a cambio instalado en producción
 RIA1- 02: Perdida de información por permitir actualizaciones al sistema
de catalogo
 RSA5- 05 Perdida de integridad en la información por tener activo usuarios
genéricos con privilegios
 RCA1- 01 Indisponibilidad de la información por error en backup
 RCA1- 02 Pérdida de información por omisión de backup diario
 RAA1- 02 Daño en equipo del centro de cómputo por intrusión de personal
no autorizado
 RAA2- 01 Ausencia de pisos falsos en centro de cómputo
 Empresa: Inversión Alcabama S.A

ANALISIS DE RIESGOS

IDENTIFICACION Y VALORACIÓN DE RIESGOS

Escenario Actividad Código Nombre Descripción Impacto Probabilidad Control
catego peso categ peso
ría oría
Perdida de Pérdida de integridad Configuración de
AC01 - RSA1- integridad por por permitir acceso a permisos de usuarios
SEGURIDAD Creación de 01 permitir usuarios no Mayor 4 Posibl 3 de acuerdo a roles y
LOGICA
nuevos acceso a autorizados a la BD, e perfiles establecidos
usuarios usuarios no causando información
autorizados al errada en los procesos
BD de liquidación
Divulgación Divulgación de Configuración de
RSA1- de información información por permisos de usuarios
02 permitir ingreso a Catastr Posibl de acuerdo a roles y
usuarios no ófico 5 e 4 perfiles establecidos
autorizados al BD
causando multas o
sanciones por
divulgación de
información sensible
 Falta de Falta de disponibilidad Mayor Realizar
disponibilidad por cambio instalado 5 procedimientos de
INTEGRIDAD RIA1- debido a en producción el cual Proba 4 solicitud y pruebas
AC01- 01 cambio genera retrasos en la ble de control de
Control de instalado en liquidación de cambios
cambios producción seguridad social
Perdida de Perdida de Mayor La opción de
RIA1- información información por 4 configuración del
02 por permitir permitir Impro servidor debe
actualizaciones actualizaciones al bable 1 configurarse para no
al sistema de sistema de Catalogo permitir
catalogo actualizaciones
directas en las tablas
del sistema.
3.3 ETAPA DE EJECUTAR
A partir de los objetivos de control desarrollados en la etapa 2 del modelo, ya se conoce
que se debe de cumplir y de esta manera la etapa de ejecución deberá abarcar las tareas
de aquellas categorías que aún no alcanzan el grado de madurez óptimo y están dirigidas
a los objetivos de control que aún no se cumplen.
Es muy importante señalar que muchos de los procesos de verificación cuando se desea
implantar una Base de Datos sirven a posteriori cuando se intenta auditar una Base de
Datos ya implantada. Cada vez es más importante auditar también el entorno alrededor
de la Base de Datos (por ejemplo, también el SO sobre el que está soportado, los usuarios
definidos, los paquetes de seguridad a su alrededor, las huelas para auditoría),
Auditoría del SGBD
El sistema de gestión de base de datos tiene multitud de componentes (todos auditables).
 Kernel
 Catálogo
 Utilidades de administración (descarga / recarga, rearranques, logs...)
 Pistas de auditoría (no sólo logs)
 Lenguajes de cuarta generación sobre ella
Habrá que revisar esos entornos, además de comprobar que se utilizan las propias
herramientas del SGBD para auditoría control y siguiendo las políticas y procedimientos
definidos.
Auditoría del entorno SGBD
 Software de auditoría (extracción de datos-pistas, seguimiento transacciones...)
 Monitorización y ajuste (estadísticas, tiempos, avisos degradación...)
 Sistema Operativo subyacente (control de memoria, gestión buffer, dead-lock...)
 Sistemas distribuidos (asegurar al menos funciones de administración de datos y
de bases de datos centralizadas y fuertes)
 Paquetes de seguridad (mejor si integrado en SGBD, pero se venden también
como ad-in sobre BD comerciales –a veces es malo: interface entre ellos
vulnerable)
 Diccionario de datos (ahora lo llevan todos los SGBD, pero antes había algunos
que no. Que lo lleven no significa que se use..., ni que se use bien...)
 Herramientas CASE (si existen, comprobar que se han utilizado según la
metodología y niveles de calidad/seguridad aprobados)
  L4G externos (las aplicaciones generadas con L4G externos tienen que seguir
los mismos procedimientos de petición de desarrollo y autorización –muchos
utilitarios que no es así-. Cuidado con el rendimiento –suele ser malo-. Revisar
que hacerlo en L4G ha sacado ventajas sobre L3G)
 Facilidades y aplicaciones de usuario (sobre todo las de interface gráfica).
Realmente desconectan al usuario de la estructura de datos que hay detrás, por
lo que muchas veces los usuarios sólo están preocupados de que lo que tienen
que hacer cuele con independencia de lo que hayan hecho en realidad (hay que
proteger al usuario de sus propios errores)
 Herramientas de minería de datos (controlar la política de si acceden a la propia
Base de Datos o se hace con carga en otro entorno. Si lo segundo –habitual-,
control de la política de carga y refresco de la información, control de accesos,
de usuarios y de que no se modifica la Base de Datos original (salvo petición)
por retroalimentación)

3.4 ETAPA DE REVISAR

3.4.1 Descripción
Esta etapa se enfoca a comprobar que se cumplan cada uno de los objetivos de
control especificados en la etapa de ejecución, se verifica a detalle que todo se
efectué, identificando de esta manera los puntos que se cumplen y los que no.
Pudiendo así administrar la Seguridad de la Información brindando un modelo
para el establecimiento, implementación, operación, seguimiento, revisión,
mantenimiento y mejora de un sistema de gestión de la seguridad de la
información.

3.4.2 Conceptos
Criticidad del riesgo

Se deben evaluar las consecuencias potenciales para poder evaluar su

criticidad: riesgo aceptable y riesgo residual.

Riesgo aceptable No se trata de eliminar totalmente el riesgo, ya que muchas

veces no es posible ni tampoco resultaría rentable, sino de reducir su
posibilidad de ocurrencia y minimizar las consecuencias a unos niveles que la
organización pueda asumir, sin que suponga un perjuicio demasiado grave a
todos los niveles: económico, logístico, de imagen, de credibilidad, etc. Riesgo
residual Se trata del riesgo que permanece y subsiste después de haber
implementado los debidos controles, es decir, una vez que la organización haya
desarrollado completamente un SGSI. Es un reflejo de las posibilidades de que
ocurra un incidente, pese a verse implantado con eficacia las medidas
evaluadoras y correctoras para mitigar el riesgo inherente.

Formas de afrontar el riesgo

Una empresa puede afrontar el riesgo básicamente de tres formas diferentes:

eliminarlo, mitigarlo o trasladarlo.

Eliminar el riesgo Si el riesgo es muy crítico, hasta el punto de que pueda

poner en peligro la propia continuidad de la organización, ésta debe poner
todos los medios para tratar de eliminarlo, de manera que haya una posibilidad
cero de que la amenaza se llegue realmente a producir.

Mitigarlo En la gran mayoría de ocasiones no es posible llegar a la eliminación

total del riesgo, ya sea porque es imposible técnicamente o bien porque la
empresa decida que no es un riesgo suficientemente crítico. En estos casos la
organización puede aceptar el riego, ser consciente de que la amenaza para la
información existe y dedicarse a monitorearlo con el fin de controlarlo. En
definitiva, se trata de implantar las medidas preventivas o correctivas
necesarias con el fin de reducir la posibilidad de ocurrencia o el impacto de
riesgo.

Trasladarlo Esta opción está relacionada con la contratación de algún tipo de

seguro que compense las consecuencias económicas de una pérdida o deterioro
de la información. Sea cual el plan de tratamiento elegido por la empresa, la
gestión de riesgos debe garantizar a la organización la tranquilidad de tener
suficientemente identificados los riesgos y los controles pertinentes, lo cual le
va a permitir actuar con eficacia ante una eventual materialización de los
mismos

Establecimiento de un rango para cada control

A cada punto de control se le debe asociar un rango o factor determinado. Por

ejemplo, el acceso a un área segura podría dividirse en:
 Rango 1. No hay establecida ninguna medida de seguridad.

Rango 2. Existe alguna medida de seguridad, pero no se ha establecido una

pauta concreta ni periodicidad.

Rango 3. Existen una serie de medidas establecidas, pero no se ha determinado

una evaluación de las mismas.

Rango 4. Los controles tienen establecidos una periodicidad, evaluación y

seguimiento.

Rango 5. Son actividades ligadas al propio negocio, es decir, se trata de un

factor interno de la empresa que lo gestiona y está implementada dentro de la
propia organización.

Se debe decidir qué tipo de rango necesita para cada control con el fin de
asegurar la seguridad de la información, teniendo en cuenta que los controles
de carácter preventivo son más eficaces que los correctivos.

Todos estos controles siguen un ciclo de mejora continúa vinculado al plan de

tratamiento de riesgos y asociados a la evaluación de los mismos para el cálculo
del riesgo residual, que es el riesgo bruto mitigado por los controles

3.4.3 Herramientas
3.4.3.1 Listas de Control (check-list)

La lista de control, tiene como objetivo fundamental la verificación de la

existencia de controles en cada uno de los procesos evaluados, para la
construcción de las preguntas de la lista de chequeo es necesario conocer los
objetivos de control en cada proceso, en esos objetivos de control están
descritos los controles en cada proceso de acuerdo al estándar aplicado en la
auditoría.

Diseño de una lista de control:

Una lista de control se determina la serie de ítems referidos a características,

realizaciones y actividades que requieren que el observador indicando
simplemente si se realizó o no una conducta, si una determinada característica
aparece o no en la actuación observada, etc.
 EXISTENTE CUMPLE OBSERVACION
CONTROLES
SI NO SI NO
CATEGORIA
01
02
03

3.4.3.2 Diagrama de Ishikawa

El Diagrama Causa-Efecto es llamado usualmente Diagrama de “Ishikawa”

porque fue creado por Kaoru Ishikawa, experto en dirección de empresas,
quien a su vez estaba muy interesado en mejorar el control de la calidad. Se
trata de una herramienta para el análisis de los problemas que básicamente
representa la relación entre un efecto (problema) y todas las posibles causas
que lo ocasionan, ampliamente utilizada dado que orienta la toma de decisiones
al abordar las bases que determinan un desempeño deficiente.

Estructura de diagrama Ishikawa:

La estructura del Diagrama de Ishikawa es intuitiva: identifica un problema o

efecto y luego enumera un conjunto de causas que potencialmente explican
dicho comportamiento. Adicionalmente cada causa se puede desagregar con
grado mayor de detalle en sub-causas. Esto último resulta útil al momento de
tomar acciones correctivas dado que se deberá actuar con precisión sobre el
fenómeno que explica el comportamiento no deseado.

3.4.3.3 Diagrama de Pareto

 El Diagrama de Pareto presenta el concepto de que, en la mayoría de las
situaciones, el 80% de las consecuencias son el resultado del 20% de las causas.
Esto puede ser muy útil para tratar no conformidades, identificar puntos de
mejora y definir qué planes de acción deben ser atacados primero en lo que se
refiere a la prioridad. El diagrama de Pareto muestra un gráfico de barras que
permite determinar, qué problemas se deben resolver primero. Por medio de
las frecuencias de las ocurrencias, de la mayor a la menor.

Los problemas referentes a la calidad de productos y procesos, que resultan en

pérdidas, pueden ser clasificados de la siguiente manera:

 Pocos vitales: Representan pocos problemas que resultan en grandes

pérdidas;
 Muchos triviales: Representan muchos problemas que resultan en
pocas pérdidas.

Estructura del diagrama de Pareto

 Seleccionar los aspectos que se van a analizar, los problemas y las

causas.
 Seleccionar la unidad de medida para el análisis: la cantidad de
ocurrencias, los costos u otra medida de influencia.
 Seleccionar el período de tiempo para el análisis de los datos
 Relacionar los aspectos de izquierda a derecha en el eje horizontal en
el orden de magnitud decreciente de la unidad de medida. Las
categorías que contienen la menor cantidad de aspectos pueden
combinarse en «otra» categoría, la cual se debe colocar en la extrema
derecha).
 Encima de cada aspecto, se dibuja un rectángulo cuya altura represente
la magnitud de la unidad de medida para cada aspecto.
 Construir la línea de frecuencia acumulativa sumando las magnitudes
de cada aspecto de izquierda a derecha.

Número de Casos Porcentual Porcentual

Razones
ocurrencias acumulado unitario % acumulado %
01
 02

𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑜𝑐𝑢𝑟𝑟𝑒𝑛𝑐𝑖𝑎𝑠
𝑃𝑜𝑟𝑐𝑒𝑛𝑡𝑢𝑎𝑙 𝑢𝑛𝑖𝑡𝑎𝑟𝑖𝑜 % =
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑜𝑐𝑢𝑟𝑟𝑒𝑛𝑐𝑖𝑎𝑠

𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑐𝑎𝑠𝑜𝑠 𝑎𝑐𝑢𝑚𝑢𝑙𝑎𝑑𝑜

𝑃𝑜𝑟𝑐𝑒𝑛𝑡𝑢𝑎𝑙 𝑢𝑛𝑖𝑡𝑎𝑟𝑖𝑜 % =
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑐𝑎𝑠𝑜𝑠 𝑎𝑐𝑢𝑚𝑢𝑙𝑎𝑑𝑜𝑠

3.4.4 Aplicación de la metodología: Verificación de controles

El desarrollo del plan de trabajo establecido ha permitido poder evaluar los
controles aplicados, para poder detectar los puntos débiles dentro de la
aplicación del proceso de auditoría.

EXISTENTE CUMPLE
CONTROLES OBSERVACION
SI NO SI NO
GESTION DE ACTIVOS
01 Inventario de activos Es necesario establecer el
tecnológicos y de procedimiento para la
X X
información. actualización del inventario
actual
02 Responsables de los activos La actualización es necesaria
tecnológicos debido a que es impredecible
X X
saber que pasara con los
responsables
03 Uso aceptable de los
activos tecnológicos
SEGURIDAD FÍSICA Y DEL ENTORNO
01 Controles físicos de
entrada.
02 Aseguramiento de oficinas
cuartos e instalaciones.
03 Seguridad en el cableado.
GESTIÓN DE COMUNICACIONES Y OPERACIONES
01 Separación de los
ambientes de desarrollo,
prueba y producción
02 Controles contra código
03 Controles de la red
04 Gestión de medios
removibles
05 Gestión de destrucción de
medios
INTERCAMBIO DE LA INFORMACIÓN
01 Medios físicos en transito
02 Mensajería electrónica
Se incluye en el Manual de
X X
Políticas del área.
No se lleva un control adecuado
X X
al área de desarrollo.
Aplica un acceso a través de
X X
personal.
X X Infraestructura desfasada.
No se cuenta con divisiones en
X X ambientes de pruebas y
producción.
Se cuenta con antivirus y
X X
medidas de control de detección.
Está definido el esquema
perimetral con la administración
X X
del firewall a cargo de personal
específico..
Se ha masificado el uso de
unidades externas de
X X
almacenamiento sin controles de
uso.
Solo existe la reutilización de
X X máquinas y no hay
procedimientos asociados.
La información enviada por
correspondencia se encriptan
X X
como buena práctica de
seguridad,
La seguridad se configura con
X X las aplicaciones del antivirus y
firewall.

01 Registros de auditoria
02 Monitoreo del uso del
sistema
03 Protección de los registros
04 Registros de monitoreo de
administración y
operadores
05 Registro de fallas
06 Sincronización de relojes
07 Política de control de
acceso
CONTROL DE ACCESO
01 Registros de usuarios
02 Gestión de privilegios
03 Gestión de contraseñas
04 Revisión de los permisos
asignados a los usuarios
05 Diagnostico remoto y
protección de la
configuración a la red de
trabajo
MONITOREO
Aplicación de auditoria interna y
X X
externa
X X
Se rigen a políticas
X X implementadas dentro del área,
que validan el alcance a la base
X X de datos.
X X Intento de erradicarlos
Distribución de tareas en todo el
personal, pero un escaso
X X
seguimiento y corrección de
variaciones.
Políticas establecidas y
X X
administradas
Generación de manera
X X
automática
Existe la política de control de
X X
acceso.
Tanto la política como el
Acuerdo Individual mencionan
X X
las pautas para la adecuada
gestión de contraseñas.
Verificación de privilegios
X X
Se están documentando guías de
aseguramiento para
X X
configuraciones estándar.
06 Control de conexión a la
red
07 Control de enrutamiento
El alcance de las políticas
X X incluye en el caso la
configuración de permisos.
Se debería hacer un análisis de
X X
riesgos

3.5 ETAPA DE CONSERVAR

3.5.1. Descripción
A partir de los objetivos de control que fueron identificados como cumplidos en
la etapa 4 del modelo, se deben establecer tareas para garantizar que dichos
controles se mantengan en el estado en el que se documenta y si éste no es el
óptimo se deberá recurrir a las etapas anteriores para cumplir en su totalidad con
los objetivos, de ninguna manera retroceder, siempre ver hacia adelante. Se debe
tener en cuenta lo siguiente:

 Consideraciones de riesgo de auditoría.

 Óptimo monitoreo.
 Garantizar las políticas de comunicación, estándares y procedimientos de
gobierno de TI y control.
 Emisión de una conclusión final temporal. (Velasque, 2001)

3.5.2. Concepto
Se realiza una documentación acerca de los de los accesos almacenados en la
base de datos con el fin de monitorear y tener en constancia de que la
información almacenada esté segura.

Permite responder a muchas preguntas como quién accede a la base de datos y

que controles se están llevando a cabo.

3.5.3. Herramientas
 Inventario físico: Proceso de identificación y categorización de los recursos de
información. Esto permite elaborar un diagnóstico de los recursos de
información que ofrece una determinada tecnología o sistema.
 Mapeo de información: Constituye una forma gráfica de representar los
recursos de información que hay en la organización y la interrelación entre
 éstos. Esto permite comprender los flujos, los tipos de interacciones, los
mecanismos de almacenamiento y el modo en que estos se actualizan.
 Análisis de las necesidades de información: Tiene como finalidad principal
determinar qué información requieren los usuarios y la entidad–institución–
empresa para alcanzar sus objetivos.
 ISO 9001: 2015: trae cambios muy importantes, aunque el más destacado es la
incorporación de la gestión del riesgo o el enfoque basado en riesgos en los
Sistemas de Gestión de la Calidad. Asimismo, un enfoque en una cultura
proactiva de prevención, mejora y protección; y un enfoque en calidad de
productos y servicios. (Escuela Europea de Excelencia, 2019).

3.5.4. Aplicación de la Metodología

En el caso de UDEMSI:

 Tienen auditorías externas (cada dos años) e internas (cada año) que se
realizan en UDEMSI.
 El DBA es el único en acceder a la base de datos en modo administrador, los
demás programadores en modo no privilegiado, pero solo a algunas tablas de
la base de datos.
 Dos veces al día se realiza la copia de seguridad de la BD de manera
automática. Dicha copia de seguridad es encriptada.
 Las copias de seguridad son almacenadas en disco duro externo, pero está
resguardado en una ubicación que no corresponde al área de UDEMSI.
 Cuentan con procedimientos para realizar un backups de base de datos que se
ajusta a la ISO 19001 pero no se contempla todos los parámetros de la ISO.
 Migración a un nuevo gestor de base de datos SQL Server porque aparte de
ser un sistema de gestión de bases de datos relacionales (RDBMS) de
Microsoft que está diseñado para el entorno empresarial, tiene ventajas como
escalabilidad, rendimiento, menos vulnerabilidades y herramientas de
BI(business Intelligence) en modo autoservicio.
4. PROBLEMA Y ESTRATEGIAS

4.1. Hallazgos y recomendaciones

Debilidad encontrada y/o Hallazgo

Aplicación estándar Nivel de Riesgo: Medio

Condición Soporte a Herramientas de auditoria

Causa Se trabaja con el SGBD ASA v.9.5 que tiene políticas de auditoria
antiguas.

Efecto Las herramientas antiguas no tienen bien implementadas los

estándares de auditorías actuales.

Recomendación:
Se recomienda realizar una migración de SGBD a una herramienta
empresarial más actual y estándar, puesto que las aplicaciones
estándar maduras presentan generalmente una gran cantidad de
controles integrados.

Comentarios TI La jefatura de OTIC ya considera realizar una migración de SGBD

en aproximadamente 2 años.

Debilidad encontrada y/o Hallazgo

Control de acceso Nivel de Riesgo: Medio

Condición Actualización de claves

Causa No se obliga el cambio de la contraseña de forma automática.

Efecto Existe un mayor riesgo de que las claves pueden ser obtenidas y
usadas si no se cambiar regularmente.

Recomendación: El jefe del área de OTIC debe requerir a la totalidad de empleados

del área de UDEMSI el cambio periódico de las claves.

Comentarios TI Lo que hace el sistema automáticamente es quitarle todos los

privilegios al usuario que fue retirado.

Debilidad encontrada y/o Hallazgo

Control de acceso Nivel de Riesgo: Bajo

Condición No existe un registro de Acceso denegados

Causa No se encuentran listados de todos aquellos intentos de accesos no

satisfactorios o denegados a estructuras, tablas físicas y lógicas del
repositorio, el log (registro de transacciones) de la base de datos
almacena transacción hecha a una base de datos

Efecto La posibilidad de pasar por alto algún tipo de conexión puede

convertirse en un tremendo agujero de seguridad, por lo que hay que
asegurarse de que el DBA conoce todas las posibles formas de
conectarse a la base de datos. La captura de conexiones fallidas a la
base de datos es obviamente importante, ya que nos puede ayudar a
detectar intentos de intrusión.

Recomendación: Implementar una herramienta capaz de capturar todo el contexto de

sesión sin excepciones.

Comentarios TI Se captura las sesiones y procedimiento que utilizo un

desarrollador.
 Debilidad encontrada y/o Hallazgo

Control de acceso Nivel de Riesgo: Medio

Condición Separación de pruebas y producción

Causa El control del acceso durante las pruebas de los programas y

aplicaciones es bajo.

Efecto Se distorsiona la producción de datos y los datos confidenciales

corren riesgo de exposición y perdida.

Recomendación: Las pruebas deben realizarse utilizando una base de datos de prueba
y no se trabaja en un entorno de producción, esta buena práctica
debe estar documentada.

Comentarios TI Los proyectos en curso se trabajan con una base de datos de

pruebas, pero todavía no existe en la documentación un marco de
referencia que sea aplicable a todos los proyectos.
4.2. Conclusiones

 El riesgo mayor es el que va ligado a la figura del administrador de bases de

datos (DBA). Sus actividades dan cuenta de hasta un 80 por ciento de las
amenazas que afectan a las bases de datos, y es lógico que sea así pues es quien
poseen todas las claves y conocen todas las puertas y ventanas de acceso.

 En la gestión de contraseñas que la configuración de contraseñas a utilizar por

el usuario está debe ajustarse a las buenas prácticas: No repetición contraseñas,
vigencia máxima de contraseñas de utilización de contraseña (al menos 30 días),
que las fechas de cambio de contraseñas reales se corresponden con las políticas
aprobadas.

 Se debe garantizar que el sistema operativo tiene instalados los últimos parches.

 Las herramientas de desarrollo que se utilicen como memorias y laptop son

entregadas para su desarrollo y no se permitiría el uso de dispositivos
personales.
5. BIBLIOGRAFIA
Daniel Díaz, M., & Lopez Guzmán, V. (2007). SOLUCIONES DE SOFTWARE LIBRE PARA EL
DESARROLLO DE APLICACIONES DE BASE DE DATOS. Pachuca, Hidalgo.

Escuela Europea de Excelencia. (2019). Obtenido de https://www.nueva-iso-9001-2015.com

Velasque, A. (21 de octubre de 2001). Obtenido de https://es.slideshare.net/villarrealino/cobit-

9803980
6. ANEXOS
Anexo N° 1: Check-List

CUESTIONARIO PARA AUDITORÍA DE BASE DE DATOS

A continuación, se presenta un checklist resumido para analizar el estado en que se encuentra la base de
datos.

1) Datos de los Integrantes del Grupo de Trabajo:

Apellidos y Nombres:
Apellidos y Nombres:
Apellidos y Nombres:
Apellidos y Nombres:
Apellidos y Nombres:

2) Datos Generales de la Organización:

Unidad de Desarrollo, Evaluación y Desarrollo de sistemas de Información – UDEMSI

CUESTIONARIO

1. ¿Se realiza copias de seguridad (diariamente, semanalmente, mensualmente, etc.)?

SI NO N/A

Observaciones: 2 veces al Día

2. Existe algún usuario que no sea el DBA (administrador de base de datos) pero que tenga asignado el rol DBA del
servidor?
SI NO N/A

Observaciones:

3. ¿Se encuentra un administrador de sistemas en el área que lleve un control de los usuarios?
SI NO N/A
Observaciones:

El jefe del OTIC

4. ¿Son gestionados los perfiles de acceso de estos usuarios por el administrador?
SI NO N/A

Observaciones:

5. ¿Se renuevan las claves de los usuarios de la Base de Datos?

SI NO N/A

Observaciones:

________________________________________________________________________________________________
_

6. ¿Se obliga el cambio de la contraseña de forma automática?

 SI NO N/A
Observaciones:
Lo que hace el sistema automáticamente es quitarle todos los privilegios al usuario que fue retirado

7. ¿Se encuentran listados de todos aquellos intentos de accesos no satisfactorios o denegados a estructuras, tablas físicas y
lógicas del repositorio?
SI NO N/A
Observaciones:
No, pero si quien ha entrado a que programa cuando, como, si se logueó o no, y que procedimientos utilizó.

8. ¿Posee la base de datos un diseño físico y lógico (estructura de las tablas de la base de datos)?
SI NO N/A
Observaciones:

9. ¿Las copias de seguridad se efectúan diariamente?

SI NO N/A
Observaciones:
Dos veces al día, está automatizado. Cada cierto tiempo se verifica que se hayan realizado las copias de
seguridad.

10. ¿Las copias de seguridad son encriptadas?

SI NO N/A
Observaciones:

11. ¿Se ha probado restaurar alguna vez una copia de seguridad, para probar que las mismas se encuentren bien hechas?
SI NO N/A
Observaciones:

12. ¿Los dispositivos que tienen las copias de seguridad, son almacenados fuera del edificio del área?
SI NO N/A
Observaciones:
Está en disco duro externo, pero está resguardado en una ubicación que no corresponde a esta
unidad.

13. ¿En caso de que el equipo principal que contiene la base de datos sufra una avería, existen equipos auxiliares?
SI NO N/A
Observaciones:

14. ¿Cuándo se necesita restablecer la base de datos, se le comunica al administrador?

SI NO N/A
Observaciones:
Las modificaciones son hechas íntegramente por el
DBA

15. ¿Se documentan los cambios efectuados manualmente de la base de datos?

SI NO N/A
 Observaciones:
Hasta el año pasado se hacía con un documento físico era un control de actividades así se llamaba el
documento, pero ahora lo hacemos con un sistema llamado helpdesk que utilizamos internamente ahí se
registran.

16. ¿Existe algún plan de contingencia ante alguna situación no deseada en la Base de Datos?
SI NO N/A
Observaciones:
La OTIC elaboro toda esa planificación, para todo lo que es perdida de información, anomalías que ocurren
dentro de un área de tecnología que incluido incendio, desastres naturales. Este documento lo tiene la jefatura.

17. ¿Existen log’s que permitan tener pistas de auditoría sobre las acciones realizadas sobre los objetos de la base de datos?
SI NO N/A
Observaciones:
Sentencias SQL

18. ¿Existe un contrato de confidencialidad en caso que la base de datos sea administrada o puesta en
mantenimiento por terceras partes?
SI NO N/A
Observaciones:
Para evitar fuga de información el DBA es el único con acceso a la DB y existe un compromiso verbal.

19. ¿Ha existido fuga de información en esta área?

SI NO N/A
Observaciones:
Si habido fuga de información no por personal antiguo que ha trabajo aquí, desde la creación de UDEMSI se
implementaron políticas de seguridad.

20. ¿Estos terceros notifican las acciones realizadas de mantenimiento de hardware y por ende su no disponibilidad de la base de
datos?
SI NO N/A
Observaciones:

21. ¿La comunicación para la restauración de la base de datos se establece de forma escrita?
SI NO N/A
Observaciones:

22. ¿Una vez efectuada la restauración, se le comunica al interesado?

SI NO N/A
Observaciones:
 Anexo N° 2: Entrevista 2
1) ¿Con respecto a su base de datos, cuántas tablas manejan?
2500 a 2600 tablas aproximadamente.
2) ¿Cuántos registros por tabla hay aproximadamente?
23 00 registros aproximadamente.
3) ¿Cuántos registros aproximadamente se ingresan por año?
16 000 registros por año
4) ¿Qué tipos de datos manejan?
A necesidad del programador, puede utilizar los tipos de datos convenientes
5) ¿Para las claves primarias, tienen permitido usar los tipos de llave compuesta?
Por políticas de buen programador, no están permitidos las llaves compuestas. Se crean
índices, que pueden ser compuestas para búsquedas más rápidas.
6) ¿Qué protocolo usan para conectarse a la Base de Datos?
El protocolo TCP, todo está cableado.
7) 1, ¿Cada cuánto tiempo se realiza copia de seguridad de la Base de Datos?
Dos veces al día, está automatizado. Cada cierto tiempo se verifica que se hayan realizado las
copias de seguridad.
8) ¿Se ha realizado algún control de calidad anteriormente?
El DBA debe verificar que se haya realizado las copias de seguridad restaurándolo en una
base de datos temporal.
9) ¿Tratan de implementar alguna ISO en sus procesos informáticos?
No se han aplicado todavía, solo tenemos un procedimiento para hacer el back up de base de
datos que se ajusta a la ISO 19001 pero no se contempla todos los parámetros de la ISO, solo
lo que corresponde a la base de datos.
10) ¿La copia de seguridad es encriptada?
Sí.
11) ¿Anteriormente, se les ha hecho una auditoria de base de datos?
Sí, recientemente hemos tenido un control.
12) ¿De qué dependencia viene ese control?
Contraloría hace una auditoría a la universidad. Se realiza una auditoría periódica, cada dos
años. Aparte se realiza una auditoría externa. La universidad también tiene su área de
auditoría.
13) ¿La Universidad cada cuanto tiempo realiza auditoria?
En esta área, a lo mucho cerca de 5 años.
14) ¿Los dispositivos que tienen las copias de seguridad, son almacenados fuera del área?
Está en disco duro externo, pero está resguardado en una ubicación que no corresponde a esta
unidad.
15) ¿Aparte del DBA, hay otra persona que accede a la Base de Datos?
Modo administrador solo el DBA. Los demás pueden acceder de modo no privilegiado, solo
a ciertas tablas.
16) ¿El control de la Base de Datos soporta herramientas de Auditoria?
Tenemos la versión 9.5 que tiene sus políticas de auditoria, pero no contemplan los que tienen
ahora, son versiones antiguas. Ya empezamos a migrar, tenemos la necesidad de migrar, pero
es un costo y un tiempo para hacerlo. Está programado la migración de la Base de datos dentro
de dos años.
17) ¿Cuáles son las principales razones para migrar de Base de Datos?
Por los tipos de datos que necesitamos, por ejemplo, guardar imágenes, los sistemas
informáticos actuales necesitan que capturemos imágenes. Para un postulante, se necesita que
suba su foto, su certificado de estudios, algo que nosotros no podemos almacenar, necesitamos
tener un servidor File para guardad esos archivos, cuando en realidad podemos guardarlo en
la base de datos, una base de datos más robusta como SQL Server u Oracle.
18) ¿La información que tienen desde que año es?
El SIIGAA se implementa en el año 2006, pero se alimenta de información de un sistema
multi-data, no se ha perdido información en la parte académica, solo se ha migrado. En la
parte administrativa es totalmente nueva a partir del 2006, pero si hablamos de todo en
conjunto a partir del 2006 pero con data de los años anteriores, por eso que los chicos de años
anteriores aún mantienen sus certificados, su consolidado está dentro de nuestro sistema.
19) ¿A parte del tipo de datos, cual es el otro motivo por el cual piensan migrar?
Muy aparte del tipo de dato también son las herramientas de auditoria que tienen mejores
herramientas, método y técnicas para recuperación de información en el caso de fallas, no ha
existido hasta el momento con el ASA 9.5 caídas abruptas o perdida de información relevante
eso no quiere decir que ello no va a ocurrir, mientras los softwares de desarrollo de aplicación
van incrementándose probablemente tengamos más errores o problemas para poder programar
o utilizar esa misma base de datos , ya se ha tenido cuando se ha pasado a java por ejemplo ,
los primeros años que han tenido su sistema de alumnos tenía muchas fallas , se caída
constantemente , perdida de información cuando se realizaba registro en el sistemas, eso era
porque no se sabía cómo trabajar el jsf que es la forma que se está utilizando para el desarrollo
web con el ASA 9.5 , al final se encontró una herramienta que funciona con la 11 pero ha
 respondido para la versión 9.5 , pero si nunca se hubiera probado la 11 no nos habríamos dado
cuenta que también funciona con el ASA 9.5 porque no existía un framework para trabajar el
jpa que utilizamos para la base de datos para la versión 9.5 , en realidad no estaba en sus
planes utilizar la versión 9.5 para la conexión de la base de datos o persistencia para una BD
con java.
20) ¿En cuanto a la persistencia usan hibernite o usan otro?
Jpa que es persistencia en java

21) Si ven es cierto dice que nunca se ha tenido una caída grave dentro de la base de datos,
pero en el caso de que exista hay algún plan de contingencia preparado
Exacto si existe
22) ¿Y eso ya lo tienen documentado en informe personales dentro del área?
Eso no corresponde a nosotros, la OTIC tuvo en su momento un personal que correspondía a
seguridad, eran otra área que eran los encargados de elaborar toda esa planificación, para todo
lo que es perdida de información, anomalías que ocurren dentro de un área de tecnología que
incluido incendio, desastres naturales. Este documento lo tiene la jefatura, pero no lo tenemos
nosotros, pero se ha pedido porque es una herramienta que nos sirve para hacer simulacros y
prever en el caso de que suceda.
23) En cuanto a los cambios que se hace en la base de datos, se documentan cuando se hacen
alguna modificación
Si, hasta el año pasado se hacía con un documento físico era un control de actividades así se
llamaba el documento, pero ahora lo hacemos con un sistema llamado helpdesk que
utilizamos internamente ahí se registran , cada vez que algunas de mis compañeras quiere
hacer un update o un insert into en una tabla o hacer una consulta en las tablas , como ellas
no pueden hacerlo simplemente lo solicitan a través del helpdesk al DB y este recibe un aviso
en el sistema helpdesk para ejecutar algo pero lo valida primero y después lo ejecuta , esa es
la rutina.
24) ¿Actualmente han tenido en la base de datos?
Más allá del corte eléctrico que es un problema que no se puede prever, no hemos tenido
problema, pero hay problemas de consistencias en algunas bases de datos cuando alguien
ingresa data, pero en los programas se trata de poner sistemas que no alteren o que involucren
esa alteración en la base de datos, no hemos tenido ninguna caída o mal ingreso de una data
que no corresponde, por ejemplo si es un entero y tú le quiere meter una letra el sistema
 primero no debe permitir así de simple y la base de datos se protege así mismo , estamos
hablado de ASA 9.5 pero si tiene protección contra eso , solo te manda un mensaje de error
pero no se cae , no como otras base de datos antiguas que tú le metías una letra y colapsaba ,
corrompía la base de datos , no hemos tenido hasta el momento en nuestra base de datos.
25) ¿A existido alguna fuga de información?
No podemos negar algo que es cierto, si habido fuga de información no por personal antiguo
que ha trabajo aquí, solo que antes no había políticas de seguridad, cuando el siga se crea y
hablo del siga, porque UDEMSI se crea en el 2014, solo era un proyecto desarrollo de
software que estaba siendo desarrollado por 11 programadores en el cual todos tenían acceso
a la base de datos y todos podían acceder de cualquier modo, cuando me pusieron de
coordinador en el 2016 empiezo a separar las cosas y a poner las políticas de seguridad , me
costó porque es hacer un cambio de mentalidad con los que estábamos ,pero fue más fácil
para los nuevos porque solo se le dan las políticas , pero con los chicos antiguos fue más
complicado a que se cambien a las políticas o a la forma de trabajo que teníamos antes , pero
es un cambio a bien porque si todos hubiéramos seguido así , la fuga de información hubiera
continuado , el simple hecho de llevar en mi USB parte de la base de datos es fuga de
información aun así lo utilice para bien o mal, simplemente el hecho de tener los algoritmos
o software que desarrollamos aquí fuera de la universidad es fuga de información ,se está
evitando eso ahora con la no disponibilidad total a la base de datos , el guardado rutinario de
los algoritmos en nuestro sistema , pero es imposible al 100% resguardar toda la información
pero al menos garantizamos que la información correcta se quede con nosotros y ahora si
evitamos la data que es la base de datos , ya no hay fuga de información , talvez por ahí tengan
nuestra estructura de la base de datos pero jamás la data actual que corresponde.
26) ¿Respecto a eso cada cuanto es el tiempo de actualización de las claves para acceder,
existe un control en eso?
Existe un módulo del SIGGA que es el modulo Escalafón, en el cual la unidad escalafonario
de la UNS hace la eliminación o anulación de un usuario cuando ya deja de trabajar en la
universidad, lo que hace el sistema automáticamente es quitarle todos los los privilegios a ese
usuario que fue retirado.
En caso de que un usuario es despedido o ya no trabaje pero maneje una clave aparte como
trabajador, por ejemplo acceso para su computador, debe entregar la clave antes de retirarse
y el jefe de área se encargará de darle el uso correspondiente.
27) Para la seguridad de la base de datos, ¿existe prueba de inyecciones SQL?
 Las inyecciones se dan a través de las aplicaciones; no trabajamos SQL en aplicaciones web
pero tratamos de utilizar sentencias JPQL(Java Persistence Query Language) que son netas
de la persistencia. Hasta el momento no hemos observado que algún usuario se haya quejado
de una falla en su sistema como una nota mal colocada, un docente que haya dicho que puso
una nota y luego otra. No garantizamos en un 100% que haya existido inyección porque hay
un montón de formas y no todas se pueden detectar para poder corregirlas.
28) ¿La conexión a la BD está permitida por un firework?

Si eso lo maneja la de Oficina de Tecnología de Información y Comunicación, actualmente

si entran a su aplicación todo está configurado con un .htps que corresponde a una
certificación digital, pues todos los accesos internos y externos de la universidad tienen
conexión con ese certificado el cual cada año se contrata. Todos los puntos de red están
validados en un inventario, podemos acceder quien está accediendo en qué punto y con qué
MAC de todas las máquinas que están en inventario en la universidad.

29) ¿Si hay un cambio o limitan algo, es acción se va a una tabla en la base de datos?
No, desde ese punto pero si quien ha entrado a que programa cuando, como, si se logueó o
no, y que procedimientos utilizó, eso sí está en tabla a través del sistema de pasaporte, pero
no directamente un insert into, un delete eso no, sino que procedimiento de que botón eso sí.
Acciones del usuario pero no sentencias, eso ya está en el log de la base de datos.
30) ¿Lo anterior es un tipo de auditoría?
Claro, si para auditoría nos sirve el sistema de pasaporte, cuando nos han pedido registro de
acceso eso está en el pasaporte, cuando nos han pedido procedimientos a la base de datos,
siempre hemos dicho que está en el log de la bd. Y no en una tabla porque sufre vulnerabilidad
pero un log jamás porque no lo pueden así nomas controlar.
31) ¿A pesar que ustedes tienen ya un modelo lógico, se pueden estructurar las tablas?
Dependiendo del programador, en caso lo sugiera la modificación de una tabla se hace, es
decir si existe. Pero debemos recordar que tenemos un sistema integrado, es decir, que la
modificación de una tabla no solo puede afectar a un solo modulo sino a varios módulos; el
sistema de notas por ejemplo puede afectar al alumno al momento de ver sus promedios o al
docente al momento de ingresar su nota.
32) ¿Ese tipo de modificaciones lo evalúa el DBA?
Si los evalúa él.
33) ¿Ha existido problemas en la base de datos que no han podido migrar hasta el momento?
 En la base de datos nunca habido tal problema, por eso te digo que la información la tenemos
al 100%.
34) ¿Cuáles han sido los problemas más frecuentes que se le han presentado?
En la base de datos, hemos tenido tablas bloqueadas cuando no se han dado cuenta de que un
sistema estaba siendo concurrente en una tabla y bloqueaba hacia todos los demás usuarios,
error en el tipo de dato como por ejemplo la aplicación no aceptaba decimal o al contrario si
debía aceptar y el usuario no le permitía guardar notas con decimales por ejemplo, pero no
era error del sistema sino que así estaban en los reglamentos pero no fue falla del sistema sino
del usuario que no supo manejar el sistema.
35) ¿En cuanto al plan a de migración lo tienen para el otro año?
Sí, pero sabemos que eso conlleva a cambiar casi todas las estructuras del sistema, tenemos
que eliminar todos los sistemas desktop y pasarnos a todo lo que es java pero el java desktop
en power builder debemos desaparecerlo, es decir queremos dejar power builder porque
estamos en la versión muy antigua la 10.5.
Anexo N° 4: FOTOS

Figura N° 1 Entrada de las instalaciones de UDEMSI

Figura N° 2 Rack de servidores

Figura N° 3 Unidad de Desarrollo Evaluación y Mantenimiento de Sistemas de
Información

Figura N° 4 Unidad de Desarrollo Evaluación y Mantenimiento de Sistemas de

Información