AUDITORIA SISTEMAS UCV

FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE SISTEMAS
AUDITORIA A LA BASE DE DATOS DE LOS
LABORATORIOS ANGLOLAB S.A
INTEGRANTES DEL EQUIPO:
• CULQUICONDOR MARTINEZ, BETSY
• MENDOZA SOLÓRZANO, ROVER
• SANTOS MORÁN, JHONNY
• ZAMORA ROJAS, PAUL
PROFESOR:
ING. BALDEON BRAVO, PERCY
LIMA – PERÚ
2013

AUDITORIA DE SISTEMAS – UNIVERSIDAD CESAR VALLEJO 2
CAPÍTULO I
DATOS DE LA EMPRESA

1.1. DATOS DE LA EMPRESA
Nombre: ANGLOLAB S.A
Rubro:Medicina - Salud
Dirección: Alfredo Salazar 314 – San Isidro
Teléfono:614-8800
1.2. VISIÓN
Ser el mejor laboratorio en el país, líder en tecnología, reconocido por su
calidad y excelencia en el servicio, satisfaciendo la demanda y necesidades
de nuestros clientes, creando y fomentando una conciencia preventiva y,
de esta manera, contribuir a la mejora de la salud de nuestra comunidad.
1.3. MISIÓN
Como empresa en el rubro de la salud estamos comprometidos en brindar
una atención de laboratorio con gran calidad, calidez y profesionalismo;
contando para ello con tecnología de punta que nos permite otorgar un
servicio integral de laboratorio a todos nuestros clientes.
1.4. OBJETIVOS
El sistema de gestión de la calidad de Anglolab ha planteado los siguientes
objetivos:
Brindar atención de laboratorio con una cultura de calidad y seguridad
garantizando 0% de riesgos sobre los resultados.
Contar con equipos tecnológicos apropiados en estado operativo y
certificados lo que garantiza una efectividad de éxito en los exámenes
solicitados
Contar con stock suficiente de suministro de material de laboratorio
proveniente de proveedores que nos brindan una atención exclusiva.
Emitir informes y resultados confiables y oportunos.
Cumplir con las normas de bioseguridad vigentes.

1.5. POLÍTICA
El laboratorio clínico patológico ha establecido una política de la calidad en
beneficios de la comunidad a la que ofrece sus servicios de proveedor
independiente de ensayos en el campo de la salud. El objetivo fundamental
de esta política es conducir al laboratorio con un nivel de excelencia para
brindar:
1. Seguridad y rapidez en los análisis.
2. Una atención cálida, respetuosa y eficiente.
3. Incorporación de nuevas tecnologías analíticas.
4. Información bioquímica de utilidad.
5. Compromiso con las buenas prácticas profesionales y la calidad.
Con este fin, el directorio con el apoyo de todo su personal promueve e
implanta un sistema de mejora continua de la gestión conforme a las
normas de COLLEGUE OFAMERICAN PATHOLOGISS y asegura el
cumplimiento de los requisitos legales aplicables y otros a los que adquiera
en la seguridad de que el mismo permita mantener a lo largo del tiempo las
condiciones operativas y humanas necesarias para el logro de sus
objetivos.
1.6. SEDES
 LIMA
Clínica Angloamericana
Clínica Angloamericana – Sede La Molina
Instituto de Ginecología y Reproducción
Clínica San Gabriel
Clínica San Juan Bautista
Clínica Tezza
Cimedic
Andromed

 CUSCO
Clínica La Cultura
Clínica San José
 LAMBAYEQUE
Hospital Metropolitano Izaga
Hospital Metropolitano Conquista
1.7. GIRO DE LA EMPRESA
Otras Actividades relacionadas con la salud humana
1.8. PRINCIPALES PRODUCTOS O SERVICIOS OFRECIDOS
Realizamos exámenes de:
Bacteriología
Banco de Sangre
Bioquímica
Inmunología
Genética
Hematologia
Hematologia Especial
Imunologia
Microbiologia

CAPÍTULO II

2.1. BENEFICIARIOS:
Este trabajo permite realizar auditoria de base de datos; los destinatarios
más beneficiados serán profesionales de sistemas y auditoria que
requieran una herramienta especifica que les brinde controlar y revisar la
base de datos del sistema que se está implantando.
2.2. ALCANCE:
Con esta auditoría se pretende llevar a cabo un análisis de riesgos para el
Sistema HIGEA de los Laboratorios ANGLOLAB S.A.
Se auditaran los controles de la base de datos de la aplicación del “Sistema
Higea”, en el cual utilizaremos las buenas prácticas de la metodología
COBIT, llevando a cabo la revisión de los siguientes procesos:
PO2 DEFINIR LA ARQUITECTURA DE
LA INFORMACION
PO4 DEFINIR LOS PROCESOS,
ORGANIZACIÓN Y RELACIONES
DE TI
PO9 EVALUAR Y ADMINISTRAR LOS
RIESGOS DE TI
PO7 ADMINISTRACION DE
RECURSOS HUMANOS
AI2 ADQUIRIR Y MANTENER
SOFTWARE APLICATIVO
DS5 GARANTIZAR LA SEGURIDAD DE
LOS SISTEMAS
DS8 ADMINISTRAR LA MESA DE
SERVICIO Y LOS INCIDENTES

DS12 ADMINISTRACION DEL
AMBIENTE FISICO
DS13 ADMINISTRACION DE
OPERACIONES
Esta auditoría de base de datos sirve como una guía para la introducción
al estudio de este tema, en el cual será aplicada en el área de sistema de
los laboratorios clínicos Anglolab S.A. siendo una auditoria tipo externa,
desarrollándose en normas, estandarizaciones y procedimientos que
pautan las actividades relacionadas con la protección de base de datos.
Podemos llevar a cabo que el tiempo de duración es de 12 semanas con
un presupuesta aproximado de S/nuevos soles que ha sido autorizado por
el jefe de sistemas.
Se ha propuesto que el Jefe de Sistemas, el Asistente del Jefe de Sistemas
del área de sistemas y el área de R.R.H.H. que colaboren brindar la mayor
información que se requiera.
Así mismo se ha autorizado al área de RR.HH y Sistemas brindar solo la
documentación relacionada a la auditoria. Las entrevistas y los permisos
para el ingreso de los auditores serán notificados como mínimo con dos
días de anticipación siguiendo el cronograma que se ha desarrollado para
llevar a cabo con esta auditoría de base de datos, se reserva la
disponibilidad del tiempo de personal, dándole prioridad a sus actividades
programadas sin previo aviso. Las actividades de auditoría se realizarán
como máximo dos veces por semana, de 4:00 pm a 9:00 pm, por el tiempo
que dure la auditoria. El costo de la auditoria no podrá exceder de lo
presupuestado, de ser así debe ser sustentado con documentos.
2.3. OBJETIVOS DE LA AUDITORIA
2.3.1. OBJETIVOS GENERALES
Realizar una evaluación y diagnóstico sobre la base de datos en el
área de sistemas de la empresa ANGLOLAB S.A.

