AUDITORÍA A LA BASE DE DATOS SQL DEL SISTEMA DE … · AUDITORÍA A LA BASE DE DATOS SQL DEL...

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

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA

UNIDAD CULHUACAN

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 INTRODUCCIÓN A LA AUDITORIA CAPITULO II. BASE DE DATOS CAPITULO III METODOLOGÍAS DE ANÁLISIS DE RIESGOS CAPITULO IV 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 ING. EDUARDO MARTÍNEZ CORONA Coordinador del Seminario Instructor del Seminario

M. EN C. LUIS CARLOS CASTRO MADRID Jefe de la carrera de I.C.

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

“SEGURIDAD DE PRESAS” CONAGUA

3

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



4

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



5

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



6

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



7

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



8

Í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



9

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



10

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



11

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



12

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.



13

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: 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 (cumplimiento)

Objetivo: Evaluar el nivel de seguridad y control del entorno de TI asegurando que refuerza la estructura de control interno de la organización (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.



14

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.

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.

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 eficiente y según normas establecidas

Gestión Opinión Dirección Eficiencia, Eficacia economicidad

Cumplimiento Opinión Normas establecidas Las operaciones se adecuan a estas normas



15

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.



16

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. Análisis. 2. Pruebas de la Auditoría. 3. Evaluación del Riesgo. 4. Hallazgos de la Auditoría. 5. Implementación de los controles.



17

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.



18

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.



19

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

AUDITORIA INFORMÁTICA

SIMILITUDES

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.

DIFERENCIAS

Análisis de controles en el día a día El alcance de sus funciones es únicamente sobre el departamento de informática.

Análisis de un momento informático determinado 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.



20

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



21

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.



22

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.



23

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



24

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 de los objetos del mundo real y sus asociaciones.

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:



25

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.



26

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.



27

2.8 RESTRICCIONES DE INTEGRIDAD

Restricción de integridad Descripción Identificador de entidad 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

Restricción de integridad Descripción Tipo de valor de un atributo 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).



28

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).

Restricción de integridad 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.


Restricción de integridad Descripción

Referencias

Son establecidos para mantener consistencia sobre tuplas de la relación.

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.



29

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.



30

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.



31

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.



32

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 que ocurren en la definición de la BD o en la BD en sí misma. 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;



33

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. El sistema de aplicación que actualiza la BD procesa datos erróneamente

2. 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. En función de los tiempos o la cantidad de recursos requeridos para aplicar transacciones puede surgir la necesidad de reorganizar la BD.

2. 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 que ocurren en la definición de la BD o en la BD en sí misma.



34

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. Confirmar que la última transacción ha alcanzado la definición de la BD o la BD misma;

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.

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.



35

CAPITULO III METODOLOGÍAS DE ANÁLISIS DE RIESGOS

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



36

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.



37

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



38

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.



39

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



40

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



41

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



42

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



43

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).



44

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.



45

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.



46

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?



47

¿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.



48

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.



49

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.



50

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



51

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



52

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.



53

Tabla 3.1 Atributos de madurez

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 Existe comunicación esporádica de los problemas.

Existen enfoques ad hoc hacia los procesos y las prácticas Los procesos y las prácticas no están definidos

Pueden existir algunas herramientas; el uso se basa en herramienta estándar de escritorio No existe un enfoque planeado para el uso de herramientas

No están definidas las habilidades requeridas para el proceso No existe un plan de entrenamiento y no hay entrenamiento formal

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.

Las metas no están claras y no existen las mediciones.

2 Existe conciencia de la necesidad de actuar La gerencia comunica los problemas generales

Surgen procesos similares y comunes pero en su mayoría son intuitivos y parten de la experiencia individual 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

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 identifican los requerimientos mínimos de habilidades para áreas críticas Se da entrenamiento como respuesta a las necesidades, en lugar de hacerlo con base en un plan acordado. Existe entrenamiento informal sobre la marcha.

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.

Existen algunas metas; se establecen algunas mediciones financieras pero solo las conoce la alta dirección. Hay monitoreo inconsistente en áreas aisladas.

3 Existe el entendimiento de la necesidad de actuar La gerencia es más formal y estructurada en su comunicación

Surge el uso de buenas prácticas Los procesos, políticas y procedimientos están definidos y documentados para todas las actividades clave

Existe un plan para el uso y estandarización de las herramientas para automatizar el proceso 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í

Se definen y documentan los requerimientos y habilidades para todas las áreas. 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 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.

4 Hay entendimiento de los requerimientos completos Se aplican técnicas maduras de comunicación y se usan herramientas estándar de comunicación

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.

