AUDITORÍA A LA BASE DE DATOS SQL DEL SISTEMA DE

Transcription

INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y
ELÉCTRICA
UNIDAD CULHUACAN
TESINA
Seminario de Titulación:
“Auditoría de las Tecnologías de la Información y
Comunicaciones”
DES/ESIME-CUL 2009/38/10
AUDITORÍA A LA BASE DE DATOS SQL DEL
SISTEMA DE “SEGURIDAD DE PRESAS”
CONAGUA
Que como prueba escrita de su Examen Profesional para obtener el
Título de: Licenciado en
Ciencias de la Informática
Presenta:
EFREN RAMÍREZ AGUILAR
IRAIS ELENA TORRES FLORES
JUDITH ORALIA YAÑEZ MORALES
YAZMIN MOSQUEDA JARAMILLO
Que como prueba escrita de su Examen Profesional para obtener el
Título de: Ingeniero en Informática
Presenta:
JOSÉ LUIS TAPIA MARTÍNEZ
México D.F.
Agosto 2010
IPN
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
UNIDAD CULHUACAN
TESINA
QUE PARA OBTENER EL TITULO DE:
LICENCIATURA EN CIENCIAS DE LA INFORMÁTICA
INGENIERÍA EN INFORMÁTICA
NOMBRE DEL SEMINARIO:
“AUDITORIA DE LAS TECNOLOGIAS DE LA INFORMACION Y COMUNICACIONES”
Vigencia DES/ESIME-CUL 2009/38/10
DEBERA DESARROLLAR:
YAZMIN MOSQUEDA JARAMILLO
EFREN RAMÍREZ AGUILAR
JOSÉ LUIS TAPIA MARTÍNEZ
IRAIS ELENA TORRES FLORES
JUDITH ORALIA YAÑEZ MORALES
“AUDITORÍA A LA BASE DE DATOS SQL DEL SISTEMA DE SEGURIDAD DE PRESAS CONAGUA”
En la presente tesina se aplica la auditoria informática a la Base de Datos en SQL del “Sistema
de Seguridad de Presas” de la CONAGUA basado en la metodología COBIT, con el fin de
dictaminar una recomendación para que dicho sistema siga las mejores prácticas orientadas en
la metodología antes mencionada.
CAPITULADO
CAPITULO I
CAPITULO II.
CAPITULO III
CAPITULO IV
INTRODUCCIÓN A LA AUDITORIA
BASE DE DATOS
METODOLOGÍAS DE ANÁLISIS DE RIESGOS
AUDITORIA A LA BASE DE DATOS DEL "SISTEMA DE SEGURIDAD DE PRESAS"
DE LA CONAGUA
México D.F. a 21 de agosto de 2010
M. EN C. RAYMUNDO SANTANA ALQUICIRA
Coordinador del Seminario
ING. EDUARDO MARTÍNEZ CORONA
Instructor del Seminario
M. EN C. LUIS CARLOS CASTRO MADRID
Jefe de la carrera de I.C.
“SEGURIDAD DE PRESAS” CONAGUA
AGRADECIMIENTOS
Agradezco a mi familia que ha estado a mi lado todo el tiempo, que me ha dado la
felicidad de tenerlos y convivir con ellos.
En especial agradezco a mi madre, Silvia, que nunca me dejo caer y siempre
estuvo conmigo en este largo camino, gracias a sus consejos, su motivación y
cariño.
A mi padre, Efrén, que me dio todo lo necesario para llegar hasta este punto de mi
vida, gracias por brindarme el soporte, fortaleza y cariño todo este tiempo.
Gracias a los dos por realizar uno de mis objetivos más importante en mi
formación personal y por hacer de mi una persona con valores y principios.
Agradezco a mis hermanos, Emmanuel y Belén, por estar a mi lado compartiendo
conmigo buenos momentos, travesuras y felicidad en el hogar.
Gracias por todo, este logro es para todos ustedes.
Efrén
3
Agradezco el apoyo que eh recibido de parte de mis padres, ya que ellos son la
parte fundamental de lograr esta carrera profesional, a mi padre Sergio que con su
esfuerzo y dedicación se volvió mi primer maestro y me enseño lo esencial para
forjar mi carrera, agradezco a mi madre Martha que en todo momento me
transmitió ese conjunto de conocimientos importantes para la vida.
Además de mis padres agradezco a mis hermanos por ser en todo momento el
ejemplo a seguir y ofrecer todo su esfuerzo a mis estudios así mismo brindarme la
ayuda y experiencia para completar mi camino por el aprendizaje.
A toda mi familia, que me ayudaron y estuvieron conmigo dándome el apoyo
necesario para concluir mis estudios profesionales, además de compartir los
momentos de tristeza y felicidad que nos unen y nos hacen fuertes para
superarnos.
A Judith por ser parte de mí, de mi vida, por estar siempre a mi lado en todo
momento y apoyarme para lograr mis metas y triunfos, así como de compartir los
buenos momentos de su vida y brindarme todo el amor, cariño y comprensión que
se puede dar.
A mis amigos les agradezco el infinito e incondicional apoyo que he recibido a lo
largo de mis estudios y que en compañía de ellos he vivido buenas experiencias
escolares y no olvidar de los momentos malos o difíciles que pasamos juntos y
que son complemento en mi vida.
También deseo agradecer a los profesores que me guiaron y trasmitieron sus
conocimientos atreves de todos mis estudios, así como a mis compañeros y
amigos de clases, además agradezco la valiosa participación en la realización de
esta Tesina a mis profesores de Seminario, así como a mis compañeros por su
ayuda y esfuerzo que realizaron en conjunto conmigo para alcanzar esta meta.
Por ultimo doy gracias a la vida por todo lo que me ha dado.
José Luis
4
A Dios: Por acompañarme y cuidarme en todos los momentos de mi vida.
A mis Padres: Por su infinito apoyo a lo largo de mi vida académica y personal.
A mi Esposo: Por tu compañía y apoyo incondicional.
A mi AMADA Hija: Por tu infinita paciencia. Por tu tierna compañía. Por tu
GRANDIOSO apoyo. Esta tesis también es tuya.
David: Por ser mi fortaleza y mi ejemplo Gracias por todo tu cariño, paciencia y
esfuerzo de toda la vida.
Lucia y Lázaro: Gracias por todo su apoyo y Gracias por su amable paciencia
A todos mis amigos y compañeros: Que formaron parte de este proyecto.
Gracias por su infinito apoyo.
Irais
5
A mis padres: Con la mayor gratitud por los esfuerzos realizados para que yo
lograra concluir mi carrera profesional, siendo para mí la mayor herencia.
A mi madre: que es el ser más maravilloso, gracias por el apoyo moral, cariño y
comprensión que siempre me has brindado y por siempre estar al pendiente de
todo lo que me sucede, Te amo.
A mi padre: porque desde niña ha sido para mí un gran hombre maravilloso que
siempre he admirado, por darme siempre lo necesario para seguir adelante y guiar
mi camino con sabiduría.
A mi hermano: Gracias por guiar mi vida con energía, buenos consejos, por tus
sugerencias y opiniones. Además de ser un buen amigo y un gran ejemplo para
mí, eres la mejor compañía para compartir el mismo techo.
A mis amigos: Valente, Oswaldo, Edgar, Moni, y Erika por compartir tantas
aventuras, experiencias, desveladas y triunfos, por apoyarme con su enorme
amistad, alegría y comprensión en los momentos más importantes de mi vida
convirtiéndose para mí en personas muy importantes en ella.
A Luis: Por tu apoyo, comprensión y amor que me permite sentir poder lograr lo
que me proponga. Gracias por escucharme, y por el cariño que me has brindado
así como todos los momentos compartidos. Gracias por ser parte de mi vida.
A los Maestros: Raymundo, Miguel, Eduardo y Jaime por los conocimientos y
consejos impartidos durante el Seminario.
Con amor, respeto y admiración
Judith
6
Agradezco a Dios: Por darme llenarme de luz para guiar mi camino, la fortaleza
para salir de los obstáculos que se presentaba y convirtiéndolo en experiencias,
sobre todo muchas gracias por darme brindarme una familia hermoso que a pesar
de no ser perfecta es lo más valioso que tengo.
Agradezco a mi Madre: Por todo el apoyo y el amor que me has dado durante
toda mi vida, mil gracias por toda esa paciencia y esfuerzo que has puesto en
este camino, gracias por creer en mí, enseñándome que en la vida es de una
constante lucha, de esfuerzo y dedicación para lograr nuestras metas. Te amo
Agradezco a mi Padre: Por apoyarme durante mi seminario, y darme consejos
cuando sentía que no podía seguir adelante. Gracias por volver a ser parte de mi
vida. Te amo
Agradezco a Adalid: Por ser mi ejemplo a seguir, apoyarme en todo momento,
que a pesar de las distancia el amor que tenemos es mucho más fuerte, porque
sin tu apoyo y consejos no hubiera podido salir adelante. Gracias por ser mi
hermana. Te amo
Agradezco a Claudia: Gracias por escucharme y apoyarme en esos momentos
difíciles, ya que eres para mí un ejemplo a seguir, quiero que sepas que eres
como una segunda hermana. Te quiero mucho.
Agradezco a mis Amigos: Por todo ese apoyo y momentos vividos juntos,
agradezco a Dios que los puso en mi camino, mil gracias a todos ya que de cada
uno de ustedes he aprendido y me han enriquecido como persona, recuerden que
los llevo en mi corazón. Los quiero mucho
Agradezco a mis Profesores: Porque de ellos he aprendido tanto en lo
académico como en la vida, ya que sus experiencias y enseñanzas me ayudaban
a seguir adelante y a querer avanzar.
Con todo con mi cariño y agradecimiento
Yazmín
7
ÍNDICE
AGRADECIMIENTOS _______________________________________________________ 3 CAPÍTULO I INTRODUCCIÓN A LA AUDITORÍA _________________________________ 12 1.1 ANTECEDENTES ________________________________________________________ 12 1.2 CONCEPTO DE AUDITORÍA _______________________________________________ 13 1.3 CLASES DE AUDITORÍA ______________________________________________________ 14 1.3.2 Auditoría Externa ______________________________________________________________ 15 1.4 FASES DE LA AUDITORÍA ____________________________________________________ 15 1.4.1 PLANEACIÓN _________________________________________________________________ 16 1.4.2 EJECUCIÓN ___________________________________________________________________ 16 1.4.3 INFORME FINAL _______________________________________________________________ 17 1.5 CONTROL INTERNO INFORMÁTICO ____________________________________________ 18 1.6 AUDITORÍA INFORMÁTICA ___________________________________________________ 18 1.6.1 Funciones de un auditor informático ______________________________________________ 18 1.7 AUDITORÍA EN LAS BASES DE DATOS __________________________________________ 20 1.7.1 Concepto de Auditoría de la base de datos __________________________________________ 20 1.7.2 Técnicas para el control de base de datos en un entorno complejo ______________________ 20 CAPÍTULO II BASE DE DATOS _______________________________________________ 22 2.1 CONCEPTO DE UNA BASE DE DATOS ___________________________________________ 22 2.2 OBJETIVOS DE UNA BASE DE DATOS. __________________________________________ 22 2.3 COMPONENTES DE UNA BASE DE DATOS _______________________________________ 22 2.4 CARACTERÍSTICAS DE UNA BASE DE DATOS _____________________________________ 23 2.5 TIPOS DE DATOS QUE INTEGRAN UNA BASE DE DATOS ___________________________ 24 2.6 TIPOS DE BASES DE DATOS __________________________________________________ 24 2.6.1 BASES DE DATOS ESTÁTICAS _____________________________________________________ 25 2.6.2 BASES DE DATOS DINÁMICAS ____________________________________________________ 25 2.6.3 BASES DE DATOS BIBLIOGRÁFICAS ________________________________________________ 25 2.6.4 BASE DE DATOS DE TEXTO COMPLETO _____________________________________________ 25 2.6.5 BASE DE DATOS DISTRIBUIDA ____________________________________________________ 25 2.7 TIPOS DE RESTRICCIONES EN UNA BASE DE DATOS _______________________________ 26 2.8 RESTRICCIONES DE INTEGRIDAD ______________________________________________ 27 2.9 CONCEPTO DE CIFRADO EN UNA BASE DE DATOS ________________________________ 28 2.10 TIPOS DE CIFRADO ________________________________________________________ 29 2.10.1 CIFRADO DE BLOQUE __________________________________________________________ 29 8
2.10.2 CIFRADO STREAM ____________________________________________________________ 29 2.11 CONCEPTO DE UN SISTEMA GESTOR DE BASE DE DATOS _________________________ 29 2.12 FUNCIONES PRINCIPALES DE UN SISTEMA GESTOR DE BASE DE DATOS _____________ 29 2.13 PROGRAMAS QUE INTEGRAN UN SISTEMA GESTOR DE BASE DE DATOS _____________ 30 2.13.1 LENGUAJE DE DEFINICIÓN DE DATOS (DDL Data Definition Language) ___________________ 30 2.13.2 LENGUAJES DE MANIPULACIÓN DE DATOS _________________________________________ 30 2.14 COMPONENTES DE UN SISTEMA GESTOR DE BASE DE DATOS _____________________ 31 2.15 LOGS DE AUDITORÍA DE UNA BASE DE DATOS __________________________________ 32 2.16 DEFINICIÓN DE UNA ESTAMPA DE TIEMPO DE UNA BASE DE DATOS________________ 34 CAPITULO III METODOLOGÍAS DE ANÁLISIS DE RIESGOS _________________________ 35 3.1 CONCEPTO DE ANÁLISIS DE RIESGOS __________________________________________ 35 3.2 METODOLOGÍA EN AUDITORÍA INFORMÁTICA __________________________________ 35 3.3 METODOLOGÍA TRADICIONAL PARA AUDITORÍA DE LA BASE DE DATOS ______________ 36 3.4 METODOLOGÍA COBIT ______________________________________________________ 36 3.5 RECURSOS DE TI ___________________________________________________________ 45 3.6 DOMINIOS ________________________________________________________________ 46 3.6.1 PLANEAR Y ORGANIZAR (PO) _____________________________________________________ 46 3.6.2 ADQUIRIR E IMPLEMENTAR (AI) __________________________________________________ 46 3.6.3 ENTREGAR Y DAR SOPORTE (DS) __________________________________________________ 47 3.6.4 MONITOREAR Y EVALUAR (ME) ___________________________________________________ 47 3.7 MODELOS DE MADUREZ ____________________________________________________ 47 3.8 OBJETIVOS DE CONTROL EMPLEADOS PARA LA AUDITORÍA ________________________ 56 3.8.1 PO9 EVALUAR Y ADMINISTRAR LOS RIESGOS DE TI ___________________________________ 56 3.8.2 AI2 ADQUIRIR Y MANTENER SOFTWARE APLICATIVO__________________________________ 56 3.8.3 DS8 ADMINISTRAR LA MESA DE SERVICIO Y LOS INCIDENTES ___________________________ 61 3.8.4 DS11 ADMINISTRACIÓN DE DATOS ________________________________________________ 63 3.8.5 DS13 ADMINISTRACIÓN DE OPERACIONES __________________________________________ 64 CAPÍTULO IV AUDITORÍA A LA BASE DE DATOS DEL "SISTEMA DE SEGURIDAD DE PRESAS" DE LA CONAGUA _________________________________________________ 66 4.1 MISIÓN DE LA EMPRESA ____________________________________________________ 68 4.2 VISIÓN DE LA EMPRESA _____________________________________________________ 68 4.3 ESTADO ACTUAL DEL SISTEMA DE SEGURIDAD DE PRESAS _________________________ 69 4.3.1 Antecedentes _________________________________________________________________ 69 4.3.2 Descripción del Servicio _________________________________________________________ 69 9
4.4 PROBLEMÁTICA RESUELTA POR EL SISTEMA ____________________________________ 69 4.5 OBJETIVO DEL SISTEMA _____________________________________________________ 70 4.6 ALCANCE DEL SISTEMA ______________________________________________________ 70 4.7 BENEFICIOS _______________________________________________________________ 71 4.8 CARACTERÍSTICAS PRINCIPALES ______________________________________________ 71 4.9 BASE DE DATOS: ___________________________________________________________ 73 4.9.1 VINCULACIÓN Y CLASIFICACIÓN DE ARCHIVOS. ______________________________________ 73 4.9.2 REPORTES ____________________________________________________________________ 74 4.9.3 FORMATOS ___________________________________________________________________ 74 4.9.4 SEGURIDAD __________________________________________________________________ 74 4.9.5 MÓDULOS ___________________________________________________________________ 74 4.9.6 SERVICIOS ____________________________________________________________________ 74 4.10 CONSIDERACIONES GENERALES _____________________________________________ 75 4.11 CARACTERÍSTICAS TÉCNICAS ________________________________________________ 77 4.12 AUDITORÍA EN LA BASE DE DATOS DEL SISTEMA DE SEGURIDAD DE PRESAS _________ 77 4.12.1 Aspectos generales de su elaboración ____________________________________________ 77 4.12.2 Objetivo ____________________________________________________________________ 77 4.12.3 Objetivos específicos __________________________________________________________ 78 4.13 PROBLEMÁTICA __________________________________________________________ 78 4.14 ALCANCE ________________________________________________________________ 78 4.15 JUSTIFICACIÓN ___________________________________________________________ 78 4.16 PLANEACIÓN _____________________________________________________________ 79 4.17 CRONOGRAMA DE ACTIVIDADES ____________________________________________ 80 4.18 PRESENTACIÓN DE ACTIVIDADES Y OBJETIVOS. _________________________________ 80 4.19 EJECUCIÓN DE LA AUDITORÍA. _______________________________________________ 81 4.19.1 Aspectos generales de su elaboración ____________________________________________ 81 4.20 HALLAZGOS ______________________________________________________________ 83 4.21 ANÁLISIS DE RIESGOS (CHECKLIST) ___________________________________________ 84 4.22 MAPA DE RIESGOS ________________________________________________________ 85 4.23 CIERRE DE LA AUDITORÍA ___________________________________________________ 86 4.24 MODELO DE MADUREZ ____________________________________________________ 86 4.25 RECOMENDACIONES ______________________________________________________ 87 CONCLUSIONES _________________________________________________________ 89 10
ANEXOS _______________________________________________________________ 90 ANEXO 1 ____________________________________________________________________ 90 ANEXO 2 ____________________________________________________________________ 93 ANEXO 3 ____________________________________________________________________ 94 ANEXO 4 ____________________________________________________________________ 95 ANEXO 5 ____________________________________________________________________ 96 ANEXO 6 ____________________________________________________________________ 98 ANEXO 7 ___________________________________________________________________ 100 ANEXO 8 ___________________________________________________________________ 101 ANEXO 9 ___________________________________________________________________ 103 ANEXO 10 __________________________________________________________________ 109 ANEXO 11 __________________________________________________________________ 113 ANEXO 12 __________________________________________________________________ 114 ANEXO 13 __________________________________________________________________ 115 ANEXO 14 __________________________________________________________________ 121 ANEXO 15 __________________________________________________________________ 122 ÍNDICE DE FIGURAS _____________________________________________________ 129 ÍNDICE DE TABLAS ______________________________________________________ 130 GLOSARIO _____________________________________________________________ 131 BIBLIOGRAFÍA __________________________________________________________ 136 11
CAPÍTULO I INTRODUCCIÓN A LA AUDITORÍA
1.1 ANTECEDENTES
En tiempos remotos se practicaba alguna especie de auditoría en donde los
soberanos exigían un mantenimiento en las cuentas de su residencia por
escribanos, para evitar desfalcos en las cuentas. A medida que se desarrolló el
comercio surgió la necesidad de realizar revisiones independientes para
asegurarse de la adecuación y finalidad de los registros mantenidos en varias
empresas comerciales.
La auditoría como profesión fue reconocida por primera vez bajo la ley Británica de
sociedades Anónimas de 1862 y en reconocimiento general tuvo lugar durante el
periodo de mandato de la ley “un sistema metódico y normalizado de contabilidad
era deseable una adecuada información y prevención del fraude.
Desde 1862 hasta 1905, la profesión de auditoría creció y floreció en Inglaterra
para introducirse en los Estados Unidos hacia 1900, el objetivo principal consistía
en la detección y prevención de errores.
En los Estados Unidos se desarrollaba la auditoría interna y del Gobierno, lo que
entró a formar parte del campo de la auditoría. A medida que los auditores
percibían una importancia en contar un buen sistema de control interno y su
relación con el alcance de las pruebas a efectuar en una auditoría independiente,
progresivamente las compañías adoptaron la expansión de las actividades del
departamento de la auditoría interna hacia áreas que están más allá de su alcance
de los sistemas contables.
Muchos ingleses de la comunidad de “inversionistas” en América, tenían fuertes
intereses económicos en Estados Unidos, esto presentaba el problema de que a
las operaciones económicas pudieran ser manipuladas en perjuicio de los dueños
británicos. Se puede decir que a un auditor se relaciona con el sentido del auditivo,
la razón es por que como el sentido del oído conforma el equilibrio en el ser
humano, el auditor conforma la parte de oír y reportar las irregularidades que se
presenten en las operaciones en las empresas.
En la actualidad la información se ha convertido en uno de los activos principales
de las empresas, que representan su principal ventaja estratégica.
Las empresas invierten enormes cantidades de dinero y tiempo en la creación de
sistemas de información que les ofrezcan la mayor productividad y calidad
posibles. Es por eso que los temas relativos a la auditoría informática cobran cada
vez más relevancia tanto a nivel internacional como nacional.
12
De esta importancia la auditoría se debe pensar en el auditor como un elemento
imprescindible para una sana operación de las empresas, el papel de auditor ha
pasado de ser un detector de problemas a un identificador de oportunidades y
emisor de propuestas de valor.
Un auditor actual no puede concebirse así mismo simplemente como el
responsable de identificar riesgos en la operación de una empresa, aunque
ciertamente la identificación de riesgos sigue siendo una parte importante de sus
actividades, su compromiso profesional va más allá de fungir como un mecanismo
detectivo.
EVOLUCIÓN DE LA PRÁCTICA DE AUDITORÍA
Enfoque tradicional
Enfoque Actual
Objetivo:
Objetivo:
Evaluar un conjunto de prácticas
operativas vinculadas al diseño,
desarrollo
y
explotación
del
soporte de TI, así como adquisición
de bienes o contratación de
servicios requeridos para brindar
estas
funciones
y
su
administración
Evaluar el nivel de seguridad y
control del entorno de TI asegurando
que refuerza la estructura de control
interno
de
la
organización
(cumplimiento)
(cumplimiento)
Asegurar que la organización obtiene
un beneficio en sus recursos de TI
contribuyendo a reforzar el gobierno
corporativo de la organización
(Desempeño y Gestión)
Tabla 1.1 Evolución de la Práctica de auditoria
1.2 CONCEPTO DE AUDITORÍA
La palabra auditoría proviene del latín “auditorius”, y de esta proviene la palabra
auditor, que se refiere a todo aquel que tiene virtud de oír.
Conceptualmente la auditoría es la actividad consistente en la emisión de una
opinión profesional sobre el objeto sometido al análisis.
Definición
Es un proceso de recoger, agrupar y evaluar evidencias para determinar si un
sistema de información salvaguarda los activos, mantiene la integridad de los
datos, lleva acabo los fines de la organización, y utiliza eficientemente los
recursos.
13
1.3 CLASES DE AUDITORÍA
La auditoria comprende el análisis y gestión de sistema para identificar y
posteriormente corregir las diversidades vulnerabilidades. El objeto sometido a
estudio, sea cual sea su soporte, por una parte y la finalidad con que se realiza el
estudio, definen el tipo de auditoría que se trata.
CLASE
CONTENIDO
OBJETO
FINALIDAD
Financiera
Opinión
Cuentas anuales
Presentan realidad
Informática
Opinión
Sistemas de aplicación recursos
informáticas,
planes
de
contingencia
Operatividad
según
establecidas
Gestión
Opinión
Dirección
Eficiencia,
economicidad
Cumplimiento
Opinión
Normas establecidas
Las
operaciones
se
adecuan a estas normas
eficiente y
normas
Eficacia
Tabla 1.2 Clases de auditoría.
La auditoría en la organización se divide en dos campos:
1.3.1 Auditoría Interna
Es una actividad independiente que tiene lugar dentro de la empresa y que está
encaminada a la revisión de operaciones contables y de otra naturaleza, con la
finalidad de prestar un servicio a la dirección.
Las auditorías internas son hechas por personal de la empresa. Un auditor interno
tiene a su cargo la evaluación permanente de control de las transacciones y
operaciones y se preocupa en sugerir el mejoramiento de los métodos y
procedimientos de control interno que redunden en una operación más eficiente y
eficaz.
Objetivo
 Revisión y evaluación de controles contables, financieros y operativos.
 Determinación de la utilidad de políticas, planes y procedimientos, así como