2.3.2. OBJETIVOS ESPECÍFICOS
a) Identificar la estructura organizacional de la empresa (PO4.5)
b) Verificar la Definición de estructuras físicas y lógicas de Base de
Datos.
c) Evaluar los estándares de diseño de la BD de desarrollo.
d) Evaluar el contenido del diccionario de datos. (PO2.2)
e) Evaluar los requisitos de los elementos del diccionario de datos.
f) Verificar el uso de una metodología para el diseño de la Base de
Datos.
g) Evaluar el control de la integridad y seguridad de los datos.
h) Evaluar los controles de los Procedimientos de respaldo y de
recuperación de datos.()
i) Evaluar la administración de las sesiones de usuarios de la Base
de Datos.
j) Evaluar el Monitoreo y el rendimiento del SGBD.
k) Evaluar la arquitectura de red con acceso a la Base de Datos.
l) Verificar la satisfacción del cliente con respecto a la base de
datos.
m) Verificar el funcionamiento de los servicios que brinda la Base de
datos.

n) Verificar la documentación existente con respecto a todos los
procesos de la Base de Datos.
o) Evaluar el Soporte y mantenimiento de la Base de Datos.
p) Evaluar el manejo que se le da a los datos en la Base de Datos.
q) Evaluar la competencia del personal y la capacitación que se les
brinda con respecto a nuevas herramientas. (PO7.7)

CAPÍTULO III
METODOLOGIA
3.1. METODOLOGIA TRADICIONAL PARA AUDITORIA DE LA BASE DE
DATOS
Esta metodología ayudara al auditor para revisar el entorno con la ayuda
de una lista de control o mejor llamada como Checklist, que costa de una
serie de cuestiones a verificar. En el cual se colocara “S” si la respuesta es
afirmativa, “N” si la respuesta es negativa o “NA” si no aplica.

3.2. METODOLOGIA COBIT:
Los Objetivos de Control para la Información y la Tecnología
relacionada
(COBIT®) brindan buenas prácticas a través de un marco de trabajo de
dominios y procesos, y presenta las actividades en una estructura
manejable y lógica. 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 asegurarán la entrega del servicio y
brindaran apoyo cuando las cosas no vayan bien. Para que la TI tenga
éxito en satisfacer los requerimientos del negocio, la dirección debe
implantar un sistema de control interno o un marco de trabajo. El marco de
trabajo de control COBIT contribuye a estas necesidades de la siguiente
manera:
Estableciendo un vínculo con los requerimientos del negocio.
Organizando las actividades de TI en un modelo de procesos
generalmente aceptado.
Identificando los principales recursos de TI a ser utilizados.
Definiendo los objetivos de control gerenciales a ser considerados.
En resumen, para proporcionar la información que la empresa necesita
para lograr sus objetivos, los recursos de TI deben ser administrados por
un conjunto de procesos agrupados de forma natural.
Primero, la dirección requiere objetivos de control que definan la última
meta de implantar políticas, procedimientos, prácticas y estructuras
organizacionales diseñadas para brindar un nivel razonable para garantizar
que:
Se alcancen los objetivos del negocio.
Se prevengan o se detecten y corrijan los eventos no
deseados.
En segundo lugar, en los complejos ambientes de hoy en día, la dirección
busca continuamente información oportuna y condensada, para tomar

decisiones difíciles respecto a riesgos y controles, de manera rápida y
exitosa. ¿Qué se debe medir y cómo?
Las empresas requieren una medición objetiva de dónde se encuentran y
dónde se requieren mejoras, y deben implantar una caja de herramientas
gerenciales para monitorear esta mejora.
En esta imagen podemos observar algunas preguntas frecuentes y las
herramientas gerenciales de información usadas para encontrar las
respuestas donde requieren de indicadores, marcadores de puntuación que
utilizan las mediciones y los Benchmarking que requieren una escala de
medición.
Lo que podemos observar se define en:
Benchmarking de la capacidad de los procesos de TI, expresada
como modelos de madurez, derivados del Modelo de Madurez de
la Capacidad del Instituto de Ingeniería de Software
Metas y métricas de los procesos de TI para definir y medir sus
resultados y su desempeño, basados en los principios de balanced
business Scorecard de Robert Kaplan y David Norton

Metas de actividades para controlar
Los productos COBIT se han organizado en tres niveles diseñados para
dar soporte a:
Administración y consejos ejecutivos
Administración del negocio y de TI
Profesionales en Gobierno, aseguramiento, control y seguridad.
3.2.1. COMO SATISFACE COBIT LA NECESIDAD
Como respuesta a las necesidades descritas en la sección anterior,
el marco de trabajo COBIT se creó con las características
principales de ser orientado a negocios, orientado a procesos,
basado en controles e impulsado por mediciones.
Orientado al negocio
La orientación a negocios es el tema principal de COBIT. Está
diseñado para ser utilizado no solo por proveedores de servicios,
usuarios y auditores de TI, sino también y principalmente, como
guía integral para la gerencia y para los propietarios de los
procesos del negocio. El marco de trabajo COBIT se basa en el
siguiente principio:
Proporcionar la información que la empresa requiere para lograr
sus objetivos, la empresa necesita administrar y controlar los
recursos de TI usando un conjunto estructurado de procesos que
ofrezcan los servicios requeridos de información.
El marco de trabajo COBIT ofrece herramientas para garantizar la
alineación con los requerimientos del negocio.

3.2.2. DOMINIOS
3.2.2.1. PLANEAR Y ORGANIZAR (PO)
Este dominio cubre las estrategias y las tácticas, y tiene que ver con
identificar lamanera en que TI pueda contribuir de la mejor manera al
logro de los objetivos delnegocio. Además, la realización de la visión
estratégica requiere ser planeada,comunicada y administrada desde
diferentes perspectivas. Finalmente, se debeimplementar una
estructura organizacional y una estructura tecnológica apropiada.
Este dominio cubre los siguientes cuestionamientos típicos de la
gerencia:
¿Están alineadas las estrategias de TI y del negocio?
¿La empresa está alcanzando un uso óptimo de sus
recursos?
¿Entienden todas las personas dentro de la organización los
objetivos de TI?
¿Se entienden y administran los riesgos de TI?

¿Es apropiada la calidad de los sistemas de TI para las
necesidades del negocio?
3.2.2.2. ADQUIRIR E IMPLEMENTAR (AI)
Para llevar a cabo la estrategia de TI, las soluciones de TI necesitan
seridentificadas, desarrolladas o adquiridas así como la
implementación e integraciónen los procesos del negocio. Además,
el cambio y el mantenimiento de lossistemas existentes está cubierto
por este dominio para garantizar que lassoluciones sigan
satisfaciendo los objetivos del negocio.
Este dominio, por lo general, cubre los siguientes cuestionamientos
de la gerencia:
¿Los nuevos proyectos generan soluciones que satisfagan las
necesidades del negocio?
¿Trabajarán adecuadamente los nuevos sistemas una vez
sean implementados?
¿Los nuevos proyectos son entregados a tiempo y dentro del
presupuesto?
3.2.2.3. ENTREGAR Y DAR SOPORTE (DS)
Este dominio cubre la entrega en sí de los servicios requeridos, lo
que incluye laprestación del servicio, la administración de la
seguridad y de la continuidad, elsoporte del servicio a los usuarios,
la administración de los datos y de lasinstalaciones operacionales.
Por lo general aclara las siguientes preguntas de la gerencia:
¿Se están entregando los servicios de TI de acuerdo con las
prioridades del negocio?
¿Están optimizados los costos de TI?