Se implantan las herramientas de acuerdo a un plan estándar y algunas se han integrado con otras herramientas relacionadas Se usan herramientas en las principales áreas para automatizar la administración del proceso y monitorear las actividades y controles críticos

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.

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.

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.

5 Existe un entendimiento avanzado y a futuro de los requerimientos 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

Se aplican las mejores prácticas y estándares externos 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

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

La organización fomenta de manera formal la mejora continua de las habilidades, con base en metas personales y organizacionales claramente definidas. 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.

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.



54

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.



55

Figura 3.9 Marco de trabajo General de COBIT



56

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



57

organizaciones apoyar la operatividad del negocio de forma apropiada con las aplicaciones automatizadas correctas. Control sobre el proceso TI de Adquirir y dar mantenimiento a software aplicativo Que satisface el requisito de negocio de TI para construir las aplicaciones de acuerdo con los requerimientos del negocio y haciéndolas a tiempo y a un costo razonable Enfocándose en garantizar que exista un proceso de desarrollo oportuno y confiable Se logra con • La traducción de requerimientos de negocio a especificaciones de diseño • La adhesión a los estándares de desarrollo para todas las modificaciones • La separación de las actividades de desarrollo, de pruebas y operativas Y se mide con • Número de problemas en producción por aplicación, que causan tiempo perdido significativo • Porcentaje de usuarios satisfechos con la funcionalidad entregada 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.



58

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.



59

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



60

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.



61

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 causa-efecto 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.



62

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



63

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



64

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. Las metas y métricas de este dominio se describen en la Figura 3.13



65

Figura 3.13 Metas y Métricas DS13



66

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



67

Para cumplir con su propósito esencial, la Comisión se divide operativamente en tres grandes áreas:

1. Oficinas Centrales 2. Organismos de Cuenca. 3. 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. Península de Baja California (Mexicali, Baja California). II. Noroeste (Hermosillo, Sonora). III. Balsas (Cuernavaca, Morelos) IV. Pacífico Sur (Oaxaca, Oaxaca) V. Río Bravo (Monterrey, Nuevo León). VI. Cuencas Centrales del Norte (Torreón, Coahuila). VII. Lerma Santiago Pacífico (Guadalajara, Jalisco). VIII. Golfo Norte (Ciudad Victoria, Tamaulipas). IX. Golfo Centro (Jalapa, Veracruz). X. Frontera Sur (Tuxtla Gutiérrez, Chiapas). XI. Península de Yucatán (Mérida, Yucatán). XII. Aguas del Valle de México y Sistema Cutzamala (México, Distrito

Federal).



68

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. Determinar la disponibilidad del agua 2. Orientar los nuevos polos de desarrollo. 3. Lograr el uso sustentable del agua. 4. Asegurar la preservación de los acuíferos. 5. Garantizar la calidad del agua superficial. 6. Llevar a cabo la recaudación en materia de aguas nacionales y sus

bienes. 7. Solucionar conflictos relacionados con el agua. 8. Otorgar concesiones, asignaciones y permisos. 9. Promover la cultura del buen uso y preservación del agua. 10. Prevenir los riesgos y atender los daños por inundaciones. 11. Prevenir los riesgos y atender los efectos por condiciones severas de

escasez de agua. 12. 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".



69

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.



70

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



71

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)



72

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.



73

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)



74

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.



75

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



76

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.



77

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



78

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



79

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



80

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



81

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. Entrevistas, 2. Checklist, 3. Carta de requerimientos, 4. Hallazgos, 5. Pruebas y 6. 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



82

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.



83

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)



84

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)



85

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

Total de preguntas 55 Resp Afirmativas 39 Resp. Negativas 11 No aplican 5

Porcentaje afirmativo 70.91% 55 100% 39 70.91

Porcentaje Negativo 20% 55 100% 11 20

Porcentaje no aplican 9.09% 55 100% 5 9.09 TOTAL 100.00%



86

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



87

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)



88

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)



89

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.



90

ANEXOS

ANEXO 1

Figura 4.1 Inicio Sistema de Seguridad de Presas



91

Figura 4.2 Búsqueda de Presas, Sistema de Seguridad de Presas

Figura 4.3 Archivos para validar, Sistema de Seguridad de Presas



92

Figura 4.4 Listados de Verificación, Sistema de Seguridad de Presas

Figura 4.5 Búsqueda Listado de Verificación



93

ANEXO 2 ESTRUCTURA OCUPACIONAL SUBDIRECCIÓN GENERAL DE ADMINISTRACIÓN, GERENCIA DE INFORMÁTICA Y TELECOMUNICACIONES



94

ANEXO 3

Figura 4.6 Ejecución de la auditoría



95