su nivel de cumplimiento.
 Divulgación de políticas y procedimientos establecidos.
 Información exacta a la gerencia.
14
1.3.2 Auditoría Externa
Es una actividad que se desempeña fuera de la organización para examinar y
evaluar lo sistemas informáticos de esta, emitiendo una opinión independiente
sobre los mismos teniendo por objeto averiguar la razonabilidad, integridad y
autenticidad de los datos
La auditoría externa en general es un examen crítico, sistemático y detallado de
un sistema de información de una unidad económica, utilizado técnicas
determinadas y con el objeto de emitir una opinión independiente sobre la forma
como opera el sistema, el control interno del mismo y formula sugerencias para su
mejoramiento.
Objetivo
 Obtención de elementos de juicio fundamentados en la naturaleza de los
hechos examinados
 Medición de la magnitud de un error ya conocido, detección de errores
supuestos o confirmación de errores.
 Detección de los hechos importantes ocurridos tras el cierre del ejercicio.
 Control de las actividades de investigación y desarrollo.
Diferencias entre auditoría interna y externa
La auditoría interna se lleva a cabo con personas pertenecientes a la misma
empresa, mientras que la externa exige como condición esencial a la misma y de
su credibilidad, que los profesionales que la realizan no formen parte de la
empresa auditada, es decir que sean totalmente independientes de ella y de sus
directivos.
Los trabajos de auditoría externa se desarrollan de acuerdo con normas y
procedimientos internacionalmente homologados, mientras que los procedimientos
de auditoría interna son mucho más flexibles y depende en cada caso de la
empresa, de sus dirigentes y de los propios responsables de la auditoría.
1.4 FASES DE LA AUDITORÍA
Los controles pueden implantarse a varios niveles, por lo que se requiere analizar
diversos elementos interdependientes para llegar a conocer bien la configuración
del sistema, con el objeto de identificar los elementos, productos y herramientas
que existen para saber dónde pueden implantarse los controles, así como
identificar posibles riesgos, Figura 1.1.
15
Figura 1.1. Fases de la auditoría.
1.4.1 PLANEACIÓN
Uno de los objetivos de un auditor es proceder a obtener un conocimiento general
de la empresa que va ser auditada, sus características de negocio, su
infraestructura tecnológica, sus sistemas de información, sus áreas de riesgo, sus
objetivos estratégicos y cualquier asunto de interés específico sobre la auditoría a
realizar.
Para efectuar todo lo anterior el auditor debe realizar un trabajo de planeación en
el que determine un procedimiento de revisión que deberá emplear el personal
responsable del desarrollo de las actividades y las fechas de la duración
aproximada.
1.4.2 EJECUCIÓN
En esta fase se realizarán diferentes tipos de pruebas y análisis para determinar
su razonabilidad, detectando las posibles amenazas y vulnerabilidades si es que
los hay, evaluando los resultados de las pruebas se identifican los hallazgos; con
lo que se elaborará posteriormente las conclusiones y recomendaciones que
serán comunicadas a las autoridades de la entidad auditada.
Elementos de la fase de ejecución
Las etapas que conforman la ejecución son:
1.
2.
3.
4.
5.
Análisis.
Pruebas de la Auditoría.
Evaluación del Riesgo.
Hallazgos de la Auditoría.
Implementación de los controles.
16
1.4.3 INFORME FINAL
Este informe incluye detalles y recomendaciones de la sección de análisis de
riesgos, además de realizar un costo- beneficio a los puestos jerárquicos que se
dedican a la toma de decisiones.
El informe lleva una visión rápida de los aspectos previamente realizados, en los
cuales se redactan en el Informe de Auditoría Informática, esto es la comunicación
del Auditor informático, al cliente de manera formal teniendo como puntos
principales:





Objetivo
Periodo de cobertura
Extensión del trabajo realizado
Resultados y
Conclusiones
También se puede decidir si el informe es largo o por el contrario corto, detallando
las debilidades que se tienen en el control interno, incluso de hechos o aspectos
que tengan en cuenta con la legislación vigente.
La redacción del informe deberá ser clara, adecuada, suficiente y comprensible.
Una utilización apropiada del lenguaje informático resulta recomendable.
Estructura del Informe
1. Identificación del Informe: Título del informe que deberá identificarlo con
objeto de distinguirlo de otros informes.
2. Identificación del cliente: Deberá identificarse a los destinatarios y a las
personas que efectúen el encargo.
3. Identificación de la entidad auditada: Identificación de la entidad con
objeto de la Auditoría Informática.
4. Objetivos de la Auditoría Informática Declaración de los objetivos de la
auditoría para identificar su propósito señalando los objetivos cumplidos.
5. Normativa aplicada y excepciones: Identificación de las normas legales y
profesionales utilizadas, así como las excepciones significativas de uso y el
posible impacto en los resultados de la auditoría.
6. Alcance de la Auditoría: Concretar la naturaleza y extensión del trabajo
realizado: área organizativa, periodo de auditoría, sistemas de información,
señalando limitaciones al alcance y restricciones del auditado.
7. Conclusiones: Informe corto de opinión.
Lógicamente se ha llegado a los resultados y sobre todo, a la esencia del
dictamen, la opinión y los párrafos de salvedades y énfasis, si procede.
17
1.5 CONTROL INTERNO INFORMÁTICO
El control interno informático se encarga de controlar diariamente que todas las
actividades de los sistemas informáticos sean realizadas cumpliendo los
procedimientos, estándares y no normas fijados por la dirección de la organización
y/o dirección de Informática, así como los requerimientos legales.
La misión del control interno informático es asegurarse de que las medidas que se
obtienen de los mecanismos implantados por cada responsable sean correctas y
válidas.
Sus principales objetivos son:
 Controlar las actividades para que se cumplan los procedimientos y
normas fijados asegurándose del cumplimiento de las normas legales.
 Colaborar y apoyar el trabajo de auditoría informática, así como de las
auditorías externas.
 Definir, implantar y ejecutar mecanismos y controles para comprobar el
logro de los servicios.
1.6 AUDITORÍA INFORMÁTICA
La auditoría en informática es la revisión y la evaluación de los controles de los
sistemas, su utilización con eficiencia y seguridad en la organización participan en
el procesamiento de la información, a fin de que por medio de señalamientos de
cursos alternativos se logre una mayor eficiencia y seguridad en la información
que servirá para una adecuada toma de decisiones.
Es de vital importancia para el buen desempeño de los sistemas de información,
ya que proporciona los controles necesarios para que los sistemas sean confiables
y con un buen nivel de seguridad.
Al momento de realizar una auditoría de sistemas, el auditor deberá reunir las
evidencias necesarias que permita realizar una evaluación de las fortalezas y
debilidades de los controles existentes en la organización con la finalidad de
preparar un informe de auditoría que presente temas en forma objetiva a la
gerencia, así mismo la gerencia de auditoría deberá disponer y asignar
adecuadamente de recursos para el trabajo de auditoría además de realizar
seguimiento en las acciones correctivas emprendidas por la gerencia.
1.6.1 Funciones de un auditor informático
Participar en las revisiones durante y después del diseño realización, implantación
y explotación de aplicaciones informáticas.
18
Revisar y juzgar los controles implantados en los sistemas, para verificar su
adecuación a las órdenes e instrucciones de la dirección.
Revisar y juzgar el nivel de eficiencia, utilizada, fiabilidad y seguridad de los
equipos e información.
Cuadro de comparación
CONTROL INTERNO
INFORMÁTICO
SIMILITUDES
AUDITORIA INFORMÁTICA
Conocimientos especializados en la tecnología de
información
Verificación del cumplimiento de controles internos y
procedimientos establecidos por la dirección de informática.
Análisis de controles en el Análisis de un momento
día a día
informático determinado
DIFERENCIAS
El alcance de sus funciones
es únicamente sobre el
departamento
de
informática.
Tiene cobertura sobre todos
los componentes de los
sistemas de información de la
organización
Tabla 1.3 Comparación Control Interno y Auditoría Informática
El auditor evalúa y comprueba en determinados momentos del tiempo los
controles y procedimientos informativos más complejos, desarrollando y aplicando
técnicas mecanizadas de auditoría, incluyendo el uso de software. El auditor es
responsable de revisar e informar a la Dirección de la organización el diseño y el
funcionamiento de los controles implantados y sobre la fiabilidad de la información
suministrada.
Se puede establecer tres grupos de funciones a realizar por un auditor informático:
 Participar en las revisiones durante y después del diseño, realización,
implantación y explotación de aplicaciones informativas.
 Revisar y juzgar los controles implantados en los sistemas informativos para
verificar su adecuación a las órdenes e instrucciones de la Dirección,
requisitos legales, protección de confidencialidad y cobertura ante errores y
fraudes.
 Revisar y juzgar el nivel de eficacia, utilidad, fiabilidad y seguridad de los
equipos e información.
19
1.7 AUDITORÍA EN LAS BASES DE DATOS
El objetivo de la base de datos, no es tan solo contar con los recursos de
información si no también los mecanismos necesarios para poder encontrar y
recuperar esos recursos. De esta forma la base de datos se ha convertido en un
elemento indispensable tanto para el funcionamiento de los grandes motores de
búsqueda y la recuperación de la información como también para la creación de
sedes Web, intranets y otros sistemas de información.
Las bases de datos se han constituido como una herramienta más ampliamente
difundida por la sociedad de la información, utilizadas como un almacenamiento
de información en todos los campos, científica, social, económica, cultural y
político. El uso de estos sistemas automatizados se desarrollo a partir de la
necesidad de almacenar grandes cantidades de datos, para su posterior
consulta, producidas por las
En la actualidad existe una gran difusión en los Sistemas de Gestión de Base de
datos, como una consagración de los datos como uno de los recursos
fundamentales para las empresas, por lo que ha hecho temas relativos a su
control interno y auditoría cada vez de mayor interés.
1.7.1 Concepto de Auditoría de la base de datos
Es el proceso que permite medir, asegurar, demostrar, monitorear y registrar los
accesos a la información almacenada en la base de datos incluyendo la
capacidad de determinar:






Quien accede a los datos
Cuando se accedió a los datos
Desde que ubicación en la red
Desde que tipo de dispositivo /aplicación
Cual fue la sentencia ejecutada en SQL
Cual fue el efecto de acceso a la base de datos.
1.7.2 Técnicas para el control de base de datos en un entorno complejo
El SGBD influyen en la seguridad e integridad de los datos, en los que cada uno
se apoya en la operación correcta y predecible de otros, el efecto es debilitar la
seguridad global del sistema, reduciendo la fiabilidad e introduciendo un conjunto
de controles descoordinados y difíciles de gestionar.
La dirección de la empresa tiene, por tanto la responsabilidad fundamental por lo
que se refiere a la coordinación de los distintos elementos y a la aplicación
consistente de los controles de seguridad. Para llevar a cabo esta labor se deben
fijar claramente las responsabilidades sobre los diferentes componentes, utilizar
informes de excepción efectivos que permitan monitorizar los controles, establecer
20
procedimientos adecuados, implantar una gestión rigurosa de la configuración del
sistema.
Por lo que es recomendable realizar matrices de control; estas matrices sirven
para identificar los conjuntos de datos de SI junto con los controles de seguridad o
integridad implementados sobre los mismos.
21
CAPÍTULO II BASE DE DATOS
2.1 CONCEPTO DE UNA BASE DE DATOS
Una BD es una colección estructurada de elementos de datos interrelacionados, a
fin de modelar parte del mundo real. Tiene como objetivo principal el compartir
recurso dentro de una organización. Un sistema de base de datos está formado
por una base de datos, un sistema de gestión de bases de datos (SGBD), así
como por el hardware y personal apropiado. Los datos se controlan por medio de
un diccionario de datos, que está controlado por los administradores de la Base de
Datos.
2.2 OBJETIVOS DE UNA BASE DE DATOS.
 Los datos deben de poder compartirse.
 El uso de los datos debe ser controlado. De esta tarea se encarga el
sistema de gestión de base de datos (SGBD).
 Los datos se integran de una forma lógica, eliminando redundancias,