¿Es capaz la fuerza de trabajo de utilizar los sistemas de TI
de manera productiva y segura?
¿Están implantadas de forma adecuada la confidencialidad, la
integridad y la disponibilidad?
3.2.2.4. MONITOREAR Y EVALUAR (ME)
Todos los procesos de TI deben evaluarse de forma regular en el
tiempo en cuanto a su calidad y cumplimiento de los requerimientos
de control.
Este dominio abarca la administración del desempeño, el monitoreo
del control interno, el cumplimiento regulatorio y la aplicación del
gobierno.
Por lo general abarca las siguientes preguntas de la gerencia:
¿Se mide el desempeño de TI para detectar los problemas
antes de que sea demasiado tarde?
¿La Gerencia garantiza que los controles internos son
efectivos y eficientes?
¿Puede vincularse el desempeño de lo que TI ha realizado
con las metas del negocio?
Los recursos de TI son manejados por procesos de TI para lograr metas de TI que
respondan a los requerimientos del negocio. Este es el principio básico del marco
de trabajo COBIT, como se ilustra en el cubo COBIT

En detalle, el marco de trabajo general COBIT, con el modelo de procesos de
COBIT compuesto de cuatro dominios que contienen 34 procesos genéricos,
administrando los recursos de TI para proporcionar información al negocio de
acuerdo con los requerimientos del negocio y de gobierno.

3.3. OBJETIVOS DE CONTROL PARA LA AUDITORIA
3.3.1. DEFINIR LA ARQUITECTURA DE LA INFORMACION (PO2)
Control sobre el proceso TI de
Definir la arquitectura de la información
Que satisface el requerimiento del negocio de TI para
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
Enfocándose en El establecimiento de un modelo de datos empresarial
que incluya un esquema de clasificación de información que garantice la
integridad y consistencia de todos los datos
Se logra con
La asignación de propiedad de datos
La clasificación de la información usando un esquema de
clasificación acordado
Y se mide con
El porcentaje de elementos de datos redundantes / duplicados
El porcentaje de aplicaciones que no cumplen con la metodología
de arquitectura de lainformación usada por la empresa.
La frecuencia de actividades de validación de datos
PO2.2 Diccionario de datos y reglas de sintaxis de datos
Mantener un diccionario de datos empresarial que incluya las reglas de
sintaxis de datos de la organización. El diccionario facilita compartir
elementos de datos entre aplicaciones y los sistemas, fomentando un
entendimiento común de datos entre los usuarios de TI y del negocio, y
previene la creación de elementos de datos incompatibles.

3.3.2. DEFINIR LOS PROCESOS, ORGANIZACIÓN Y RELACIONES
DE TI (PO4)
Control sobre el proceso TI de
Definir los procesos, organización y relaciones de TI
Que satisface el requerimiento del negocio de TI para
Agilizar la respuesta a las estrategias del negocio mientras se cumplen los
requerimientos de gobierno y se establecen puntos de contactos definidos
y competentes
Enfocándose en
El establecimiento de estructuras organizacionales de TI transparentes,
flexibles y responsables, y en la de implementación de procesos de TI con
dueños, y en la integración de roles y responsabilidades hacia los
procesos de negocio y de decisión
Se logra con
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 los roles y responsabilidades
Y se mide con
Responsabilidades del nivel directivo sobre TI
Dirección de la gerencia y supervisión de TI
Alineación de TI con el negocio
Participación de TI en los procesos clave de decisión
Flexibilidad organizacional
Roles y responsabilidades claras
Equilibrio entre supervisión y delegación de autoridad
Descripciones de puestos de trabajo
Niveles de asignación de personal y personal clave

Ubicación organizacional de las funciones de seguridad, calidad y
control interno
Segregación de funciones
PO4.5 Estructura organizacional
Establecer una estructura organizacional de TI interna y externa que
refleja las necesidades del negocio. Además implementar un proceso
para revisar la estructura organizacional de TI de forma periódica para
ajustar los requerimientos del personal y las estrategias internas parea
satisfacer los objetivos de negocios esperados y las circunstancias
cambiantes.
PO4.8Responsabilidad sobre el riesgo, la seguridad y el
cumplimiento
Establecer la propiedad y la responsabilidad de los riesgos
relacionados con TI a un nivel superior apropiado.
Definir y asignar roles críticos para administrar los riesgos de TI,
incluyendo la responsabilidad específica de la seguridad de
información, la seguridad física y el cumplimiento.
Establecer responsabilidades 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.
Obtener orientación de la alta dirección con respecto al apetito de
riesgo de TI.
PO4.11 segregación de funciones
Implementar una división de roles y responsabilidades que reduzca la
posibilidad de que un solo individuo afecte negativamente un proceso
crítico.

3.3.3. EVALUAR Y ADMINISTRAR LOS RIESGOS DE TI (PO9)
Crear y dar mantenimiento a un marco de trabajo de administración de
riesgos. Elmarco de trabajo documenta un nivel común y acordado de
riesgos de TI,estrategias de mitigación y riesgos residuales acordados.
Cualquier impactopotencial sobre las metas de la organización, causado
por algún evento noplaneado se debe identificar, analizar y evaluar. Se
deben adoptar estrategias demitigación de riesgos para minimizar los
riesgos residuales a un nivel aceptable. Elresultado de la evaluación debe
ser entendible para los participantes y se debeexpresar en términos
financieros, para permitir a los participantes alinear losriesgos a un nivel
aceptable de tolerancia.
Control sobre el proceso TI de Evaluar y administrar los riesgos de TI
Que satisface el requisito de negocio de TI para analizar y comunicar
losriesgos de TI y su impacto potencial sobre los procesos y metas de
negocio.
Enfocándose en la elaboración de un marco de trabajo de administración
deriesgos el cual está integrado en los marcos gerenciales de riesgo
operacional,evaluación de riesgos, mitigación del riesgo y comunicación
de riesgos residuales.
Se logra con La garantía de que la administración de riesgos está
incluidacompletamente en los procesos administrativos, tanto interna
como externamente,y se aplica de forma consistenteLa realización de
evaluaciones de riesgoRecomendar y comunicar planes de acciones para
mitigar riesgos
Y se mide con Porcentaje de objetivos críticos de TI cubiertos por la
evaluaciónde riesgos.

PO9.4 Evaluación de riesgos TI
Evaluar de forma recurrente la posibilidad eimpacto de todos los riesgos
identificados, usando métodos cualitativos ycuantitativos. La posibilidad e
impacto asociados a los riesgos inherentes yresiduales se debe
determinar de forma individual, por categoría y con base en elportafolio.
3.3.4. ADMINISTRACION DE RECURSOS HUMANOS (PO7)
Control sobre el proceso de TI de administración de recursos humanos
Que satisface los requerimientos de negocio de Adquirir y mantener
una fuerza de trabajo motivada y competente y maximizar las
contribuciones del personal a losprocesos de TI.
Se hace posible a través de prácticas de administración de personal,
sensata, justa y transparentepara reclutar, alinear, pensionar, compensar,
entrenar, promover y despedir
Y se mide con
• Reclutamiento y promoción
• Entrenamiento y requerimientos de calificaciones
• Desarrollo de conciencia
• Entrenamiento cruzado y rotación de puestos
• Procedimientos para contratación, veto y despidos
• Evaluación objetiva y medible del desempeño
• Responsabilidades sobre los cambios técnicos y de mercado
• Balance apropiado de recursos internos y externos
• Plan de sucesión para posiciones clave
PO7.2 Personal calificado
El personal que se contrata para los distintos puestos de trabajo se debe
realizar una definición de requerimientos del puesto también se debe