ANEXO 4 CRONOGRAMA DE ACTIVIDADES



96

ANEXO 5



97



98

ANEXO 6



99



100

ANEXO 7



101

ANEXO 8



102



103

ANEXO 9

HALLAZGOS



104



105



106



107

RECOMENDACIÓN



108

Realizar Oficio de consideración y autorización en el Programa Anual 2011 para la compra de software adicional y actualizaciones



109

ANEXO 10



110



111



112



113

ANEXO 11

Figura 4.7 Gráfica de Riesgos



114

ANEXO 12

Figura 4.9 Mapa de Riesgos



115

ANEXO 13



116



117



118



119



120



121

ANEXO 14

Figura 4.8 Modelo de Madurez



122

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 “A” RESPONSABLE DE SISTEMA DE SEGURIDAD DE PRESAS

2.0 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



123

INFORME DE AUDITORIA SISTEMA DE SEGURIDAD DE PRESAS

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.



124

INFORME DE AUDITORIA SISTEMA DE SEGURIDAD DE PRESAS

METODOLOGÍA COBIT

Equipo de auditores

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.

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



125

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

Apoyo logistico Disponibilidad del personal de la Institución Programa presupuestal de alto indice economico Infraestructura de alta calidad

3.2 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.



126

HALLAZGOS ENCONTRADOS CONFORME A LA METODOLOGÍA COBIT

Domino del

COBIT

Descripción del Proceso del Domino del COBIT

Hallazgo encontrado Rieso presentado

Planeación y

Organización

PO9. Evaluación de Riesgos de TI

Evaluar de forma recurrente la probabilidad e

impacto de todos los riesgos identificados,

usando métodos cualitativos y cuantitativos.

La probabilidad e impacto asociados a los

riesgos inherentes y residuales se debe

determinar de forma individual, por categoría

y con base en el portafolio.

No se cuenta con una auditoría previa al sistema,

ni una relación con la evaluación de los riesgos

de TI.

Posibles fallas y no

detección de amenazas y

no vulnerabilidades del

sistema perjudicando la

integridad y

confiabilidad de la

información

Entrega

y

Soporte

DS5.2. Plan de seguridad de TI

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.

No se cuenta con un Plan de contingencia

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.

Las políticas y procedimientos de seguridad no son comunicados con

frecuencia

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.

Entrega

y

Soporte

DS5. Administración de Identidades

Asegurar que todos los usuarios (internos, externos y temporales) y su actividad en sistemas de TI

No cuentan con un registro de identidades del usuario

en un repositorio



127

(aplicación de negocio, entorno de TI, operación de sistemas, desarrollo y mantenimiento) deben ser identificables de manera única. Permitir que el usuario se identifique a través de mecanismos de autenticació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.

Las identidades del usuario y los derechos de acceso se mantienen en un repositorio central

No cuentan con una administración de cuentas dadas de baja del personal

que no labora en la institución

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.

Entrega

y

Soporte

DS5.4 Administración de cuentas de usuario

Garantizar que la solicitud, establecimiento, emisión, suspensión, modificación y cierre de cuentas de usuarios y de los privilegios relacionados, sean tomados en cuenta por un conjunto de procedimientos de la gerencia de cuentas de usuarios

No cuentan con una administración de cuentas para las bajas del personal

que no labora en la institución

Al mantener activas cuentas de usuario pueden existir una suplantación de identidades del personal no permitido al área y alterar o robar información importante.

Entrega

y

Soporte

DS5.9 Prevención, Detección y Corrección de Software Malicioso

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 actualizaciones en la base

de datos

El riesgo que se presenta al no actualizar ocasiona un mal funcionamiento en los procesos de captura y almacenamiento provocando inestabilidad en el sistema.



128

México, D.F. a 21 de Agosto del 2010.

A t e n t a m e n t e

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

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.

No cuentan con un control en la habilitación o

inhabilitación de los puertos que dan salida a la red

El riesgo es la intrusión de hackers, spywares, phising, malwares que provoquen daño irreparables o pérdidas de información relevante para la institución



129

Í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



130

Í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.4 Referencias .............................................................................................................. 28

Tabla 3.1 Atributos de madurez .............................................................................................. 53

Tabla 4.1 Porcentajes Checklist ............................................................................................... 85



131

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.



132

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).



133

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.



134

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



135

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.



136

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

AUDITORÍA A LA BASE DE DATOS SQL DEL SISTEMA DE … · AUDITORÍA A LA BASE DE DATOS SQL DEL...

Documents

Transcript of AUDITORÍA A LA BASE DE DATOS SQL DEL SISTEMA DE … · AUDITORÍA A LA BASE DE DATOS SQL DEL...