resolviendo ambigüedades en la definición y manteniendo la
consistencia interna entre los mismos.
2.3 COMPONENTES DE UNA BASE DE DATOS
Hardware. Es el conjunto de dispositivos físicos sobre los que reside una base de
datos. Pueden usarse mainframes o minicomputadoras para soportar acceso a
varios usuarios, o computadoras personales que se utilizan con bases de datos
autónomas controladas por un usuario único. Hay que señalar también que las
unidades de disco son el mecanismo de almacenamiento principal para las bases
de datos.
Software. Hay dos tipos de software: el sistema de gestión de bases de datos
(SGBD) y el software de aplicación (que usa las facilidades del SGBD para
manipular las bases de datos. Este último suele ser desarrollado por los
empleados de la compañía para resolver un problema específico, mientras que el
SGBD debe brindar varios servicios que se describirán más tarde.
Datos. Los datos tienen que ser cuidadosa y lógicamente estructurados y deben
almacenarse de manera precisa en el diccionario de datos.
22
Personas. Pueden ser: usuarios (que necesitan información de la base de datos
para desarrollar su responsabilidad en el negocio) o profesionales de la
computación (que su responsabilidad reside en el diseño y mantenimiento del
sistema de la base de datos).
2.4 CARACTERÍSTICAS DE UNA BASE DE DATOS
INTEGRIDAD
La integridad de los datos consiste en mantener la precisión y consistencia de los
valores de los datos. Los mecanismos de seguridad protegen la integridad de los
datos. También se pueden mantener en el diccionario de datos restricciones sobre
los valores, aunque es una tarea que resulta complicada.
Por último, resaltar que los mecanismos de copias de seguridad y restauración
soportados por el SGBD deben preservar los datos de cualquier fallo del sistema.
SEGURIDAD
Los administradores de la base de datos pueden restringir el acceso a los
usuarios sólo para recuperación o permitir acceso y actualización. La información
relativa a los derechos de acceso se almacena en el diccionario de datos.
El acceso a la base de datos también es controlado por un mecanismo de
contraseñas; un usuario que quiera acceder al sistema debe dar una contraseña y
que el sistema la valide.
REDUNDANCIA MÍNIMA
En una Base de datos se deberá eliminar las redundancias o repeticiones que
puedan llevar a error, como el llamar a un mismo campo de distinta manera en
varios archivos, ya que si no existe el riesgo de inconsistencia entre las distintas
versiones de los mismos datos.
COMPARTIR INFORMACIÓN
Existen tres formas de compartir información:

Entre unidades funcionales. El combinar los datos en una base de datos
produce que los datos combinados tengan más valor que la suma de los
23
datos en los archivos por separado. A este concepto de combinar los datos
para un uso común se le llama integración de datos.
 Entre diferentes niveles de usuarios. Se pueden distinguir 3 niveles de
usuarios: personal, mandos intermedios y ejecutivos. Estos niveles se
corresponden con los 3 diferentes tipos de automatización de los sistemas
de negocios: procesamiento electrónico de datos (PED), sistemas de
información de gestión (MIS) y sistemas de apoyo a la toma de decisiones
(STD).
2.5 TIPOS DE DATOS QUE INTEGRAN UNA BASE DE DATOS
DATOS DECLARATIVOS
Los datos declarativos describen aspectos estáticos de objetos del mundo real y
sus asociaciones. Históricamente, los datos contenidos en un sistema de Base de
Datos han sido datos declarativos.
Ejemplo:
Un archivo de cuentas corrientes.
Un archivo de personal.
DATOS PROCEDURALES
Los datos procedurales describen los aspectos dinámicos
mundo real y sus asociaciones.
de los objetos del
Ejemplo:
Un conjunto de reglas de descripción de toma de decisiones sobre que stocks y
límites se eligen para abastecer un depósito.
Cuando se almacenan ambos tipos de datos, declarativos y procedurales, la BD
suele denominarse base de conocimiento.
2.6 TIPOS DE BASES DE DATOS
Las bases de datos pueden clasificarse de varias maneras, de acuerdo al contexto
que se esté manejando, o la utilidad de la misma:
24
2.6.1 BASES DE DATOS ESTÁTICAS
Éstas son bases de datos de sólo lectura, utilizadas primordialmente para
almacenar datos históricos que posteriormente se pueden utilizar para estudiar el
comportamiento de un conjunto de datos a través del tiempo, realizar
proyecciones y tomar decisiones.
2.6.2 BASES DE DATOS DINÁMICAS
Éstas son bases de datos donde la información almacenada se modifica con el
tiempo, permitiendo operaciones como actualización, borrado y adición de datos,
además de las operaciones fundamentales de consulta. Un ejemplo de esto puede
ser la base de datos utilizada en un sistema de información de una tienda de
abarrotes, una farmacia, un videoclub.
2.6.3 BASES DE DATOS BIBLIOGRÁFICAS
Solo contienen un representante de la fuente primaria, que permite localizarla. Un
registro típico de una base de datos bibliográfica contiene información sobre el
autor, fecha de publicación, editorial, título, edición, de una determinada
publicación, etc. Puede contener un resumen o extracto de la publicación original,
pero nunca el texto completo, porque si no, estaríamos en presencia de una base
de datos a texto completo. Como su nombre lo indica, el contenido son cifras o
números. Por ejemplo, una colección de resultados de análisis de laboratorio,
entre otras.
2.6.4 BASE DE DATOS DE TEXTO COMPLETO
Almacenan las fuentes primarias, como por ejemplo, todo el contenido de todas
las ediciones de una colección de revistas científicas.
2.6.5 BASE DE DATOS DISTRIBUIDA
Una Base de Datos Distribuida consiste en un conjunto de datos almacenado de
manera sistemática siempre dispuesto a ser utilizado. Pero tiene una
particularidad que la diferencia y que consiste en que estos datos están
almacenados en distintas maquinas que integran un sistema y que tienen
conexión entre sí.
Cada uno de los procesadores que integran dicho sistema se conoce con el
nombre de localidad o nodo, y por lo tanto la información va a estar distribuida en
las distintas localidades y no en una sola localidad, que es lo que ocurre con las
bases de datos centralizadas.
25
Cada localidad tiene una base de datos local aunque la información que se
necesite puede provenir tanto de la base de datos local como de otras localidades,
lo que se conoce como transacciones locales o transacciones globales
respectivamente.
Debido a que la información está distribuida en localidades, los resultados a las
consultas se pueden obtener de manera rápida, ágil y fiable. Asimismo, en caso
de que alguna de las localidades falle, como todas tienen autonomía local, el resto
sigue trabajando sin que se desactive el sistema.
2.7 TIPOS DE RESTRICCIONES EN UNA BASE DE DATOS
Un buen sistema de administración de BD ( DBMS) deberá realizar varios tipos de
restricciones de integridad dentro del SGBD. Las restricciones de integridad son
establecidas para mantener:
1. La consistencia.
2. La completitud
3. La unicidad de las instancias de las estructuras usadas dentro del
modelado conceptual o aproximación del modelo de datos.
Los tipos específicos de restricciones provistos por el sistema dependerán de:
1. Alguna extensión del modelo conceptual
2. La aproximación del modelado de datos que este soporta.
Para ilustrar la naturaleza de los controles de integridad que podrían realizarse,
proveemos una visión de los mismos asociados con:
1. el modelo entidad-relación (E-R),
2. el modelo de datos relacional, y
3. el modelo de datos de objetos.
Las construcciones fundamentales del modelo son:
1. entidades,
2. relaciones entre entidades, y
3. atributos de entidades.
Las entidades son tipos básicos o clases de objetos del mundo real que deben ser
modelados.
26
2.8 RESTRICCIONES DE INTEGRIDAD
Restricción de integridad
Identificador de entidad
Descripción
Especifica los atributos cuyos valores
únicos identifican cada instancia de una
entidad.
Tipo de valor de un identificador
Especifica los tipos de valores
permitidos para los atributos que
comprenden un identificador de entidad
(ejemplo: número real, entero, string
alfanumérico).
Conjunto de valores de un identificador
Especifica el conjunto permitido de
valores para los atributos que
comprenden el identificador de una
entidad.
Tabla 2.1 Restricciones de Integridad
Tipo de valor de un atributo
Descripción
Especifica los tipos de valores
permitidos para un atributo (real,
alfanumérico)
Conjunto de valores de un atributo
Especifica el conjunto permitido de
valores para un atributo
Leyes de transición
Especifica las relaciones entre valores
previos de atributos y sus nuevos
valores
Dentro del SBD, una restricción de integridad que se aplica a las relaciones es el
control de cardinalidad, que especifica una de las siguientes dos posibilidades:
1. El número máximo de instancias de una entidad que puede ser asociado
con una instancia de otra entidad (o tupla de instancias de entidades
múltiples).
27
2. El número mínimo de instancias de una entidad que puede ser asociado
con una instancia de otra entidad (o tupla de instancias de entidades
múltiples).
Descripción
Llaves o Claves
Especifica las llaves candidatas de una
relación. Estos valores deben identificar
únicamente cada tupla de la relación.
Entidad
Se establecen para asegurar que las
claves primarias nunca tienen valores
nulos.
Descripción
Son
establecidos
para
mantener
consistencia sobre tuplas de la relación.
Referencias
Si una tupla en la relación refiere a un
dato en otra tupla de la relación o a una
tupla de otra relación, este control
asegura que la tupla referenciada debe
existir.
Tabla 2.4 Referencias
La integridad del SGBD también depende de los controles implementados en los
programas de aplicación que usan la BD. A continuación veremos distintos tipos
de protocolos de actualización y reporte que podrían ser implementados en una
aplicación de software para proteger la integridad de la BD.
2.9 CONCEPTO DE CIFRADO EN UNA BASE DE DATOS
El cifrado es el proceso de conversión de datos en un formato que no puedan leer
otros usuarios.
28
2.10 TIPOS DE CIFRADO
2.10.1 CIFRADO DE BLOQUE
El cifrado de Bloque opera sobre bloques de datos individuales, y difiere del
cifrado de stream, en la cual los valores criptográficos de un bloque de datos
dependen de los valores de otros bloques de datos.
El cifrado de bloque debería ser usado cuando los usuarios requieren acceso a
sólo una parte de un archivo.
Los controles de cifrado también son utilizados para proteger la integridad de
datos almacenados en una BD.
El cifrado de bloque opera sobre bloques de datos individuales, y difiere del cifrado
stream, en la cual los valores criptográficos de un bloque de datos dependen de
los valores de otros bloques de datos. El cifrado de bloque debería ser usado
cuando los usuarios requieren acceso a sólo una parte de un archivo.
2.10.2 CIFRADO STREAM
El cifrado Stream es útil para transferir archivos enteros entre dos usuarios, es útil
para transferir archivos enteros entre dos usuarios.
2.11 CONCEPTO DE UN SISTEMA GESTOR DE BASE DE DATOS
Es un tipo de software específico, dedicado a servir de interfaz entre la base de
datos, el usuario y las aplicaciones que la utilizan.
2.12 FUNCIONES PRINCIPALES DE UN SISTEMA GESTOR DE
BASE DE DATOS





Creación y mantenimiento de la base de datos.
Control de accesos.
La manipulación de datos de acuerdo con las necesidades del usuario.
El cumplimiento de las normas de tratamiento de datos.
Evitar redundancias e inconsistencias y mantener la integridad.
29
2.13 PROGRAMAS QUE INTEGRAN UN SISTEMA GESTOR DE
BASE DE DATOS
2.13.1 LENGUAJE DE DEFINICIÓN DE DATOS (DDL Data Definition
Language)
El lenguaje de definición de datos (DDL, Data Definition Language) provee de los
medios necesarios para definir los datos con precisión, especificando las distintas
estructuras. Acorde con el modelo de arquitectura de tres niveles, habrá un
lenguaje de definición de la estructura lógica global, otro para la definición de la
estructura interna, y un tercero para la definición de las estructuras externas.
Este tipo de lenguaje opera sobre la definición de la Base de Datos. Proveen un
diccionario de datos, metadatos, estructuras de almacenamiento y los métodos de
acceso usados.
2.13.2 LENGUAJES DE MANIPULACIÓN DE DATOS
El lenguaje de manipulación de datos (DML, Data Manipulation/ Management
Language), es el encargado de facilitar a los usuarios el acceso y manipulación
de los datos. Pueden diferenciarse en procedimentales (aquellos que requieren
qué datos se necesitan y cómo obtenerlos) y no procedimentales (que datos se
necesitan, sin especificar cómo obtenerlos), y se encargan de la recuperación de
los datos almacenados, de la inserción y supresión de datos en la base de datos, y
de la modificación de los existentes. Permiten realizar acciones sobre la Base de
Datos en sí misma: obtener información almacenada, agregar, eliminar, y
modificar información.
30
Figura 2.1. Arquitectura de un Sistema Gestor de Bases de Datos.
2.14 COMPONENTES DE UN SISTEMA GESTOR DE BASE DE
DATOS
 Sistema de administración de BD. Usado para manipular datos.
 Programas de Aplicación: definidos para crear, modificar y eliminar
datos.
 Sistemas operativos: para realizar las operaciones básicas de E/S para
mover datos a y desde medios de almacenamiento.
 Procesador central y almacenamiento primario: donde se ejecutan las
actividades.
 Almacenamiento secundario: para mantener la copia permanente o
semi-permanente de los datos.
31
Los controles de acceso en el SBD previenen de acceso no autorizados a los
datos.
Se especifican mediante:
1.
Una política de seguridad para el subsistema.
2.
Eligiendo un mecanismo de control de acceso que sea efectivo para
tal política.
En SGBD, los usuarios dueños deben especificar:
 Quien puede acceder a los datos.
 Que acciones de privilegio pueden tener respecto de los datos.
 Se requiere un administrador de sistema.
Los controles de acceso pueden ser:
1.
Control de acceso discrecional
2.
Control de acceso mandatorio
Los privilegios frecuentemente son dados a usuarios que son designados como
propietarios.
2.15 LOGS DE AUDITORÍA DE UNA BASE DE DATOS
Los logs de auditoría en un SGBD mantienen la cronología de eventos
ocurren en la definición de la BD o en la BD en sí misma.
que
Se graba un conjunto de todos los eventos que ocurren sobre la BD como
creaciones, modificaciones, eliminaciones recuperaciones.
Para mantener los logs contables de auditoría en un sistema de aplicación, el
SGBD debe realizar se debe asociar una única estampa de tiempo para cada
transacción sobre la definición de la Base de Datos.
Estas estampas de tiempo tienen dos propósitos:
1 Confirmar que la última transacción ha alcanzado la definición de la BD o la
BD misma;
32
2 Identificar una posición única de tiempo para la transacción, en una serie de
eventos que le han sucedido al ítem de dato, de la definición de la BD o la
BD misma.
Como resultado, los logs de auditoría deben permitir una de dos alternativas:
1 una operación de implosión
2 una operación de explosión
Implosión: cada transacción puede ser trazada desde su fuente al ítem de dato
que afecta.
El identificador de fuente de transacción establece su origen para ser trazada de
forma no ambigua.
El identificador de destino designa el ítem de dato afectado.
El SGBD debe proveer facilidades para definir, crear, modificar, eliminar, y
recuperar datos desde los logs de auditoría, ya que estos requieren un
almacenamiento permanente o semipermanente.
Usualmente los logs de auditoría no deberían ser modificados ya que reflejan la
verdad de lo sucedido.
Sin embargo, esto puede suceder porque:
1.
2.
El sistema de aplicación que actualiza la BD procesa datos
erróneamente
El proceso que crea el log de auditoría podría presentar fallas en ambos
casos, conviene modificar el log para evitar posibles decisiones sobre
información errónea.
Los logs de auditoría de operaciones mantienen la cronología de los eventos que
consumen recursos que afectan la definición de la BD o la BD.
Los administradores de base de datos deben tomar dos decisiones:
1.
2.
En función de los tiempos o la cantidad de recursos requeridos para
aplicar transacciones puede surgir la necesidad de reorganizar la BD.
En función de los datos de consumo de recursos, puede surgir que sea
necesario reestructurar o reescribir el proceso que aplica las
transacciones a la BD.
Los logs de auditoría en un SGBD mantienen la cronología de eventos
ocurren en la definición de la BD o en la BD en sí misma.
que
33
Se graba un conjunto de todos los eventos que ocurren sobre la BD como
creaciones, modificaciones, eliminaciones recuperaciones.
2.16 DEFINICIÓN DE UNA ESTAMPA DE TIEMPO DE UNA BASE
DE DATOS
La estampa de tiempo confirma el efecto tomado sobre la definición de la Base de
Datos.
Estas estampas de tiempo tienen dos propósitos:
1.
2.
Confirmar que la última transacción ha alcanzado la definición de la BD
o la BD misma;
Identificar una posición única de tiempo para la transacción, en una
serie de eventos que le han sucedido al ítem de dato, de la definición de
la BD o la BD misma.
La estampa de tiempo puede ser clasificada dentro del identificador de destino,
para un conjunto de transacciones.
La estampa de tiempo tiene dos propósitos:
1.
Facilitar las consultas sobre logs de auditoría: los efectos de la
transacción serán determinados inmediatamente consultando el log.
2.
Proveer redundancia: una eliminación fraudulenta de una entrada del
log de auditoría o una alteración de una estampa de tiempo puede ser
detectada verificando la imagen posterior versus la anterior.
La estampa de tiempo confirma el efecto tomado sobre la definición de la Base de
Datos. La estampa de tiempo puede ser clasificada dentro del identificador de
destino, para un conjunto de transacciones.
34
CAPITULO
RIESGOS
III
METODOLOGÍAS
DE
ANÁLISIS
DE
3.1 CONCEPTO DE ANÁLISIS DE RIESGOS
La auditoria informática solo identifica el nivel de “exposición” por la falta de
controles mientras el análisis de riesgos facilita la evaluación de los riesgos y
recomienda acciones en base al costo-beneficio de la misma.
Todas las metodologías existentes en seguridad de sistemas van encaminadas a
establecer y mejorar un entramado de contramedidas que garanticen que la
productividad de que las amenazas se materialicen en hechos sea lo más baja
posible o al menos quede reducida de una forma razonable en costo-beneficio.
Las metodologías más realizadas en la evaluación de los sistemas son un Análisis
de riesgos y la auditoría informática con dos enfoques distintos. La auditoría
informática sólo identifica el nivel de “exposición” por la falta de controles, mientras
el análisis de riesgos facilita la “evaluación” de los riesgos y recomienda acciones
en base al costo-beneficio de las mismas.
El análisis de riesgos se enfoca en identificar las amenazas, vulnerabilidades,
riesgos y el impacto que se encuentran en los sistemas, o bien en un enfoque de
estudio.
Las metodologías de análisis de riesgos se utilizan desde los años setenta, en la
industria del seguro basándose en grandes volúmenes de datos estadísticos
agrupados. Todos los riesgos que se presentan podemos:




Evitarlos
Transferirlos
Reducirlo
Asumirlo
3.2 METODOLOGÍA EN AUDITORÍA INFORMÁTICA
Todas las metodologías existentes desarrolladas y utilizadas en la auditoría y el
control informático, se puede agrupar en dos grandes familias:
Cuantitativas: Basadas en un modelo matemático numérico que ayuda a la
realización del trabajo, están diseñadas para producir una lista de riesgos que
pueden compararse entre sí con facilidad por tener asignados unos valores
35
numérico. Están diseñadas para producir una lista de riesgos que pueden
compararse entre sí con facilidad por tener asignados unos valores numéricos.
Estos valores son datos de probabilidad de ocurrencia de un evento que se debe
extraer de un riesgo de incidencias donde el número de incidencias tiende al
infinito.
Cualitativas: Basadas en el criterio y raciocinio humano capaz de definir un
proceso de trabajo, para seleccionar en base al experiencia acumulada. Puede
excluir riesgos significantes desconocidos (depende de la capacidad del
profesional para usar el check-list/guía). Basadas en métodos estadísticos y lógica
borrosa, que requiere menos recursos humanos / tiempo que las metodologías
cuantitativas.
Ventajas:
 Enfoque lo amplio que se desee.
 Plan de trabajo flexible y reactivo.
 Se concentra en la identificación de eventos.
Desventajas
 Depende fuertemente de la habilidad y calidad del personal
involucrado.
 Identificación de eventos reales más claros al no tener que
aplicarles probabilidades complejas de calcular.
 Dependencia profesional.
3.3 METODOLOGÍA TRADICIONAL PARA AUDITORÍA DE LA
BASE DE DATOS
Este tipo de metodología para el auditor sirve para revisar el entorno con la ayuda
de una lista de control (Checklist), que consta de una serie de cuestiones a
verificar.
El auditor deberá colocar a la investigación S, si las respuesta es afirmativa, N en
caso contrario o NA (no aplica).
3.4 METODOLOGÍA COBIT
El gobierno de TI es responsabilidad de los ejecutivos, del consejo de directores y
consta de liderazgo, estructuras y procesos organizacionales que garantizan que
la TI de la empresa sostiene y extiende las estrategias y objetivos
organizacionales.
36
Más aún, el gobierno de TI integra e institucionaliza las buenas prácticas para
garantizar que la TI de la empresa sirve como base a los objetivos del negocio. De
esta manera, el gobierno de TI facilita que la empresa aproveche al máximo su
información, maximizando así los beneficios, capitalizando las oportunidades y
ganando ventajas competitivas.
Estos resultados requieren un marco de referencia para controlar la TI, que se
ajuste y sirva como soporte al Committee Of Sponsoring Organisations Of The
Treadway Commission Control interno—Marco de Referencia integrado, el marco
de referencia de control ampliamente aceptado para gobierno de la empresa y
para la administración de riesgos, así como a marcos compatibles similares.
Las organizaciones deben satisfacer la calidad, los requerimientos fiduciarios y de
seguridad de su información, así como de todos sus activos. La dirección también
debe optimizar el uso de los recursos disponibles de TI, incluyendo aplicaciones,
información, infraestructura y personas.
Para descargar estas responsabilidades, así como para lograr sus objetivos, la
dirección debe entender el estatus de su arquitectura empresarial para la TI y
decidir qué tipo de gobierno y de control debe aplicar.
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
ayudarán a optimizar las inversiones facilitadas por la TI, asegurarán la entrega
del servicio y brindarán una medida contra la cual juzgar 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.
La orientación al negocio que enfoca COBIT consiste en vincular las metas de
negocio con las metas de TI, brindando métricas y modelos de madurez para
37
medir sus logros, e identificando las responsabilidades asociadas de los
propietarios de los procesos de negocio y de TI.
El enfoque hacia procesos de COBIT se ilustra con un modelo de procesos, el cual
subdivide TI en 34 procesos de acuerdo a las áreas de responsabilidad de
planear, construir, ejecutar y monitorear, ofreciendo una visión de punta a punta
de la TI. Los conceptos de arquitectura empresarial ayudan a identificar aquellos
recursos esenciales para el éxito de los procesos, es decir, aplicaciones,
información, infraestructura y personas.
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.
Pero, ¿cómo puede la empresa poner bajo control la TI de tal manera que genere
la información que la empresa necesita? ¿Cómo puede administrar los riesgos y
asegurar los recursos de TI de los cuales depende tanto? ¿Cómo puede la
empresa asegurar que TI logre sus objetivos y soporte los del negocio?
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.
La figura 3.1 muestra algunas preguntas frecuentes y las herramientas
gerenciales de información usadas para encontrar las respuestas, aunque estos
tableros de control requieren indicadores, los marcadores de puntuación
requieren mediciones y los Benchmarking requieren una escala de comparación.
38
Figura 3.1 Preguntas frecuentes
Una respuesta a los requerimientos de determinar y monitorear el nivel apropiado
de control y desempeño de TI son las definiciones específicas de COBIT de los
siguientes conceptos:
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 estos procesos, con base en los objetivos de
control detallados de COBIT
La evaluación de la capacidad de los procesos basada en los modelos de
madurez de COBIT es una parte clave de la implementación del gobierno de TI.
Después de identificar los procesos y controles críticos de TI, el modelado de la
madurez permite identificar y demostrar a la dirección las brechas en la capacidad.
Entonces se pueden crear planes de acción para llevar estos procesos hasta el
nivel objetivo de capacidad deseado. COBIT da soporte al gobierno de TI
(Figura3.2) al brindar un marco de trabajo que garantiza que:




TI está alineada con el negocio
TI capacita el negocio y maximiza los beneficios
Los recursos de TI se usen de manera responsable
Los riesgos de TI se administren apropiadamente
La medición del desempeño es esencial para el gobierno de TI. COBIT le da
soporte e incluye el establecimiento y el monitoreo de objetivos que se puedan
39
medir, referentes a lo que los procesos de TI requieren generar (resultado del
proceso) y cómo lo generan (capacidad y desempeño del proceso).
Muchos estudios han identificado que la falta de transparencia en los costos, valor
y riesgos de TI, es uno de los más importantes impulsores para el gobierno de TI.
Mientras las otras áreas consideradas contribuyen, la transparencia se logra de
forma principal por medio de la medición del desempeño.
Figura 3.2 Áreas Focales del Gobierno de TI
Los productos COBIT se han organizado en tres niveles (figura 3.3) 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.
Figura 3.3 Productos de COBIT
40
Es de interés primordial para los ejecutivos:
El resumen informativo al consejo sobre el gobierno de TI, 2da Edición—
Diseñado para ayudar a los ejecutivos a entender porqué el gobierno de TI es
importante, cuáles son sus intereses y sus responsabilidades para su
administración
Es de primordial interés para la dirección del negocio y de tecnología:
Directrices Gerenciales: Herramientas para ayudar a asignar responsabilidades,
medir el desempeño, llevar a cabo benchmarks y manejar brechas en la
capacidad. Las directrices ayudan a brindar respuestas a preguntas comunes de
la administración: ¿Qué tan lejos podemos llegar para controlar la TI?, y ¿el costo
justifica el beneficio? ¿Cuáles son los indicadores de un buen desempeño?
¿Cuáles son las prácticas administrativas clave a aplicar? ¿Qué hacen otros?
¿Cómo medimos y comparamos?
MARCO DE TRABAJO
Cada vez más, la alta dirección se está dando cuenta del impacto significativo que
la información puede tener en el éxito de una empresa.
La dirección espera un alto entendimiento de la manera en que la tecnología de
información (TI) es operada y de la posibilidad de que sea aprovechada con éxito
para tener una ventaja competitiva.
En particular, la alta dirección necesita saber si con la información administrada en
la empresa es posible que:








Garantice el logro de sus objetivos
Tenga suficiente flexibilidad para aprender y adaptarse
Cuente con un manejo juicioso de los riesgos que enfrenta
Reconozca de forma apropiada las oportunidades y actúe de acuerdo a
ellas Las empresas exitosas entienden los riesgos y aprovechan los
beneficios de TI, y encuentran maneras para: • Alinear la estrategia de
TI con la estrategia del negocio
Lograr que toda la estrategia de TI, así como las metas fluyan de forma
gradual a toda la empresa
Proporcionar
estructuras
organizacionales
que
faciliten
la
implementación de estrategias y metas
Crear relaciones constructivas y comunicaciones efectivas entre el
negocio y TI, y con socios externos
Medir el desempeño de TI
41
Las empresas no pueden responder de forma efectiva a estos requerimientos de
negocio y de gobierno sin adoptar e implementar un marco de Referencia de
gobierno y de control para TI, de tal manera que:
 Se forme un vínculo con los requerimientos del negocio • El desempeño
real con respecto a los requerimientos sea transparente
 Organice sus actividades en un modelo de procesos generalmente
aceptado • Identifique los principales recursos a ser aprovechados
 Se definan los objetivos de control Gerenciales a ser considerados
Además, el gobierno y los marcos de trabajo de control están siendo
parte de las mejores prácticas de la administración de TI y sirven como
facilitadores para establecer el gobierno de TI y cumplir con el constante
incremento de requerimientos regulatorios.
Las mejores prácticas de TI se han vuelto significativas debido a un número de
factores:
Directores de negocio y consejos directivos que demandan un mayor retorno de la
inversión en TI, es decir, que TI genere lo que el negocio necesita para mejorar el
valor de los participantes
Preocupación por el creciente nivel de gasto en TI
La necesidad de satisfacer requerimientos regulatorios para controles de TI en
áreas como privacidad y reportes financieros (por ejemplo, Sarbanes-Oxley Act,
Basel II) y en sectores específicos como el financiero, farmacéutico y de atención
a la salud
La necesidad de las empresas de valorar su desempeño en comparación con
estándares generalmente aceptados
y con respecto a su competencia
(Benchmarking)
Riesgos crecientemente complejos de la TI como la seguridad de redes
La selección de proveedores de servicio y el manejo de Outsourcing y de
Adquisición de servicios
La madurez creciente y la consecuente aceptación de marcos de trabajo
respetados tales como COBIT, ITIL, ISO 17799, ISO 9001, CMM y PRINCE2
La necesidad de optimizar costos siguiendo, siempre que sea posible, un enfoque
estandarizado en lugar de enfoques desarrollados especialmente
Iniciativas de gobierno de TI que incluyen la adopción de marcos de referencia de
42
control y de mejores prácticas para ayudar a monitorear y mejorar las actividades
críticas de TI, aumentar el valor del negocio y reducir los riesgos de éste
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 (figura 3.4):
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.
Figura 3.4 Principio Básico
Si se pretende que la TI proporcione servicios de forma exitosa para dar soporte a
la estrategia de la empresa, debe existir una propiedad y una dirección clara de los
requerimientos por parte del negocio (el cliente) y un claro entendimiento para TI,
de cómo y qué debe entregar (el proveedor).
43
La Figura 3.5 ilustra como la estrategia de la empresa se debe traducir por parte
del negocio en objetivos para su uso de iniciativas facilitadas por TI (Las metas de
negocio para TI).
Estos objetivos a su vez, deben conducir a una clara definición de los propios
objetivos de la TI (las metas de TI), y luego éstas a su vez definir los recursos y
capacidades de TI (la arquitectura empresarial para TI) requeridos para ejecutar
de forma exitosa la parte que le corresponde a TI de la estrategia empresarial.
Todos estos objetivos se deben expresar en términos de negocios significativos
para el cliente, y esto, combinado con una alineación efectiva de la jerarquía de
objetivos, asegurará que el negocio pueda confirmar que TI puede, con alta
probabilidad, dar soporte a las metas del negocio.
Figura 3.5 Definiendo metas de TI y arquitectura empresarial para TI
Una vez que las metas alineadas han sido definidas, requieren ser monitoreadas
para garantizar que la entrega cumple con las expectativas. Esto se logra con
métricas derivadas de las metas y capturadas en scorecard de TI que el cliente
pueda entender y seguir, y que permita al proveedor enfocarse en sus propios
objetivos internos.
44
3.5 RECURSOS DE TI
La organización de TI se desempeña con respecto a estas metas como un
conjunto de procesos definidos con claridad que utiliza las habilidades de las
personas, y la infraestructura de tecnología para ejecutar aplicaciones
automatizadas de negocio, mientras que al mismo tiempo toma ventaja de la
información del negocio. Estos recursos, junto con los procesos, constituyen una
arquitectura empresarial para TI.
Para responder a los requerimientos que el negocio tiene hacia TI, la empresa
debe invertir en los recursos requeridos para crear una capacidad técnica
adecuada (ej., un sistema de planeación de recursos empresariales) para dar
soporte a la capacidad del negocio (ej., implementando una cadena de suministro)
que genere el resultado deseado (ej., mayores ventas y beneficios financieros).
Los recursos de TI identificados en COBIT se pueden definir como sigue:
 Las aplicaciones incluyen tanto sistemas de usuario automatizados como
procedimientos manuales que procesan información.
 La información son los datos en todas sus formas de entrada, procesados y
generados por los sistemas de información, en cualquier forma en que son
utilizados por el negocio.
 La infraestructura es la tecnología y las instalaciones (hardware, sistemas
operativos, sistemas de administración de base de datos, redes,
multimedia, etc., así como el sitio donde se encuentran y el ambiente que
los soporta) que permiten el procesamiento de las aplicaciones.
Procesos orientados
COBIT define las actividades de TI en un modelo genérico de procesos en cuatro
dominios. Estos dominios son Planear y Organizar, Adquirir e Implementar,
Entregar y Dar Soporte y Monitorear y Evaluar.
Los dominios se equiparan a las áreas tradicionales de TI de planear, construir,
ejecutar y monitorear.
El marco de trabajo de COBIT proporciona un modelo de procesos de referencia y
un lenguaje común para que cada uno en la empresa visualice y administre las
actividades de TI.
45
La incorporación de un modelo operacional y un lenguaje común para todas las
partes de un negocio involucradas en TI es uno de los pasos iníciales más
importantes hacia un buen gobierno. También brinda un marco de trabajo para la
medición y monitoreo del desempeño de TI, comunicándose con los proveedores
de servicios e integrando las mejores prácticas administrativas. Un modelo de
procesos fomenta la propiedad de los procesos, permitiendo que se definan las
responsabilidades.
Para gobernar efectivamente TI, es importante determinar las actividades y los
riesgos que requieren ser administrados. Éstos se pueden resumir como sigue:
3.6 DOMINIOS
3.6.1 PLANEAR Y ORGANIZAR (PO)
Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la
manera en que TI pueda contribuir de la mejor manera al logro de los objetivos del
negocio. Además, la realización de la visión estratégica requiere ser planeada,
comunicada y administrada desde diferentes perspectivas. Finalmente, se debe
implementar 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.6.2 ADQUIRIR E IMPLEMENTAR (AI)
Para llevar a cabo la estrategia de TI, las soluciones de TI necesitan ser
identificadas, desarrolladas o adquiridas así como la implementación e integración
en los procesos del negocio. Además, el cambio y el mantenimiento de los
sistemas existentes está cubierto por este dominio para garantizar que las
soluciones 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?
46
 ¿Los nuevos proyectos son entregados a tiempo y dentro del
presupuesto?
 ¿Trabajarán adecuadamente los nuevos sistemas una vez sean
implementados?
3.6.3 ENTREGAR Y DAR SOPORTE (DS)
Este dominio cubre la entrega en sí de los servicios requeridos, lo que incluye la
prestación del servicio, la administración de la seguridad y de la continuidad, el
soporte del servicio a los usuarios, la administración de los datos y de las
instalaciones 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.6.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?
3.7 MODELOS DE MADUREZ
Cada vez con más frecuencia, se les pide a los directivos de empresas
corporativas y públicas que se considere qué tan bien se está administrando TI.
47
Como respuesta a esto, se debe desarrollar un plan de negocio para mejorar y
alcanzar el nivel apropiado de administración y control sobre la infraestructura de
información.
Aunque pocos argumentarían que esto no es algo bueno, se debe considerar el
equilibrio del costo beneficio y éstas preguntas relacionadas:
 ¿Qué están haciendo nuestra competencia en la industria, y cómo
estamos posicionados en relación a ellos?
 ¿Cuáles son las mejores prácticas aceptables en la industria, y cómo
estamos posicionados con respecto a estas prácticas?
 Con base en estas comparaciones, ¿se puede decir que estamos
haciendo lo suficiente?
 ¿Cómo identificamos lo que se requiere hacer para alcanzar un nivel
adecuado de administración y control sobre nuestros procesos de TI?
Puede resultar difícil proporcionar respuestas significativas a estas preguntas. La
gerencia de TI está buscando constantemente herramientas de evaluación por
benchmarking y herramientas de auto-evaluación como respuesta a la necesidad
de saber qué hacer de manera eficiente.
Comenzando con los procesos y los objetivos de control de alto nivel de COBIT, el
propietario del proceso se debe poder evaluar de forma progresiva, contra los
objetivos de control.
Esto responde a tres necesidades:
1. Una medición relativa de dónde se encuentra la empresa
2. Una manera de decidir hacia dónde ir de forma eficiente
3. Una herramienta para medir el avance contra la meta
El modelado de la madurez para la administración y el control de los procesos de
TI se basa en un método de evaluación de la organización, de tal forma que se
pueda evaluar a sí misma desde un nivel de no-existente (0) hasta un nivel de
optimizado (5).
Este enfoque se deriva del modelo de madurez que el Software Engineering
Institute definió para la madurez de la capacidad del desarrollo de software.
Cualquiera que sea el modelo, las escalas no deben ser demasiado granulares, ya
que eso haría que el sistema fuera difícil de usar y sugeriría una precisión que no
es justificable debido a que en general, el fin es identificar dónde se encuentran
los problemas y cómo fijar prioridades para las mejoras.
48
El propósito no es avaluar el nivel de adherencia a los objetivos de control.
Los niveles de madurez están diseñados como perfiles de procesos de TI que una
empresa reconocería como descripciones de estados posibles actuales y futuros.
No están diseñados para ser usados como un modelo limitante, donde no se
puede pasar al siguiente nivel superior sin haber cumplido todas las condiciones
del nivel inferior.
Si se usan los procesos de madurez desarrollados para cada uno de los 34
procesos TI de COBIT, la administración podrá identificar:
 El desempeño real de la empresa—Dónde se encuentra la empresa
hoy
 El estatus actual de la industria—La comparación
 El objetivo de mejora de la empresa—Dónde desea estar la empresa
Para hacer que los resultados sean utilizables con facilidad en resúmenes
gerenciales, donde se presentarán como un medio para dar soporte al caso de
negocio para planes futuros, se requiere contar con un método gráfico de
presentación (figura 3.6).
Figura 3.6 Representación gráfica de modelos de madurez
0 No existente. Carencia completa de cualquier proceso reconocible. La empresa
no ha reconocido siquiera que existe un problema a resolver.
1 Inicial. Existe evidencia que la empresa ha reconocido que los problemas
existen y requieren ser resueltos. Sin embargo; no existen procesos estándar en
su lugar existen enfoques ad hoc que tienden a ser aplicados de forma individual o
caso por caso. El enfoque general hacia la administración es desorganizado.
49
2 Repetible. Se han desarrollado los procesos hasta el punto en que se siguen
procedimientos similares en diferentes áreas que realizan la misma tarea. No hay
entrenamiento o comunicación formal de los procedimientos estándar, y se deja la
responsabilidad al individuo. Existe un alto grado de confianza en el conocimiento
de los individuos y, por lo tanto, los errores son muy probables.
3 Definido. Los procedimientos se han estandarizado y documentado, y se han
difundido a través de entrenamiento. Sin embargo, se deja que el individuo decida
utilizar estos procesos, y es poco probable que se detecten desviaciones. Los
procedimientos en sí no son sofisticados pero formalizan las prácticas existentes.
4 Administrado. Es posible monitorear y medir el cumplimiento de los
procedimientos y tomar medidas cuando los procesos no estén trabajando de
forma efectiva. Los procesos están bajo constante mejora y proporcionan buenas
prácticas. Se usa la automatización y herramientas de una manera limitada o
fragmentada.
5 Optimizado. Los procesos se han refinado hasta un nivel de mejor práctica, se
basan en los resultados de mejoras continuas y en un modelo de madurez con
otras empresas. TI se usa de forma integrada para automatizar el flujo de trabajo,
brindando herramientas para mejorar la calidad y la efectividad, haciendo que la
empresa se adapte de manera rápida.
La ventaja de un modelo de madurez es que es relativamente fácil para la
dirección ubicarse a sí misma en la escala y evaluar qué se debe hacer si se
requiere desarrollar una mejora.
La escala incluye al 0 ya que es muy posible que no existan procesos en lo
absoluto. La escala del 0-5 se basa en una escala de madurez simple que muestra
como un proceso evoluciona desde una capacidad no existente hasta una
capacidad optimizada.
Sin embargo, la capacidad administrativa de un proceso no es lo mismo que el
desempeño. La capacidad requerida, como se determina en el negocio y en las
metas de TI, puede no requerir aplicarse al mismo nivel en todo el ambiente de TI,
es decir, de forma inconsistente o solo a un número limitado de sistemas o
unidades.
La medición del desempeño, como se cubre en los próximos párrafos, es esencial
para determinar cuál es el desempeño real de la empresa en sus procesos de TI.
Aunque una capacidad aplicada de forma apropiada reduce los riesgos, una
empresa debe analizar los controles necesarios para asegurar que el riesgo sea
50
mitigado y que se obtenga el valor de acuerdo al apetito de riesgo y a los objetivos
del negocio.
Estos controles son dirigidos por los objetivos de control de COBIT. El apéndice III
brinda un modelo de madurez para el control interno que ilustra la madurez de una
empresa con respecto al establecimiento y desempeño del control interno.
La capacidad, el desempeño y el control son dimensiones de la madurez de un
proceso como se ilustra en la Figura 3.7.
Figura 3.7 Las tres dimensiones de la madurez
El modelo de madurez es una forma de medir qué tan bien están desarrollados los
procesos administrativos, esto es, qué tan capaces son en realidad.
Qué tan bien desarrollados o capaces deberían ser, principalmente dependen de
las metas de TI y en las necesidades del negocio subyacentes a la cuales sirven
de base.
Cuánta de esa capacidad es realmente utilizada actualmente para retornar la
inversión deseada en una empresa. Por ejemplo, habrá procesos y sistemas
críticos que requieren de una mayor administración de la seguridad que otros que
son menos críticos. Por otro lado, el grado y sofisticación de los controles que se
requiere aplicar en un proceso están más definidos por el apetito de riesgo de una
empresa y por los requerimientos aplicables.
Las escalas del modelo de madurez ayudarán a los profesionales a explicarle a la
gerencia dónde se encuentran los defectos en la administración de procesos de TI
y a establecer objetivos donde se requieran
51
La tabla de atributos de madurez que se muestra en la Tabla 3.1 lista las
características de cómo se administran los procesos de TI y describe cómo
evolucionan desde un proceso no existente hasta uno optimizado.
Estos atributos se pueden usar para una evaluación más integral, para un análisis
de brechas y para la planeación de mejoras.
En resumen, los modelos de madurez brindan un perfil genérico de las etapas a
través de las cuales evolucionan las empresas para la administración y el control
de los procesos de TI, estos son:
 Un conjunto de requerimientos y los aspectos que los hacen posibles en
los distintos niveles de madurez.
 Una escala donde la diferencia se puede medir de forma sencilla.
 Una escala que se presta a sí misma para una comparación práctica.
 La base para establecer el estado actual y el estado deseado.
 Soporte para un análisis de brechas para determinar qué se requiere
hacer para alcanzar el nivel seleccionado.
 Tomado en conjunto, una vista de cómo se administra la TI en la
empresa.
52
Conciencia y comunicación
Políticas, estándares y
procedimientos
Herramientas y automatización
Habilidades y experiencia
Responsabilidad y rendición de
cuentas
Establecimiento y medición de
metas
1 Surge el reconocimiento de la
necesidad del proceso
Existen enfoques ad hoc hacia los
procesos y las prácticas
Pueden existir algunas herramientas;
el uso se basa en herramienta
estándar de escritorio
No están definidas las habilidades
requeridas para el proceso
Las metas no están claras y no
existen las mediciones.
Existe comunicación esporádica de
los problemas.
Los procesos y las prácticas no están
definidos
No existe definición de
responsabilidades y de rendición de
cuentas. Las personas toman la
propiedad de los problemas con base
en su propia iniciativa de manera
reactiva.
2 Existe conciencia de la necesidad
de actuar
Surgen procesos similares y
comunes pero en su mayoría son
intuitivos y parten de la experiencia
individual
Existen enfoques comunes para el
uso de herramientas pero se basan
en soluciones desarrolladas por
individuos clave.
Pueden haberse adquirido
herramientas de proveedores, pero
probablemente no se aplican de
forma correcta o incluso no usarse.
Se da entrenamiento como respuesta
a las necesidades, en lugar de
hacerlo con base en un plan
acordado. Existe entrenamiento
informal sobre la marcha.
Existen algunas metas; se
establecen algunas mediciones
financieras pero solo las conoce la
alta dirección. Hay monitoreo
inconsistente en áreas aisladas.
Algunos aspectos de los procesos
son repetibles debido a la
experiencia individual, y puede existir
alguna documentación y
entendimiento informal de las
políticas y procedimientos
Un individuo asume su
responsabilidad, y por lo general
debe rendir cuentas aún si esto no
está acordado de modo formal.
Existe confusión acerca de la
responsabilidad cuando ocurren
problemas y una cultura de culpas
tiende a existir.
Surge el uso de buenas prácticas
Existe un plan para el uso y
estandarización de las herramientas
para automatizar el proceso
Se definen y documentan los
requerimientos y habilidades para
todas las áreas.
Se usan herramientas por su
propósito básico, pero pueden no
estar de acuerdo al plan acordado, y
pueden no estar integradas entre sí
Existe un plan de entrenamiento
formal pero todavía se basa en
iniciativas individuales
La responsabilidad y la rendición de
cuentas sobre los procesos están
definidas y se han identificado a los
propietarios de los procesos de
negocio. Es poco probable que el
propietario del proceso tenga la
autoridad plena para ejercer las
responsabilidades.
Se implantan las herramientas de
acuerdo a un plan estándar y algunas
se han integrado con otras
herramientas relacionadas
Los requerimientos de habilidades se
actualizan rutinariamente para todas
las áreas, se asegura la capacidad
para todas las áreas críticas y se
fomenta la certificación
Se aplican técnicas maduras de
entrenamiento de acuerdo al plan y
se fomenta la compartición del
conocimiento. Todos los expertos
internos están involucrados y se
evalúa la efectividad del plan de
entrenamiento.
La organización fomenta de manera
formal la mejora continua de las
habilidades, con base en metas
personales y organizacionales
claramente definidas.
Se establecen algunas mediciones y
metas de efectividad, pero no se
comunican, y existe una relación
clara con las metas del negocio.
Surgen los procesos de medición
pero no se aplican de modo
consistente. Se adoptan ideas de un
balanced scorecard de TI así como la
aplicación intuitiva ocasional de
análisis de causas raíz.
La eficiencia y la efectividad se
miden y comunican y están ligadas a
las metas del negocio y al plan
estratégico de TI. Se implementa el
balanced scorecard de TI en algunas
áreas, con excepciones conocidas
por la gerencia y se está
estandarizando el análisis de causas
raíz. Surge la mejora continua.
La gerencia comunica los problemas
generales
3 Existe el entendimiento de la
necesidad de actuar
La gerencia es más formal y
estructurada en su comunicación
4 Hay entendimiento de los
requerimientos completos
Se aplican técnicas maduras de
comunicación y se usan
herramientas estándar de
comunicación
Los procesos, políticas y
procedimientos están definidos y
documentados para todas las
actividades clave
El proceso es sólido y completo; se
aplican las mejores prácticas
internas.
Todos los aspectos del proceso
están documentados y son
repetibles. La dirección ha terminado
y aprobado las políticas. Se adoptan
y siguen estándares para el
desarrollo y mantenimiento de
procesos y procedimientos.
5 Existe un entendimiento avanzado
y a futuro de los requerimientos
Se aplican las mejores prácticas y
estándares externos
Existe una comunicación proactiva
de los problemas, basada en las
tendencias, se aplican técnicas
maduras de comunicación y se usan
herramientas integradas de
comunicación
La documentación de procesos ha
evolucionado a flujos de trabajo
automatizados. Los procesos, las
políticas y los procedimientos están
estandarizados e integrados para
permitir una administración y mejoras
integrales
No existe un enfoque planeado para
el uso de herramientas
Se usan herramientas en las
principales áreas para automatizar la
administración del proceso y
monitorear las actividades y controles
críticos
Se usan juegos de herramientas
estandarizados a lo largo de la
empresa.
Las herramientas están
completamente integradas con otras
herramientas relacionadas para
permitir un soporte integral de los
procesos.
Se usan las herramientas para dar
soporte a la mejora del proceso y
detectar de forma automática las
excepciones de control
No existe un plan de entrenamiento y
no hay entrenamiento formal
Se identifican los requerimientos
mínimos de habilidades para áreas
críticas
El entrenamiento y la educación dan
soporte a las mejores prácticas
externas y al uso de conceptos y
técnicas de vanguardia. La
compartición del conocimiento es
parte de la cultura empresarial y se
implementan sistemas basados en
conocimiento. Se usan a expertos
externos y a líderes de la industria
como guía.
Las responsabilidades y la rendición
de cuentas sobre los procesos están
aceptadas y funcionan de modo que
se permite al propietario del proceso
descargar sus responsabilidades.
Existe una cultura de recompensas
que activa la acción positiva.
Los propietarios de procesos tienen
la facultad de tomar decisiones y
medidas. La aceptación de la
responsabilidad ha descendido en
cascada a través de la organización
de forma consistente.
Existe un sistema de medición de
desempeño integrado que liga al
desempeño de TI con las metas del
negocio por la aplicación global del
balanced scorecard de TI. La
dirección nota las excepciones de
forma global y consistente y el
análisis de causas raíz se aplica. La
mejora continua es una forma de
vida.
Tabla 3.1 Atributos de madurez
53
Para resumir, 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 (Figura 3.8)
Figura 3.8 El cubo de COBIT
En detalle, el marco de trabajo general COBIT se muestra gráficamente en la
Figura 3.9, 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.
54
Figura 3.9 Marco de trabajo General de COBIT
55
3.8 OBJETIVOS DE CONTROL EMPLEADOS PARA LA AUDITORÍA
3.8.1 PO9 EVALUAR Y ADMINISTRAR LOS RIESGOS DE TI
Crear y dar mantenimiento a un marco de trabajo de administración de riesgos. El
marco de trabajo documenta un nivel común y acordado de riesgos de TI,
estrategias de mitigación y riesgos residuales acordados. Cualquier impacto
potencial sobre las metas de la organización, causado por algún evento no
planeado se debe identificar, analizar y evaluar. Se deben adoptar estrategias de
mitigación de riesgos para minimizar los riesgos residuales a un nivel aceptable. El
resultado de la evaluación debe ser entendible para los participantes y se debe
expresar en términos financieros, para permitir a los participantes alinear los
riesgos 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 los
riesgos 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 de
riesgos 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á incluida
completamente en los procesos administrativos, tanto interna como externamente,
y se aplica de forma consistente
La realización de evaluaciones de riesgo
Recomendar y comunicar planes de acciones para mitigar riesgos
Y se mide con Porcentaje de objetivos críticos de TI cubiertos por la evaluación
de riesgos
PO9.4 IT Evaluación de riesgos Evaluar de forma recurrente la posibilidad e
impacto de todos los riesgos identificados, usando métodos cualitativos y
cuantitativos. La posibilidad e impacto asociados a los riesgos inherentes y
residuales se debe determinar de forma individual, por categoría y con base en el
portafolio
3.8.2 AI2 ADQUIRIR Y MANTENER SOFTWARE APLICATIVO
Las aplicaciones deben estar disponibles de acuerdo con los requerimientos del
negocio. Este proceso cubre el diseño de las aplicaciones, la inclusión apropiada
de controles aplicativos y requerimientos de seguridad, y el desarrollo y la
configuración en sí de acuerdo a los estándares. Esto permite a las
56
organizaciones apoyar la operatividad del negocio de forma apropiada con las
aplicaciones automatizadas correctas.
Control sobre el proceso TI de
aplicativo
Adquirir y dar mantenimiento a software
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
3.8.3 DS5 GARANTIZAR LA SEGURIDAD DE LOS SISTEMAS
La necesidad de mantener la integridad de la información y de proteger los activos
de TI, requiere de un proceso de administración de la seguridad. Este proceso
incluye el establecimiento y mantenimiento de roles y responsabilidades de
seguridad, políticas, estándares y procedimientos de TI. La administración de la
seguridad también incluye realizar monitoreos de seguridad y pruebas periódicas
así como realizar acciones correctivas sobre las debilidades o incidentes de
seguridad identificados. Una efectiva administración de la seguridad protege todos
los activos de TI para minimizar el impacto en el negocio causado por
vulnerabilidades o incidentes de seguridad
Control sobre el proceso TI de Garantizar la seguridad de los sistemas que
satisface el requisito de negocio de TI para mantener 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.
57
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 de
emergencia. 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.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.
58
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.
Las metas y métricas de este dominio se describen en la Figura 3.10
Figura 3.10 Metas y Métricas.DS5
59
Modelo de Madurez
DS5 GARANTIZAR LA SEGURIDAD DE LOS SISTEMAS
La administración del proceso de Garantizar la seguridad de los sistemas
que satisfaga el requerimiento de negocio de TI de mantener la integridad de
la información y de la infraestructura de procesamiento y minimizar el
impacto de vulnerabilidades e incidentes de seguridad es:
0 No-existente cuando La organización no reconoce la necesidad de la seguridad
para TI. Las responsabilidades y la rendición de cuentas no están asignadas para
garantizar la seguridad. Las medidas para soportar la administrar la seguridad de
TI no están implementadas. No hay reportes de seguridad de TI ni un proceso de
respuesta para resolver brechas de seguridad de TI. Hay una total falta de
procesos reconocibles de administración de seguridad de sistemas.
1 Inicial/Ad Hoc cuando La organización reconoce la necesidad de seguridad
para TI. La conciencia de la necesidad de seguridad depende principalmente del
individuo. La seguridad de TI se lleva a cabo de forma reactiva. No se mide la
seguridad de TI. Las brechas de seguridad de TI ocasionan respuestas con
acusaciones personales, debido a que las responsabilidades no son claras. Las
respuestas a las brechas de seguridad de TI son impredecibles.
2 Repetible pero intuitivo cuando Las responsabilidades y la rendición de
cuentas sobre la seguridad, están asignadas a un coordinador de seguridad de TI,
pero la autoridad gerencial del coordinador es limitada. La conciencia sobre la
necesidad de la seguridad esta fraccionada y limitada. Aunque los sistemas
producen información relevante respecto a la seguridad, ésta no se analiza. Los
servicios de terceros pueden no cumplir con los requerimientos específicos de
seguridad de la empresa. Las políticas de seguridad se han estado desarrollando,
pero las herramientas y las habilidades son inadecuadas. Los reportes de la
seguridad de TI son incompletos, engañosos o no aplicables. La capacitación
sobre seguridad está disponible pero depende principalmente de la iniciativa del
individuo. La seguridad de TI es vista primordialmente como responsabilidad y
disciplina de TI, y el negocio no ve la seguridad de TI como parte de su propia
disciplina.
3 Proceso definido cuando Existe conciencia sobre la seguridad y ésta es
promovida por la gerencia. Los procedimientos de seguridad de TI están definidos
y alineados con la política de seguridad de TI. Las responsabilidades de la
seguridad de TI están asignadas y entendidas, pero no continuamente
implementadas. Existe un plan de seguridad de TI y existen soluciones de
seguridad motivadas por un análisis de riesgo. Los reportes no contienen un
enfoque claro de negocio. Se realizan pruebas de seguridad adecuadas (por
ejemplo, pruebas contra intrusos). Existe capacitación en seguridad para TI y para
el negocio, pero se programa y se comunica de manera informal.
60
4 Administrado y Medible cuando Las responsabilidades sobre la seguridad de
TI son asignadas, administradas e implementadas de forma clara. Regularmente
se lleva a cabo un análisis de impacto y de riesgos de seguridad. Las políticas y
prácticas de seguridad se complementan con referencias de seguridad
específicas. El contacto con métodos para promover la conciencia de la seguridad
es obligatorio. La identificación, autenticación y autorización de los usuarios está
estandarizada. La certificación en seguridad es buscada por parte del personal
que es responsable de la auditoría y la administración de la seguridad. Las
pruebas de seguridad se hacen utilizando procesos estándares y formales que
llevan a mejorar los niveles de seguridad. Los procesos de seguridad de TI están
coordinados con la función de seguridad de toda la organización. Los reportes de
seguridad están ligados con los objetivos del negocio. La capacitación sobre
seguridad se imparte tanto para TI como para el negocio. La capacitación sobre
seguridad de TI se planea y se administra de manera que responda a las
necesidades del negocio y a los perfiles de riesgo de seguridad. Los KGIs y KPIs
ya están definidos pero no se miden aún.
5 Optimizado cuando La seguridad en TI es una responsabilidad conjunta del
negocio y de la gerencia de TI y está integrada con los objetivos de seguridad del
negocio en la corporación. Los requerimientos de seguridad de TI están definidos
de forma clara, optimizados e incluidos en un plan de seguridad aprobado. Los
usuarios y los clientes se responsabilizan cada vez más de definir requerimientos
de seguridad, y las funciones de seguridad están integradas con las aplicaciones
en la fase de diseño. Los incidentes de seguridad son atendidos de forma
inmediata con procedimientos formales de respuesta soportados por herramientas
automatizadas. Se llevan a cabo valoraciones de seguridad de forma periódica
para evaluar la efectividad de la implementación del plan de seguridad. La
información sobre amenazas y vulnerabilidades se recolecta y analiza de manera
sistemática. Se recolectan e implementan de forma oportuna controles adecuados
para mitigar riesgos. Se llevan a cabo pruebas de seguridad, análisis de causaefecto e identificación pro-activa de riesgos para la mejora continua de procesos.
Los procesos de seguridad y la tecnología están integrados a lo largo de toda la
organización. Los KGIs y KPIs para administración de seguridad son recopilados y
comunicados. La gerencia utiliza los KGIs y KPIs para ajustar el plan de seguridad
en un proceso de mejora continua.
3.8.3 DS8 ADMINISTRAR LA MESA DE SERVICIO Y LOS INCIDENTES
Responder de manera oportuna y efectiva a las consultas y problemas de los
usuarios de TI, requiere de una mesa de servicio bien diseñada y bien ejecutada, y
de un proceso de administración de incidentes.
Este proceso incluye la creación de una función de mesa de servicio con registro,
escalamiento de incidentes, análisis de tendencia, análisis causa-raíz y resolución.
Los beneficios del negocio incluyen el incremento en la productividad gracias a la
resolución rápida de consultas.
61
Además, el negocio puede identificar la causa raíz (tales como un pobre
entrenamiento a los usuarios) a través de un proceso de reporte efectivo.
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.
Figura 3.11Metas y métricas DS8
62
3.8.4 DS11 ADMINISTRACIÓN DE DATOS
Una efectiva administración de datos requiere de la identificación de
requerimientos de datos. El proceso de administración de información también
incluye el establecimiento de procedimientos efectivos para administrar la librería
de medios, el respaldo y la recuperación de datos y la eliminación apropiada de
medios. Una efectiva administración de datos ayuda a garantizar la calidad,
oportunidad y disponibilidad de la información del negocio.
Control sobre el proceso TI de Administración de datos
Que satisface el requisito de negocio de TI para Optimizar el uso de la
información y garantizar la disponibilidad de la información cuando se requiera.
Enfocándose en mantener la integridad, exactitud, disponibilidad y protección de
los datos.
Se logra • Respaldando los datos y probando la restauración • Administrando
almacenamiento de datos en sitio y fuera de sitio. • Desechando de manera
segura los datos y el equipo.
Y se mide con • Satisfacción del usuario con la disponibilidad de los datos. •
Porcentaje de restauraciones exitosas de datos. • Número de incidentes en los
que tuvo que recuperarse datos sensitivos después que los medios habían sido
desechados.
Figura 3.12 Metas y Métricas DS11
63
3.8.5 DS13 ADMINISTRACIÓN DE OPERACIONES
Un procesamiento de información completo y apropiado requiere de una efectiva
administración del procesamiento de datos y del mantenimiento del hardware.
Este proceso incluye la definición de políticas y procedimientos de operación para
una administración efectiva del procesamiento programado, protección de datos
de salida sensitivos, monitoreo de infraestructura y mantenimiento preventivo de
hardware.
Una efectiva administración de operaciones ayuda a mantener la integridad de los
datos y reduce los retrasos en el trabajo y los costos operativos de TI.
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.
64
Figura 3.13 Metas y Métricas DS13
65
CAPÍTULO IV AUDITORÍA A LA BASE DE DATOS DEL
"SISTEMA DE SEGURIDAD DE PRESAS" DE LA
CONAGUA
Comisión Nacional del Agua (CONAGUA)
La Comisión Nacional del Agua es heredera de una gran tradición hidráulica y a lo
largo de su historia ha estado integrada por destacados profesionales y
especialistas de diversas disciplinas, reconocidos internacionalmente por su
dedicación y capacidad técnica.
Dentro de las instituciones que le antecedieron destacan la Dirección de Aguas,
Tierras y Colonización creada en 1917; la Comisión Nacional de Irrigación, en
1926; la Secretaría de Recursos Hidráulicos en 1946 y la Secretaría de Agricultura
y Recursos Hidráulicos en 1976.
Actualmente, la misión de la Comisión Nacional del Agua consiste en administrar y
preservar las aguas nacionales, con la participación de la sociedad, para lograr el
uso sustentable del recurso
.
La Comisión considera que la participación de la sociedad es indispensable para
alcanzar las metas que se han trazado en cada cuenca del país, ya que entre
otros aspectos, los habitantes pueden dar la continuidad que se requiere a las
acciones planteadas.
Por otra parte, considera que el uso sustentable del agua se logra cuando se
cumplen los aspectos siguientes:
1. El agua genera bienestar social: básicamente se refiere al suministro de
los servicios de agua potable y alcantarillado a la población, así como al
tratamiento de las aguas residuales.
2. El agua propicia el desarrollo económico: considera al agua como un
insumo en la actividad económica; por ejemplo, en la agricultura, la
producción de energía eléctrica o la industria
3. El agua se preserva: es el elemento que cierra el concepto de
sustentabilidad. Si bien se reconoce que el agua debe proporcionar
bienestar social y apoyar el desarrollo económico, la Comisión Nacional
del Agua está convencida de que se debe preservar en cantidad y calidad
adecuadas para las generaciones actuales y futuras y la flora y fauna de
cada región
66
Para cumplir con su propósito esencial, la Comisión se divide operativamente en
tres grandes áreas:
1.
2.
3.
Oficinas Centrales
Organismos de Cuenca.
Direcciones Locales
La sede de Oficinas Centrales está en la ciudad de México y dentro de sus
acciones principales se encuentran: apoyar a los Organismos de Cuenca y
Direcciones Locales en la realización de las acciones necesarias para lograr el uso
sustentable del agua en cada región del país, establecer la política y estrategias
hidráulicas nacionales, integrar el presupuesto de la institución y vigilar su
aplicación, concertar con los organismos financieros nacionales e internacionales
los créditos que requiere el Sector Hidráulico, establecer los programas para
apoyar a los municipios en el suministro de los servicios de agua potable y
saneamiento en las ciudades y comunidades rurales y para promover el uso
eficiente del agua en el riego y la industria.
Oficinas Centrales también establece la política de recaudación y fiscalización en
materia de derechos de agua y permisos de descargas, coordina las
modificaciones que se requieran a la Ley de Aguas Nacionales y apoya su
aplicación en el país, elabora las normas en materia hidráulica, opera el servicio
meteorológico nacional, mantiene una sólida y fructífera relación con el H.
Congreso de la Unión, atiende a los medios de comunicación nacionales y se
vincula con las dependencias federales para trabajar en forma conjunta en
acciones que beneficien al Sector Hidráulico.
Los Organismos de Cuenca son las responsables de administrar y preservar las
aguas nacionales en cada una de las trece regiones hidrológico-administrativas en
que se ha dividido el país. Las regiones y sus sedes son:
I.
II.
III.
IV.
V.
VI.
VII.
VIII.
IX.
X.
XI.
XII.
Península de Baja California (Mexicali, Baja California).
Noroeste (Hermosillo, Sonora).
Balsas (Cuernavaca, Morelos)
Pacífico Sur (Oaxaca, Oaxaca)
Río Bravo (Monterrey, Nuevo León).
Cuencas Centrales del Norte (Torreón, Coahuila).
Lerma Santiago Pacífico (Guadalajara, Jalisco).
Golfo Norte (Ciudad Victoria, Tamaulipas).
Golfo Centro (Jalapa, Veracruz).
Frontera Sur (Tuxtla Gutiérrez, Chiapas).
Península de Yucatán (Mérida, Yucatán).
Aguas del Valle de México y Sistema Cutzamala (México, Distrito
Federal).
67
El desempeño de los Organismos de Cuenca es también muy importante, ya que
tienen a su cargo aplicar la razón misma de ser de nuestra institución en cada
región del país. Para ello, realizan las siguientes tareas básicas:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Determinar la disponibilidad del agua
Orientar los nuevos polos de desarrollo.
Lograr el uso sustentable del agua.
Asegurar la preservación de los acuíferos.
Garantizar la calidad del agua superficial.
Llevar a cabo la recaudación en materia de aguas nacionales y sus
bienes.
Solucionar conflictos relacionados con el agua.
Otorgar concesiones, asignaciones y permisos.
Promover la cultura del buen uso y preservación del agua.
Prevenir los riesgos y atender los daños por inundaciones.
Prevenir los riesgos y atender los efectos por condiciones severas de
escasez de agua.
Operar la infraestructura estratégica.
Además, los Organismos de Cuenca son el vínculo con los Gobernadores de las
entidades donde se ubican.
Por lo que se refiere a las Direcciones Locales, éstas tienen la importante labor de
aplicar las políticas, estrategias, programas y acciones de la Comisión en las
entidades federativas que les corresponden
4.1 MISIÓN DE LA EMPRESA
"Administrar y preservar las aguas nacionales y sus bienes inherentes, para lograr
su uso sustentable, con la corresponsabilidad de los tres órdenes de gobierno y la
sociedad en general".
4.2 VISIÓN DE LA EMPRESA
"Ser autoridad con calidad técnica y promotor de la participación de la sociedad y
de los órdenes de gobierno en la gestión integrada del recurso hídrico y sus
bienes públicos inherentes".
VISIÓN DEL SECTOR HIDRÁULICO
"Una nación que cuente con agua en cantidad y calidad suficiente, reconozca su
valor estratégico, la utilice de manera eficiente, y proteja los cuerpos de agua, para
garantizar un desarrollo sustentable y preservar el medio ambiente".
68
4.3 ESTADO ACTUAL DEL SISTEMA DE SEGURIDAD DE PRESAS
4.3.1 Antecedentes
La Gerencia del Consultivo Técnico de la Comisión Nacional del Agua, cuenta con
una herramienta la cual les permite informar y actualizar cada uno de los registros
de la información que se deriva de las inspecciones que se realizan
periódicamente a cada una de las presas del país.
La gerencia realiza un proceso exhaustivo para recopilar, verificar y autorizar la
información de cada una de las obras de captación y control de agua del país.
Es un factor importante tener información consistente y actualizada para cada una
de las instalaciones hidráulicas, de tal manera que se puedan generar informes
con características generales de cada una de las presas en México.
4.3.2 Descripción del Servicio
El Sistema de Seguridad de Presas considera un tablero de visualización con
Georeferenciación, digitalización de doctos e imágenes o fotografías y
conectividad al sistema de administración de seguridad de presas para la
explotación de información en diferentes bases cartográficas.
4.4 PROBLEMÁTICA RESUELTA POR EL SISTEMA
La Gerencia del Consultivo Técnico de la CNA, cuenta con un desarrollo previo de
un Sistema de Seguridad de Presas, en cual, para las necesidades actuales
resulta insuficiente y obsoleto para ser consultado de manera amplia por todas las
personas relacionadas en la CONAGUA con esa información, así como para
actualizar los registros periódicamente a esas importantes instalaciones
hidráulicas del país.
No se contaba con un sistema integral de administración de información,
digitalización y georeferenciación para la actualización ubicación validación e
informe de las características de cada una de las instalaciones hidráulicas en el
país.
Esta ocasiona que los datos generados puedan tener un alto margen de error y
que el proceso de captura, validación y publicación sea complejo y lento con
información muy inconsistente de las características de las presas en México.
69
Así mismo la herramienta anterior no contaba con la explotación de información en
un sistema de georeferenciación, la cual nos permita ubicar a través de cartografía
cada una de las presas en México.
4.5 OBJETIVO DEL SISTEMA
La Gerencia del Consultivo Técnico de la CNA, contará con un sistema integral de
administración de seguridad de presas para dar seguimientos online, además de
poder georeferenciar a través de un tablero de control toda la información que se
levanta en cada una de las obras de captación del México.
4.6 ALCANCE DEL SISTEMA
El Sistema de Seguridad de Presas, es un sistema de recopilación, carga,
presentación y administración de los datos y generación de documentos índice
para su consulta a través de la página web Intranet, de modo que facilita el
análisis de los datos para que el personal encargado de la seguridad de presas
tenga disponible de manera más ágil la información para la toma de decisiones.
El Sistema de Seguridad de Presas se desarrolla en ambiente web-enable, que se
pueda acceder a nivel Nacional a través de la Red de la CONAGUA en donde se
puedan tener los datos técnicos y características técnicas, así como de los
informes relacionados con las inspecciones periódicas, fotos y documentos
generados. Permitirá la realización de consultas estadísticas de las obras y la
emisión de reportes de informes.
A través de Intranet se tiene acceso a gráficas, fotos, diferentes tipos de archivos
e información general y que permite, en base a perfiles definidos, acceso para
actualización de información y datos técnicos más detallados. Incluye presentación
de datos sobre algunos mapas.
El Sistema permite cargar información desde Organismos de Cuenca y
Direcciones Locales de la CONAGUA a Oficinas Centrales para su análisis y si
fuese el caso lleva a cabo la actualización y validación de manera controlada y
clasificada.
El tablero de control permite interactuar con cualquier sistema cartográfico tanto
gratuito como licenciado, de tal manera que tiene la flexibilidad de poder operar
con cualquier base de datos cartográfica.
El sistema permite:
 Simplificar el levantamiento de información
 Mejorar la calidad de información
70
 Disminuir tiempo de procesos y de operación
 Minimizar el tiempo de validación
 Información en línea
4.7 BENEFICIOS
Contar con un Sistema de Seguridad de Presas permite la administración y control
de los registros de inspecciones y desahogos de los mismos.
Una sola Base de Datos de Información centralizada para todos los Organismos
de Cuenca, Direcciones Locales y Oficinas Centrales para un control efectivo de la
información.
Diversos avisos vía correo electrónico (recordatorio de nuevas modificaciones, o
captura de presas, etc.)
Impresión de Reportes Generales y de Estadísticas específicas
Consultas dinámicas que permite identificar las situaciones actuales de las
diferentes Presas
Acceso al Sistema desde cualquier punto de la INTRANET
Disminuir el tiempo para la búsqueda de información
Visibilidad de la información acorde a los perfiles de usuarios establecidos
Soporta cualquier formato de documento electrónico, al adjuntar archivos a un
informe de presa. Cabe señalar, que el archivo adjunto sólo podrá ser visualizado
si se cuenta con la herramienta origen con la que fue creado. Por ejemplo, si
adjunto un archivo con extensión “.doc” se requiere contar con la herramienta de
MS Word.
Cuenta con un tablero de visualización con capacidad de georeferenciación.
4.8 CARACTERÍSTICAS PRINCIPALES
Para administrar la información de cada una de las presas en México, contiene la
siguiente estructura (Anexo 1):
1) El Acceso al sistema es a través del Directorio Activo de red CONAGUA,
para tomar las credenciales y perfil del usuario (Figura 4.1)
71
2) Pantallas de búsqueda de cualquier información que se capture en el
sistema en forma ordenada y clasificada, así como filtros para facilitar la
búsqueda. (Figura 4.2)
Se toman en cuenta, entre otros, los siguientes campos: Nombre Oficial,
Nombre Común, Organismo de Cuenca, Región Hidrológica, Cuenca,
Estado, Municipio, Coordenadas Geográficas (Latitud y Longitud),
Corriente, Capacidades de Almacenamiento, Altura de Cortina, Tipo de
Cortina, Tipo de material, Intervalo de fechas de inspección.
El resultado de la búsqueda puede ser utilizado para realizar las diferentes
acciones identificadas por el usuario, así como poder exportarlo para su uso
en herramientas como procesadores de textos u hojas de cálculo. Las
búsquedas también pueden realizarse desde el módulo de
georeferenciación.
3) Funcionalidad de ADJUNTAR a cada registro, diferentes tipos de archivos
digitales para el informe de cada presa. Los tipos de archivos serán: fotos
estandarizadas formato ".jpg" archivos desde 0 hasta 500 Kb, fotos o
imágenes a detalle con un tamaño de 150 hasta 5000 Kb (5Mg) pdf, txt, rtf,
jpg, gif, jpeg, tiff, tif, emf, wmf y video. Todos los de office, excepto Power
Point.(Figura 4.3)
4) Estadísticas y gráficas, esta funcionalidad considera los esquemas de
seguridad establecidos para cada usuario únicamente teniendo acceso a la
información según su perfil. (Ver módulo de perfiles)
5) Acceso vía navegador Internet (compatible con Internet Explorer 6.0 y
posteriores), permitiendo acceso a través de Intranet.
6) Monitoreo de alertas para indicar la modificación de cada presa solo al
usuario Administrador, quien controla cualquier modificación.
7) Perfil de usuarios:
 Usuario de Consulta: Solo consultará cierta información, misma que