tener en cuenta el proceso de verificación de la calificación de las
personas.
PO7.4 Entrenamiento del personal
Este entrenamiento consta de un proceso de inducción de nuevos
empleados en la empresa también consta en llevar a cabo un programa
de capacitación de acuerdo a los requerimientos de cargo y de una
proceso periódico de revisión del programa de capacitación.
PO7.7 Evaluación del desempeño del empleado
Es necesario que las evaluaciones de desempeño se realicen
periódicamente, comparando contra los objetivos individuales derivados
de las metas organizacionales, estándares establecidos y
responsabilidades específicas del puesto. Los empleados deben recibir
adiestramiento sobre su desempeño y conducta, según sea necesario.
3.3.5. ADQUIRIR Y MANTENER SOFTWARE APLICATIVO (AI2)
Control sobre el proceso TI de Adquirir y dar mantenimiento a software
aplicativo.
Que satisface el requisito de negocio de TI para construir las
aplicaciones de acuerdo con los requerimientos del negocio y haciéndolas
a tiempo y a un costo razonable.
Enfocándose en garantizar que exista un proceso de desarrollo oportuno
y confiable.
Se logra con
La traducción de requerimientos de negocio a especificaciones de
diseño.
La adhesión a los estándares de desarrollo para todas las
modificaciones

La separación de las actividades de desarrollo, de pruebas y
operativas
Y se mide con
Número de problemas en producción por aplicación, que causan
tiempo perdido significativo
Porcentaje de usuarios satisfechos con la funcionalidad entregada
AI2.3 Control y posibilidad de auditar las aplicaciones
Implementar controles de negocio, cuando aplique, en controles de
aplicación automatizados tal que el procesamiento sea exacto, completo,
oportuno, autorizado y auditable.
3.3.6. GARANTIZAR LA SEGURIDAD DE LOS SISTEMAS (DS5)
Control sobre el proceso TI de Garantizar la seguridad de los sistemas
Satisface el requisito de negocio de TI paramantener la integridad de la
información y de la infraestructura de procesamiento y minimizar el
impacto de las vulnerabilidades e incidentes de seguridad.
Enfocándose en la definición de políticas, procedimientos y estándares
de seguridad de TI y en el monitoreo, detección, reporte y resolución de
las vulnerabilidades e incidentes de seguridad.
Se logra con
El entendimiento de los requerimientos, vulnerabilidades y
amenazas de seguridad.
La administración de identidades y autorizaciones de los usuarios
de forma estandarizada.
Probando la seguridad de forma regular.

Y se mide con
El número de incidentes que dañan la reputación con el público
El número de sistemas donde no se cumplen los requerimientos
de seguridad
El número de de violaciones en la segregación de tareas.
DS5.2 Plan de seguridad de TI Trasladar los requerimientos de
información del negocio, la configuración de TI, los planes de acción del
riesgo de la información y la cultura sobre la seguridad en la información a
un plan global de seguridad de TI.
El plan se implementa en políticas y procedimientos de seguridad en
conjunto con inversiones apropiadas en servicios, personal, software y
hardware. Las políticas y procedimientos de seguridad se comunican a los
interesados y a los usuarios.
DS5.3 Administración de identidad Todos los usuarios (internos,
externos y temporales) y su actividad en sistemas de TI (aplicación de
negocio, operación del sistema, desarrollo y mantenimiento) deben ser
identificables de manera única.
Los derechos de acceso del usuario a sistemas y datos deben estar
alineados con necesidades de negocio definidas y documentadas y con
requerimientos de trabajo. Los derechos de acceso del usuario son
solicitados por la gerencia del usuario, aprobados por el responsable del
sistema e implementado por la persona responsable de la seguridad. Las
identidades del usuario y los derechos de acceso se mantienen en un
repositorio central. Se implementan y se mantienen actualizadas medidas
técnicas y procedimientos rentables, para establecer la identificación del
usuario, realizar la autenticación y habilitar los derechos de acceso.
DS5.4 Administración de cuentas del usuario Garantizar que la
solicitud, establecimiento, emisión, suspensión, modificación y cierre de
cuentas de usuario y de los privilegios relacionados, sean tomados en
cuenta por la gerencia de cuentas de usuario. Debe incluirse un

procedimiento que describa al responsable de los datos o del sistema
como otorgar los privilegios de acceso. Estos procedimientos deben
aplicar para todos los usuarios, incluyendo administradores (usuarios
privilegiados), usuarios externos e internos, para casos normales y
deemergencia. Los derechos y obligaciones relacionados al acceso a los
sistemas e información de la empresa son acordados contractualmente
para todos los tipos de usuarios. La gerencia debe llevar a cabo una
revisión regular de todas las cuentas y los privilegios asociados.
DS5.5. Pruebas, vigilancia y monitoreo de la seguridad
Garantizar que la implementación de la seguridad en TI sea probada y
monitoreada de forma pro-activa. La seguridad en TI debe ser acreditada
periódicamente para garantizar que se mantiene el nivel seguridad
aprobado. Una función de ingreso al sistema (logging) y de monitoreo
permite la detección oportuna de actividades inusuales o anormales que
pueden requerir atención.
DS5.6 Definición de incidente de seguridad Garantizar que las
características de los posibles incidentes de seguridad sean definidas y
comunicadas de forma clara, de manera que los problemas de seguridad
sean atendidos de forma apropiada por medio del proceso de
administración de problemas o incidentes.
Las características incluyen una descripción de lo que se considera un
incidente de seguridad y su nivel de impacto. Un número limitado de
niveles de impacto se definen para cada incidente, se identifican las
acciones específicas requeridas y las personas que necesitan ser
notificadas.
DS5.8 Administración de llaves criptográficas Determinar que las
políticas y procedimientos para organizar la generación, cambio,
revocación, destrucción, distribución, certificación, almacenamiento,
captura, uso y archivo de llaves criptográficas estén implantadas, para

garantizar la protección de las llaves contra modificaciones y divulgación
no autorizadas.
DS5.9 Prevención, detección y corrección de software malicioso
Garantizar que se cuente con medidas de prevención, detección y
corrección (en especial contar con parches de seguridad y control de virus
actualizados) a lo largo de toda la organización para proteger a los
sistemas de información y a la tecnología contra software malicioso (virus,
gusanos, spyware, correo basura, software fraudulento desarrollado
internamente, etc.).
DS5.11 Intercambio de datos sensitivos Garantizar que las
transacciones de datos sensibles sean intercambiadas solamente a través
de una ruta o medio confiable con controles para brindar autenticidad de
contenido, prueba de envío, prueba de recepción y no rechazo del origen.
3.3.7. ADMINISTRAR LA MESA DE SERVICIO Y LOS INCIDENTES
(DS8)
Control sobre el proceso TI de Administrar la mesa de servicio y los
incidentes
Que satisface el requisito de negocio de TI para permitir el efectivo uso
de los sistemas de TI garantizando la resolución y el análisis de las
consultas de los usuarios finales, incidentes y preguntas.
Enfocándose en una función profesional de mesa de servicio, con tiempo
de respuesta rápido, procedimientos de escalamiento claros y análisis de
tendencias y de resolución.
Se logra con
Instalación y operación de un servicio de una mesa de servicios
Monitoreo y reporte de tendencias

Definición de procedimientos y de criterios de escalamiento claros
Y se mide con
Satisfacción del usuario con el soporte de primera línea
Porcentaje de incidentes resueltos dentro de un lapso de tiempo
aceptable / acordado.
Índice de abandono de llamadas.
DS8.1 Mesa de servicios
Establecer la función de mesa de servicio, la cual es la conexión del
usuario con TI, para registrar, comunicar, atender y analizar todas las
llamadas, inciden monitoreo y escalamientoo basados en los niveles de
servicio acordados en los SLAs, que permitan clasificar y priorizar
cualquier problema reportado como incidente, solicitud de servicio o
solicitud de información. Medir la satisfacción del usuario final respecto la
calidad de la mesa de servicios y de los servicios de TI.
3.3.8. ADMINISTRACION DEL AMBIENTE FISICO (DS12)
Control sobre el proceso de TI de
Administración de instalaciones (sitios donde se procesa información)
Que satisface los requerimientos de negocio de:
Proporcionar un ambiente físico conveniente que proteja losequipos y al
personal de TI contra peligros naturales o fallashumanas
Se hace posible a través de:
La instalación de controles físicos y ambientales adecuados que sean
revisados regularmente para garantizar su adecuado funcionamiento
Y toma en consideración:
Acceso a instalaciones
Identificación del sitio (instalación)
Seguridad física
Políticas de inspección y escalamiento
Plan de continuidad de negocios y administración de crisis

Salud y seguridad del personal
Políticas de mantenimiento preventivo
Protección contra amenazas ambientales
Monitoreo automatizado
DS12.3 Acceso físico
Definir e implementar procedimientos para otorgar, limitar y revocar el
acceso a locales, edificios y áreas de acuerdo con las necesidades del
negocio, incluyendo las emergencias. El acceso a locales, edificios y
áreas debe justificarse, autorizarse, registrarse y monitorearse. Esto
aplica para todas las personas que accedan a las instalaciones,
incluyendo personal, clientes, proveedores, visitantes o cualquier tercera
persona.
3.3.9. ADMINISTRACION DE OPERACIONES (DS13)
Control sobre el proceso TI de Administrar operaciones
Que satisface el requisito de negocio de TI para mantener la integridad
de los datos y garantizar que la infraestructura de TI puede resistir y
recuperase de errores y fallas.
Enfocándose en cumplir con los niveles operativos de servicio para
procesamiento de datos programado, protección de datos de salida
sensitivos y monitoreo y mantenimiento de la infraestructura.
Se logra
Operando el ambiente de TI en línea con los niveles de servicio
acordados y con las instrucciones definidas
Manteniendo la infraestructura de TI

Y se mide con
Número de niveles de servicio afectados a causa de incidentes en
la operación.
Horas no planeadas de tiempo sin servicio a causa de incidentes
en la operación.
Porcentaje de activos de hardware incluidos en los programas de
mantenimiento.
DS13.1 Procedimientos e instrucciones de operación
Definir, implementar y mantener procedimientos estándar para
operaciones de TI y garantizar que el personal de operaciones
estáfamiliarizado con todas las entrega de turno (transferencia formal de
la actividad, estatus, actualizaciones, problemas de operación,
procedimientos de escalamiento, y reportes sobre las responsabilidades
actuales) para garantizar la continuidad de las operaciones.

CAPÍTULO IV
HERRAMIENTAS Y DESARROLLO DE
LA AUDITORIA

4.1. RECURSOS Y TIEMPO
En esta auditoria se empleará los recursos que el área de R.R H.H. nos
brindara. Por otro lado utilizaremos el recurso humano en el cual está
conformado por 5 auditores en el cual ya se ira describiendo cada uno de
los cargos dentro del MOF interno.
En los recursos materiales se utilizaran pc, laptops, el lugar (empresa),
impresora, papeles, archivadores, etc.
El tiempo se mostrara de forma detallada en el cronograma hecho en el
programa MS PROYECT.
CRONOGRAMA DE ACTIVIDADES
Durante la planeación de la auditoria se desarrolló, un cronograma de
actividades en el cual se observan los tiempos de inicio, ejecución y fin del
proyecto y de cada actividad correspondiente dentro del mismo, así mismo
incluye un apartado en donde se indica el nombre de la persona que
realizo la actividad y una gráfica de Gantt que describe todo el proceso.
Cuadro de cronograma de actividades

JEFE DE AUDITORIA
Culquicondor
Martinez, Betsy
AUDITOR SUPERVISOR
Mendoza
Solórzano, Rover
AUDITOR DE BASE DE DATOS 1
Zamora Rojas, Paul
AUDITOR DE BASE DE DATOS 2
Santos Moran,Jhonny
4.2. MOF INTERNO

4.3. MANUAL DE ORGANIZACIÓN Y FUNCIONES INTERNO
4.3.1. Finalidad
La finalidad de este manual es dar a conocer las funciones de cada
uno de los auditores que realizaran dicho trabajo en los
laboratorios clínicos ANGLOLAB S.A.
4.3.2. ESTRUCTURA ORGÁNICA
 Dirección
Jefe de Auditoría
 Supervisión
Auditor Supervisor I
 Operación
Auditor Base de Datos I
Auditor de Base de Datos II
CUADRO DE ASIGNACIÓN DE PERSONAL
Cargo Cantidad
Jefe de Auditoría 1
Auditor Supervisor 1
Auditor de Base de Datos I 1
Auditor de Base de Datos II 1

4.4. PERFIL Y FUNCIONES
Jefe de Auditoria
El jefe de auditoria tiene responsabilidades particulares que asumir,
estas responsabilidades no deben ser ignoradas. Debe realizar las
siguientes funciones:
 Determina la cantidad de trabajo.
 Nombra a los otros miembros del equipo. La base de la
selección debe ser siempre que el líder confíe y pueda
trabajar bien con los miembros del equipo, pero debe pensar
también en la necesidad de conocimiento o cualificación
especial, desarrollo personal o necesidades de formación.
Debido a las molestias que las auditorías suponen, es
recomendable que se escoja el número de miembros
suficientes para completar el trabajo en no más de tres días.
 Fija una fecha con el candidato que asegure la disponibilidad
de todas las partes. Obviamente, la notificación de las
auditorías externas debe hacerse siempre a los auditados.
 Comunicar a los miembros del equipo todos los detalles de la
logística, objetivos de la auditoría y métodos.
 Asignar tareas a los miembros del equipo, preferiblemente en
espacios de media jornada.
 Se asegura que los miembros del equipo están
completamente preparados.
Auditor supervisor
Realiza la actividad de supervisar la ejecución de la auditoria; es
responsable de dirigir el trabajo de un equipo de auditoria, su objetivo
es controlar tiempo, calidad y costo de la auditoria.

El éxito del supervisor en el desempeño de sus deberes determina el
éxito o el fracaso de los programas y los objetivos.
Conforme a las condiciones actuales, el supervisor debe ser un
profesional con la capacidad suficiente para vigilar y controlar el
cumplimiento de Normas en el cual debe tener las siguientes
características:
 Experiencia
 Capacidad de organización
 Seriedad
 Profesionalismo
 Honestidad
 Criterio técnico
 Ordenado
Auditor de Base de datos
El auditor de base de datos debe ser una persona con un alto grado
de calificación técnica y estar integrado a las nuevas tecnologías,
también debe contemplar conocimientos como:
 Desarrollo informático
 Gestión de departamento de sistemas
 Análisis de riesgo en un retorno informático
 Sistemas operativos
 Gestión de base de datos
 Redes locales
4.5. RESUMEN DE RECURSOS