será definida por el Administrador del Sistema.
 Usuario de Captura: Captura de información de la presa, registro de
inspecciones, modificación de informes, generación de reportes
sobre inspecciones.
 Usuario de Supervisor.- Generación de Reportes, Estadísticas y
visualizar el detalle de información de cada presa.
72
 Usuario de Administrador.- Acceso a Catálogos que se definan,
listado de catálogos, altas, bajas y cambios en catálogos, generación
de reportes, altas, bajas, cambios, asignación de permisos y roles,
Actualización de datos generados por cada inspección realizada.
8) Además contempla la migración de la información del Sistema de Presas a
SQL Server 2005 ya que se tenía anteriormente en Access 2003, con la
supervisión del Administrador del Sistema.
9) Dentro de la migración se toma en cuenta la asociación o vinculación de los
archivos con los que se contaban anteriormente, estos pueden ser
documentos de tipo texto, imágenes y video, el sistema contempla la
clasificación de estos además permite la visualización de los mismos.
10)El sistema contempla los históricos de registros y archivos vinculados, así
como la comparación de información en diferentes tiempos.(Figura 4.4 y
Figura 4.5)
11)Contiene procedimientos simplificados para los usuarios con perfiles
definidos e integra información al Sistema de Seguridad de Presas,
12)Información que se va generando a través de las inspecciones realizadas a
las presas. Dichas inspecciones se realizan de forma periódica.
En el sistema se tomó en cuenta la siguiente información:
4.9 BASE DE DATOS:
La base de datos contiene un número aproximado de 5000 registros, no es una
base de datos normalizada, se tienen algunos catálogos, por lo que la
información no es consistente.
Se cuenta con 63 tablas
4.9.1 VINCULACIÓN Y CLASIFICACIÓN DE ARCHIVOS.
Se cuenta con diferentes tipos de documentación digitalizada, misma que se
vincula de manera clasificada para un mejor manejo de información. (El uso de
esta información se determina de acuerdo a los perfiles del usuario)
Gráficos (jpg, jpeg, tif, ewf, mwf)
Documentos (pdf, doc, rtf, xls, docx, xlsx, txt)
Video (avi, wmv)
73
4.9.2 REPORTES
Grandes Presas
Datos Generales de Presa
De impresión de Presas
Reportes Estadísticos (3)
Reportador dinámico
4.9.3 FORMATOS
Para Registro de Presas
De inspección de Presas
4.9.4 SEGURIDAD
Acceso al sistema (Directorio activo)
Perfiles
Administrador
Administrador Local
Captura (Inspecciones)
Consulta de datos generales (Usuario CNA)
4.9.5 MÓDULOS
Consulta
Georeferenciación
Inspección
Reportes
4.9.6 SERVICIOS
Manuales
Tablero de Visualización, Georeferenciación y Estadísticas
El sistema contempla las siguientes características:
 Visualizador “Stand-Alone” adaptado a la funcionalidad definida en el
análisis de requerimientos gráficos del visualizador para mostrar imágenes
3D
 Visualizador web adaptado a la funcionalidad definida en el análisis de
requerimientos para mostrar imágenes satelitales o aéreas 2D
 Herramientas de comparación entre diferentes visualizadores cartográficos,
(eliminación, codificación, búsqueda y consulta de información)
 Herramientas de reporteo en pantalla o archivo (formato PDF, Excel, etc.).
 Movilidad del plano cartográfico en 2D y 3D en pantalla.
 Selección de puntos de interés, referencias geográficas, rutas especiales.
74
 Activación de opciones de video, imágenes específicas o de movimiento
virtual
 Herramientas de consulta de datos para cruce de información estadística
 Generación de llamadas de datos hacia mapas, polígonos, figuras 3D.
 Generación de llamadas de información o mapas para relacionar con datos.
 Manejo de cualquier base de datos cartográfica gratuita o licenciada
 Georeferencia (Ubicación de información, imágenes o simbología en
cartografía)
 Controles de búsqueda de información
 Controles Estadísticos y Diagramas Gráficos.
 El sistema deberá tener la capacidad de conectarse con diferentes bases
de datos cartográficas sean gratuita o licenciadas y la información asociada
con los diferentes visualizadores.
4.10 CONSIDERACIONES GENERALES
Capacidad de consulta, visualización o procesamiento de la información contenida
en una o más bases de datos con el objeto de aprovechar los datos actualmente
disponibles.
Estructura un tablero que permite la visualización geográfica de elementos
asociando información estadística contenida en la base de datos.
Estructura herramientas de consulta que permite comparar información estadística
entre dos o más elementos identificados geográficamente (comparar tamaño,
longitud, capacidad, etc.)
Genera una herramienta que permite realizar altas bajas y cambios de las tablas,
campos e información asociada a la base de datos.
Genera una herramienta que permite administrar información de la base de datos
para altas, bajas y cambios de documentos digitalizados, fotografías o formatos
asociados con uno o varios registros.
Genera un módulo de administración de usuarios que permite limitar la
visualización, consulta y/o modificación de registros de la base de datos.
Genera un módulo de administración que permita validar firmas, autorizaciones y
aprobaciones de actualización de la base de datos según el tipo de usuario
cualquier modificación a los registros o elementos asociados al sistema.
Genera un módulo de elaboración de documentos que puede ser transformado de
manera automática en un documento digital “imprimible” pero que la información
75
contenida actualice a su vez la base de datos con el objeto de duplicar la
alimentación de información.
El desarrollo considera las licencias necesarias para su desarrollo y
mantenimiento y de ser posible evita el pago recurrente de las mismas por parte
de CONAGUA.
El desarrollo considera la posibilidad de obtener información estadística de una o
varias bases de datos ya sea de orden público o privado según el usuario y
considerar que CONAGUA pueda modificar en un futuro el tipo de base de datos
utilizada.
La solución de visualización considera la posible alternancia de la base
cartográfica ya sea a través de gráficos de dominio público (sin costo) o privada
(Contratada o disponible por el usuario) ofreciendo la factibilidad de seleccionar la
base cartográfica a nivel de “botón” por el usuario.
La solución de visualización puede identificar mediante el uso de herramientas de
acceso a la base de datos identificar por “capas” diferentes elementos o
características en la cartográfica, por ejemplo, diferenciando sistemas
hidrológicos, áreas de alto riesgo o inundación, o agregar en un futuro nuevos
elementos hidrológicos de la base de datos. Considera un total de 20 capas.
La solución de visualización considera herramientas de medición lineal, poligonal o
de superficies considerando algoritmos que calculen las variaciones del contorno
geográfico o curvas de la superficie que son sujetas de medición.
La solución de visualización considera que el usuario puede consultar a través de
una página web, red interna o a través de una desktop la información desplegada
en pantalla. De ser posible el visualizador puede mostrar las variaciones de
altimetría presentes en la superficie geográfica y visualización de un terreno
seleccionado en 3D.
Este desarrollo considera la convertibilidad de cualquier información cartográfica
disponible en CONAGUA hacia otro sistema cartográfico o la posibilidad de
obtener bases de cartografía para complementar dicha información.
El sistema permite la captura de información a través de catálogos (en su caso)
que a su vez carga la información existente contenida en la base de datos.
El sistema permite interactuar con Google Earth versión gratuita de manera
directa, de tal forma que al consultar la información del sistema integral de
administración de seguridad de presas, se visualiza cualquier presa y su
información relevante. Debe estar vinculado el sistema con el tablero de
visualización.
76
Las pantallas de búsqueda consideran entre sus datos llave el campo de ID de la
presa, además de los ya solicitados en el presente documento.
El prestador de servicios realiza el diseño de la base de datos juntamente con la
Gerencia del Consultivo Técnico de la CONAGUA y la Gerencia de Informática y
Telecomunicaciones.
La Comisión Nacional del Agua a través de la Gerencia del Consultivo Técnico
entrega al prestador de servicios el Diccionario de Datos correspondiente del
sistema actual con los catálogos, diccionario que el prestador de servicios deberá
de completar a partir de los requerimientos solicitados por la CONAGUA para el
sistema a ser desarrollado.
4.11 CARACTERÍSTICAS TÉCNICAS
Manejador de base de satos SQL Server 2005 o superior, tecnología .net,
Plataforma Windows Server 2003.
El sistema está desarrollado en VB. NET 2005 a 32 bits con el Framework 2.0 o
superior y debe utilizar IIS 6.0 o superior como servidor Web.
Deberá ser instalado en el sistema operativo Windows Advanced Server 2003.
El sistema debe ser desarrollado en tecnología Web con una Base de Datos
centralizada, no se aceptara ningún modulo Cliente-Servidor.
Las licencias de SQL Server 2005 y Windows Server 2003 para el servidor en
producción serán provistos por la CONAGUA, cualquier licencia diferente a las
anteriores será responsabilidad del prestador de servicios y deberá proporcionar a
la CONAGUA una licencia corporativa de uso sin costo adicional.
4.12 AUDITORÍA EN LA BASE DE DATOS DEL SISTEMA DE
SEGURIDAD DE PRESAS
4.12.1 Aspectos generales de su elaboración
4.12.2 Objetivo
Auditar la Base de Datos de la aplicación de “Sistema de Seguridad de Presas”
bajo la metodología de COBIT
77
4.12.3 Objetivos específicos