4.6. TIEMPO
El tiempo que se necesitara para realizar la auditoria de calidad de software
en los laboratorios ANGLOLAB S.A es de 12 semanas, desde el 10 de
Abril del 2013 al 4 de julio.
4.7. PLANEACION
Durante la planeación de la auditoria de base de datos se tomaron diversos
aspectos en consideración, ya que una mala planeación de la auditoria
podría causar retrasos, olvidos, y no se podría dar un seguimiento lógico y
constante. La fase de planeación consta de diversas partes en las cuales
se detallan cada uno de los procedimientos y pasos a seguir dentro de la
auditoria.
Como primera instancia se reunió el equipo auditor para definir y delimitar
la auditoria con esto se lograría solo enfocarse a la base de datos y no
involucrar otras áreas o procedimientos que no estuvieran justificados y
además que causaran el retrase de algunas actividades, en base a esto se
desarrolló una lista de puntos específicos donde se quedaran por escrito
cada una de las tareas a realizar. Se realizó el cronograma de actividades
elaborado el MS proyect, en el cual se detalla el inicio, ejecución y find e
cada actividad.
Una vez terminado el cronograma se asignó las tareas y días
correspondientes a cada integrante del equipo registrándose en el mismo.
Se realizó un diagrama de bloques ordenando los siguientes puntos y que
más adelante se detallan:
Entrevista
Checklist
Oficio de requerimientos
Hallazgos
Pruebas
Análisis de riesgos

1) ENTREVISTAS: En esta parte podemos obtener las entrevistas formales
con el personal encargado tanto del sistema como del área a la que
pertenece, esto con el fin de tener una visión más clara de nuestra
auditoria para así obtener los permisos necesarios al acceso de la base de
datos, realizar las pruebas pertinentes en el sistema y documentación
requerida para realizarla.
2) CHECKLIST: en esta etapa se llevara a cabo la auditoria ya que
aplicándolo nos mostrara una visión más detallada de cómo se encuentra
el activo que se auditara.
3) OFICIO DE REQUERIMIENTOS: Este documento es realizado una vez
terminado el checklist y el cronograma de actividades para poder tener bien
claro los documentos, políticas, manuales y todo aquel escrito de forma
física o lógica que nos permitiera la comprensión de la situación actual y
que al mismo tiempo nos diera la posibilidad de recomendar mejores
prácticas para el buen funcionamiento del sistema. Este se compone por
un título, fechas de realización, persona y cargo a quien va dirigido y nos
ENTREVISTA CHECKLIST
OFICIO DE
REQUERIMIENTOS
ANALISIS DE
RIESGOS
PRUEBASHALLAZGOS

va a proponer dicha información, una breve descripción de la
documentación y por último el nombre y firma de quien lo solicita.
(ANEXO 1)
4) PRUEBAS: en esta actividad puede o no realizarse, según se considere
necesario, sin embargo , si se quiere realizar una auditoria más profunda
donde ningún punto quede sin verificar, las pruebas son necesarias ya que
no sindican si lo que se encontró en el checklist realmente se está
cumpliendo. Por lo tanto en esta actividad solo realizaremos dos pruebas
(query) para poder comprobar los tipos de cuenta de solo la base de datos,
roles y permisos de los usuarios que accedían a ella.
PRUEBA 1: podemos observar los usuarios que pueden ingresar al
sistema.
PRUEBA 2: Podemos observar los perfiles de los usuarios en el cual son
los permisos a que áreas pueden ingresar.

Por ejemplo el supervisor tiene estos permisos:
Estos son los
permisos que
tiene el
SUPERVISOR

5) HALLAZGOS: estos son los resultados de haber realizado correctamente
un buen checklist, tener la información correcta, haber hecho las pruebas,
pero lo más importante es haber realizado un análisis de riesgos que nos
permitiera identificar claramente lo que debemos corregir.
6) ANALISIS DE RIESGOS: es la base de nuestros hallazgos y
recomendaciones, sin este paso no tendríamos nada que evaluar y no se
detectarían los problemas.
4.8. HALLAZGOS
En esta fase podemos dar a conocer los errores, riesgos o alguna
anomalía que haya sido detectada, aquí se deberá tener en cuenta todos
los puntos que tuvieran un gran impacto o que interfieran con las
actividades del sistema.
1) PRIMER HALLAZGO: (PO 9.4)
a. Observación:
Se ha identificado que debido a que el sistema es reciente, aun no
se ha llevado a cabo el análisis de riesgos y pueden existir posibles
fallos, detección de amenazas y riesgos no contemplados en la BD
perjudicando así la confiabilidad, integridad del sistema, seguridad
de la información de los pacientes.
Aquí podemos
ver algunas
pestañas de
estos permisos.

b. Causa: El sistema HIGEA será llevado a producción en Junio del
2013 y aun no se ha llevado a cabo un análisis de riesgo para
prevenir problemas o riesgos en momentos de producción.
c. Recomendación: antes o después de llevar a cabo la
implementación del producto se debería realizar una auditoría a
corto plazo para obtener el análisis de riesgos ya que se debe tener
mayor importancia en prevenir el mal funcionamiento del Sistema
HIGEA.
2) SEGUNDO HALLAZGO: (PO7.2)
a. Observación: se identifico que al contratar un personal no tienen un
lista de requerimientos para llevar a cabo el cargo que se le asignara
por lo tanto no cuenta con un proceso de calificación de personas
sin embargo son algunos del personal de trabajo que no son
calificados para trabajar en el cargo signado.
b. Causa: Los laboratorios Anglolab reciben las renuncias del personal
sin tener en cuenta que estos deben ser presentados con tiempo ya
que al retirarse el personal no cuentan con otro para suplantar el
puesto vacio, es decir que la búsqueda del personal nuevo es con
mayor apuro sin tener en cuenta los requisitos que este debe tener.
c. Recomendación: Se debe aclarar al personal que las renuncias
deben ser entregadas con mayor tiempo para que los gerentes o
jefes puedan buscar un personal adecuado que cumplan los
requerimientos del listado.
3) TERCER HALLAZGO: (PO7.4)
a. Observación:Se identifico que

b. Causa: Este hallazgo se debe que no existe tiempo para contratar a
un personal por lo tanto tampoco hay tiempo para realizar una
capacitación de todo el sistema.
c. Recomendación: Al aceptar un empleado se debe llevar a cabo
una capacitación del c que se está usando actualmente y si se
llevara a cabo un desarrollo del un nuevo sistema se debe conocer
los requerimientos y una visualización lógica de lo que se requiere
implementar.
4) CUARTO HALLAZGO: (DS5.2)
a. Observación: Se detecto que el área de sistemas no cuenta con un
plan de contingencia para prevenir perdidas de información.
b. Causa: El sistema HIGEA será implementado en Junio del 2013
puesto que no se tiene un plan de contingencia formalizado sin
embargo con los sistemas anteriores tampoco se tiene dicho plan
para evitar la pérdida de los datos ante los desastres naturales o
algún tipo de sabotaje interno.
c. Recomendación: Reunirse con la gerencia para concretar e
implementar un plan de contingencia que asegure la continuidad de
las operaciones y evitar la pérdida de la información de los pacientes
ante los riesgos.
5) QUINTO HALLAZGO: (DS5.2)
a. Observación: Se identifico que no se realiza un seguimiento de los
log en la Base de Datos.
b. Causa: No se tiene un control de quien accede al sistema en el cual
corre el riesgo de que la información de los pacientes sean
modificados o eliminados