Comprobar que se cumplan los controles de acceso a la base de datos.
Realizar la auditoria de acuerdo a las buenas prácticas.
Aplicar herramientas de seguridad que nos ayuden a evaluar el sistema.
Verificar la seguridad entorno de la Base de Datos.
4.13 PROBLEMÁTICA
Dentro de la política de la empresa, señala que se debió realizar después de la
implementación, algún proceso de auditoria a la aplicacion y dicho proceso no se
ha llevado a cabo para verificar si el sistema que se esta poniendo en marcha
cumple con los requerimientos de las mejores prácticas.
4.14 ALCANCE
Con la presente auditoria se pretende llevar a cabo un análisis de riesgos para el
“Sistema de Seguridad de Presas” de la CONAGUA que permita revisar la
aplicación apegándonos a la metodología de COBIT y la relación con la política de
la empresa.
Se auditarán los controles de la Base de datos de la aplicación “Sistema de
Seguridad de Presas”, se realizara un análisis de riesgos conforme a las buenas
practicas de la metodología COBIT, llevandose a cabo la revisión de los siguientes
Procesos(anexo):






PO9 - Evaluar y administrar los riesgos de TI.
AI2 - Adquirir y dar mantenimiento a software aplicativo.
DS5 - Garantizar la seguridad de los sistemas.
DS8 - Administración Mesa de servicio e incidentes.
DS11 - Administrar datos.
DS13 - Administrar operaciones.
Con el fin de facilitar a quienes lo precisen, respuestas a consultas de la
información almacenada en el “Sistema de Seguridad de Presas”. A su vez
generar un informe que facilite el análisis de datos para que el personal encargado
de la seguridad de presas tenga disponibilidad confiabilidad e integridad de a
información para una mejor toma de decisiones.
4.15 JUSTIFICACIÓN
Debido a que el “sistema de seguridad de presas” se implementó por primera vez
el 1º de marzo de 2010 en la CONAGUA, es necesario llevar a cabo el proceso de
78
auditoria para minimizar los riesgos de que la aplicación no funcione
adecuadamente y determinar si cumple con las buenas prácticas.
Al realizar dicha auditoria tendremos como resultado, disminuir las incidencias que
surgieran en la aplicación, de esta forma, ayudar a que la aplicación opere de
forma eficiente, tomando como referencia COBIT para elaboración del checklist.
4.16 PLANEACIÓN
Durante la planeación de la auditoria a la base de datos del sistema de seguridad
de presas 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 la 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 aéreas o procedimientos que no estuvieran justificados y además que
causaran el retraso de algunas actividades, en base a esto se desarrollo una lista
de puntos específicos donde se quedaran por escrito cada una de las tareas a
realizar, considerando como primer paso la solicitud de la Estructura
Organizacional (Anexo 2) Con lo anterior se desarrollo un cronograma de
actividades, elaborado en Microsoft Project 2003, en el cual se detalla el inicio,
ejecución y fin de cada actividad.
Una vez terminado el cronograma se asigno las tareas y días correspondientes a
cada integrante del equipo registrándose en el mismo. Así se aseguro que cada
día se realizara una tarea diferente y no hubiera complicaciones, malentendidos o
traslapes en actividades.
Una vez realizado lo anterior el equipo se dispone a hacer las entrevistas con el
personal del área encargada, se le entrega un oficio indicando lo anteriormente
señalado y la carta de aceptación para la realización de la auditoria, esto es para
darle formalidad, cumplimiento a lo establecido y no haya malentendidos con la
empresa.
Para esto se realizo un diagrama a bloques ordenando los siguientes puntos
(Anexo 3) y que más adelante se detallan:




Entrevista
Checklist
Oficio de Requerimientos
Hallazgos
79
 Pruebas
 Análisis de Riesgos
4.17 CRONOGRAMA DE ACTIVIDADES
Durante la planeación de la auditoria se desarrollo, un cronograma de actividades
en el cual se observan los tiempos de inicio, ejecución, 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 realizó la actividad y una gráfica de
Gantt que describe todo el proceso (Anexo 4).
El cronograma se dividió en 5 actividades principales: Estudio general de la
empresa, donde se recopila información que nos ayude a comprender mejor el
funcionamiento y procesos de la empresa. Planeación y programa de trabajo, se
llevan a cabo las actividades correspondientes a las entrevistas, permisos,
reuniones y aceptación. Realización de la auditoria, están todas las actividades
relacionadas con la ejecución de la auditoria a la base de datos. Evaluación de la
auditoria, se describen los hallazgos encontrados las vulnerabilidades y se realiza
el análisis de riesgos.
Por último la Presentación del informe ejecutivo, donde se describen los impactos
y las recomendaciones para minimizar los riesgos encontrados.
4.18 PRESENTACIÓN DE ACTIVIDADES Y OBJETIVOS.
Una vez realizadas las entrevistas y previa aceptación de la auditoria, se llevo a
cabo la entrega del Oficio del Plan de auditoría (Anexo 5), el cual contendrá en un
aspecto más detallado las actividades a realizar.
Especificando los siguientes puntos:
Persona a quien va dirigida el oficio, numero y fecha de la auditoria que será
realizada, objetivo y alcance de la auditoria, personas que participaran en la
auditoria, dirección y área dentro de la empresa donde se llevara a cabo la
auditoria y por último se anexa el plan de auditoría que comprende las actividades,
documentación requerida, la asignación de actividades, tiempo y ejecución de las
mismas.
CARTA DE ACEPTACIÓN:
Carta en la cual se da la autorización para realizar la auditoria. Indicando, fecha de
elaboración, nombre de la persona que va a dar la autorización y su cargo,
redacción formal pidiendo la aceptación del proyecto y por ultimo nombre y firma
80
de la persona que solicita la aceptación (Anexo 6 con relación del equipo
responsable de la auditoría).
4.19 EJECUCIÓN DE LA AUDITORÍA.
Dentro de la ejecución de la auditoria a la base de datos se contemplaron diversos
puntos realizados sucesivamente, de a cuerdo a el cronograma de actividades, ya
que todas dependían de los resultados de la o las actividades anteriores.
La ejecución requirió seis etapas:
1.
2.
3.
4.
5.
6.
Entrevistas,
Checklist,
Carta de requerimientos,
Hallazgos,
Pruebas y
Análisis de riesgos.
Esto fue para una mayor comprensión y un mejor resultado en el informe final, ya
que se describe a manera de detalle cada aspecto de lo que se realizo siguiendo
el cronograma de actividades.
4.19.1 Aspectos generales de su elaboración
Para esta etapa de la auditoria se ocuparon diversos formatos para darle una
mejor presentación, comprensión y profesionalismo, en cada uno de ellos se
describe detalladamente lo que se realizo dentro de la auditoria y el significado del
por qué se opto por seguir ese camino.
Como se menciona anteriormente, la ejecución de la auditoria a la base de datos
del sistema seguridad de presas de la CONAGUA consta de seis actividades
principales, las cuales nos proporcionaron la información necesaria para llevar a
cabo dicha auditoria, que se describen a continuación de forma cronológica:
1. Entrevistas.- en esta parte se tienen entrevistas formales con la gente
encargada 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 tener los
permisos necesarios para tener acceso a la base de datos, realizar las
pruebas pertinentes en el sistema y documentación requerida para
realizarla.
2. Checklist. Este actividad, es una de las más importantes para llevar a cabo
la auditoria, ya que aplicándolo nos mostrara una visión más detallada de
81
cómo se encuentra el activo que se auditará. Esto se explicara más
adelante.
3. Oficio de requerimientos. Este documento fue realizado una vez terminado
el checklist y el cronograma de actividades para poder nosotros, como
responsables de la auditoria 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 las mejores prácticas para el buen
funcionamiento del sistema. Este se compone por un titulo, fecha de
realización, persona y cargo a quien va dirigido y nos va a proporcionar
dicha información, una breve introducción seguida de la documentación
requerida y por ultimo nombre y firma del quien solicita la información
(Anexo 7).
4. Pruebas. Esta actividad puede o no puede realizarse, según se considere
necesario y el activo que se auditara, sin embargo, si se quiere realizar una
auditoría más profunda donde ningún punto quede sin verificar, las pruebas
son necesarias ya que nos indican si lo que se encontró en el checklist
realmente se está cumpliendo, en esta actividad solo realizamos dos
pruebas (query) para comprobar los tipos de cuenta de la base de datos,
roles y permisos de los usuarios que accedían a ella (Anexo 8)
5. Hallazgos. Esta es la última parte de nuestra actividad principal, que es la
ejecución. Los hallazgos son resultado de haber realizado correctamente un
buen checklist, tener la información correcta, haber hecho las pruebas
pertinentes y por último y lo más importante haber realizado un análisis de
riesgos que nos permitiera identificar claramente lo que debemos atacar o
corregir, con esto se logra que se encuentren a tiempo las vulnerabilidades,
amenazas y riegos, que se expongan y que se de la solución apropiada y la
más acertada. (Anexo 9). Este punto es explicado con más detalle en el
punto 4.22.
6. Análisis de riesgos. Es otra de las fases más importantes de la auditoria, es
la base de nuestros hallazgos y recomendaciones, sin este paso no
tendríamos nada que evaluar y no se detectarían los problemas. Se
explicara más adelante
En esta actividad se recopilo información del análisis de riesgos y en conjunto con
las pruebas se demostró que cumplía con algunos aspectos de seguridad pero sin
llegar a las mejores prácticas de COBIT, se encontraron 11 riesgos de los cuales
ocho eran sumamente importante el atenderlos o, por lo menos, darle una
prioridad alta para que en un plazo menor a 3 meses fueran resueltos.
82
4.20 HALLAZGOS
Esta actividad tiene como objetivo principal el dar a conocer los errores,
vulnerabilidades, riesgos y cualquier otra anomalía que haya sido detectada en el
análisis de riesgos, con esto se asegura que se tengan bien presentes todos los
puntos que tuvieran un gran impacto o que interfirieran con las actividades diarias
del sistema.
Nuestro análisis de riesgos detecto 11 riesgos, por lo tanto y por lógica los riesgos
se transforman en 11 hallazgos los cuales se plasman en un formato indicando el
riesgo y que objetivo de control no se está cumpliendo, cada hallazgo pasa por un
proceso de reconocimiento y análisis, se identifican las causas, que son las
amenazas de cada riesgo, también se identifica el impacto, que es el riesgo
ocasionado por el hallazgo y por último la recomendación, que es una posible
solución al problema, este último se llena al final de la auditoria en la actividad de
recomendaciones.
En nuestra auditoria encontramos los siguientes hallazgos:
1. Se identificó que debido a que el sistema es reciente no se han llevado a
cabo análisis de riesgos y pueden existir posibles fallos, detección de
amenazas y vulnerabilidades no contempladas en su BD, perjudicando la
integridad, confiabilidad e integridad del sistema (P09.4)
2. Se detectó que no cuentan con un plan de contingencia. (DS5.2)
3. No se notifica al personal de modificaciones en el sistema. (DS5.2)
4. No se respaldan archivos logs en la Base de datos. (DS5.2 )
5. Los passwords de usuarios no son seguros debido a que se asignan igual
que el nombre del usuario. (DS5.3)
6. Asimismo se observó que no contemplan un almacenamiento del registro
de accesos no se ha hecho una revisión de los usuarios y privilegios
definidos en las aplicaciones, a fin de asegurar que únicamente existan los
autorizados con los privilegios apropiados. (DS5.3)
7. Identificamos cuentas activas que ya no laboran en CONAGUA. Existen 2
cuentas en esta situación. (DS5.4)
8. No se notifican incidencias de seguridad. (DS5.6)
9. Las contraseñas de los usuarios no están fuertemente cifradas. (DS5.8)
10. El software de la base de datos no es actualizado. (DS5.9)
11. No se cuenta con un protocolo específico para el envío de la información.
(DS5.11)
83
4.21 ANÁLISIS DE RIESGOS (CHECKLIST)
Como ya se mencionó anteriormente, el checklist es una de las actividades más
importantes de la auditoria, ya que de este depende que se realice de forma
correcta el análisis de riesgos.
El checklist elaborado por el equipo auditor partía de manera muy precisa de los
puntos señalados en el alcance, logrando que se siguiera por el camino de las
buenas prácticas de COBIT, a manera de lista se fueron revisando los cuatro
dominios y de ahí solos se tomaron los procesos con sus respectivos objetivos de
control que cubrieran los aspectos que pretendíamos evaluar y que a nuestra
consideración, podrían darnos información relevante y nos permitirían tener una
visión del sistema y sus problemas con mayor detalle.
Nuestro checklist lo creamos en Microsoft Excel, en donde realizamos 7 columnas
en el siguiente orden:
1. Dominio de COBIT,
2. Proceso del dominio,
3. Checklist (realizado con objetivos de control de cada proceso de COBIT);
Las siguientes 3 columnas de:
1. SI
2. NO
3. NO APLICA (en caso de que no estuviera dentro de contexto la pregunta)
En donde se responderían cada una de las preguntas según fuera el caso y por
ultimo una columna de observaciones (Anexo 10).
Con un total de 55 preguntas, el equipo auditor entrevisto al encargado del
sistema aplicando el checklist, quedando graficado y detallado de la siguiente
manera (Anexo 11 Figura 4.7)
84
Total de preguntas
Resp Afirmativas
Resp. Negativas
No aplican
55
39
11
5
Porcentaje afirmativo
55
39
70.91%
100%
70.91
Porcentaje Negativo
55
11
20%
100%
20
Porcentaje no aplican
55
5
9.09%
100%
9.09
TOTAL
100.00%
Tabla 4.1 Porcentajes Checklist
A pesar de que nuestro resultado fue positivo ya que la mayoría de las preguntas
son afirmativas, las resultantes negativas tenían un gran impacto en el sistema
generando un riesgo muy grande dentro del sistema.
Para mayor comodidad, dentro del mismo checklist se hicieron nuevas columnas
en donde se planteo y resolvió el Análisis de Riesgos. Dentro de esta actividad,
nos concentramos en ver qué puntos del checklist eran buenos, cuáles eran
regulares y cuales tenían un impacto negativo al sistema. En base a esto se
fueron distinguiendo con una escala de colores de acuerdo a su nivel de riesgo.
Se realizaron las observaciones correspondientes a los 11 riesgos encontrados
describiendo la causa del riesgo y su impacto dentro del sistema en caso de que
no fuera atendido
.
Dentro del análisis de riesgos también se hicieron observaciones para dar posibles
soluciones a los riesgos encontrados, pero todo esto se detalla mejor en el cierre
de la auditoria presentando las recomendaciones.
4.22 MAPA DE RIESGOS
Una vez realizado nuestro análisis de riesgos, y haber encontrado los puntos
defectuosos en la actividad hallazgos, se realizó el mapa de riesgos para tener
85
una idea mejor de las condiciones del sistema, en donde nos muestra a los
hallazgos encontrados clasificados según su impacto y ocurrencia.
Se hizo un esquema que se divide en cuatro cuadrantes y en donde se
representan los riesgos encontrados esquematizados con círculos numerados de
acuerdo a la consideración del equipo auditor, para darnos una idea de lo que
significaba cada circulo. Se agregó un cuadro con las leyendas de la numeración
de cada circulo (Anexo 12 Figura 4.9). Así sabríamos que riesgo estaba en el
cuadrante y que tanto podría afectar al sistema.
4.23 CIERRE DE LA AUDITORÍA
En la última parte de la auditoria, se empezarán a plasmar todos los resultados
obtenidos tanto del análisis de riesgos como de la actividad “hallazgos”, logrando
que la auditoria sea comprendida, que el alcance fuera el correcto y que la
justificación fuera completa.
Dentro de nuestro cierre de auditoría para mayor comprensión se dividió en cuatro
actividades: Modelo de Madurez, son los resultados de la ponderación realizada
por el equipo auditor según dicho modelo; Mapa de Riesgos, se encuentran
establecidos los hallazgos encontrados dentro de un cuadrante que refleja el
impacto y ocurrencia de cada riesgo; Recomendaciones, en esta actividad se
presentan cada uno de los hallazgos encontrados con su causa e impacto y se le
sugiere una recomendación o una posible solución para mitigar el riesgo. Cada
una de las actividades mencionadas se detallara mejor más adelante.
4.24 MODELO DE MADUREZ
Como ya se ha explicado con anterioridad, el Modelo de Madurez de COBIT es un
conjunto de métricas que determinan que tan estructurado tiene una empresa sus
procesos y políticas dentro del ámbito de TI.
Nuestro modelo de madurez se baso en los objetivos de control DS5, DS8 y DS13
ya que son los procesos que mas giran en torno a nuestra auditoria.
Para esta actividad se diseño un formato especial en donde se puede evaluar
cada objetivo de control, dándole una ponderación según lo establecido en dicho
modelo.
El formato está compuesto por 2 partes: la primera se encuentra el nombre del
dominio donde pertenece el proceso, el proceso que se va a evaluar y por ultimo
su objetivo del proceso; la segunda consta de una tabla de tres columnas en las
cuales se describe el objetivo de control a evaluar, seguido por la columna de
86
pruebas que no es más que la actividad que se realizo para evaluar ese objetivo y
por último la ponderación según el Modelo de Madurez (Anexo 13)
En base a lo anterior se elaboro una grafica (Anexo 14 Figura 4.8) en donde se
representan todos los objetivos de control evaluados, logrando así graficar el nivel
de Madurez del sistema, para mejor comprensión se integro la leyenda de cómo
se establecen los parámetros del modelo.
4.25 RECOMENDACIONES
Para las recomendaciones, como ya se dijo anteriormente, se llenó el mismo
formato en el cual están juntos hallazgos, causa, impacto y por supuesto la
recomendación. (Anexo 15)
Para nuestra auditoria se hicieron 11 recomendaciones para cubrir cada uno de
los riesgos encontrados, dándoles una posible solución, las que el equipo auditor
fueron:
1. Después de la auditoria en curso, recomendamos realizar diversas
valoraciones periódicamente (cada 6 meses), tomando en cuenta la
importancia y riesgos del mal funcionamiento del Sistema de Seguridad de
Presas. (P09.4 )
2. Reunirse con el personal de la Gerencia de Informática y
Telecomunicaciones para concretar e implementar un plan de contingencia
que asegure la continuidad en las operaciones así como los procedimientos
a realizar en un posible desastre o sabotaje. (DS5.2)
3. Nombrar a una persona encargada de boletinar los acontecimientos,
cambios y nuevos procedimientos para asegurar el cumplimiento de los
cambios realizados a las políticas o en su defecto ligar con el Sistema de
Control de Gestión para monitorear los acuses de recibo. (DS5.2)
4. Almacenar y realizar copias de seguridad utilizar el programa mysqldump o
el script mysqlhotcopy script. (DS5.2 )
5. Se debe de tener una restricción en la consulta del campo Password
Al realizar el query
SELECT * FROM USUARIOS, no arrojar
USUARIOS_PASSWORD
y si es necesaria dicha consulta solicitar
contraseña de administrador.
Establecer políticas de seguridad en los password (no aceptar password
con relación al nombre, puesto, función o área del usuario. (DS5.3)
87
6. Definir los privilegios requeridos y autorizados a asignar a los usuarios
(lectura, modificación, etc.) de acuerdo a su puesto y funciones y
principalmente almacenarlos y modificarlos por un periodo definido, a fin de
asegurar que se encuentran activos y con los privilegios que les
corresponden únicamente usuarios autorizados. (DS5.3)
7. Realizar un procedimiento o minuta para que todo movimiento de personal
involucrado en el acceso al sistema sea notificado y/o bloqueado por los
administradores del sistema. (DS5.4)
8. Crear y difundir el procedimiento en donde se haga conciencia a los
empleados al presentarse un problema en el sistema.
Proponer un protocolo de fallo que asegure la información dentro del
desastre y un procedimiento para reportar y reparar el mismo. (DS5.6)
9. Contar con un sistema y una metodología de cifrado de contraseñas, así
como la buena propaganda de la cultura de los passwords seguros. (DS5.8)
10. Realizar Oficio de consideración y autorización en el Programa Anual 2011
para la compra de software adicional y actualizaciones. (DS5.9)
11. Implementar un Protocolo seguro para la transmisión de datos como son los
SSH, SSL, TSL y HTTPS que son protocolos usados en la actualidad.
(DS5.11)
88
CONCLUSIONES
Durante el desarrollo de la auditoría concluimos que existe conciencia sobre la
seguridad y ésta es promovida por la Gerencia aunque esté un poco fraccionada y
limitada en cuanto al control de accesos.
 Algunas políticas de seguridad están alineadas con la política de seguridad
de TI
 Las responsabilidades de la seguridad de TI están asignadas y entendidas,
pero no continuamente implementadas.
 Existe capacitación en seguridad para TI pero se programa y se comunica
de manera informal.
 La seguridad de TI es vista primordialmente con responsabilidad y disciplina
pero la institución no lo ve como parte importante de sus propios objetivos.
Podemos concluir que el proceso está definido y el contacto con métodos para
promover la conciencia de la seguridad es obligatorio por lo tanto la información
debe ser correctamente gestionada, controlada y asegurada por medio de
controles que prevengan la ocurrencia de situaciones de riesgo para la
organización y que a su vez asegure su integridad, disponibilidad y
confidencialidad tanto de los datos como de los procesos, asimismo, se tendrá que
tomar en cuenta las medidas correctivas antes observadas para que la
responsabilidad sea conjunta de la institución y sus objetivos optimizados con las
mejores prácticas.
Esta propuesta aportará considerables beneficios a la Gerencia de Informática y
Telecomunicaciones, para que tengan en cuenta una base de conocimiento que
pueda retroalimentar el buen funcionamiento de la base de datos en el sistema de
“Seguridad de Presas”, contando así con flexibilidad en sus procedimientos,
estandarización y control de datos, adaptabilidad a los diferentes procesos, mayor
comunicación, y garantía en cuanto a la seguridad en su información.
89
ANEXOS
ANEXO 1
Figura 4.1 Inicio Sistema de Seguridad de Presas
90
Figura 4.2 Búsqueda de Presas, Sistema de Seguridad de Presas
Figura 4.3 Archivos para validar, Sistema de Seguridad de Presas
91
Figura 4.4 Listados de Verificación, Sistema de Seguridad de Presas
Figura 4.5 Búsqueda Listado de Verificación
92
ANEXO 2
ESTRUCTURA OCUPACIONAL SUBDIRECCIÓN
INFORMÁTICA Y TELECOMUNICACIONES
GENERAL
DE
ADMINISTRACIÓN,
GERENCIA
DE
93
ANEXO 3
Figura 4.6 Ejecución de la auditoría
94
ANEXO 4
CRONOGRAMA DE ACTIVIDADES
95
ANEXO 5
96
97
ANEXO 6
98
99
ANEXO 7
100
ANEXO 8
101
102
ANEXO 9
HALLAZGOS
103
104
105
106
RECOMENDACIÓN
107
Realizar Oficio de consideración y autorización en el Programa Anual 2011 para la compra de software adicional y actualizaciones
108
ANEXO 10
109
110
111
112
ANEXO 11
Figura 4.7 Gráfica de Riesgos
113
ANEXO 12
Figura 4.9 Mapa de Riesgos
114
ANEXO 13
115
116
117
118
119
120
ANEXO 14
Figura 4.8 Modelo de Madurez
121
ANEXO 15
INFORME DE AUDITORIA
SISTEMA DE SEGURIDAD DE PRESAS
METODOLOGÍA COBIT
1.0
DATOS GENERALES DE LA ORGANIZACIÓN
Nombre: Comisión Nacional del Agua
Dirección:Insurgentes Sur. No. 2416 Colonia Copilco el bajo CP.04340,
Delegación Coyoacán México D.F.
Servicios: Administrar y preservar las aguas nacionales
No de empleados: 13600 empleados totales de la Comision Nacional del
agua, con : 3Subgerencia de Seguridad de Presas y 3 en Subgerencia de
Sistemas
Representantes de la organización auditada:
ING. ARCADIO GARCÍA GIRON
SUBDIRECTOR ADMINISTRATIVO
SEGURIDAD DE PRESAS
2.0
“A”
RESPONSABLE
DE
SISTEMA
DE
OBJETIVO, PROBLEMÁTICA, ALCANCE y CRITERIOS DE AUDITORIA.
Los objetivos de esta auditoria fueron:
Auditar la base de datos de la aplicación del “sistema de seguridad de presas”, bajo la
metodología de COBIT
Confirmar que el sistema de seguridad de presas en su base de datos que cumple con
lo requerido por la metodología aplicada COBIT
Problemática
Dentro de la política de la empresa, se debió realizar después de la implementación
algún proceso de auditoria al mismo y dicho proceso no se ha llevado a cabo
122
METODOLOGÍA COBIT
Alcance:
Con la presente auditoria se pretende llevar a cabo un análisis de riesgos para el
“Sistema de Seguridad de Presas” de la CONAGUA que permita revisar la aplicación
apegándonos a la metodología de COBIT y la relación con la política de la empresa.
Con el fin de facilitar a quienes lo precisen, respuestas a consultas de la información
almacenada en el “Sistema de Seguridad de Presas”. A su vez generar un informe que
facilite el análisis de datos para que el personal encargado de la seguridad de presas
tenga disponibilidad confiabilidad e integridad de a información para una mejor toma de
decisiones
Como criterios de auditoria se han definido los siguientes documentos:
1) Metodología COBIT.
2) Documentación del sistema de Seguridad de Presas otorgado por el área de
sistemas de la institución
Justificación
Debido a que el “sistema de seguridad de presas” se implementó por primera vez el 1º
de marzo de 2010 en la CONAGUA, es necesario llevar a cabo el proceso de auditoria
para minimizar los riesgos de que la aplicación no funcione adecuadamente y
determinar si cumple con las buenas prácticas.
Al realizar dicha auditoria tendremos como resultado, disminuir las incidencias que
surgieran en la aplicación, de esta forma, ayudar a que la aplicación opere de forma
eficiente basándonos en la metodología PRIMA y tomando como referencia COBIT
para elaboración del cheklist.
123
METODOLOGÍA COBIT
Equipo de auditores
Nombre
Iniciales
1
Judith Yañez Morales
JYM
2
Elena Torres Flores
ETF
3
Yazmín Mosqueda Jaramillo
YMJ
4
Efrén Ramírez Aguilar
ERA
5
José Luis Tapia Martínez
JTM
LISTA DE DISTRIBUCIÓN DEL INFORME
Original
ING. Arcadio García Giron
Copia
Ing. Rodrigo Murillo Fernández
3.0
CONCLUSIONES DE LA AUDITORIA
Concluimos que existe conciencia sobre la seguridad y ésta es promovida por la
gerencia aunque esta sea un poco fraccionada y limitada en cuanto al control de
accesos.
 Algunas políticas de seguridad están alineadas con la política de seguridad de TI
 Las responsabilidades de la seguridad de TI están asignadas y entendidas, pero