c. Recomendación: Que se realice la capacitación necesaria al
personal que se encargara de verificar los ingresos al sistema para
así evitar pérdidas o modificaciones de información, también se
debe realizar copias de seguridad por fechas.
6) SEXTO HALLAZGO: (DS5.3)
a. Observación: los password de algunos usuarios no son seguros ya
que para que recuerden sus claves al crear un usuario se le coloca
el nombre del usuario o números del 1 al 8.
b. Causa: Los usuarios que tiene mayor edad no cambian las
contraseñas que se le brinda al principio y puede a que se modifique
la información importante.
c. Recomendación: Realizar una pequeña capacitación a los usuarios
para que aprendan a como cambiar sus contraseñas y generar las
políticas de seguridad en los password.
7) SETIMO HALLAZGO: (DS5.4)
a. Observación: Se identificó que no cuentan con registro por fechas
de los accesos al sistema en el cual no se ha hecho una revisión de
los usuarios y privilegios definidos en las aplicaciones.
b. Causa: No existe un personal que verifique los accesos realizados
por fechas puesto que no consideran como prioridad dicho control.
c. Recomendación: almacenar y modificar los registros de accesos
por periodos definidos, se debe definir los privilegios requeridos y
autorizados a asignar los usuarios.
8) OCTAVO HALLAZGO: (DS5.4) ELIMINACION DE USUARIOS
a. Observación:Se identifico que no se esta realizando la eliminación
de usuarios.
b. Causa: No se elimina los usuarios por que no existen un monitoreo
de las cuentas de los usuarios.

c. Recomendaciones: Realizar constantemente monitoreos sobre la
administración de los usuarios para empezar a tomar decisiones
para inhabilitarlos o eliminarlos
9) NOVENO HALLAZGO: (DS5.6)
a. Observación: Se identifico que no cuentan con incidencias de
seguridad
b. Causa: Las incidencias de seguridad son informadas cuando al
usuario le sucede un problema estos no son detectadas con tiempo
ocurren en el momento y cuenta con el riesgo que se detenga la
continuidad de actividades.
c. Recomendaciones: Dar a conocer a los usuarios los posibles y
constantes problemas que pueden suceder en cualquier instante
para que así puedan tener conciencia y pero solucionar el problema
al instante sin tener que detener las actividades esperando a que
llegue alguien a revisar estas actividades.
10)DECIMO HALLAZGO: (DS5.9)
a. Observación: El Gestor de la base de datos y el sistema operativo
de la base de datos no es actualizado.
b. Causa:El Gestor de la base de datos y el sistema operativo no son
actualizados ya que se está esperando a los mensajes de
actualización para empezar con ello sin embargo no lo realizan cada
cierto tiempo una actualización de estas.
c. Recomendación: Realizar una autorización para la compra de
software adicional y actualizaciones
11)ONCEAVO HALLAZGO: (PO2.2)
a. Observación: se identifico que el área de sistemas en el cual se
encuentra el sistema HIGEA no cuenta con un diccionario de datos
que incluya las reglas de sintaxis de datos de la organización.

b. Causa: El sistema se implementara en junio del 2013 en el cual aun
no se ha implementado un diccionario de datos.
c. Recomendación: Realizar una reunión con la alta gerencia y el jefe
de sistemas para realizar un diccionario de control del sistema
HIGEA.
12)DOCEAVO HALLAZGO: (PO4.5)
a. Observación: se identifico que los laboratorios AngloLab S.A. no
cuentan con una estructura organizacional.
b. Causa: No se ha propuesto una estructura organizacional por lo
tanto no se puede identificar los cargos de los empleados con sus
requerimientos y los distintos objetivos de los negocios esperados.
c. Recomendación:Proponer a la gerencia la realización de una
estructura organizacional
13)TRECEAVO: (PO4.8)
a. Observación: se identifico que no se cuenta con un trabajador que
se encarga directamente de los análisis de riesgos.
b. Causa: en el área de sistemas no se está asignando responsables
específicos que se encarguen de realizar los análisis de riesgo.
c. Recomendación: Se recomienda asignar dicha tarea a un grupo
específico del área de sistemas.
14)CATORCEAVO: (PO4.11)
a. Observación: Se identifico que las responsabilidades y los roles no
están siendo derivadas a otros personal para evitar la carga de
trabajo de una solo personal.
b. Causa: No existe una segregación de funciones ya que no todo el
personal esta capacitado para efectuar distintos procesos críticos.
c. Recomendación: El jefe de sistemas debe derivar los cargos a su
personal para no llegar a una sobrecarga de trabajo.
15)QUINCEAVO: (PO7.2)

a. Observación: Se identifico que al momento de llegar al contrato con
el nuevo personal no se está evaluando su ingreso con la lista de
requerimientos para el puesto que se desea ocupar.
b. Causa: El área de sistemas no cuenta con una lista de
requerimientos para contratar a un paciente.
c. Recomendación: Para caga cargo o puesto de trabajo se debe
realizar una lista de requerimientospara así terminar con el ingreso
del personal.
16)DIECISEISAVO: (PO7.7)
a. Observación: Se identifico que no se está realizando un seguimiento
al desempeño del empleado.
b. Causa: No se realiza el seguimiento al empleado ya que el área se
encuentra en demasiada carga de trabajo.
c. Recomendación: los empleados se les debe realizar evaluaciones y
revisiones periódicas para verificar el desempeño en su cargo y la
conducta según sea necesario.
17)DIECISIETEAVO: (DS5.2)
a. Observación: Se identificó que no se realiza copias de seguridad a
la base de datos en forma periódica.
b. Causa: No se hatomado en cuenta la configuración del gestor de
base datos con respecto a las copias de seguridad.
c. Recomendación:Se recomienda realizar las gestiones
correspondientes para la configuración de las copias de seguridad
de la base de datos.

18)DIECIOCHO: (DS8.1)
a. Observación: No se cuenta con una mesa de servicios para
atender y analizar las llamadas ante cualquier problema
b. Recomendación: se debe reunir con las altas direcciones para
proponer una mesa de servicios ya que esta es la comunicación
entre el usuario con TI para así no combinar las áreas de la
organización.
19)DIECINUEVE: (DS12.3)
a. Observación: se identifico que los empleados no se registran al
ingresar al edificio y oficina.
b. Causa: No se está realizando un monitoreo de los ingresos al área
sin embargo los empleados cuentan con una llave para ingresas a
sus oficinas de trabajo.
c. Recomendación: se debe realizar un monitoreo de ingresos del
personal a las oficinas y estos ingresos se debe justificar o registrar
20)VEINTEAVO HALLAZGO: (DS4.9)
a. Observación: se identificó que los laboratorios AngloLab S.A. no
cuentan con un área externa de almacenamiento de respaldos en
sus servicios.
b. Causa: EL jefe de sistemas no cuenta con un respaldo externo a la
de los laboratorios, cada vez que ocurren un desperfecto de gran
magnitud, generando pérdidas y retardos en la información.
c. Recomendación: Solicitar los servicios de un outsourcing para dicha
implementación.

CAPITULO V
FUNDAMENTACION TEÓRICA
5.1. AUDITORIA
La Auditoría es una función de dirección cuya finalidad es analizar y
apreciar, con vistas a las eventuales las acciones correctivas, el control
interno de las organizaciones para garantizar la integridad de la empresa y
el mantenimiento de la eficacia de sus sistemas de gestión.

Según Piattini es la actividad consistente en la emisión de una opinión
profesional sobre si el objetivo sometido a análisis presenta
adecuadamente la realidad que pretende reflejar y/o cumple con las
condiciones que le han sido prescritas.
Por lo tanto, la auditoría de sistemas consiste en obtener apoyos de
terceras personas para realizar la validación en los sistemas y
procedimientos de uso en una empresa, con el propósito de determinar si
su diseño, procedimientos y aplicaciones son correctos. También la
auditoría es un examen crítico y sistemático que se realiza una persona o
grupo de personasindependientes del sistema hacer auditado.
5.1.1. CARACTERISTICAS DE UN AUDITOR
El trabajo del auditor consiste en obtener una información precisa y
completa sobre unas actividades específicas. Para hacerlo, tiene
que trabajar desplazado de su lugar habitual de trabajo. Tiene que
comunicarse con gente y concentrarse en actividades que pueden
ser extrañas para él, y realizar juicios precisos sobre ello.
Un buen auditor debe caracterizarse por ser entre, otras cosas,
diplomático, paciente, buen comunicador, buen juez, disciplinado,
imparcial, trabajador, con mente abierta, honesto, analítico, curioso,
interesado, con carácter resistente, profesional y entrenado.
5.2. AUDITORIA DE BASE DE DATOS
Podemos definir esta auditoria como el proceso que permite medir,
asegurar, monitorear y registrar los accesos a la información
almacenadas en las bases de datos en el cual también tiene la
capacidad de acceder a los datos, cuando se accedieron a los datos,

desde que dispositivo o tipo de aplicación, desde que ubicación en la
red se puede ingresar a su servidor, cual fue la sentencia que se
ejecutó, etc.
5.2.1. OBJETIVO DE LA AUDITORIA DE BD
– Mitigar los riesgos asociados con el manejo inadecuado de los
datos.
– Apoyar el cumplimiento regulatorio.
– Satisfacer los requerimientos de los auditores.
– Evitar acciones criminales.
– Evitar multas por incumplimiento.
La importancia de la auditoría del entorno de bases de datos radica
en que es el punto de partida para poder realizar la auditoría de las
aplicaciones que utiliza esta tecnología.
5.3. AUDITORIA Y SU MARCO LEGAL
5.3.1. LEY DE PROTECCIÓN DE DATOS PERSONALES
El Congreso de la República ha promulgado la ley N° 29733 denominada “Ley
de protección de datos personales”. Esta ley establece en el artículo 9 las
condiciones de seguridad y confidencialidad que deben cumplir cualquier tipo
de registración de datos.
Artículo 9. Principio de seguridad
El titular del banco de datos personales y el encargado de su tratamiento
deben adoptar las medidas técnicas, organizativas y legales necesarias
para garantizar la seguridad de los datos personales. Las medidas de
seguridad deben ser apropiadas y acordes con el tratamiento que se vaya
a efectuar y con la categoría de datos personales de que se trate.
(Congreso de la República)

El artículo 32 nos da a conocer que el órgano se encargara del
cumplimiento de esta ley.
Artículo 32. Órgano competente y régimen jurídico
El Ministerio de Justicia, a través de la Dirección Nacional de Justicia, es la
Autoridad Nacional de Protección de Datos Personales. Para el adecuado
desempeño de sus funciones, puede crear oficinas en todo el país. La
Autoridad Nacional de Protección de Datos Personales se rige por lo
dispuesto en esta Ley, en su reglamento y en los artículos pertinentes del
Reglamento de Organización y Funciones del Ministerio de Justicia.
5.3.2. SANCIONES PREVISTAS POR LA LEY
En el artículo 37 y 38 incluyen el procedimiento patrocinador y las
infracciones al que no cumpla con esta Ley.
Artículo 37. Procedimiento sancionador
El procedimiento sancionador se inicia de oficio, por la Autoridad Nacional
de Protección de Datos Personales o por denuncia de parte, ante la
presunta comisión de actos contrarios a lo dispuesto en la presente Ley o
en su reglamento, sin perjuicio del procedimiento seguido en el marco de
lo dispuesto en el artículo 24. Las resoluciones de la Autoridad Nacional
de Protección de Datos Personales agotan la vía administrativa. Contra las
resoluciones de la Autoridad Nacional de Protección de Datos Personales
procede la acción contencioso-administrativa.
Artículo 38. Infracciones
Constituye infracción sancionable toda acción u omisión que contravenga
o incumpla alguna de las disposiciones contenidas en esta Ley o en su
reglamento. Las infracciones se califican como leves, graves y muy
graves.
1. Son infracciones leves:

a. Dar tratamiento a datos personales sin recabar el
consentimiento de sus titulares, cuando el mismo sea necesario
conforme a lo dispuesto en esta Ley.
b. No atender, impedir u obstaculizar el ejercicio de los derechos
del titular de datos personales reconocidosen el título III, cuando
legalmente proceda.
c. Obstruir el ejercicio de la función fiscalizadora de la Autoridad
Nacional de Protección de Datos Personales. (…)
2. Son infracciones graves:
a. Dar tratamiento a los datos personales contraviniendo los
principios establecidos en la presente Ley o incumpliendo sus
demás disposiciones o las de su Reglamento.
b. Incumplir la obligación de confidencialidad establecida en el
artículo 17.
c. No atender, impedir u obstaculizar, en forma sistemática, el
ejercicio de los derechos del titular de datos personales
reconocidos en el título III, cuando legalmente proceda. (…)
3. Son infracciones muy graves:
a. Dar tratamiento a los datos personales contraviniendo los
principios establecidos en la presente Ley o incumpliendo sus
demás disposiciones o las de su Reglamento, cuando con ello se
impida o se atente contra el ejercicio de los derechos
fundamentales.
b. Crear, modificar, cancelar o mantener bancos de datos
personales sin cumplir con lo establecido por la presente Ley o su
reglamento.
c. Suministrar documentos o información falsa o incompleta a la
Autoridad Nacional de Protección de Datos Personales.(…)

CAPITULO VI
DESARROLLO
6.1. INTRODUCCIÓN:
Sabiendo el concepto de la auditoria de base de datos, empezaremos con
el desarrollo de la auditoria de base de datos de los Laboratorios clínicos
Anglolab S.A.

6.2. DESCRIPCIÓN DEL PRODUCTO DESARROLLADO
HIGEA es un sistema diseñado para gestionar las órdenes de los pacientes
al realizar un análisis clínico o un examen y los resultados de los exámenes
por paciente, también interviene en la gestión de facturación de exámenes,
pagos; es decir administra las tarifas de cada uno de los exámenes y
realiza los pagos de las órdenes que se requiere. Todo ello es un marco de
múltiples gestores de base de datos.
Esta desarrollado en Visual .NET y SQL Server 2012.
Posee mecanismos de seguridad
Permite el ingreso de órdenes en un menor tiempo y esfuerzo.
Es fácil de usar.
Este sistema cuenta con 5 módulos:
Tarifario
Facturación
Gestión de órdenes de laboratorio
Seguridad
Configuración del sistema

Donde cada uno de ellos se despliega de esta forma:
6.3. FUNCIONAMIENTO DE PRODUCTO
HIGEA es un sistema que genera órdenes de laboratorio, pacientes,
facturación, tarifas, administración de contraseñas y seguridad y gestión de
muestras de exámenes de laboratorios. Este sistema cuenta con un único
servidor de BD en cual este es conectado con el sistema de Tharsys en el

cual este último realiza la toma de muestra e ingresos de resultados, estos
son enviados al SQL Hexalis y recién visualizados en HIGEA.
6.4. COMPONENTES DEL PROYECTO EN VISUAL BASIC
6.5. COMPONENETES DEL PROYECTO EN SQL

AUDITORIA SISTEMAS UCV

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a AUDITORIA SISTEMAS UCV

Semelhante a AUDITORIA SISTEMAS UCV (20)

Último

Último (20)

AUDITORIA SISTEMAS UCV