no continuamente implementadas.
124
 Existe capacitación en seguridad para TI pero se programa y se comunica de
manera informal.
 La seguridad de TI es vista primordialmente con responsabilidad y disciplina pero
la institución no lo ve como parte importante de sus propios objetivos.
Podemos concluir que el proceso está definido y el contacto con métodos para
promover la conciencia de la seguridad es obligatorio por lo tanto se tendrá que tomar
en cuenta las medidas correctivas antes observadas para que la responsabilidad sea
conjunta de la institución y sus objetivos optimizados con las mejores prácticas.
3.1
FORTALEZAS




3.2
Apoyo logistico
Disponibilidad del personal de la Institución
Programa presupuestal de alto indice economico
Infraestructura de alta calidad
DEBILIDADES
 La no comprensión por parte de los usuarios de la política corporativa de SGSI.
 Falta de concienciación con respecto a la importancia de la confidencialidad del
password.
 Los passwords no consideran
8 caracteres, mayúsculas, minúsculas y
caracteres especiales.
3.3
SUGERENCIAS POR PARTE DEL EQUIPO AUDITOR
 Dar una mayor difusión a la Política Corporativa de Seguridad de la Información.
Asegurarse que la información que se está transmitiendo sea clara. Difundir
información que involucra la participación del usuario.
 Corroborar que se hayan dado de baja las cuentas de correo electrónico
solicitadas a sistemas centrales e incluir las bajas de todas las cuentas de las
aplicaciones que el usuario utilizaba.
 Concientizar a los usuarios para que utilicen el bloqueo de equipo cuando están
fuera de su lugar de trabajo.
125
HALLAZGOS ENCONTRADOS CONFORME A LA METODOLOGÍA COBIT
Domino del COBIT Descripción del Proceso del Domino del
COBIT
Hallazgo encontrado
Rieso presentado
PO9. Evaluación de Riesgos de TI Evaluar de forma recurrente la probabilidad e impacto de todos los riesgos identificados, No se cuenta con una
auditoría
previa al sistema,
Planeación y usando métodos cualitativos y cuantitativos. ni una relación con la
Organización La probabilidad e impacto asociados a los evaluación de los riesgos
de TI.
riesgos inherentes y residuales se debe determinar de forma individual, por categoría y con base en el portafolio. DS5.2. Plan de seguridad de TI
Entrega y Soporte Trasladar los requerimientos de negocio, riesgos y
cumplimiento dentro de un plan de seguridad de TI
completo, teniendo en consideración
la
infraestructura de TI y cultura de la seguridad.
Comunicar las políticas y procedimientos de
seguridad a los interesados y a los usuarios.
Entrega DS5. Administración de Identidades
Las políticas y
procedimientos de
seguridad no son
comunicados con
frecuencia
El sistema se encuentra
susceptible a la continuidad
de sus operaciones si
llegará a tener una pérdida
total
o
parcial
de
información por un desastre
natural o un sabotaje
interno o externo.
Al
no
llevar
una
comunicación
apropiada
hacia los miembros de TI,
puede provocar
una
inestabilidad en flujo de
trabajo de las operaciones
del sistema.
No cuentan con un registro
de identidades del usuario
y Soporte No se cuenta con un Plan
de contingencia
Posibles fallas y no detección de amenazas y no vulnerabilidades del sistema perjudicando la integridad y confiabilidad de la información Asegurar que todos los usuarios (internos, externos
y temporales) y su actividad en sistemas de TI
en un repositorio
126
(aplicación de negocio, entorno de TI, operación de
sistemas, desarrollo y mantenimiento) deben ser
No cuentan con una
identificables de manera única. Permitir que el administración de cuentas
usuario se identifique a través de mecanismos de dadas de baja del personal
que no labora en la
autenticación
institución
Confirmar que los permisos de acceso al usuario al
sistema y los datos están en línea con las
necesidades del negocio y documentadas .
Verificar que los derechos al acceso a los usuarios
sean solicitadas por la gerencia y aprobados por
el responsable del sistema e implementado por la
persona responsable de la seguridad.
Al no contar con el
almacenamiento de con un
registro de las identidades
del
usuario
pueden
provocar una alteración en
la base de datos al no tener
establecidos los tipos de
acceso para cada usuario.
Las identidades del usuario y los derechos de
acceso se mantienen en un repositorio central
Entrega y Soporte Entrega DS5.4 Administración de cuentas de usuario
Al
mantener
activas
cuentas de usuario pueden
No cuentan con una
existir una suplantación de
administración de cuentas identidades del personal no
Garantizar que la solicitud, establecimiento, para las bajas del personal
permitido al área y alterar o
emisión, suspensión, modificación y cierre de
que no labora en la
robar
información
cuentas de usuarios y de los privilegios
institución
importante.
relacionados, sean tomados en cuenta por un
conjunto de procedimientos de la gerencia de
cuentas de usuarios
DS5.9 Prevención, Detección y Corrección de
Software Malicioso
y Soporte Medidas preventivas, detectivas y correctivas ( en
especial contar con parches de seguridad y
control de virus actualizados en toda la
organización para proteger los sistemas de la
información y a la tecnología contra malware
No cuentan con un
El riesgo que se presenta al
actualizaciones en la base no actualizar ocasiona un
de datos
mal funcionamiento en los
procesos de captura y
almacenamiento
provocando inestabilidad
en el sistema.
127
Entrega y Soporte DS5.10 Seguridad en la red
Uso de técnicas de seguridad y procedimientos de
administración asociados con firewalls, dispositivos
de seguridad, segmentación de redes y detección
de intrusos para autorizar el acceso y controlar los
flujos de información desde y hacia las redes.
El riesgo es la intrusión de
No cuentan con un control hackers, spywares, phising,
en la habilitación o
malwares que provoquen
inhabilitación de los puertos daño
irreparables
o
que dan salida a la red
pérdidas de información
relevante para la institución
México, D.F. a 21 de Agosto del 2010.
Atentamente
Nombre
Firma Judith Oralia Yañez Morales
Irais Elena Torres Flores
Yazmín Mosqueda Jaramillo
Efrén Ramírez Aguilar
José Luis Tapia Martínez
128
ÍNDICE DE FIGURAS
Figura 1.1. Fases de la auditoría. ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 16 Figura 2.1. Arquitectura de un Sistema Gestor de Bases de Datos. ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 31 Figura 3.1 Preguntas frecuentes ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 39 Figura 3.2 Áreas Focales del Gobierno de TI ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 40 Figura 3.3 Productos de COBIT ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 40 Figura 3.4 Principio Básico ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 43 Figura 3.5 Definiendo metas de TI y arquitectura empresarial para TI ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 44 Figura 3.6 Representación gráfica de modelos de madurez ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 49 Figura 3.7 Las tres dimensiones de la madurez ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 51 Figura 3.8 El cubo de COBIT ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 54 Figura 3.9 Marco de trabajo General de COBIT ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 55 Figura 3.10 Metas y Métricas.DS5 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 59 Figura 3.11Metas y métricas DS8‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 62 Figura 3.12 Metas y Métricas DS11 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 63 Figura 3.13 Metas y Métricas DS13 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 65 Figura 4.1 Inicio Sistema de Seguridad de Presas ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 90 Figura 4.2 Búsqueda de Presas, Sistema de Seguridad de Presas ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 91 Figura 4.3 Archivos para validar, Sistema de Seguridad de Presas ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 91 Figura 4.4 Listados de Verificación, Sistema de Seguridad de Presas ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 92 Figura 4.5 Búsqueda Listado de Verificación ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 92 Figura 4.6 Ejecución de la auditoría ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 94 Figura 4.7 Gráfica de Riesgos ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 113 Figura 4.9 Mapa de Riesgos ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 114 Figura 4.8 Modelo de Madurez ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 121 129
ÍNDICE DE TABLAS
Tabla 1.1 Evolución de la Práctica de auditoria ....................................................................... 13 Tabla 1.2 Clases de auditoría. ................................................................................................. 14 Tabla 1.3 Comparación Control Interno y Auditoría Informática ............................................. 19 Tabla 2.1 Restricciones de Integridad ...................................................................................... 27 Tabla 2.2 Restricciones de Integridad ...................................................................................... 27 Tabla 2.3 Restricciones de Integridad ...................................................................................... 28 Tabla 2.4 Referencias .............................................................................................................. 28 Tabla 3.1 Atributos de madurez .............................................................................................. 53 Tabla 4.1 Porcentajes Checklist ............................................................................................... 85 130
GLOSARIO
Atributos de madurez: lista de las características de cómo se administran los procesos
de TI y describe cómo evolucionan desde un proceso no existente hasta uno optimizado
Arquitectura de TI - Un marco integrado para evolucionar o dar mantenimiento a la TI
existente y adquirir nueva TI para alcanzar las metas estratégicas y de negocio de la
empresa.
Arquitectura empresarial - Mapa de rutas tecnológicas orientada al negocio para el
logro de las metas y objetivos de negocio.
Arquitectura empresarial para TI - Respuesta en la entrega de TI, provista por
procesos claramente definidos usando sus recursos (aplicaciones, información,
infraestructura y personas).
Auditoria informática - es el proceso de recoger, agrupar y evaluar evidencias para
determinar si un Sistema de Información salvaguarda el activo empresarial, mantiene la
integridad de los datos, lleva a cabo eficazmente los fines de la organización y utiliza
eficientemente los recursos
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
Checklist - listado que se utiliza para identificar información específica que se requiere
para completar la descripción de un problema.
Cliente - Una persona o una entidad externa o interna que recibe los servicios
empresariales de TI
COBIT - Control Objective for Information Technology es hoy reconocido mundialmente
como un marco de referencia para la implementación de un mejor gobierno o gestión de
TI.
Confiabilidad significa proporcionar la información apropiada para que la gerencia
administre la entidad y ejercite sus responsabilidades fiduciarias y de gobierno.
Confidencialidad se refiere a la protección de información sensitiva contra revelación
no autorizada.
Continuidad - Prevenir, mitigar y recuperarse de una interrupción. Los términos planear
la reanudación del negocio, planear la recuperación después de un desastre y planear
contingencias también se pueden usar en este contexto; todos se concentran en los
aspectos de recuperación de la continuidad.
131
Control - Las políticas, procedimientos, practicas y estructuras organizacionales
diseñadas para proporcionar una garantía razonable de que los objetivos del negocio se
alcanzarán y los eventos no deseados serán prevenidos o detectados
Control aplicativo- Un conjunto de controles integrados dentro de las soluciones
automatizadas (aplicaciones).
Control de accesos- El proceso que limita y controla el acceso a los recursos de un
sistema computacional; un control lógico o físico diseñado para brindar protección
contra la entrada o el uso no autorizados.
Control de detección - Un control que se usa para identificar eventos indeseables
Control Interno- Las políticas, procedimientos, practicas y estructuras organizacionales
diseñadas para brindar una garantía razonable de que los objetivos del negocio se
alcanzarán y de que los eventos indeseables serán prevenidos o detectados y
corregidos
Control preventivo - Un control interno que se usa para prevenir eventos indeseables,
errores u otras ocurrencias que pudieran tener un efecto material negativo sobre un
proceso o producto final, de acuerdo a la organización.
Cumplimiento tiene que ver con acatar aquellas leyes, reglamentos y acuerdos
contractuales a los cuales está sujeto el proceso de negocios, es decir, criterios de
negocios impuestos externamente, así como políticas internas.
Diccionario de datos - Un conjunto de meta-datos que contiene definiciones y
representaciones de elementos de datos.
Disponibilidad se refiere a que la información esté disponible cuando sea requerida
por los procesos del negocio en cualquier momento. También concierne con la
protección de los recursos y las capacidades necesarias asociadas.
Dominio- Agrupación de objetivos de control en etapas lógicas en el ciclo de vida de
inversión en TI.
Efectividad - tiene que ver con que la información sea relevante y pertinente a los
procesos del negocio, y se proporcione de una manera oportuna, correcta, consistente
y utilizable.
Eficiencia - consiste en que la información sea generada optimizando los recursos
(más productivo y económico).
132
Incidente - Cualquier evento que no sea parte de la operación estándar de un servicio
que ocasione, o pueda ocasionar, una interrupción o una reducción de la calidad de ese
servicio (alineado a ITIL).
Infraestructura - La tecnología, los recursos humanos y las instalaciones que permiten
el procesamiento de las aplicaciones.
Integridad está relacionada con la precisión y completitud de la información, así como
con su validez de acuerdo a los valores y expectativas del negocio.
ISO 17799 - Código de práctica para la administración de la seguridad de la información
de la Organización Internacional para la Estandarización (ISO).
ISO 9001:2000 - Código de práctica para la administración de la calidad de la
Organización internacional
ITIL - Librería de Infraestructura de TI de la Oficina de Gobierno Gubernamental del
Reino Unido (OGC).Un conjunto de lineamientos sobre la administración y procuración
de servicios operativos de TI.
Madurez - Indica el grado de confiabilidad o dependencia que el negocio puede tener
en un proceso, al alcanzar las metas y objetivos deseados
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 estos procesos, con base en los objetivos de
control detallados de COBIT
Métrica - Un estándar para medir el desempeño contra la meta.
Plan estratégico de TI - Un plan a largo plazo, ej., con un horizonte de tres a cinco
años, en el cual la gerencia del negocio y de TI describen de forma cooperativa cómo
los recursos de TI contribuirán a los objetivos estratégicos empresariales (metas)
Modelo de Madurez: es un plan de negocio para mejorar y alcanzar el nivel apropiado
de administración y control sobre la infraestructura de información
Modelo de madurez de la capacidad (CMM) - El modelo de madurez de la capacidad
para software (CMM), del Instituto de Ingeniería de Software (SEI), es un modelo
utilizado por muchas organizaciones para identificar las mejores prácticas, las cuales
son convenientes para ayudarles a evaluar y mejorarla madurez de su proceso de
desarrollo de software.
133
Plan de infraestructura tecnológica - Un plan para el mantenimiento y desarrollo de la
infraestructura tecnológica.
Plan táctico de TI - Un plan a mediano plazo, ej., con un horizonte de seis a dieciocho
meses, que traduzca la dirección del plan estratégico de TI en las iniciativas requeridas,
requisitos de recursos y formas en las que los recursos y los beneficios serán
supervisados y administrados
Política - Por lo general, un documento que ofrece un principio de alto nivel o una
estrategia a seguir. El propósito de una política es influenciar y guiar la toma de
decisiones presente y futura, haciendo que estén de acuerdo a la filosofía, objetivos y
planes estratégicos establecidos por los equipos gerenciales de la empresa. Además
del contenido de la política, esta debe describir las consecuencias de la falta de
cumplimiento de la misma, el mecanismo para manejo de excepciones y la manera en
que se verificará y medirá el cumplimiento de la política.
Práctica de control - Mecanismo clave de control que apoya el logro de los objetivos
de control por medio del uso responsable de recursos, la administración apropiada de
los riesgos y la alineación de TI con el negocio
PRINCE2 - Proyectos en un ambiente controlado, un método de administración de
proyectos que cubre la administración, el control y la organización de un proyecto
Problema - Causa subyacente desconocida de uno o más incidentes
Procedimiento - Una descripción de una manera particular de lograr algo; una forma
establecida de hacer las cosas; una serie de pasos que se siguen en un orden regular
definido, garantizando un enfoque consistente y repetitivo hacia las actividades.
Proceso - Por lo general, un conjunto de procedimientos influenciados por las políticas
y estándares de la organización, que toma las entradas provenientes de un número de
fuentes, incluyendo otros procesos, manipula las entradas, y genera salidas, incluyendo
a otros procesos, para los clientes de los procesos. Los procesos tienen razones claras
de negocio para existir, propietarios responsables, roles claros y responsabilidades
alrededor de la ejecución del proceso, así como los medios para medir el desempeño.
Programa - Una agrupación estructurada de proyectos independientes que incluye el
alcance completo del negocio, del proceso, de las personas, de la tecnología y las
actividades organizacionales que se requieren (tanto necesarias como suficientes) para
lograr un resultado de negocios claramente especificado.
Programa aplicativo - Un programa que procesa.
Propietarios de datos - Individuos, por lo general gerentes o directores, que tienen la
134
responsabilidad de la integridad, el uso y el reporte preciso de los datos
computarizados.
Proveedor de servicios - Organización externa que presta servicios a la organización.
Proyecto - Un conjunto estructurado de actividades relacionadas con la entrega de una
capacidad definida a la organización (la cual es necesaria, aunque no suficiente para
lograr un resultado de negocios requerido) con base en un calendario y presupuesto
acordado.
Recursos TI - conjunto de procesos definidos con claridad que utiliza las habilidades de
las personas, y la infraestructura de tecnología para ejecutar aplicaciones
automatizadas de negocio
Riesgo - El potencial de que una amenaza específica explote las debilidades de un
activo o grupo de activos para ocasionar pérdida y/o daño a los activos. Por lo general
se mide por medio de una combinación del impacto y la probabilidad de ocurrencia.
TI - Tecnología de información.
Usuario - Una persona que utiliza los sistemas empresariales.
135
BIBLIOGRAFÍA
 Expansión, Control Interno, Auditoría y Seguridad Informática. Tomos II-IV, 1996.
 Govindan, Marshal, John Y. Picard, Manifest on Information Systems Control and
Management, McGraw-Hill, 1990.
 Piattini, M., E. Del Peso, Auditoría Informática: un enfoque práctico, Ra-Ma,
1997.
 Piattini, Mario y Emilio del Peso. Auditoría Informática. Un enfoque práctico.
Editorial RA-MA.
 COBIT 4.0 de IT Governance Institute.
 Comité Directivo de CobiT/ISACA
 http://www.isaca.org.mx
 http://www.w3schools.com/sql/default.asp
 http://dialnet.unirioja.es/servlet/articulo?codigo=2938827
 http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx
 http://www.datasec.com.uy/ oxely-coso.pdf
136

AUDITORÍA A LA BASE DE DATOS SQL DEL SISTEMA DE

Transcription

Similar documents

Presentación de la reunión de trabajo de inicio del semestre Agosto

Revista UES ECP V.indd - Facultad de Ciencias Económicas

Sistema de Gestión Integral con g PAS 99, ISO

Descargar Presentación

Contribución de las comunidades bentónicas en la dieta del róbalo

agua, ríos y pueblos - Agua rios y pueblos

Tesis - Dirección General de Servicios Telemáticos

Guía para la Transparencia en los Documentos Presupuestarios del

Nuestro dinero - International Budget Partnership

VILLANUEVA, ZAC. 2010 - Ayuntamiento de Villanueva

Estado de wonderbra

Ver/Abrir - Repositorio Digital - Instituto Politécnico Nacional

Reptiles and Amphibians List