AUDITORIA A LOS REQUERIMIENTOS TECNOLOGICOS PARA …

INSTITUTO POLITÉCNICO NACIONAL

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

[AUDITORIA A LOS REQUERIMIENTOS TÉCNICOS PARA SERVICIO DE AULA BASE

TELEMATICA DE LA SEP]

TESINA

QUE PARA OBTENER EL TITULO DE:

INGENIERO EN COMUNICACIONES Y ELECTRONICA

INGENIERO EN COMPUTACIÓN LICENCIADO EN INFORMÁTICA

AUTORES:

GABRIEL CARLOS ANAYA IRIS GUADALUPE SOTO MATA

MARIANA MARAVILLA RAMIREZ MARLENE BECERRIL CASTILLO ELBIN ADELI MARTINEZ LOPEZ

TUTOR

ING. EDUARDO SANTANA ALQUICIRA

[MÉXICO DF. JUNIO 2012]

AUDITORIA A LOS REQUERIMIENTOS TÉCNICOS

PARA SERVICIO DE AULA BASE TELEMATICA DE LA SEP

2



3



4

CONTENIDO

INTRODUCCION ....................................................................................................................... 7 OBJETIVO: ................................................................................................................................ 8 JUSTIFICACIÓN: ...................................................................................................................... 8

ALCANCE: ................................................................................................................................. 8 PROBLEMÁTICA: ..................................................................................................................... 8 INTRODUCCION A LA AUDITORIA DE TIC’S .......................................................................... 9

1.1 CONCEPTOS GENERALES.................................................................................... 9 1.1.1 AUDITORIA DE SISTEMAS ........................................................................ 9

1.1.2 ADMINISTRACIÓN INFORMÁTICA ........................................................... 9

1.1.3 CONTROL INTERNO ................................................................................. 9 1.2 RIESGO ................................................................................................................. 10

1.2.1 RIESGOS DE NEGOCIO RELACIONADOS CON LA INFORMÁTICA .... 10

1.3 LA SEGURIDAD INFORMÁTICA Y SUS OBJETIVOS ........................................... 13 1.4 PROCESO DE LA AUDITORIA DE TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACION. .......................................................................................................... 16

1.4.1 EVALUACIÓN DEL SISTEMA DE CONTROL INTERNO (COBIT) ........... 18 1.4.2 EVALUACIÓN DE LAS POLÍTICAS DE SEGURIDAD INFORMÁTICA (ISO 17 799 ) .............................................................................................................. 20

1.5 TÉCNICAS DE AUDITORIA DE TECNOLOGÍA DE INFORMACIÓN ..................... 22

1.5.1 PRUEBAS DE CUMPLIMIENTO ............................................................... 22

1.5.2 PRUEBAS SUSTANTIVAS ........................................................................ 22

1.6 TÉCNICAS DE AUDITORIA ASISTIDAS POR COMPUTADOR ............................ 23 1.7 INDICADORES DE GESTIÓN ................................................................................. 24

1.8 AUDITORIA A LAS APLICACIONES ...................................................................... 25 1.8.1 POLÍTICAS Y PROCEDIMIENTOS ........................................................... 25 1.8.2 ESTÁNDARES DE DESARROLLO Y PRODUCCIÓN .............................. 25 1.8.3 DATOS DE ENTRADA .............................................................................. 25

1.8.4 PROCEDIMIENTOS DE CAPTURA .......................................................... 26 1.8.5 PROCEDIMIENTO Y ACTUALIZACIÓN DE INFORMACIÓN ................... 26 1.8.6 INFORMES DE COMPUTADOR ............................................................... 26 1.8.7 DOCUMENTACIÓN .................................................................................. 26 1.8.8 SEGURIDAD ............................................................................................. 27

1.8.9 PROCEDIMIENTOS DE RESPALDO ....................................................... 27

1.8.10 CAPACITACIÓN Y SOPORTE A USUARIOS ......................................... 27

1.9 AUDITORIA AL CENTRO DE CÓMPUTO .............................................................. 27 1.9.1 PREGUNTAS CLAVES. ............................................................................ 27 1.9.2 CUIDADO DE LAS INSTALACIONES ....................................................... 28 1.9.3 OPERACIÓN DE LOS SERVIDORES....................................................... 29 1.9.4 CONTROL DE ENTRADAS Y SALIDAS. .................................................. 29 1.9.5 SEGURIDAD EN INSTALACIONES. ......................................................... 29 1.9.6 ORGANIZACIÓN Y PERSONAL ............................................................... 30



5

1.9.7 PLANES DE CONTINGENCIA. ................................................................. 30

1.10 POLÍTICAS PARA LA ADMINISTRACIÓN DE LOS RECURSOS TECNOLÓGICOS ...................................................................................................................................... 31 1.11 ASPECTOS A TENER EN CUENTA .................................................................... 31

1.11.1. ORGANIZACIÓN .................................................................................... 31 1.11.2 SOFTWARE ............................................................................................ 33

1.11.3 HARDWARE ............................................................................................ 33 1.11.4 USUARIO ................................................................................................ 34 1.11.5 ÁREA DE SISTEMAS .............................................................................. 34

1.12 AUDITORIA A LOS EQUIPOS DE CÓMPUTO Y REDES LAN ............................ 34 1.12.1 PRUEBAS A REALIZAR POR CADA ASPECTO .................................... 34

BIBLIOTECA DE INFRAESTRUCTURA DE TECNOLOGIAS DE LA INFORMACION (ITIL) . 39

2.1 INTRODUCCIÓN A LA GESTIÓN DE SERVICIOS TI ............................................ 39

2.2 ¿QUÉ ES ITIL? ....................................................................................................... 40

2.3 SOPORTE AL SERVICIO ....................................................................................... 41 2.4 FORUM ITSMF ....................................................................................................... 41 2.5 CERTIFICACIONES ITIL ........................................................................................ 41

2.5.1 EXIN E ISEB .............................................................................................. 41 2.6 INCIDENT MANAGEMENT (GESTION DE INCIDENTES) ..................................... 42

2.6.1 OBJETIVOS DE LA GESTIÓN DE INCIDENTES ..................................... 42 2.6.2 CLASIFICACIÓN DEL INCIDENTE ........................................................... 44 2.6.3 ESCALADO Y SOPORTE ......................................................................... 45

2.6.4 PROCESO ................................................................................................. 46 2.7 REGISTRO Y CLASIFICACIÓN DE INCIDENTES ................................................... 47

2.7.1 REGISTRO ................................................................................................ 47 2.7.2 CLASIFICACIÓN ....................................................................................... 47

2.8 ANÁLISIS, RESOLUCIÓN Y CIERRE DE INCIDENTES .......................................... 48 2.9 CONTROL DEL PROCESO .................................................................................... 48

“ENCICLOMEDIA” ................................................................................................................... 51 3.1 INTRODUCCIÓN .................................................................................................... 51

3.2 TECNOLOGÍA EDUCATIVA EN MÉXICO .............................................................. 51 3.3 ENCICLOMEDIA ..................................................................................................... 53

3.3.1 ORIGEN .................................................................................................... 54 3.3.2 LA PRIMERA VERSIÓN DE LOS LIBROS DE TEXTO ............................. 55

AUDITORIA A LOS REQUERIMIENTOS TÉCNICOS PARA SERVICIO DE AULA BASE TELEMATICA DE LA SEP ....................................................................................................... 56

4.1 DATOS GENERALES. ............................................................................................ 56

4.2 DESCRIPCIÓN. ...................................................................................................... 56 4.3 ESTADO ACTUAL. ................................................................................................. 57 4.4 OBJETIVO GENERAL DEL SERVICIO .................................................................. 57 4.5 REGISTRO DE INCIDENTES ................................................................................. 58

4.5.1 PLAZO DE RESOLUCIÓN DEL NT .......................................................... 58

4.5.2 CIERRE DEL NT ...................................................................................... 59 4.5.3 COMPROBACIÓN DE CIERRE DE NT ..................................................... 59 4.5.4 VERIFICACIÓN DE NT ............................................................................. 60



6

4.5.5 NT POR BAJA DE ABT ............................................................................. 60

4.5.6 NT POR REUBICACIONES DE ABT......................................................... 61 5.5.7 NT POR ROBO, PÉRDIDA O DAÑOS AL ABT ......................................... 61

4.6 DESARROLLO DE LA AUDITORIA ........................................................................ 61 4.6.1 RESULTADOS DE LA GUIDE LINE .......................................................... 66

CONCLUSIONES .................................................................................................................... 71

ANEXO 1. ELEMENTOS TECNOLOGICOS DEL SABT. ........................................................ 72 ANEXO 2. GRAFICO DE MANEJO DE INCIDENTES SABT .................................................. 73 ANEXO 3. PROCESO DE REGISTRODE INCIDENTES SABT .............................................. 74 ANEXO 4. CICLO DE VIDA DE LOS REPORTES DE ATENCIÓN / INCIDENTES CON NT DE SABT ....................................................................................................................................... 75

ANEXO 5. PROCESO DE TIEMPO PARA LA ATENCION DE INCIDENTES ........................ 76

ANEXO 6. CARTA DE AUTORIZACION DE AUDITORIA....................................................... 77

ANEXO 7. CARTA DE PLANEACIÓN ..................................................................................... 78

ANEXO 8. SUPERVICION INTEGRACIÓN DE EXPEDIENTE ............................................... 79 ANEXO 9. CRONOGRAMA DE TRABAJO ............................................................................. 80 ANEXO 10. ACTA DE REUNION DE EQUIPO AUDITOR ...................................................... 81

ANEXO 11. ACTA DE CIERRE DE AUDITORIA .................................................................... 84 INDICE DE FIGURAS.............................................................................................................. 86

INDICE DE TABLAS ................................................................................................................ 86 GLOSARIO .............................................................................................................................. 87 BIBLIOGRAFIA ........................................................................................................................ 89



7

INTRODUCCION

Después de que la Secretaría de Educación Pública (SEP) pospuso la licitación pública para la contratación por cinco años del Servicio de Aula Base Telemática (SABT) por que no “definia” claramente las condiciones para licitar este servicio. Se tomo la decisión de aplicar los conocimientos adquiridos en el seminario de auditoría de tecnologías de información y comunicación (TIC) para auditar este documento. Con este proyecto se pretende hacer una revisión al documento que la SEP envía a las empresas para la licitación y hacer las recomendaciones pertinentes para alinear el SABT con el marco de regulación ITIL V3, con la intención de que se puedan incluir en la próxima licitación. Esperamos que este trabajo sea una base para mejorar el SABT pero sobre todo que sea una forma para regular todos los servicios de la SEP que incluyan TIC



8

OBJETIVO:

Auditar los requerimientos técnicos para Servicio de Aula Base Telemática (SABT), verificar que cumplan con el manual de «Mejores Prácticas de ITIL V3» en el apartado «incident Management» para hacer las recomendaciones pertinentes.

JUSTIFICACIÓN:

Aplicar los conocimientos adquiridos de IT GOVERNANCE en especial ITIL V3 en el apartado «incident Management» para realizar la auditoria a los requerimientos técnicos de SABT.

ALCANCE:

La auditoria se basa en el documento de «requerimientos técnicos para el Servicio Aula Telemática» que envía la Secretaria de Educación Publica para la concurso de licitación del servicio para el periodo escolar 2012-2013.

PROBLEMÁTICA:

La principal problemática que se tiene en este proyecto es el no tener acceso a información detallada para realizar una auditoría más a fondo puesto que el documento no especifica los detalles sin embargo cuenta con estadísticas que proporcionan datos generales.



9

CAPITULO I

INTRODUCCION A LA AUDITORIA DE TIC’S

1.1 CONCEPTOS GENERALES

Conceptos básicos necesarios para realizar una adecuada evaluación de los riesgos y

controles de la tecnología informática:

1.1.1 AUDITORIA DE SISTEMAS

Es el examen objetivo, crítico, sistemático, posterior y selectivo que se hace a la

administración informática de una organización, con el fin de emitir una opinión acerca de: • La eficiencia en la adquisición y utilización de los recursos informáticos. • La confiabilidad, la integridad, la seguridad de la información. • La efectividad de los controles en los sistemas de información. El alcance de la auditoría estará determinado de acuerdo con el objeto a auditar, el cual

está compuesto básicamente por todos los recursos informáticos (personas, equipos, aplicaciones, capacitación, etc.), la información y los controles.

1.1.2 ADMINISTRACIÓN INFORMÁTICA

Comprende la aplicación del proceso administrativo, en términos de planeación,

organización, dirección y control, expresados en hardware, software, datos, factor humano y otros recursos asociados a la automatización las actividades operativas de las organizaciones.

1.1.3 CONTROL INTERNO

El sistema de control interno es un proceso realizado por el consejo de Administración

(junta directiva o junta de directores), los administradores y demás personal de una entidad, diseñado para proporcionar seguridad razonable en la búsqueda del cumplimiento de los siguientes objetivos:

-Efectividad y Eficiencia de las Operaciones: es decir, en cuanto al cumplimiento de

los objetivos estratégicos de la organización (sean estos comerciales, sociales, de rentabilidad y financieros) y la salvaguarda o protección de sus recursos y los bienes de terceros que se encuentran en su poder de la entidad.

-Suficiencia y Confiabilidad de la Información financiera y la que se produce para uso



10

interno, así como de la preparación de los estados financieros con destino a terceros. -Cumplimiento de la Regulación: en general las disposiciones que afectan el

desarrollo institucional, tales como las leyes, normas del gobierno, los estatutos, los reglamentos, las circulares o instrucciones internas.

En otras palabras un sistema de control interno efectivo proporciona razonable

seguridad de alcanzar esos tres grandes objetivos. Ya con anterioridad se explicó por qué no brinda seguridad absoluta.

1.2 RIESGO

Es la incertidumbre de que ocurra un acontecimiento que pudiera pueda afectar el logro

de los objetivos. También se define como la posibilidad de que suceda algo que tendrá impacto en los objetivos. Se mide en términos de consecuencia y posibilidad de ocurrencia.

1.2.1 RIESGOS DE NEGOCIO RELACIONADOS CON LA INFORMÁTICA

Los principales riesgos informáticos de los negocios son los siguientes:

1. Riesgos de Integridad Abarca todos los riesgos asociados con la autorización, completitud y exactitud de la

entrada, procesamiento y reportes de las aplicaciones utilizadas en una organización. Estos riesgos aplican en cada aspecto de un sistema de soporte de procesamiento de negocio y están presentes en múltiples lugares, y en múltiples momentos en todas las partes de las aplicaciones; no obstante estos riesgos se manifiestan en los siguientes componentes de un sistema:

• Interfaz del usuario: Los riesgos en esta área generalmente se relacionan con

las restricciones, sobre las individualidades de una organización y su autorización de ejecutar funciones negocio/sistema; teniendo en cuenta sus necesidades de trabajo y una razonable segregación de funciones. Otros riesgos en esta área se relacionan concontroles que aseguren la validez y completitud de la información introducida dentro de un sistema.

• Procesamiento: Los riesgos en esta área generalmente se relacionan con el

adecuado balance de los controles de detección y preventivos que aseguran que el procesamiento de la información ha sido completado. Esta área de riesgos también abarca los riesgos asociados con la exactitud e integridad de los reportes usados para resumir resultados y tomar decisiones de negocio.

• Procesamiento de errores: Los riesgos en esta área generalmente se relacionan



11

con los métodos que aseguren que cualquier entrada/proceso de información de errores (exceptions) sean capturados adecuadamente, corregidos y reprocesados con exactitud completamente.

• Interfaz: Los riesgos en esta área generalmente se relacionan con controles

preventivos y de detección que aseguran que la información ha sido procesada y transmitida adecuadamente por las aplicaciones.

• Administración de cambios: Los riesgos en esta área pueden ser generalmente

considerados como parte de la infraestructura de riesgos y el impacto de los cambios en las aplicaciones. Estos riesgos están asociados con la administración inadecuada de procesos de cambios organizacionales que incluyen: Compromisos y entrenamiento de los usuarios a los cambios de los procesos, y la forma de comunicarlos e implementarlos.

• Información: Los riesgos en esta área pueden ser generalmente considerados

como parte de la infraestructura de las aplicaciones. Estos riesgos están asociados con la administración inadecuada de controles, incluyendo la integridad de la seguridad de la información procesada y la administración efectiva de los sistemas de bases de datos y de estructuras de datos. La integridad puede perderse por: errores de programación (buena información es procesada por programas mal construidos), procesamiento de errores (transacciones incorrectamente procesadas) o administración y procesamiento de errores (administración pobre del mantenimiento de sistemas).

2. Riesgos de relación Los riesgos de relación se refieren al uso oportuno de la información creada por una

aplicación. Estos riesgos se relacionan directamente a la información de toma de decisiones (información y datos correctos de una persona /proceso/ sistema en el tiempo preciso permiten tomar decisiones correctas).

3. Riesgos de acceso Estos riesgos se enfocan al inapropiado acceso a sistemas, datos e información.

Estos riesgos abarcan: los de segregación inapropiada de trabajo, los asociados con la integridad de la información de sistemas de bases de datos y los asociados con la confidencialidad de la información. Los riesgos de acceso pueden ocurrir en los siguientes niveles de la estructura de la seguridad de la información:

Procesos de negocio: Las decisiones organizacionales deben separar trabajo

incompatible de la organización y proveer el nivel correcto de ejecución de funciones. Aplicación: La aplicación interna de mecanismos de seguridad que provee a los

usuarios las funciones necesarias para ejecutar su trabajo. Administración de la información: El mecanismo provee a los usuarios acceso a la



12

información específica del entorno. Entorno de procesamiento: Estos riesgos en esta área están manejados por el acceso

inapropiado al entorno de programas e información. Redes: En esta área se refiere al acceso inapropiado al entorno de red y su

procesamiento. Nivel físico: Protección física de dispositivos y un apropiado acceso a ellos.

4. Riesgos de utilidad

Estos riesgos se enfocan en tres diferentes niveles de riesgo: • Los riesgos pueden ser enfrentados por el direccionamiento de sistemas antes de

que los problemas ocurran. • Técnicas de recuperación / restauración usadas para minimizar la ruptura de los

sistemas. • Backups y planes de contingencia controlan desastres en el procesamiento de la

información.

5. Riesgos en la infraestructura

Estos riesgos se refieren a que en las organizaciones no existe una estructura

información tecnológica efectiva (hardware, software, redes, personas y procesos) para soportar adecuadamente las necesidades futuras y presentes de los negocios con un costo eficiente. Estos riesgos están asociados con los procesos de la información tecnológica que definen, desarrollan, mantienen y operan un entorno de procesamiento de información y las aplicaciones asociadas (servicio al cliente, pago de cuentas, etc.). Estos riesgos se consideran en el contexto de los siguientes procesos informáticos:

Planeación organizacional: Los procesos en esta área aseguran la definición del

impacto, definición y verificación de la tecnología informática en el negocio. Además, verifica si existe una adecuada organización (gente y procesos), asegura que los esfuerzos de la tecnología informática sea exitosa.

Definición de las aplicaciones: Los procesos en esta área aseguran que las aplicaciones

satisfagan las necesidades del usuario y soporten el contexto de los procesos de negocio. Estos procesos abarcan: la determinación de comprar una aplicación ya existente o desarrollar soluciones a la medida. Estos procesos también aseguran que cualquier cambio a las aplicaciones (compradas o desarrolladas) sigue un proceso definido que confirma que los puntos críticos de proceso/control son consistentes (todos los cambios son examinados por usuarios antes de la implementación).

Administración de seguridad: Los procesos en esta área aseguran que la organización



13

está adecuadamente orientada a establecer, mantener y monitorizar un sistema interno de seguridad, que tenga políticas de administración con respecto a la integridad y confidencialidad de la información de la organización, y a la reducción de fraudes a niveles aceptables.

Operaciones de red y computacionales: Los procesos en esta área aseguran que los

sistemas de información y entornos de red están operados en un esquema seguro y protegido, y que las responsabilidades de procesamiento de información son ejecutados por personal operativo definido, medido y monitoreado. También aseguran que los sistemas son consistentes y están disponibles a los usuarios a un nivel de ejecución satisfactorio.

Administración de sistemas de bases de datos: Los procesos en esta área están

diseñados para asegurar que las bases de datos usadas para soportar aplicaciones críticas y reportes tengan consistencia de definición, correspondan con los requerimientos y reduzcan el potencial de redundancia.

Información / Negocio: Los proceso en esta área están diseñados para asegurar que

existe un plan adecuado para asegurar que la tecnología informática estará disponible a los usuarios cuando ellos la necesitan.

6. Riesgos de seguridad general Se pueden catalogar como aquellos a los que está expuesto cualquiera de los

elementos de tecnología, que se minimizan cumpliendo con los estándares proporcionados por los requisitos de diseño para lograr una seguridad general y que disminuyen el riesgo:

Riesgos de choque de eléctrico: niveles altos de voltaje. Riesgos de incendio: inflamabilidad de materiales. Riesgos de niveles inadecuados de energía eléctrica. Riesgos de radiaciones: ondas de ruido, de láser y ultrasónicas. Riesgos mecánicos: inestabilidad de las piezas eléctricas.

1.3 LA SEGURIDAD INFORMÁTICA Y SUS OBJETIVOS

La amplia utilización de los sistemas informáticos en las organizaciones, ha

incrementado la necesidad de adoptar toda serie de herramientas y procedimientos para proteger sus sistemas de información, lo que ha puesto en vigencia la importancia de la seguridad informática. El objetivo principal de la seguridad informática es proteger los recursos informáticos del daño, la alteración, el robo y la pérdida. Esto incluye los equipos, los medios de almacenamiento, el software, los listados de impresora y en general, los datos.

Una efectiva estructura de seguridad informática se basa en cuatro técnicas de

Administración de riesgos, mostradas en el siguiente diagrama:



14

1. Estrategias y políticas Estrategias de administración para seguridad informática y políticas, estándares, guías

o directivas usadas para comunicar estas estrategias a la organización.

2. Administración de la organización Procesos que se dirigen hacia políticas profesionales y programas de capacitación,

administración de cambios y control, administración de seguridad y otras actividades necesarias.

3. Monitorización de eventos Procesos reactivos que permite a la administración medir correctamente la

implementación de políticas e identificar en qué momento las políticas necesitan cambios.

4. Tecnología informática Es la tecnología necesaria para proveer la apropiada protección y soporte en los

Figura 1.1 Estructura de la seguridad informática



15

distintos procesos involucrados en la organización. La seguridad informática abarca un amplio rango de estrategias y soluciones, tales como:

Control de acceso: Una de las líneas de defensa más importantes contra los intrusos

indeseados es el control de acceso. Básicamente, el papel del control de acceso es identificar la persona que desea acceder al sistema y a sus datos, y verificar la identidad de dicha persona. La manera habitual de controlar el acceso a un sistema es restringir la entrada a cualquiera que no tenga un nombre de usuario y una contraseña válidos. Las contraseñas son un ejemplo de una forma simple pero efectiva de control de acceso.

El control de acceso es efectivo para mantener a las personas desautorizadas fuera

del sistema. Sin embargo, una vez que alguien está dentro, la persona no debería tener acceso libre a todos los programas, archivos e información existente en el sistema. El control de acceso discrecional, se realiza en muchos sistemas, y es una parte importante de cualquier acceso donde el acceso a los archivos y programas se concede en función de la clase de permisos otorgados a un usuario o un perfil de usuarios. Es discrecional en tanto que un administrador puede especificar la clase de acceso que decide dar a otros usuarios del sistema.

Virus informáticos: La prevención y control de los efectos producidos por las diferentes

clases de virus y programas destructivos que existen. Planificación y administración del sistema: Planificación, organización y administración

de los servicios relacionados con la informática , así como políticas y procedimientos para garantizar la seguridad de los recursos de la organización.

Cifrado: La encriptación y la desencriptación de la información manipulada, de forma

que sólo las personas autorizadas pueden acceder a ella. Seguridad de la red y de comunicaciones: Controlar problemas de seguridad a través

de las redes y los sistemas de telecomunicaciones. Seguridad física: Otro aspecto importante de la seguridad informática es la seguridad

física de sus servicios, equipos informáticos y medios de datos reales; para evitar problemas que pueden tener como resultado: Pérdida de la productividad, pérdida de ventaja competitiva y sabotajes intencionados. Algunos de los métodos para prevenir el acceso ilegal a los servicios informáticos incluyen:

Claves y contraseñas para permitir el acceso a los equipos. Uso de cerrojos y llaves. Fichas o tarjetas inteligentes. Dispositivos biométricos (identificación de huellas dactilares, lectores de huellas de

manos, patrones de voz, firma/escritura digital, análisis de pulsaciones y escáner de retina, entre otros).



16

1.4 PROCESO DE LA AUDITORIA DE TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACION.

La realización de la evaluación planteada en este documento, contempla las mismas fases

que sigue una auditoría de sistemas o de tecnología de información: planeación, ejecución e informe. Se plantea de esta forma para que los administradores y auditores de la tecnología, de manera objetiva, apoyados en esta herramienta, evalúen la gestión en la administración de los recursos tecnológicos.

A. PLANEACIÓN DE LA AUDITORIA

La auditoría de sistemas requiere de una adecuada planeación, con el fin de definir claramente los objetivos y el alcance del trabajo, las técnicas y herramientas a utilizar, los recursos humanos, financieros y técnicos que se emplearán, así como los plazo para realizar la evaluación (cronograma).

El objetivo de la planeación es el de proveer al auditor de un conocimiento general de

los procesos sistematizados de la organización, una evaluación preliminar de las fortalezas y debilidades y una lista de materias relacionadas con el área que sean de potencial importancia para ser examinadas en la fase de ejecución.

La fase de planeación básicamente comprende: • Conocimiento general de la empresa • Conocimiento del área de informática • Programa de trabajo

1. Conocimiento general de la empresa Esta etapa permite conocer y estudiar en forma general la entidad y el desarrollo

tecnológico en el área de informática, para lo cual es necesario obtener información relacionada con la organización que a criterio del auditor sea suficiente para conocer sus objetivos, reglamentos, normas, funciones, los sistemas de información automatizados, la arquitectura de red, las aplicaciones existentes, etc.

La evaluación de este punto, como parte de la administración de la empresa, permite

concluir si se cuenta con documentación actualizada que de manera rápida y precisa permita presentar la entidad a personas que se vinculen y a entidades que deseen conocerla, ya sea para establecer relaciones comerciales o para ejercer vigilancia y control en el caso de las Super intendencias y los mismos auditores. ¿Qué tanto conocemos nuestra entidad?

2. Conocimiento del área de Informática Este conocimiento se enfoca a determinar qué tan adecuadamente se tiene

documentada la información del área Informática como del sistema de información,



17

verificando si tienen identificadas las debilidades y fortalezas, como todas las relaciones del área con el entorno.

Para planear la evaluación de manera efectiva, se debe determinar la documentación

con que se cuenta, calificando su actualización y vigencia.sobre los siguientes aspectos: • Organización: organigrama donde se ubique el área de tecnología dentro de la

organización y el detalle de su estructura, con número de personas por unidad y, en lo posible, los nombres de los colaboradores que pertenecen a cada una de ellas, su perfil técnico, funciones, persona a cargo (si las tiene) y responsabilidades.

• Procedimientos técnicos y administrativos. • Políticas de seguridad, compras, administración de recursos, capacitación y

contratación. • Distribución física de los equipos, sistemas de seguridad y áreas usuarias. • Inventario informático, costos de los recursos informáticos y demás información

que se considere relevante para el área. Se espera que terminada la evaluación, la información que detalla cada uno de los

aspectos que involucran la tecnología informática de la empresa, estará actualizada y totalmente documentada. El grado de documentación dependerá de la complejidad y alcance que se defina tener en cada empresa.

3. Memorando de Planeación Los programas que se expresan como planes de trabajo y conforman el memorando

de planeación, contienen, cuando menos, lo siguiente: la definición de las actividades o aspectos a cubrir en la fase de ejecución, las cuales se determinan de acuerdo con las debilidades que se identifican durante de las dos etapas anteriores, priorizando aquellos aspectos que se observen de mayor riesgo, de bajo control y que estén soportando los procesos críticos. No obstante y con el apoyo de las listas de chequeo generales, se podrían identificar aspectos que a primera vista se consideren adecuadamente administrados y controlados, pudieran no estarlo tanto y hacer que se reenfoque el trabajo planeado y su alcance. La disposición de tiempo, modo y lugar de los recursos necesarios y su justificación para llevar a cabo la auditoría.

B. EJECUCIÓN Esta fase consiste en ejecutar los programas de trabajo establecidos en el memorando

de planeación, mediante: • La evaluación del sistema de control interno del área de informática (incluye la

seguridad informática). • La evaluación de la gestión de la entidad en la administración de los recursos de

tecnológicos de información. • La realización de pruebas para tener un concepto objetivo del estado actual del

sistema de control interno de la empresa.



18

C. INFORME Resultado de la evaluación, se debe preparar un informe el cual, además de ser claro,

preciso, conciso, veraz, objetivo y de presentar hechos reales debidamente sustentados, debe dar las pautas para un plan de mejoramiento de los controles y seguridades establecidas dentro del sistema de información. Sirve además para fortalecer la administración de la tecnología informática, se constituyen en otra herramienta para soportar las inversiones necesarias en tecnología ante la alta gerencia y afrontar de manera satisfactoria las auditorias que se realicen al área de tecnología.

1.4.1 EVALUACIÓN DEL SISTEMA DE CONTROL INTERNO (COBIT)

Se debe identificar y evaluar que los controles implementados permitan prevenir y

detectar oportunamente los acontecimientos que impidan el cabal cumplimiento de las políticas, procedimientos, planes, y objetivos de la entidad y que tengan directa relación con la información tecnológica y de sistemas.

Se debe evaluar si el control cumple con los principios de: • Efectividad: Se refiere a que la información relevante sea pertinente para el

proceso de la auditoria, así como que su entrega sea oportuna, correcta, consistente y de manera utilizable.

• Eficiencia: Se refiere a la provisión de información a través del óptimo (más

productivo y económico) uso de los recursos. • Confidencialidad: Relativa a la protección de la información sensitiva de su

revelación no autorizada. • Integridad: Se refiere a la exactitud y suficiencia de la información, así como su

validez, en concordancia con los valores y expectativas de la entidad. • Disponibilidad: Se refiere a que la información debe estar disponible cuando

sea requerida por los procesos de la entidad ahora y en el futuro. Involucra la salvaguarda de los recursos y sus capacidades asociadas.

• Cumplimiento: Se refiere a cumplir con las leyes, regulaciones y acuerdos

contractuales, a los que están sujetos los procesos de la entidad. • Confiabilidad: Se refiere a la provisión de la información apropiada a la alta

gerencia, para operar la entidad, tomar decisiones y evaluar la gestión realizada. • Planeación: Que las decisiones tomadas sobre la adquisición e implantación

de recursos informáticos obedezca a las políticas de la entidad y se encuentren enmarcados



19

dentro de un plan estratégico. Los recursos deben ser evaluados en el cumplimiento de los anteriores principios se

han identificado como: • Datos: Los elementos de datos internos, externos, estructurados, no

estructurados, gráficos, sonidos, etc. • Aplicaciones: Es la suma de procedimientos manuales y programados. • Tecnología: Cubre hardware, software, sistemas operativos, sistemas de

administración de base de datos, redes, multimedia, etc. • Instalaciones: Recursos para alojar y dar soporte a los sistemas de información. • Personal: Habilidades del personal, conocimientos, conciencia y productividad

para planear, organizar, adquirir, entregar, soportar, y monitorear servicios y sistemas de información.

Una vez finalizada la fase de evaluación del Sistema de Control Interno, se revisa el

memorando de planeación, de manera que puedan incluirse ajustes a las siguientes fases de la ejecución de la auditoría, de ser necesario para incluir otras áreas críticas identificadas.

Las áreas de influencia (dominios) a tener en cuenta en el proceso de evaluación son: • Planeación y Organización: Se deben evaluar los controles existentes para la

ejecución del plan estratégico, la arquitectura de la información, administración de los sistemas de información, dirección y administración del área de sistemas, administración de proyectos, administración del recurso humano.

• Adquisición e implementación: Se refiere a aquellos procedimientos

implementados por la entidad para hacer más efectiva, eficiente y económica la adquisición de recursos tecnológicos de sistemas.

Se deben identificar los controles existentes para los contratos de adquisición de

software (aplicaciones, licencias, sistemas operativos, correo electrónico, Internet, etc.), y hardware (equipos, redes, etc).

• Entrega de servicios y soporte: Se evalúan los controles que tiene la entidad

para garantizar que se cumpla con el objeto de los contratos de outsourcing (tercerización) y servicios prestados.

Se evalúan los programas de capacitación de los usuarios, la atención a los usuarios, la

administración de la configuración, de los datos, de las instalaciones, operaciones.



20

Monitoreo: Se refiere a la evaluación de los procedimientos implementados para hacer un seguimiento y una auditoría interna de todos los procesos relacionados con la informática, bien sea día a día o en forma periódica para verificar su efectividad. Igualmente a los procedimientos que se han incorporado a los sistemas de información tecnológica para hacer un seguimiento de las actividades realizadas por los usuarios.

Los controles pueden estar incluidos, de un modo intrínseco, en las actividades

recurrentes de una entidad o consistir en una evaluación periódica independiente, llevada a cabo normalmente por la dirección. La frecuencia de estas evaluaciones depende del juicio de la dirección. Mediante estos controles podremos detectar errores significativos y realizar un control continuo de la fiabilidad y de la eficacia de los procesos informáticos.

Documentación: La Entidad debe tener políticas claras y por escrito sobre la

documentación del área de sistemas y el plan estratégico de sistemas de información. Los sistemas de aplicación, los programas del sistema operativo, los equipos de cómputo, las redes de datos, los periféricos, las funciones y responsabilidades, la operación del centro de cómputo, las decisiones de cambios de equipos y aplicaciones, los estándares para el diseño y desarrollo, entre otras, deben estar suficientemente documentadas para la comprensión completa y exacta de las actividades de sistemas de información automatizados y su impacto en los usuarios.

1.4.2 EVALUACIÓN DE LAS POLÍTICAS DE SEGURIDAD INFORMÁTICA (ISO 17 799 )

Como complemento de la evaluación del control interno y como un punto de referencia,

se debe tener en cuenta durante la evaluación a realizar, las diez áreas de control propuestas por la norma internacional ISO 17799, a efecto de diagnosticar el sistema de seguridad frente a los estándares aceptados internacionalmente, si en algún momento se quisiera certificar el aspecto de seguridad

• Política de seguridad: Se necesita una política que refleje las expectativas de

la organización en materia de seguridad con el fin de suministrar administración con dirección y soporte, la cual también se puede utilizar como base para el estudio y evaluación en curso.

• Organización de la seguridad: Sugiere diseñar una estructura de administración que establezca la responsabilidad de los grupos en ciertas áreas de la seguridad y un proceso para el manejo de respuesta a incidentes.

• Control y clasificación de los recursos de información: Necesita un

inventario de los recursos de información de la organización y con base en este conocimiento, asegurar que se brinde un nivel adecuado de protección.

• Seguridad del personal: Establece la necesidad de educar e informar a los

empleados actuales y potenciales sobre lo que se espera de ellos en materia de seguridad y



21

asuntos de confidencialidad. También determina cómo incide el papel que desempeñan los empleados en materia de seguridad en el funcionamiento general. Se debe implementar un plan para reportar los incidentes.

Seguridad física y ambiental: Responde a la necesidad de proteger las áreas, el equipo

y los controles generales. Manejo de las comunicaciones y las operaciones: Los objetivos de esta sección son:

• Asegurar el funcionamiento correcto y seguro de las instalaciones de procesamiento de la información.

• Minimizar el riesgo de falla de los sistemas.

• Proteger la integridad del software y la información.

• Conservar la integridad y disponibilidad del procesamiento y la comunicación de la información.

• Garantizar la protección de la información en las redes y de la infraestructura de soporte.

• Evitar daños a los recursos de información e interrupciones en las actividades de la compañía.

• Evitar la pérdida, modificación o uso indebido de la información que intercambian las organizaciones.

Control de acceso: Establece la importancia de monitorear y controlar el acceso a la

red y los recursos de aplicación para proteger contra los abusos internos e intrusos externos. Desarrollo y mantenimiento de los sistemas: Recuerda que en toda labor de la

tecnología de la información, se debe implementar y mantener la seguridad mediante el uso de controles de seguridad en todas las etapas del proceso.

Manejo de la continuidad de la empresa: Aconseja estar preparado para

contrarrestar las interrupciones en las actividades de la empresa y para proteger los procesos importantes, en caso de una falla grave o desastre.

Cumplimiento: Imparte instrucciones para que se verifique si el cumplimiento con la

norma técnica ISO 17799 concuerda con otros requisitos jurídicos. Esta sección también requiere una revisión a las políticas de seguridad, al cumplimiento y consideraciones técnicas que se deben hacer en relación con el proceso de auditoría del sistema a fin de garantizar que las empresas obtengan el máximo beneficio.



22

1.5 TÉCNICAS DE AUDITORIA DE TECNOLOGÍA DE INFORMACIÓN

Los procedimientos en auditoría requieren de técnicas que ayuden a establecer la

eficiencia en la adquisición y utilización de los recursos informáticos, la consistencia, integridad y oportunidad de la información y la efectividad de los controles.

Las pruebas de auditoría constituyen la base con que el auditor obtiene evidencias adecuadas que le permiten estructurar los hallazgos, los cuales fundamentan las conclusiones de la ejecución de la auditoría. Los hallazgos, sin descartar otros aspectos, son las debilidades u oportunidades de mejoramiento, que se deben tomar en cuenta para fortalecer el sistema de control interno.

Las pruebas que se pueden realizar sobre los sistemas son pruebas sustantivas y

pruebas de cumplimiento, tal como se define a continuación:

1.5.1 PRUEBAS DE CUMPLIMIENTO

Se usan para determinar si un procedimiento de control, previamente establecido, está funcionando efectivamente, y consisten en verificar:

• La aplicación de leyes o reglamentos y de los procedimientos establecidos en los

manuales y que éstos se encuentren actualizados. • El conocimiento por parte del personal, de los manuales y de las políticas del

ambiente informático. • La existencia del plan estratégico de sistemas, informes o memorandos preparados

por el Departamento de Informática. • Si han sido implantadas las recomendaciones emitidas por auditorias anteriores.

1.5.2 PRUEBAS SUSTANTIVAS

Se usan para determinar que existe una seguridad razonable sobre la validez de la

información producida. El desarrollo de las pruebas es logrado mediante la aplicación de una o varias técnicas de auditoría, ya sea simultánea o sucesivamente, tales como:

• Analizar registros.

• Hacer operaciones.

• Comparar archivos.

• Estratificar archivos.

• Seleccionar una muestra aleatoria.

• Resumir información.

• Generar reportes.

• Construir archivos de prueba.

• Extraer información de un archivo.



23

• Realizar análisis estadísticos.

• Simular parte del sistema o el sistema completo.

1.6 TÉCNICAS DE AUDITORIA ASISTIDAS POR COMPUTADOR

Unas de las herramientas más útiles para adelantar pruebas de cumplimiento y

sustantivas, son las que se conocen como técnicas de auditoría asistidas por computador (TAAC), las cuales se orientan hacia los datos, las aplicaciones, los equipos y programas, y permiten seleccionar y procesar la información necesaria para fines específicos de la auditoría, facilitando la aplicación de métodos de muestreo estadístico, aumentar el alcance de las pruebas y verificar la integridad de los datos en la población auditada.

Las TAAC sirven para:

• probar controles en aplicaciones,

• seleccionar y monitorear transacciones,

• verificar datos,

• analizar programas de las aplicaciones,

• auditar centros de procesamiento de información

• auditar el desarrollo de aplicaciones.

1. Para probar controles en aplicaciones Utilizadas para evaluar los controles en aplicaciones sistematizadas y para probar el

cumplimiento de los controles existentes en las aplicaciones, a saber: Evaluación del caso base: Elaborar archivo de prueba y verificar la exactitud de los

procesos. Se realiza la prueba en todo el ciclo del sistema. Operación paralela: Busca verificar el buen desempeño de nuevas aplicaciones,

identificar resultados no esperados, comparar lo antiguo con lo nuevo operando conjuntamente. Prueba integrada: Esta técnica implica tener, como mínimo, la misma capacidad

tecnológica en la cual está la aplicación en producción. Se deben procesar archivos de prueba en aplicaciones en producción y comparar los resultados reales versus los esperados.

Simulación paralela: Codificar rutinas que simulen la lógica del programa real, se debe considerar el porcentaje de error en los resultados de la simulación. Se emplea generalmente software generalizado de auditoría y programas a la medida.

2. Para auditar centros de procesamiento de información

Se debe hacer un análisis de datos, verificar si existe un plan de contingencia y si existen las suficientes medidas de seguridad para salvaguardar y proteger los recursos tecnológicos de informática.



24

Para realizar la evaluación del sistema de información tecnológica se propone hacerlo mediante la utilización de las listas de chequeo anexas al presente documento, las cuales se han desarrollado teniendo en cuenta los tipos de control. Se aclara que estas listas de chequeo son generales, no son excluyentes, ni exhaustivas; por tanto, se deben considerar como una guía en el proceso de evaluación y la profundidad de la evaluación dependerá de la complejidad de la tecnología utilizada por cada auditoria, lo que conduciría a depurarlas y actualizarlas, en caso de que se utilicen de manera periódica, de tal forma que nunca pierdan vigencia.

1.7 INDICADORES DE GESTIÓN

"Lo que no es medible no es gerenciable, ya que el control se ejerce a través de hechos y

datos”. Partiendo de la premisa anterior, es necesario identificar de qué manera se está

midiendo la gestión de informática dentro de la auditoria. Es por esto que en este punto ponemos a su consideración el uso de esta herramienta de administración, que tiene entre otras las siguientes funciones:

• Permiten la realización de una evaluación del impacto de la gestión realizada.Son utilizados para comparar un plan establecido contra unos valores reales.

• Seguimiento y rendimiento de cuentas. • Sirven como instrumento de regulación, como base para toma de decisiones,

transferencias presupuéstales y políticas. Ejemplos: A continuación se enuncian algunos de los indicadores de gestión que se

pueden implementar en el área de tecnología:

NOMBRE CALCULO RESULTADO

Eficacia en la gestión

No. actividades desarrolladas

No. Actividades planeadas

(pesi)

Evaluar el cumplimiento del

Plan Estratégico de Sistemas

(pesi

Efectividad de documentación

Aplicativos

No. aplicativos documentados

Total aplicativos

Identifica si existe una

adecuada documentación

Cubrimiento No. puntos de red

No. equipos

Cubrimiento de la red

Eficiencia de los

recursos tecnológicos

No de computadores en uso

Total de computadores

Verifica la productividad de

los equipos. Se mide

teniendo en cuenta los

aplicativos existentes



25

NOMBRE CALCULO RESULTADO

Eficiencia en la distribución del

recurso tecnológico

No. Computadores

No. funcionarios que necesitan

computador

Verifica la adecuada

distribución de los recursos

Legalidad No de licencias adquiridas

No de aplicativos instalados

Verifica que el

software

Legalidad No. de licencias por software

No equipos en que está

instalado

Se puede establecer si el

software está debidamente

licenciado

Capacitación No. de usuarios capacitados

Total de usuarios

Determina la efectividad en la

capacitación

Conectividad de recursos

compartidos

No. Puntos de red x 100

No. computadores instalado

cuente con la licencia

Determina el porcentaje de

cubrimiento de las redes de

datos

Tabla 1.1Indicadores de Gestión

1.8 AUDITORIA A LAS APLICACIONES

1.8.1 POLÍTICAS Y PROCEDIMIENTOS

Revisión de los manuales y procedimientos que documentan la aplicación. Entrevistas a los usuarios y al personal de sistemas usando los diagramas de flujo de

datos para documentar las operaciones que se describan.

1.8.2 ESTÁNDARES DE DESARROLLO Y PRODUCCIÓN

Evaluación del procedimiento de actualización de los estándares. Verificar que los mantenimientos efectuados a la aplicación se ajusten a los estándares de desarrollo.

Revisar el cumplimiento de las políticas de backups. Comparación de la descripción de archivos, campos y programas con los que

recomienda el estándar. Revisar la bitácora de operación, verificando que todos los procesos que se corren

queden registrados. Verificar que los procesos de almacenamiento y restauración de datos cumplen con los

estándares de producción. Verificar que la codificación de la aplicación se ajusta al estándar de procedimientos

y comandos de producción.

1.8.3 DATOS DE ENTRADA

Revisar los documentos fuente que utilice el paquete verificando su consistencia e



26

integridad en la información. Aspectos a revisar como los siguientes: 1. Legibilidad de la información. 2. Manejo de errores en el documento fuente. 3. Políticas de retención de los documentos. 4. Control de los documentos confidenciales. 5. Almacenamiento de los documentos no diligenciados. 6. Sistema de control sobre documento digitado. 7. Sistema de control de lotes o grupos de documentos procesados. 8. Conservación del consecutivo del documento. 9. Verificar separación de funciones entre quien prepara el documento fuente y quien lo

captura en el sistema.

1.8.4 PROCEDIMIENTOS DE CAPTURA

Verificar la validación de los datos que son capturados, mediante pruebas en línea y en ambientes paralelos a los programas respectivos.

Examinar la metodología de corrección de errores que tienen los programas en su codificación interna.

Revisar los procedimientos de manejo de errores que son descubiertos durante la captura.

1.8.5 PROCEDIMIENTO Y ACTUALIZACIÓN DE INFORMACIÓN

Ejecución de pruebas a los programas correspondientes a la aplicación. Suministro de datos reales y de prueba, verificando a la salida (informes o reportes por

pantalla y listados) la consistencia de la información. Revisión analítica de los programas fuente para los programas más críticos. Verificar la acción de las cifras de control en los programas y procesos que las posean. Verificar la consistencia de los campos descritos en los archivos con la información que

debe ser almacenada en ellos. Observar el método de actualización que evidencian los archivos. Analizar los cambios y mantenimientos a los programas verificando las debidas

autorizaciones.

1.8.6 INFORMES DE COMPUTADOR

Revisar la estructura de los informes de computador utilizando la matriz de análisis. Analizar el origen y destino final de los informes. Evaluar el sistema de archivo y retención de los informes de computador. Analizar los

procedimientos de manejo de error en los listados. Verificar el borrado de los archivos magnéticos de impresión luego de ser listados.

Evaluar la información de salida a la luz del sistema de información requerido por la gerencia.

1.8.7 DOCUMENTACIÓN

Revisar las carpetas fuente de los programas seleccionados a fin de determinar la



27

documentación correspondiente a los estándares de desarrollo. Evaluar la existencia de manuales de sistemas, técnicos y de usuario de la aplicación. Analizar la documentación que soporta las modificaciones que evidencian los

programas.

1.8.8 SEGURIDAD

Evaluar el sistema de seguridad lógico a través del archivo de seguridad y los archivos de usuarios con privilegios.

Analizar el período de modificación de los password propios de la aplicación. Verificación en el log del sistema de los accesos que observan los programas y archivos

más críticos.

1.8.9 PROCEDIMIENTOS DE RESPALDO

Evaluar el plan de contingencias de la aplicación y el conocimiento de la misma por parte de los usuarios.

Evaluar el sistema de backups utilizado para los archivos de datos.

1.8.10 CAPACITACIÓN Y SOPORTE A USUARIOS

Verificar el conocimiento que tienen los usuarios del manejo de los módulos propios de la aplicación.

Revisar los procedimientos de capacitación que son utilizados para la instrucción de los usuarios.

Analizar la respuesta que tienen los usuarios a sus problemas tanto de hardware como de programas.

1.9 AUDITORIA AL CENTRO DE CÓMPUTO

1.9.1 PREGUNTAS CLAVES.

Procedimientos escritos que se manejan.Manuales por aplicación (sistemas y operación)

Red instalada en la Empresa. Número de servidores. Ubicación de los servidores. Número de terminales conectadas. Número de usuarios conectados al servidor. Configuración de memoria y discos de los servidores. Protocolos instalados y servicios. Volumen de producción mensual de registros de cada aplicación. Interfases que

manejan. Reciben y/o envían archivos a entidades externas. Principales proveedores de

tecnología. Sistemas de seguridad electrónica instalados Actualmente se tiene auditoría de

sistemas. Planes de contingencia para el área de informática. Proyectos futuros.



28

1.9.2 CUIDADO DE LAS INSTALACIONES

Ubicación Del centro de cómputo. Techos, maquinarias especiales. Tipo de estantería. Ubicación de la luz. Existe un procedimiento claro de limpieza y aseo para los computadores y el centro de cómputo? Electricidad Hay corriente regulada identificada? Tienen reguladores de voltaje?. Existen pruebas funcionamiento de la UPS. Las fases deben estar balanceadas?. Existe plano eléctrico de la Empresa? (preferiblemente en medio magnético). Se hace revisión periódica de los circuitos eléctricos? Se cuenta con planta eléctrica?. Se tienen procedimientos claros para su uso y mantenimiento? Aire Acondicionado Hay sistema de aire acondicionado?. Verificar si es independiente al de las personas. Hay sistema de reserva energética para el aire acondicionado? Es suficiente para el área del centro de computo? Controla la humedad del aire? Se tiene sistema redundante de aire acondicionado? Protección contra incendios Tienen sistema de protección contra incendios?. Revisar si es manual o automático. Se hizo capacitación al personal del área para el manejo de los extintores y se ha

probado. Qué tipo de sustancias tienen los extintores. Procedimientos de emergencia. Existen normas o actividades ante un desastre?. Existen estrategias para la

evacuación?. Seguros Revisar el sitio de ubicación del bien. Evaluar los procedimientos para el manejo de los seguros. Revisar el inventario de equipos de cómputo de la empresa y a la aseguradora. Hardware Tienen seguros todos los computadores?. Se aseguran las cintas y otros dispositivos para almacenamiento?. Verificar los amparos a los computadores? Software Se aseguran las patentes ó licencias?. Hay seguro para horas hombre en recuperación de la información? Pólizas de manejo.



29

Hay pólizas de manejo. Cual es su cobertura? Quienes están incluidos?

1.9.3 OPERACIÓN DE LOS SERVIDORES

Registro o de operaciones. Evaluar el manejo de bitácoras manuales en el centro de cómputo. Hay registro automático?. Cada cuánto se realizan y que acciones se toman? Quién las revisa? Procedimientos del operador. Tienen manual de funciones?. Sus actividades están basadas en normas claras. Hay procedimientos para: Prender el Servidor. Apagar el Servidor. Otorgar permisos en el sistema Programación de actividades. Son programadas las actividades del operador?. Manejan cronogramas, planes de trabajo y/o acuerdos de servicio?. Mantenimiento de archivos maestros. Chequeo y/o revisión de las tablas principales del sistema contable y las aplicaciones de misión crítica. Evaluar la frecuencia de depuración de los archivos maestros. Revisar los procedimientos de depuración de archivos maestros.

1.9.4 CONTROL DE ENTRADAS Y SALIDAS.

Entradas A qué horas y en que fecha se reciben? Qué control hay sobre el documento que se recibe? Salidas Existen hoja de ruta de los informes? Se comparan los informes contra los documentos de entrada? Reconciliación de salidas. Con qué frecuencia de realizan contra documentos de terceros?.

1.9.5 SEGURIDAD EN INSTALACIONES.



30

Administración general de la seguridad Evaluar los criterios de seguridad que tiene el área de informática. Revisar los sistemas de vigilancia. Observar las garantías de seguridad del sitio donde está ubicado el centro de cómputo. Seguridad Externa Evaluar los controles de acceso automático. Seguridad Interna Son independientes las áreas de trabajo?. Los computadores están ubicados en sitios seguros?. Se protegen los equipos con cobertores plásticos? Hay canaletas, iluminación y ergonomía en el área?.

1.9.6 ORGANIZACIÓN Y PERSONAL

Organización y personal. Evaluar criterios de administración. Revisar los períodos vacacionales. Hay rotación de analistas en su cargo? Cuáles son las estrategias de promoción?. Revisar los parámetros de ascenso establecidos. Segregación de funciones. Se detecta concentración de funciones en algún empleado? Evaluar los criterios del área para difundir o multiplicar conocimientos. La capacitación esta relacionada con los proyectos del área?.

1.9.7 PLANES DE CONTINGENCIA.

Creación del Plan Existen planes de contingencias?. Están documentados?. Verificar el personal que participa en la definición del plan de contingencias. Tópicos Hardware Equipo de soporte. Acuerdos con otras compañías. Acuerdos con los proveedores. Dispositivos claves. Software Procedimientos manuales que garanticen la continuidad del servicio. Personal Existe matriz de sustitutos - Quien reemplaza a quien? Difusión del plan. Planes de difusión y entrenamiento. Pruebas de simulación.



31

1.10 POLÍTICAS PARA LA ADMINISTRACIÓN DE LOS RECURSOS TECNOLÓGICOS

Las políticas son la base fundamental de todo esfuerzo enfocado a la seguridad de la

información. Con el fin de ser efectivo, el proceso para fortalecer la seguridad de la información debe tener un conjunto de políticas que brinden instrucciones claras y establezcan el soporte de la alta gerencia. Las políticas son usadas como punto de referencia para un sinnúmero de actividades relacionadas con la seguridad de la información tales como: Diseño de controles en los sistemas de información, controles de acceso, análisis de riesgos, investigaciones de crímenes por computadora, y sanciones disciplinarias de funcionarios por violaciones en la seguridad.

Como las políticas de seguridad tienen un impacto muy alto en la organización, es muy

importante que estas sean claras, concisas y que respondan al ambiente donde se pretenden implementar. Las políticas deben ser revisadas periódicamente para asegurar su aplicabilidad en la organización. El propósito de esta directriz es asesorar a los funcionarios que están desarrollando las políticas por primera vez o revisándolas.

A continuación se ofrece una guía práctica y puntual al complejo proceso de desarrollar

políticas de seguridad en informática. Nota: Entre otras cosas dentro de este proceso se debe obtener la aprobación de la

alta gerencia, divulgarlas y generar controles que permitan hacer seguimiento a su efectividad y aplicación.

1.11 ASPECTOS A TENER EN CUENTA

1.11.1. ORGANIZACIÓN

Políticas: • Debe existir un comité de sistemas (informática), conformado por funcionarios de áreas de administración, que será el encargado de avalar los requerimientos de hardware o software • Se debe asignar presupuesto por área, para todo lo que tiene que ver con recursos

de informática. Compras, cambios o eliminaciones de elementos de software o hardware. Políticas: • El comité de sistemas será el encargado de la administración de recursos de

hardware y software. • Todo requerimiento de hardware o software debe pasar a estudio por el comité de

sistemas. • Toda compra de hardware o software debe estar soportada por lo menos de tres (3) cotizaciones, bajo los mismos términos de referencia.



32

• Toda eliminación de recursos de informática, debe ser reportada por el director de área y pasar a comité de sistemas.

• Toda compra debe estar soportada por pólizas de cumplimiento. • Todo elemento de software o hardware debe tener contrato de mantenimiento. Las justificaciones de nuevas adquisiciones. Políticas: • Todo requerimiento de hardware o software debe tener adjunto, los términos de

referencia a evaluar. • Se debe contar con el presupuesto asignado para recursos de informática. Alternativas manuales que garanticen normal desempeño. Políticas: • Debe existir plan de capacitación a funcionarios del área de informática. • Deben existir manuales de procedimientos para cada proceso • Debe existir manual de operación para cada uno de los aplicativos de la

compañía. • Se debe contar con formatos prenumerados que garanticen el desarrollo manual

de cualquier actividad. • Se deben realizar inventarios generales de elementos de hardware y software de

manera periódica. Difusión de políticas. Políticas: • El documento que contiene la política de seguridad debe ser difundido a todo el

personal • Toda política debe seguir un proceso de actualización y seguimiento. Respaldo técnico y garantía tecnológica. Políticas: • Todo contrato, ya sea de adquisición o mantenimiento de elementos de

informática, se debe llevar a cabo con compañías debidamente legalizadas. • Se debe contar con cronograma de mantenimiento a dispositivos de la red. • Se debe contar con plan de copias de seguridad (backups). • Todo software o hardware debe contar con sus respectivos manuales técnicos. La capacitación y entrenamiento a usuarios de computadores. Políticas: • Se debe contar con plan de capacitación en nuevas tecnologías a funcionarios

de sistemas. • Se debe contar con planes de capacitación a nuevas versiones del software

instalado • Se debe contar por lo menos con un Help Desk dentro de la compañía. • Toda capacitación patrocinada debe ser retroalimentada a las áreas que lo ameriten.



33

1.11.2 SOFTWARE

Propiedad Intelectual Políticas: . • El departamento de informática es el responsable de realizar revisiones periódicas a

los equipos para que solo exista software licenciado en las instalaciones de la compañía. • Corresponde a la dirección de informática autorizar cualquier compra o actualización

del software. • Todo software de dominio público vendrá de sitios seguros. Desarrollo de software de acuerdo a la metodología de desarrollo existente. Políticas: • El área de informática emitirá las normas y procedimientos para instalación de software

básico en todo tipo de equipo. • El área de informática será la responsable de brindar asesoría y supervisión para la

instalación de nuevo software. • Todo software que desde el punto de vista del área de informática coloque en riesgo los

recursos de la compañía no es permitido. Desarrollos de sistemas soportados en micros y su documentación. Políticas: • Todo procedimiento que en buen uso de la información se desarrolle bajo software

ofimático debe estar debidamente documentado. • Es responsabilidad de cada área informar al departamento de informática sobre rutinas o

desarrollos que se generen en el área. • Se deben respetar los derechos de autor para cada desarrollo en particular que ayude al

normal funcionamiento de sus labores. Revisión de Auditoría Políticas: • El área de auditoría debe ser la responsable de dar cabal cumplimiento a cada una de

las políticas establecidas. • El comité de sistemas debe contar con la participación activa de un funcionario de

auditoría. • Se deberá dar cumplimiento a cada uno de los requerimientos que plantee la

auditoría.

1.11.3 HARDWARE

Políticas: • Criterios de compatibilidad con la base instalada de equipos de la CAC. • Compartir al máximo los recursos, definiendo restricciones de seguridad. • Inventario periódico. • Cambios de localización, apertura y mantenimiento de equipos. • Uso de equipos especiales.



34

• Solicitud de disquetes, cintas, CD o medios afines.

1.11.4 USUARIO

Políticas: • Toda solicitud de programas o equipos de acuerdo con los procedimientos de

compras de la empresa. • Responsabilidad de la correcta administración de la información que utilice,

previendo las acciones de seguridad y confidencialidad. • Identificador individual de acceso. • Espacio en disco duro del servidor. Invasión de áreas de disco asignadas a otros

usuarios. • Área del disco servidor destinada para el sistema operacional, programas de

aplicación o utilitarios. • Prohibición al uso de cualquier tipo de software que no esté autorizado

1.11.5 ÁREA DE SISTEMAS

Políticas: • Atención a usuarios de manera continua y segura. • Continuidad en el procesamiento y la reducción de tiempos. • Espacio en disco necesario para almacenamiento de datos. • Garantizar la permanencia fiel de los datos que residan en discos del servidor.

1.12 AUDITORIA A LOS EQUIPOS DE CÓMPUTO Y REDES LAN

Se relacionan a continuación algunas preguntas que son pertinentes al momento

auditar una red de computadores. Se evalúan los siguientes aspectos: 1. Políticas administrativas. 2. Adquisición de hardware. 3. Adquisición y desarrollo de software. 4. Documentación. 5. Comunicaciones. 6. Entrenamiento y soporte a usuarios. 7. Mantenimiento. 8. Seguros. 9. Seguridad. 10. Procedimientos de respaldo.

1.12.1 PRUEBAS A REALIZAR POR CADA ASPECTO

1. POLÍTICAS ADMINISTRATIVAS: • Verificar la existencia de políticas administrativas escritas para: Adquisición equipos de computo. Uso de microcomputadores. Verificar si se mantiene una lista actualizada de todos los usuarios de



35

microcomputadores. Verificar la existencia de un grupo de trabajo o comité para coordinar los proyectos desarrollados en micros. • Evaluar los medios de difusión periódica de nuevos desarrollos. 2. ADQUISICIÓN DE HARDWARE • Verificar la existencia o respaldo, con análisis de costo-beneficio, de las solicitudes

de compra de equipos por parte del usuario. • Evaluar la documentación existente para el hardware. • Se hace una planeación del sitio en que se instalaron los equipos para garantizar: Protección antimagnética. Servicio eléctrico regulado. Conexión a la red. Seguridad física. • Evaluar la memoria RAM del servidor, frente al número de usuarios que posee. • Evaluar la capacidad del disco duro del servidor, con relación al número de usuarios. • Revisar el registro de uso de microcomputadores para cada área usuaria. 3. ADQUISICIÓN DE SOFTWARE • Verificar la existencia de políticas para uso y adquisición de software. • Obtener una lista de las versiones de paquetes en uso, en los diferentes micros. Verificar que sean copias originales y licenciadas por la CAC • Verificar la existencia de alternativas manuales, para llevar a cabo las tareas que actualmente se procesan en micros. • Revisión de archivos en el disco del servidor. • Verificar la existencia de un plan general sobre los desarrollos propuestos por los usuarios. 4. DOCUMENTACIÓN • Verificar la existencia de un catálogo actualizado del software aplicativo, desarrollado y adquirido. • Verificar la existencia de una metodología de desarrollo para micros. • Evaluar la documentación requerida para aplicaciones desarrolladas en microcomputadores. 5. COMUNICACIONES Tomando como base los 7 niveles del modelo OSI. Nivel 1. Físico • Evaluar el plano de la red, con base en los siguientes aspectos: Dispositivos adjuntos. Diagramas del cableado. Documentación. Actualización. • Verificar la existencia de procedimientos para mantenimiento periódico. • Analizar el soporte de proveedores alternos, si el proveedor falla. • Verificar la existencia de procedimientos para recuperación de fallas.



36

Nivel 2: De enlace de datos • Verificar si existe un monitoreo de transmisiones y determinar si: Es continuo o esporádico. Existen tasas de estadísticas de errores. Se investigan altas tasas de error. Nivel 3: De redes • Verificar las estrategias para monitoreo de las tasas de tráfico de la red. Verificar la existencia de tablas de ruta de la red. Efectuar revisión a estadísticas de tráfico. Verificar el aprovechamiento de las herramientas que provee el sistema operativo: Ejemplo en Windows 2000 - Monitor de eventos - EventViewer Manejo de su tamaño, copias. - Monitor del sistema - Programas, procesos y desempeño. -Optimización del desempeño. Uso de contadores de uso de memoria, procesador. - Uso de alertas. - Manejo de espacio en disco. - Servicios instalados del servidor. Verificar la conectividad a Internet en cuanto a: - Controles de acceso a Internet. - Firewall - Proxy - DNS - DHCP Uso de correo electrónico, administración del servicio, definición de usuarios etc, tamaños de adjuntos. Administración del Antivirus Nivel 4: De transporte • Establecer los actuales procedimientos para iniciar la red después de: Instalación inicial. Falla o modificación. Operación diaria. • Evidenciar la capacidad para detectar errores y corregirlos en transmisiones fin a fin: Monitoreo. Estadísticas. Investigación de alzas. • Establecer si son adecuados los controles de acceso a las tablas del sistema operacional de la red. • Verificar la existencia de un registro automático diario o huella de Auditoría para los cambios a las tablas. • Verificar la existencia de backups de las tablas del sistema operacional. Nivel 5: De sesión Verificar para cada estación de trabajo y para el servidor de la red si: • Se puede acceder el sistema operacional. • Las claves de acceso son: Usadas adecuadamente. Compartidas.



37

Cambiadas periódicamente. Cambiadas cuando el personal es transferido. Requeridas para todas las estaciones de la red. Requeridas por el sistema operacional de la red. • Establecer si existe un procedimiento para recuperación de claves de acceso. • Verificar si existe un procedimiento de control para claves de acceso, a la red de computadores. • Determinar si el sistema operacional de la red o cualquier programa monitor controla: Las actividades realizadas en cada estación de trabajo. Las violaciones de acceso realizadas por estación de trabajo. • Determinar si los controles de acceso para tablas de seguridad son adecuados. • Verificar que las tablas de seguridad sean respaldadas frecuentemente y almacenadas fuera del sistema. • Verificar si existe una huella de Auditoría o un registro automático diario, para todos los cambios hechos sobre las tablas de seguridad. Nivel 6: De presentación • - Determinar si existe criptografía y establecer: Si es por software. Si es por hardware. Cuantas claves se usan. Si suministran seguridad apropiada. Si las claves son cambiadas y con qué frecuencia. Nivel 7: De aplicación • Pruebas para diagnóstico de la seguridad: Establecer si las aplicaciones son individualmente seguras. Verificar la existencia de limitaciones por clase de transacción, para determinados usuarios. Verificar las restricciones establecidas para cada nivel de acceso diferente. Establecer si existe algún seguimiento para actividades inválidas. Establecer si el analista de la red es avisado de la violación y si éste avisa a los usuarios involucrados. Establecer si se hace seguimiento al caso anterior. Establecer si se usan archivos para pistas de Auditoría, disco o servidor para respaldo. Establecer si existe un procedimiento para ayudar a los usuarios en la recuperación. Establecer si hay alguien más responsable para el respaldo del servidor. Establecer si existe un procedimiento definido para backups. • Pruebas para diagnóstico de las aplicaciones: Verificar la revisión del software, antes de instalarse definitivamente en las Áreas de Producción. Revisar los sitios de almacenamiento de la documentación sensible, cuando no está en uso. Verificar si son usadas versiones de red (actualizadas) de programas de aplicación. Verificar si hay violación de área entre los usuarios.



38

6. ENTRENAMIENTO Y SOPORTE A USUARIOS • Verificar la existencia de un programa de capacitación definido, para los usuarios en hardware y software. • Verificar la existencia de material para auto estudio. • Establecer si se incluye en la capacitación a los usuarios, la difusión de normas y políticas establecidas por la empresa con respecto a los micros. • Establecer si se efectuaron análisis de necesidades de capacitación de los usuarios. 7. MANTENIMIENTO • Evaluaciones de los contratos de mantenimiento actuales. • Verificar la existencia de un programa para el mantenimiento preventivo y si existe, averiguar si lo conocen los usuarios y cómo se controla. • Establecer si existe un control que relacione los números de serie de las partes de los equipos que son llevados a mantenimiento a otras empresas. • Establecer si existe un procedimiento a seguir en caso de daño de un equipo y si existe, verificar si lo conocen los usuarios. • Establecer si se ha dado instrucciones al personal de limpieza, cuando éste se encuentra en un área de micros. • Establecer qué tipo de interventoría tiene la gestión de los contratistas. • Establecer si se protegen con forros plásticos el teclado, la pantalla y CPU. • Revisar cuál es el tipo de mantenimiento. • Establecer si existe un programa de las actividades del mantenimiento preventivo del contratista. 8. SEGUROS • Verificar si se tienen pólizas de seguros que amparen los computadores. • Verificar si las estipulaciones de las cláusulas corresponden con las instalaciones físicas de los micros (tarjetas, velocidad, valor, etc.) • Revisar los procedimientos de reporte a la aseguradora con respecto a los eventos ocurridos con los equipos. 9. SEGURIDAD • Seguridad del hardware: Verificar si se tiene un registro de todos los números seriales de los equipos periféricos y sus partes más relevantes (tarjetas especiales). Verificar si se hacen comparaciones periódicas entre el inventario físico y el registro. Verificar si están los microcomputadores ubicados en áreas de tráfico limitado. Confirmar si se tiene seguridad, para verificar cuando un equipo ha sido destapado sin autorización. • Seguridad del software: Verificar si se tiene establecido el procedimiento para autorización de nuevos usuarios. Verificar si se tienen identificados los archivos de datos confidenciales. Verificar si se registra el acceso y uso de los equipos.



39

CAPITULO II

BIBLIOTECA DE INFRAESTRUCTURA DE TECNOLOGIAS DE LA INFORMACION (ITIL)

2.1 INTRODUCCIÓN A LA GESTIÓN DE SERVICIOS TI

Las tecnologías de la información son tan antiguas como la historia misma y han jugado

un importante papel en la misma. Sin embargo, no ha sido hasta tiempos recientes que mediante la automatización de su gestión se han convertido en una herramienta imprescindible y clave para empresas e instituciones.

La información es probablemente la fuente principal de negocio en el primer mundo y

ese negocio a su vez genera ingentes cantidades de información. Su correcta gestión es de importancia estratégica y no debe considerarse como una herramienta más entre muchas otras.

Hasta hace poco las infraestructuras informáticas se limitaban a dar servicios de

soporte y de alguna forma eran equiparables con el otro material de oficina: algo importante e indispensable para el correcto funcionamiento de la organización pero poco más.

Sin embargo, en la actualidad esto ha cambiado y los servicios TI representan

generalmente una parte sustancial de los procesos de negocio. Algo de lo que es a menudo responsable el advenimiento de ubicuas redes de información: sirva de ejemplo la Banca Electrónica.

Los objetivos de una buena gestión de servicios TI han de ser: * Proporcionar una adecuada gestión de la calidad * Aumentar la eficiencia * Alinear los procesos de negocio y la infraestructura TI * Reducir los riesgos asociados a los Servicios TI * Generar negocio ITIL nace como un código de buenas prácticas dirigidas a alcanzar esas metas

mediante: * Un enfoque sistemático del servicio TI centrado en los procesos y procedimientos * El establecimiento de estrategias para la gestión operativa de la infraestructura TI



40

2.2 ¿QUÉ ES ITIL?

Desarrollada a finales de 1980, la Biblioteca de Infraestructura de Tecnologías de la

Información (ITIL) se ha convertido en el estándar mundial en la Gestión de Servicios Informáticos. Iniciado como una guía para el gobierno de UK, la estructura base ha demostrado ser útil para las organizaciones en todos los sectores a través de su adopción por innumerables compañías como base para consulta, educación y soporte de herramientas de software. Hoy, ITIL es conocido y utilizado mundialmente. Pertenece a la OGC, pero es de libre utilización.

ITIL fue desarrollada al reconocer que las organizaciones dependen cada vez más de

la Informática para alcanzar sus objetivos corporativos. Esta dependencia en aumento ha dado como resultado una necesidad creciente de servicios informáticos de calidad que se correspondan con los objetivos del negocio, y que satisfagan los requisitos y las expectativas del cliente. A través de los años, el énfasis pasó de estar sobre el desarrollo de las aplicaciones TI a la gestión de servicios TI. La aplicación TI (a veces nombrada como un sistema de información) sólo contribuye a realizar los objetivos corporativos si el sistema está a disposición de los usuarios y, en caso de fallos o modificaciones necesarias, es soportado por los procesos de mantenimiento y operaciones.

A lo largo de todo el ciclo de los productos TI, la fase de operaciones alcanza cerca del

70-80% del total del tiempo y del coste, y el resto se invierte en el desarrollo del producto (u obtención). De esta manera, los procesos eficaces y eficientes de la Gestión de Servicios TI se convierten en esenciales para el éxito de los departamentos de TI. Esto se aplica a cualquier tipo de organización, grande o pequeña, pública o privada, con servicios TI centralizados o descentralizados, con servicios TI internos o suministrados por terceros. En todos los casos, el servicio debe ser fiable, consistente, de alta calidad, y de coste aceptable.

Figura 2.1 Gestión de servicios TI



41

2.3 SOPORTE AL SERVICIO

El soporte al servicio se preocupa de de todos los aspectos que garanticen la

continuidad, disponibilidad y calidad del servicio prestado al usuario. Provisión del Servicio

La provisión del servicio se ocupa de los servicios ofrecidos en si mismos. En particular

de los Niveles de servicio, su disponibilidad, su continuidad, su viabilidad financiera, la capacidad necesaria de la infraestructura TI y los niveles de seguridad requeridos

2.4 FORUM ITSMF

El ITSMF es el único Forum completamente independiente reconocido por el sector de

la Gestión de Servicios Informáticos. Esta asociación, con fines no lucrativos, juega un papel predominante en el desarrollo y promoción de un código de Mejores Prácticas para la gestión de estos servicios.

En la actualidad, las empresas dependen cada vez en mayor medida de la tecnología

para la promoción y distribución de sus productos en el mercado, por lo que resulta imprescindible adoptar unos estándares que permitan la correcta gestión de los procesos informáticos asociados.

El objetivo del ITSMF es organizar una red de expertos en Gestión de Servicios

Informáticos, ofrecer completa información sobre los mismos y organizar seminarios y conferencias para ayudar a las empresas a resolver los problemas que puedan encontrar en este campo, todo ello con el objetivo de mantener un alto nivel de calidad de lestos servicios gracias a la utilización de un código de Mejores Prácticas.

Más de 1000 compañias, grandes corporaciones y empresas públicas de todo el mundo

pertenecen al ITSMF. Osiatis es en la actualidad una de las empresa responsables de las actividades del Forum en España y Francia (Claude Durand, Director de Desarrollo de Osiatis Francia, es tesorero de la asociación en ese país).

2.5 CERTIFICACIONES ITIL

2.5.1 EXIN E ISEB

La fundación holandesa "Exameninstituut voor Informatica" (EXIN) y la inglesa

"Information Systems Examination Board" (ISEB) han desarrollado juntas un sistema de certificación profesional para ITIL. Fue realizado en estrecha cooperación con la OGC y el itSMF. EXIN e ISEB son organizaciones sin ánimo de lucro que cooperan para ofrecer una amplia gama de certificaciones en tres niveles:



42

* Foundation Certificate en Gestión de Servicios TI * Practitioner Certificate en Gestión de Servicios TI * Manager Certificate en Gestión de Servicios TI El sistema de certificación está basado en los requisitos para representar eficazmente

el papel pertinente dentro de una organización TI. Hasta la fecha, se han entregado más de 50.000 certificados Foundation a profesionales de más de 30 países.

Hoy en día, ITIL representa mucho más que una serie de libros útiles sobre Gestión de

Servicios TI. El marco de mejores prácticas en la Gestión de Servicios TI representa un conjunto completo de organizaciones, herramientas, servicios de educación y consultoría, marcos de trabajo relacionados, y publicaciones. Desde 1990, se considera a ITIL como el marco de trabajo y la filosofía compartida por quienes utilizan las mejores prácticas ITIL en sus trabajos. Gran cantidad de organizaciones se encuentran en la actualidad cooperando internacionalmente para promover el estándar ITIL como un estándar de facto para la Gestión de Servicios TI.

2.6 INCIDENT MANAGEMENT (GESTION DE INCIDENTES)

La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause

una interrupción en el servicio de la manera más rápida y eficaz posible. La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a

diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

2.6.1 OBJETIVOS DE LA GESTIÓN DE INCIDENTES

Los objetivos principales de la Gestión de Incidentes son:

a) Detectar cualquiera alteración en los servicios TI. b) Registrar y clasificar estas alteraciones. c) Asignar el personal encargado de restaurar el servicio según se define en el SLA

correspondiente. Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de

Servicios (Service Desk) debe jugar un papel esencial en el mismo.



43

El siguiente diagrama resume el proceso de gestión de incidentes:

Figura 2.2 Gestión de Incidentes

Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL un incidente es:

“Cualquier evento que no forma parte de la operación estándar de un servicio y que

causa, o puede causar, una interrupción o una reducción de calidad del mismo”. Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un

incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar.

Cualquier cambio que requiera una modificación de la infraestructura no se considera un

servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios.

Los principales beneficios de una correcta Gestión de Incidentes incluyen: Mejorar la productividad de los usuarios. Cumplimiento de los niveles de servicio acordados en el SLA. Mayor control de los procesos y monitorización del servicio. Optimización de los recursos disponibles. Una CMDB más precisa pues se registra los incidentes en relación con los elementos de

configuración. Y principalmente: mejora la satisfacción general de clientes y usuarios. Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales

como:

Reducción de los niveles de servicio.

Se dilapidan valiosos recursos: demasiada gente o gente del nivel



44

inadecuado trabajando concurrentemente en la resolución del incidente.

Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.

Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.

Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen

en:

No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.

No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.

No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.

2.6.2 CLASIFICACIÓN DEL INCIDENTE

Es frecuente que existan múltiples incidencias concurrentes por lo que es necesario

determinar un nivel de prioridad para la resolución de las mismas. El nivel de prioridad se basa esencialmente en dos parámetros:

Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.

Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA.

También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución

esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes. Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del

incidente. La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden

encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones.

Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad

del incidente. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente:



45

Figura 2.3 Diagrama de prioridades

2.6.3 ESCALADO Y SOPORTE

Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia

un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado.

Básicamente hay dos tipos diferentes de escalado: Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para

resolver el problema. Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar

decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.



46

El proceso de escalado puede resumirse gráficamente* como sigue:

Figura 2.4 Proceso de escalado

* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario

Registro y Clasificación de Incidentes

2.6.4 PROCESO

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de

Incidentes:

Figura 2.5 Proceso de la Gestión de Incidentes



47

2.7 REGISTRO Y CLASIFICACIÓN DE INCIDENTES

2.7.1 REGISTRO

La admisión y registro del incidente es el primer y necesario paso para una correcta

gestión del mismo. Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de

aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros. El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso

hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.

La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente.

Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.

Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.

Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados...).

Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia CMDB (hardware interrelacionado), etc.

Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo.

2.7.2 CLASIFICACIÓN

La clasificación de un incidente tiene como objetivo principal el recopilar toda la

información que pueda ser de utilizada para la resolución del mismo. El proceso de clasificación debe implementar, al menos, los siguientes pasos:

Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.

Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.



48

Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).

Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad., integrar diferentes niveles en el caso de PYMES

2.8 ANÁLISIS, RESOLUCIÓN Y CIERRE DE INCIDENTES

En primera instancia se examina el incidente con ayuda de la KB para determinar si se

puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado. Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios

éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados.

Durante todo el ciclo de vida del incidente se debe actualizar la información

almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.

Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera

recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de las causas subyacentes.

Cuando se haya solucionado el incidente se:

Confirma con los usuarios la solución satisfactoria del mismo.

Incorpora el proceso de resolución a la KB.

Reclasifica el incidente si fuera necesario.

Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente.

Cierra el incidente.

2.9 CONTROL DEL PROCESO

La correcta elaboración de informes forma parte esencial en el proceso de Gestión de

Incidentes. Estos informes deben aportar información esencial para, por ejemplo:



49

La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.

Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.

Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.

Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.

Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.

Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que

facilite su correcta implementación. Entre ellos cabe destacar:

Un correcto sistema automatizado de registro de incidentes y relación con los clientes

Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una (KB) actualizada permite: Evitar escalados innecesarios.

Convertir el “know how” de los técnicos en un activo duradero de la empresa.

Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.

Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente.

Para el correcto seguimiento de todo el proceso es indispensable la utilización de

métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:



50

Número de incidentes clasificados temporalmente y por prioridades.

Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.

Nivel de cumplimiento del SLA.

Costes asociados.

Uso de los recursos disponibles en el Centro de Servicios.

Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.

Grado de satisfacción del cliente



51

CAPITULO III

“ENCICLOMEDIA”

3.1 INTRODUCCIÓN

A lo largo de la historia de México, la integración educativa ha pasado por varias facetas.

A partir de 1993 se promueve de manera oficial la integración educativa en México. Con el desarrollo de las nuevas tecnologías de la información y la comunicación se crean

diversos proyectos aplicando la tecnología educativa. Es la Secretaria de Educación Publica a través el Instituto Latinoamericano de la Comunicación Educativa, quien ha promovido y apoyado diversos programas como Edusat, Red Escolar y Sepiensa, solo por mencionar algunos.

A partir del año 2003 y retomando diversas experiencias y estudios de la tecnología

educativa en México y otros países, surge Enciclomedia como un programa que promueve la equidad al buscar que todos los niños independientemente de su condición social, de la región en la que habitan o del grupo Étnico al que pertenecen, tengan oportunidades de acceder a la escuela y participar en procesos educativos para alcanzar los propósitos de la educación básica. Enciclomedia es también una herramienta, para la integración educativa al contar con diversos recursos de accesibilidad para niños con alguna discapacidad, así como contenidos específicos y en lenguas de diversas culturas indígenas de México.

3.2 TECNOLOGÍA EDUCATIVA EN MÉXICO

Las TIC y su impacto en todos los campos de la actividad humana imponen cambios de

paradigmas en la educación, nuevas formas de concebir el proceso enseñanza- aprendizaje, así como recursos y elementos mediadores de la práctica en el aula.

En los últimos años se introducen a los salones de clase las tecnologías de la información

y la comunicación como apoyo a los procesos educativos, surgen nuevas herramientas y nuevos ambientes de aprendizaje que promueven mejoras a la práctica educativa. Con esa introducción, se desarrollan modalidades educativas que en un inicio estuvieron muy relacionadas con la educación a distancia y poco a poco dan propuestas innovadoras para la educación presencial, y por supuesto para la educación de niños con discapacidad.

Diversos proyectos pedagógicos con tecnología, proponen la elección, combinación y uso

de medios tecnológicos en forma reflexiva, contextual y estratégica, algunos se desarrollan en México a través del Instituto Latinoamericano de la Comunicación Educativa, ILCE.

El ILCE es un organismo internacional sin fines de lucro, integrado por trece países



52

miembros de Latinoamérica: Bolivia, Colombia, Costa Rica, Ecuador, El Salvador, Guatemala, Haití, Honduras, México, Nicaragua, Panamá, Paraguay y Venezuela, siendo México el país sede.

En el ILCE contribuimos a aprovechar los recursos tecnológicos para mejorar en las personas competencias útiles para la vida y el trabajo:

• Potenciamos las Tecnologías de Información y Comunicación • Promovemos la investigación • Desarrollamos contenidos en diferentes medios • Producimos materiales para la educación y formación • Innovamos modelos educativos • Fomentamos el uso de plataformas y espacios virtuales de aprendizaje • Es así como logramos tener un impacto positivo en la formación integral de las

personas e incidir en el mejoramiento de su calidad de vida, sus comunidades y países Algunos ejemplos son:

• TELE SECUNDARIA En busca de disminuir el rezago educativo, la SEP inicia en 1966 de manera experimental

el proyecto de Enseñanza Secundaria por Televisión (Telesecundaria) En 1988 se transmite por circuito abierto el primer modelo de Telesecundaria con validez

oficial por televisión con la transmisión en directo de clases. Desde entonces, este modelo de educación ha pasado por diversas etapas, misma que lo ha hecho crecer y actualizarse

• COEEBA

Tras los adelantos tecnológicos que viven la humanidad la SEP reconoce fundamental

introducir a los docentes en el uso de las nuevas herramientas tecnológicas. Es en 1985 cuando la SEP a través del ILCE realiza una serie de acciones que permita a los docentes obtener los conocimientos necesarios sobre el uso y manejo de la computadora como auxiliar didáctico en las aulas, a partir del programa de COEEBA (Computación Electrónica en la Educación Básica)

• EDUSAT http://edusat.ilce.edu.mx

En 1994 se inicia la transmisión de Edusat es un sistema de señal digital comprimida que

se transmite vía satélite, siendo el más importante de su naturaleza en Latinoamericano; depende de la Secretaria de Educación Pública y su función principal es poner a disposición de los mexicanos una amplia oferta de televisión y radio con fines educativos.

• RED ESCOLAR http://redescolar.ilce.edu.mx

Red Escolar inicio en 1997, lleva a las escuelas de educación básica y normal un modelo

tecnológico de convergencia de medios, basado en el uso de la informática educativa, la conexión a Internet, videotecas, discos compactos de consulta (Cd ROM), bibliotecas de aula y

http://edusat.ilce.edu.mx/

http://redescolar.ilce.edu.mx/



53

la red de televisión educativa. Se basa un sistema de comunicación que permite a estudiantes y profesores compartir ideas y experiencias.

Fomenta el ejercicio de un pensamiento crítico, analítico y reflexivo con base en el trabajo colaborativo que les proporciona vivir el proceso de enseñanza-aprendizaje de una forma distinta a la que generalmente se plantea en la enseñanza tradicional.

• SEPIENSA www.sepiensa.org.mx/

Es un portal en Internet dirigido a la comunidad escolar; niños y niñas, jóvenes, docentes

y familia cuyos contenidos son un apoyo a la curricula tanto de educación básica como media superior y superior. Incluye artículos sobre desarrollo humano, sexualidad, discapacidad, música, salud, entre muchos otros.

En el lenguaje pedagógico hay nuevas concepciones y estrategias para adaptar la educación especial a los tiempos actuales, en donde se busca la integración educativa. El concepto de Nuevos Ambientes de Aprendizaje ligado al uso de nuevas herramientas tecnológicas nos permite formas diferentes de organizar la práctica en el aula, que implica el empleo de estas tecnologías y el trabajo con grupos en donde se busca desarrollar al máximo las capacidades de los niños tanto con necesidades educativas especiales con o sin discapacidad, como sin ellas.

Cabe señalar una vez más, que a la par del desarrollo de las TIC, en los procesos educativos regulares en México, también se potencia el uso de las nuevas tecnologías en los niños con discapacidad, ya que a través de Éstas se logra estimular al máximo sus capacidades y les da mayores oportunidades de acceder al conocimiento y a la integración tanto en el aula de clases como en su entorno familiar y social.

3.3 ENCICLOMEDIA

En la búsqueda de seguir fortaleciendo el sistema educativo en México, con el desarrollo

de las TIC y la recopilación de experiencias surge en el 2003 Enciclomedia, que se desarrolla en el ILCE.

Enciclomedia es un sistema de e-Liaoning que está conformado elementalmente por una

base de datos didácticamente diseñada y planeada a partir de los libros de texto gratuitos de quinto y sexto grados de primaria. A través de una computadora, un pizarrón electrónico y un proyector, los maestros y alumnos tienen acceso en el salón de clases a los siguientes materiales: los libros de texto gratuitos, un sitio del maestro con el avance programático, ficheros, desarrollo profesional, papelería y demás.

Enciclomedia es un programa educativo que busca apoyar a la educación básica con TIC.

La idea principal es reforzar el contenido de los libros de texto gratuitos con materiales educativos complementarios y apoyar la enseñanza en el aula.

Con Enciclomedia se pretende mejorar las condiciones de las aulas mexicanas, actualizar

a los docentes en el uso pedagógico de las TIC (apoyando su catedra frente al grupo), mejorar la

http://www.sepiensa.org.mx/



54

calidad de la educación a nivel nacional diversificando los métodos de comprensión de los contenidos de los libros de texto, disminuir la brecha digital, desear estrategias de integración educativa para sectores en desventaja dentro del sistema educativo y abordar integralmente los temas y contenidos de los libros de texto mediante ligas transversales que recorren los contenidos de los distintos grados del nivel básico

. Enciclomedia conforma y organiza un repositorio que permite mejorar, actualizar y

acrecentar los contenidos del sistema. Es un espacio de colaboración donde las instituciones publicas, privadas e individuos pueden proponer la incorporación de contenidos de interés tanto general como regional, permitiendo enriquecer el acervo en un proceso permanente.

De esta forma, se busca tanto realizar contenidos pertinentes y cercanos al entorno de los

niños y los maestros, y contribuir a que la educación pública sea un asunto público. En su primera versión, el sistema de Enciclomedia no considera requerimientos de

accesibilidad y de incorporación de estándares en materia de aprendizaje apoyado en las TIC. Como respuesta a estas carencias, se está• desarrollando la versión 2.0 con un diseño que incluye gran variedad de metadatos para objetos de aprendizaje y herramientas de accesibilidad que posibilitan y diversifican el despliegue de estos objetos. Los meta datos de accesibilidad de los objetos de aprendizaje para el repositorio de Enciclomedia consideran estándares de IMS Global Consortium [IMSGC, 2000], SCORM [ADL, 2003] y Cancore [Friesen, 2004], e incorporan adecuaciones para la realidad mexicana. Así, se dividen en cuatro grupos:

1. Información relativa a la activación y acceso con diversos dispositivos. 2. Información sobre las maneras alternativas con que cuentan los objetos de

aprendizajes para presentar el contenido. 3. Información acerca de la manera en que el contenido de los objetos de

aprendizajes es presentado en la pantalla. 4. Información sobre la versión, idioma/lengua, y principales destinatarios del

contenido.

3.3.1 ORIGEN

Enciclomedia surgió como un proyecto de tesis de ingeniería en computación en el

Instituto Tecnológico Autónomo de México. Lo presentó Eliseo Steve Rodríguez Rodríguez después de haber trabajado junto a Felipe Bracho y otros investigadores del Instituto Politécnico Nacional en programas de innovación tecnológica para la educación. Con el nombre de SARCRAD: Sistema de Administración de Recursos Conceptuales y de Referenciarían Automática Difusa. Enciclomedia: Una aplicación específica, el creador del sistema presentó su examen el 29 de mayo de 2001 y obtuvo la mención honorífica en su titulación. Como director adjunto de Investigación Orientada en CONACYT, Felipe Bracho se encargó de difundir el proyecto y presentarlo al secretario de Educación Pública, Reyes Tamez Guerra, y más tarde al propio presidente Vicente Fox, quien lo acogió como el proyecto educativo sexenal. Se presentó como la opción para integrar programas de equipamiento tecnológico de las escuelas, que surgieron en los últimos 10 años en México. Enciclomedia incorpora contenidos de la Red



55

Satelital de Televisión Educativa, Red Escolar, Portal SEPiensa, Biblioteca Digital, Secundaria 21, Enseñanza de la Física y Matemáticas con Tecnología (EFIT-EMAT).

3.3.2 LA PRIMERA VERSIÓN DE LOS LIBROS DE TEXTO

Los libros de texto en web tienen su origen en 1998, cuando el Dr. Felipe Bracho Carpizo

siendo Director de área en el CONACYT impulsó, junto con la de otras redes temáticas, la creación de REDII (“Red de Desarrollo e Investigación e Informática”), la cual tenía por objeto integrar a los investigadores en el área de computación, diseminados en toda la República Mexicana, para trabajar en una red colaborativa, en la investigación y desarrollo de ciencias e ingeniería de computación.

En una reunión de promoción del Programa REDII efectuada el propio año de 1998, en el

Centro de Investigación en Computación (CIC) del IPN, que entonces era dirigido por el Dr. Adolfo Guzmán Arenas, el Dr. Bracho luego de explicar los objetivos de REDII y los mecanismos de apoyo y financiamiento que ofrecía, escuchó diversas propuestas de proyectos por parte de los investigadores.

El Profesor Norberto Medina López que entonces fungía como Jefe del Laboratorio de

Multimedia puso a la consideración de ambas autoridades el proyecto de investigación que se registró en el Programa REDII del CONACYT con el nombre de "Hipertexto Gratuito de Primaria" y tenía como finalidades: producir un objeto de aprendizaje con una interfaz intuitiva y amigable que permitiera estudiar los libros de texto en línea y profundizar a través de enlaces a otros recursos didácticos y educativos como foros de discusión y aplicaciones multimedia, que reforzaran el conocimiento de cada tema, hecho o personaje motivo de estudio, como son las enciclopedias en línea con la capacidad de formar automáticamente comunidades virtuales en la cuales se daba la investigación y docencia en base a determinado tema o área del sistema de educación elemental en México; además de desarrollar el software para crear el ambiente de publicación del hiperlibro o hipertexto, generar automáticamente los enlaces a los recursos didácticos adicionales y proporcionar un ambiente de navegación amigable, basado en las tecnologías Web y TCP/IP.

El CIC mantuvo en línea el sistema de los hiperlibros en producción, en el servidor del

Laboratorio de Multimedia hasta el año de 2003, con un promedio de 1000 visitas diarias. Entonces el Dr. Juan Luis Díaz de León quién fungía como Director del CIC, dio la indicación de que por órdenes de la SEP debía bajarse del servidor el hiperlibro de primaria.



56

CAPITULO IV.

AUDITORIA A LOS REQUERIMIENTOS TÉCNICOS PARA SERVICIO DE AULA BASE TELEMATICA DE LA SEP

4.1 DATOS GENERALES.

Nombre de la Organización: Grupo. Biz Rubro: Soporte a Tecnologías de la Información. Dirección: Av. Ejecito Nacional No.205, Col. Verónica Anzures México D.F. 11300 Teléfono: 5003 2995 Nombre del responsable: Joab Cervantes Bérchiman, Coordinador general de tecnologías de información.

4.2 DESCRIPCIÓN.

Grupo.Biz es consorcio empresarial con profunda experiencia en Gestión Estratégica y

de Tecnologías de la Información, lo cua les ha permitido generar resultados que han agregado valor a varias Organizaciones tanto en el sector público, como privado, financiero, industrial y de servicios.

La SEP es una de las empresas públicas con las que ha podido trabajar dentro de su

proyecto Enciclomedia. Este proyecto es un sistema de e-learning que está conformado elementalmente por una base de datos didácticamente diseñada y planeada a partir de los libros de texto gratuitos de quinto y sexto grados de primaria. A través de una computadora, un pizarrón electrónico y un proyector, los maestros y alumnos tienen acceso en el salón de clases a los siguientes materiales: los libros de texto gratuitos, un sitio del maestro con el avance programático, ficheros, desarrollo profesional, papelería y demás.

Grupo.Biz trabajo desde el 2010 apoyando como empresa hermana a Alef en la licitación

que ganara años atrás sobre la Administración de los Tickets (inicidencias) generados por las Aulas Enciclomedia. El proyecto concluyo en diciembre del 2011. Y este año la SEP volvió a lanzar la convocatoria con el nombre de “Servicio de Aula Base Telemática (SABT)” en la que Grupo.Biz pretende participar.

Para que los participantes puedan quedarse con el proyecto de la SEP, es necesario que

cumpla los siguientes requerimientos técnicos:



57

4.3 ESTADO ACTUAL.

El documento de requerimientos técnicos para el Servicio de Aula Base Telematica

(SABT) de la SEP no cuenta con ningún antecedente de auditoria o revisión que tenga como base los marcos de regulación de tecnologías de información como lo es COBIT ó ITIL, por lo que prácticamente se parte de cero.

El documento de Requerimientos Técnicos para el Servicio SABT está dividido en ocho

capítulos y nueve anexos para la fines de la auditoria solo nos basaremos en los capítulos: cuatro “Gestion de incidentes y niveles de servicios”, ocho “Actualizaciones tecnológicas, control de ABT y entrega de Consumibles” y el Anexo 1 ”Elementos tecnológicos del SABT” (el cual se anexa íntegramente )que son los que directamente se relacionan con el servicio de TI.

4.4 OBJETIVO GENERAL DEL SERVICIO

La contratación de un servicio, el SABT, tiene el objetivo de garantizar a la Secretaría la

disponibilidad de:

Los elementos tecnológicos de ABT

El Software Académico

El Software de Monitoreo

El medio de monitoreo En las aulas de 5º y 6º de primaria en apoyo al aprendizaje de los alumnos, fortaleciendo

la formación integral de los mismos en la educación básica; que incluye los elementos tecnológicos descritos en el Anexo 1 del presente documento, así como los elementos del servicio descritos, basado en los niveles de servicio establecidos, que soportan la operación diaria.

GESTION DE INCIDENTE Y NIVELES DE SERVICIO

En esta sección del documento se describe lo siguiente:

CONCEPTOS BÁSICOS

Definición de incidente

Generación de Numero de Ticket (NT)

Tiempo y forma de atención de NT

NT resuelto

NT sin resolución

Falta grave



58

4.5 REGISTRO DE INCIDENTES

A. La MSSC comunicará al licitante adjudicado un Incidente indicando el Ticket (NT)

respectivo y el Plazo de Resolución del NT como se describe en la siguiente sección. La comunicación será preferentemente de manera electrónica aunque podrá realizarse por cualquier otro medio que la MSSC tenga a su disposición.

B. El licitante adjudicado deberá acusar recibo del NT a la MSSC vía electrónica o por

escrito. Gráficamente se muestra el manejo de Incidentes y Niveles de Servicio en el Anexo 2 y

proceso de registro de incidentes se muestra en el Anexo 3. Por último ya para poder comprender mejor se muestra el Ciclo de vida de los Reportes de Atención / Incidentes con NT en el Anexo 4.

4.5.1 PLAZO DE RESOLUCIÓN DEL NT

El Plazo de Resolución del NT se considerará por regla general en Días escolares, no

obstante la Secretaría podrá establecer en algunos casos la resolución del NT en Días hábiles. El Plazo de Resolución del NT será variable de acuerdo a la característica urbana, rural o

mixta en donde se ubique el ABT. Considerando información del Consejo Nacional de Población, indicadores de la

marginación a nivel localidad, se clasificó la ubicación de las escuelas en referencia a su cercanía a centros poblacionales y vías terrestres federales, generándose tres (3) niveles de facilidad de acceso, Alto, Medio y Bajo:

Tabla 5.1 Niveles de Accesibilidad



59

La criticidad de los elementos tecnológicos de una ABT que la Secretaría ha determinado es:

Tabla 5.2 Elementos de Criticidad

Con estos dos (2) indicadores, la Secretaría ha establecido la siguiente matriz de “Índice

de Tiempo de Respuesta para la Atención y Resolución de Incidentes”

Tabla 5.3 Indice de tiempo de respuesta para la atención y resolución de Incidentes

EL proceso del tiempo de atención de Incidentes se muestra en el Anexo 5.

4.5.2 CIERRE DEL NT

Cuando el licitante adjudicado resuelva el NT, deberá enviar la documentación

comprobatoria digitalizada a la MSSC de manera electrónica: correo electrónico, intercambio de información entre el sistema del licitante adjudicado y el sistema de la MSSC, o a través de un medio de almacenamiento, para que la MSSC proceda a realizar el Cierre del NT.

La comprobación de la resolución de un NT es responsabilidad del licitante adjudicado. En

caso de que la información que remita el licitante adjudicado no sea fidedigna, será considerada como Falta Grave y se procederá a aplicar las penas correspondientes.

El cierre del NT indicará el término de la no disponibilidad del ABT, pasando al estado de Disponible.

4.5.3 COMPROBACIÓN DE CIERRE DE NT

Constituye documentación comprobatoria:

Para NT resueltos telefónicamente: el archivo electrónico conteniendo la grabación



60

de la llamada en formato MP3 donde se especifique el número del NT, número de ABT, nombre del docente, nombre del personal de soporte técnico que resolvió el NT, fecha y hora de resolución verbal del docente sobre la resolución recibida.

Para NT resueltos en sitio por personal de soporte técnico del licitante adjudicado: Formato de Resolución del NT donde se registrarán los datos correspondientes, se sellará y firmará por la Autoridad Escolar, así como por el personal del licitante adjudicado que lo resolvió.

4.5.4 VERIFICACIÓN DE NT

La Secretaría, a través de la MSSC, podrá verificar el estado que guardan las ABT a

través una muestra aleatoria de los NT registrados en su base de datos durante la vigencia del contrato. Cuando la Secretaría detecte inconsistencia en la información proporcionada por el licitante adjudicado, le requerirá por escrito su aclaración, misma que deberá entregar por escrito el licitante adjudicado en un plazo no mayor a diez (10) Días hábiles contados a partir de la fecha de recepción del requerimiento, adjuntando la documentación comprobatoria.

En caso de confirmarse la inconsistencia, se realizarán las siguientes acciones:

Se aplicará por cada NT una deductiva de 20 días de salario mínimo general vigente en el Distrito Federal.

Se corregirán los NT con los documentos comprobatorios

En caso de que existieran pagos en exceso, el licitante adjudicado deberá realizar su devolución más los intereses correspondientes.

Si el licitante adjudicado no presenta ante la Secretaría las aclaraciones correspondientes a la discrepancia en el NT verificado dentro del plazo de diez (10) Días hábiles contados a partir de la fecha de recepción del requerimiento, se realizarán las siguientes acciones:

Se aplicará por cada NT una deductiva de 20 días de salario mínimo general vigente en el Distrito Federal.

Se dejarán los NT como no resueltos, desde su origen.

En caso de que existieran pagos en exceso, el licitante adjudicado deberá realizar su devolución más los intereses correspondientes.

4.5.5 NT POR BAJA DE ABT

Cuando la Autoridad estatal requiera dar de baja una ABT, deberá solicitarlo por escrito a

la MSSC y se procederá de la siguiente manera: a. Se procederá abrir un NT para que el licitante adjudicado desinstale los elementos

tecnológicos del ABT y proceda a retirarlos. b. Al término del Plazo de Resolución del NT la Secretaría procederá a disminuir el costo



61

del ABT correspondiente.

4.5.6 NT POR REUBICACIONES DE ABT

La reubicación de una ABT se manejará a través de la apertura de un NT. El número total

de NT de reubicación de ABT estará limitado a un máximo del cinco por ciento (5%) del total de ABT amparadas en el contrato.

Una vez resuelto el NT de reubicación de ABT el licitante adjudicado deberá comprobar la

instalación anexando como documentación comprobatoria el formato de ABT disponible debidamente llenado, firmado y sellado por la Autoridad escolar y el personal del licitante adjudicado.

5.5.7 NT POR ROBO, PÉRDIDA O DAÑOS AL ABT

Los NT que se registren en la MSSC y que se refieran a eventos de robo, pérdida o daños

de los elementos tecnológicos de las ABT, ya sea de manera total o parcial, tendrán un Plazo de Resolución de NT como se define en la Sección 6.2, y conforme al siguiente procedimiento:

1. La Autoridad escolar reporta a la MSSC el robo, pérdida o daño de los elementos

tecnológicos del ABT. 2. La Autoridad escolar levanta el acta administrativa del robo, pérdida o daño en dos

(2) tantos originales, entregando uno al licitante adjudicado y conservando el otro. 3. La Autoridad escolar podrá acudir ante las autoridades locales correspondientes

para denunciar el robo, perdida o daño y obtener el acta ministerial poniéndola en su caso a disposición del licitante adjudicado.

4. La Autoridad escolar comunica a la MSSC el reporte de robo, pérdida o daño de los elementos tecnológicos de la ABT y procede a abrir un NT.

5. La MSSC comunica al licitante adjudicado el NT y que la Autoridad escolar tiene a su disposición el acta administrativa y en su caso el acta ministerial correspondiente. A partir de esta comunicación inicia el Plazo de Resolución del NT.

6. Es potestad del licitante adjudicado como propietario de los elementos tecnológicos del ABT, presentar su denuncia ante el Ministerio Público a fin de contar con el acta ministerial.

4.6 DESARROLLO DE LA AUDITORIA

Iniciamos el proceso de la auditoria con la reunión entre los integrantes del equipo de auditoria y el coordinador de Tecnologías de la Información Ing. Joab Cervantes Bérchiman el cual fue el que firmo la carta de autorización (Anexo 6) y proporciono el



62

documento base (no se anexa), se definieron los objetivos de la auditoria (Anexo 7) y se realizo la integración de expediente (Anexo 8). En la segunda reunión se presento el cronograma del plan de trabajo (Anexo 9). Se

deja como constancia la minuta de acuerdos (Anexo 10) Como resultado se muestra la siguiente tabla:

N. P. Actividad Revisada al documento Cumple

Observaciones Si No

Registro de incidencias

1 Se define un proceso para registrar incidencias

x

2 Define los tipos de incidencias que se deben atender

x

3 Se especifica el personal que debe notificar la incidencia para evitar duplicidad

x

4 Especifica la asignacion de referencia de la incidencia

x

5

Especifica la forma en que se complementa la informacion para el procesamiento del incidente (fecha, hora, descripcion del incidente, sistemas afectados, etc)

x

6 Existe un proceso para notificar a los demas usuarios la existencia de un incidente en caso de que éste los pueda afectar

x

cuenta con un monitoreo a traves de internet pero no especifica si hay comunicación entre los usuarios de SABT

Clasificacion

7

Se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente

x

8 Dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad

x

9

Existe un proceso en caso de que el Centro de Servicios no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).

x



63


Observaciones Si No

10

Asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad.

x

Analisis

11

Se proporciona al usuario una base de conocimiento para que pueda identificar el incidente con una ya resuelta y aplicar el procedimiento

x

12 Se especifica un protocolo de escalado x

13 Se especifica un proceso para la actualizacion de la informacion en las correspondientes bases de datos

x

Resolucion

14 Se especifica un procedimiento para la confirmacion de resolucion de incidencia con el usuario

x

15 Se especifica un procedimiento para la reclasificacion del incidente si fuera necesario

x

Cierre

16 Existe un procedimiento para que el usuario valide el cierre de la incidencia

x

Controles

17 Especifica que se debe contar con un area de atencion de incidencia

x

18 ¿Se tiene un procedimiento definido para la atención de incidencia?

x

19 ¿Se actualiza el historial de detalles? x

20 ¿Se tiene una persona encargada para modificar el status de la incidencia (nueva-en progreso-en espera)?

x

Se tiene una persona designada para generar, validar y cerrar la incidencia.

21 ¿Se registra el impacto de negocio ó se tiene prioridades?

x

22 ¿Se especifica el tiempo de ejecución, gasto y costo?

x



64


Observaciones Si No

23 ¿Se registra el nombre de la persona que realiza las atiende la incidencia?

x

24 ¿Se registra la fecha y hora de la modificación? x

25 ¿Se maneja un tiempo de resolución de la incidencia dependiendo de la naturaleza de la misma? x

26 ¿Todas las incidencias son reportadas y registradas en el escritorio de Servicio? x

Los resultados obtenidos de esta tabla son:

REPORTE DE OBSERVACIONESDE LA AUDITORÍA

Número de Observación Auditoría No. de Observación Año Bimestre

AU-SABT-03/12 01 02/12

Emisor: Dirección de Evaluación y Tecnologías de Información

Criterio

Área Específica Requerimientos Técnicos de SABT.

Fecha de incurrencia

Descripción “Soporte a Tecnologías de la Información.”

Fecha Compromiso

OBSERVACIONES, CAUSA, EFECTO RECOMENDACIONES

No existen antecedentes de auditoria realizadas al documento.

El documento fue rediseñado después de haber generado dudas en cuanto el servicio solicitado.

El documento esta dividido en ocho capítulos y nueve anexos de los cuales sólo se consideraron los cap. Cuatro, ocho y el anexo 1.

En el capitulo cuatro describe el proceso para la gestión de incidencia.

El capitulo ocho describe el proceso para las actualizaciones tecnológicas, control del ABT y entrega de consumibles.

Realizar un monitoreo del rendimiento del centro de servicios que permita a los clientes disponer directamente de la base de conocimientos, métricas que permitan evaluar el servicio y un proceso de retroalimentación y mejora continua. Generar un proceso de escalonamiento para la adecuada atención un incidente, respetando la asignación de recursos.



65

OBSERVACIONES, CAUSA, EFECTO RECOMENDACIONES

El anexo 1 contiene los elementos tecnológicos que componen un ABT.

Establecer un procedimiento que el centro de servicio ocupe como base para ser capaz de evaluar si el servicio requerido se incluye en el SLA o en caso contrario reenviarlo a una autoridad competente. Crear un proceso que descarte la posibilidad de que existan incidencias duplicadas. Tener un proceso que solo se ocupe en los casos en los que se tenga que notificar un incidente que pueda afectar a otros usuarios. Contar con un procedimiento en donde el proceso de resolución ocupado en los incidentes resueltos satisfactoriamente pueda incorporarse a la base de conocimientos. Crear un sistema de monitoreo para mantener un adecuado rendimiento en el centro de servicios. Contar con una extranet donde se publique una base de conocimiento a nivel usuario para que estos puedas resolver sus incidencias sin necesidad de registrarla. Establecer las métricas que evalúen el servicio brindado, para mantener siempre una objetividad del cómo se está brindado el servicio. Encontrar un proceso que nos ayude a mantener una retroalimentación constante y por consecuente tener una mejora continua.



66

4.6.1 RESULTADOS DE LA GUIDE LINE

RREEPPOORRTTEE DDEE AANNÁÁLLIISSIISS DDEE RRIIEESSGGOOSS

FFeecchhaa:: 1144--AAbbrriill--22001122 No. de auditoría: AU-SABT-03/12 Descripció

n:

Dependencia: Grupo Biz Área a Verificar:

Requerimientos Técnicos de SABT de la SEP

SITUACIÓN

El documento de requerimientos técnicos para el Servicio de Aula Base Telemática (SABT) de la SEP no cuenta con ningún antecedente de auditoria o revisión que tenga como base los marcos de regulación de tecnologías de información como lo es COBIT ó ITIL, por lo que prácticamente se parte de cero. El documento de Requerimientos Técnicos para el Servicio SABT está dividido en ocho capítulos y nueve anexos para la fines de la auditoria solo nos basaremos en los capítulos: cuatro “Gestión de incidentes y niveles de servicios”, ocho “Actualizaciones tecnológicas, control de ABT y entrega de Consumibles” y el Anexo 1 ”Elementos tecnológicos del SABT” (el cual se anexa íntegramente )que son los que directamente se relacionan con el servicio de TI. Como resultado del análisis efectuado a los Requerimientos Técnicos SABT de la SEP, y como resultado de las entrevistas, investigación, inspección , análisis de procesos se detectó lo siguiente: En general el documento cubre en un 70% con lo que marca ITIL en el apartado “incident management” Dentro de lo correspondiente al Registro se tiene presente la referencia que identifique unívocamente a cada incidente, la información básica necesaria y la información de apoyo. Se establecen niveles de servicio, prioridad en las incidencias y el procedimiento correcto para la atención de estos incidentes tomando en cuenta el registro de estos. El control de procesos y monitoreo establecido se lleva a cabo de manera correcta El escalonamiento para la atención de incidentes no específica como es, que se tiene que realizar, por lo cual establecer un proceso que nos detalle como seria el escalonamiento seria nuestra primera área de oportunidad encontrada. Dentro de este mismo rubro el documento no especifica que el centro de servicio encargado sea capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente, por lo cual aquí se podrían generar los lineamientos que nos ayuden a atacar este punto. Existe un procedimiento que descarte la posibilidad de que exista la duplicidad de incidencia, No existe un procedimiento que notifique en los casos en que el incidente pueda afectar a otros



67

usuarios para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo. En el rubro de la clasificación te toma en cuenta cada uno de los elementos que se requieren para llevar a cabo esta actividad. Es decir, el documento menciona que debe existir un proceso de categorización dependiendo del tipo de incidente, debe existir un nivel de prioridad, se tiene una adecuada asignación de recursos y se debe tomar en cuenta un proceso para llevar el monitoreo del estado y tiempo de respuesta esperado para la resolución de una incidencia. En lo que respecta al Análisis, Resolución y Cierre el documento nos menciona que debe existir una base de conocimientos, una correcta actualización de la información almacenada del incidente y la confirmación a los usuarios de la solución satisfactoria del mismo. Este apartado lo único que no tiene presente es un proceso donde la resolución de los incidentes se incorpore a la base de conocimiento. Por último en el rubro correspondiente al Control de Proceso el documento nos describe que se debe tomar en cuenta que los clientes dispongan de información puntual sobre el cumplimento de los niveles de servicio, reportes estadísticos, un correcto sistemas automatizado de registro de incidentes y uno para el soporte de incidentes. REQUERIMIENTOS TÉCNICOS SERVICIO AULA BASE TELEMÁTICA (SABT) DE LA SEP

RIESGO CONTROLES

No existe un proceso de escalonamiento para la atención de incidentes.

Generar un proceso de escalonamiento para la adecuada atención un incidente, respetando la asignación de recursos.

El centro de Servicio no es capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente.

Establecer un procedimiento que el centro de servicio ocupe como base para ser capaz de evaluar si el servicio requerido se incluye en el SLA o en caso contrario reenviarlo a una autoridad competente.

No existe algún proceso para que no exista el duplicado de incidencias.

Crear un proceso que descarte la posibilidad de que existan incidencias duplicadas.

No existe un proceso de notificación en los casos en que el incidente pueda afectar a otros usuarios para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo.

Tener un proceso que solo se ocupe en los casos en los que se tenga que notificar un incidente que pueda afectar a otros usuarios.



68

RIESGO CONTROLES

No se incorpora el proceso de resolución a la base de datos de conocimiento.

Contar con un procedimiento en donde el proceso de resolución ocupado en los incidentes resueltos satisfactoriamente pueda incorporarse a la base de conocimientos.

No se cuenta con un monitoreo del rendimiento del centro de servicios.

Crear un sistema de monitoreo para mantener un adecuado rendimiento en el centro de servicios.

Los clientes no disponen directamente de la base de conocimiento (parte o totalidad a la manera de FAQs) en una extranet.

Contar con una extranet donde se publique una base de conocimiento a nivel usuario para que estos puedas resolver sus incidencias sin necesidad de registrarla.

No existen métricas para evaluar de la forma mas objetiva el servicio

Establecer las métricas que evalúen el servicio brindado, para mantener siempre una objetividad del cómo se está brindado el servicio.

No se cuenta con un proceso de retroalimentación y mejora continua

Encontrar un proceso que nos ayude a mantener una retroalimentación constante y por consecuente tener una mejora continua.



69

ANÁLISIS DE RIESGO DE LA GUIDE LINE

20 21 22 24

15 19 23 27

1

14 16 17 18

7 8 10 11 12

6 9 13

25 26

1 2 3 4

5

La anterior grafica nos muestra como cada uno de los riesgos puede afectar al proyecto en caso de que no se tomen las medidas necesarias. RECOMENDACIONES

Realizar un monitoreo del rendimiento del centro de servicios que permita a los clientes disponer directamente de la base de conocimientos, métricas que permitan evaluar el servicio y un proceso de retroalimentación y mejora continua.

Generar un proceso de escalonamiento para la adecuada atención un incidente, respetando la asignación de recursos.

Establecer un procedimiento que el centro de servicio ocupe como base para ser capaz de evaluar si el servicio requerido se incluye en el SLA o en caso contrario reenviarlo a una autoridad competente.

Crear un proceso que descarte la posibilidad de que existan incidencias duplicadas.

Tener un proceso que solo se ocupe en los casos en los que se tenga que notificar un incidente que pueda afectar a otros usuarios.

Contar con un procedimiento en donde el proceso de resolución ocupado en los incidentes resueltos satisfactoriamente pueda incorporarse a la base de conocimientos.



70

Crear un sistema de monitoreo para mantener un adecuado rendimiento en el centro de servicios.

Contar con una extranet donde se publique una base de conocimiento a nivel usuario para que estos puedas resolver sus incidencias sin necesidad de registrarla.

Establecer las métricas que evalúen el servicio brindado, para mantener siempre una objetividad del cómo se está brindado el servicio.

Encontrar un proceso que nos ayude a mantener una retroalimentación constante y por consecuente tener una mejora continua.

El resultado final de esta auditoria se encuentra en el Anexo 11 donde se encuentra la

entrega de resultados y el cierre de la auditoria.



71

CONCLUSIONES

Realizar una auditoría es una actividad completa que requiere de habilidades personales que debe tener el personal auditor. La planeación y la estrategia para llevarla a cabo son sin duda los puntos donde se debe poner mayor énfasis para cumplir con los objetivos de la auditoria Conocer los puntos clave del plan de negocio es de vital importancia para una auditoria efectiva por lo que se le debe dedicar tiempo para comprenderlos y ampliar las áreas de oportunidad. Al concluir este proyecto esperamos que las recomendaciones que aquí presentamos puedan ser incluidas en la propuesta de Grupo Biz para obtener la licitación del Servicio Aula Base Telemática de la SEP y hacer la diferencia de entre las 80 empresas que participan. Es importante mencionar que Grupo Biz quedo satisfecho con el trabajo realizado que ha propuesto alinear los servicios que actualmente tiene con el manual de “Mejores Prácticas de ITIL”. Por lo que podemos afirmar que una auditoria no es solamente descubrir problemas o verificar las presuntas causas si no que tiene un objetivo más completo como es la de mejorar el funcionamiento de un departamento o de una empresa y si se va más lejos hasta la reingeniería de la misma.



72

ANEXO 1. ELEMENTOS TECNOLOGICOS DEL SABT.

1. PC DEL MAESTRO 2. EQUIPO PROYECTOR 3. PIZARRÓN INTERACTIVO 4. IMPRESORA MONOCROMÁTICA. 5. FUENTE DE PODER ININTERRUMPIBLE 6. MUEBLE PARA LA PC DEL MAESTRO

45 cm 120 cm

75 cm



73

ANEXO 2. GRAFICO DE MANEJO DE INCIDENTES SABT



74

ANEXO 3. PROCESO DE REGISTRODE INCIDENTES SABT

La MSSC notifica un Incidente con su respectivo número de ticket al proveedor adjudicado. A partir de esta notificación se contabilizan los tiempos de atención y resolución para el Incidente con NT, como se describe en la sección 6.1. La notificación será preferentemente de manera electrónica aunque podrá realizarse por cualquier otro medio que la MSSC tenga a su disposición en el momento de reportar el Incidente. El proveedor adjudicado es notificado del NT, regresa acuse de recibo a la MSSC, atiende y resuelve el Incidente en los plazos establecidos en la sección 6.1. El proveedor adjudicado deberá notificar la solución del Incidente, integrar el expediente con la información comprobatoria y justificativa que soporte la atención y resolución del NT y lo remite a la MSSC. La MSSC valida la información, determina si aplican penas convencionales en término de lo establecido en la sección 5 y, en su caso, cierra el NT.



75

ANEXO 4. CICLO DE VIDA DE LOS REPORTES DE ATENCIÓN / INCIDENTES CON NT DE SABT



76

ANEXO 5. PROCESO DE TIEMPO PARA LA ATENCION DE INCIDENTES



77

ANEXO 6. CARTA DE AUTORIZACION DE AUDITORIA

Oficio No. 01/ECA/03/2012

Asunto: Se ordena inicio de auditoría

México, D. F., a 1 de marzo de 2012

ING. JOAB CERVANTES BERCHIMAN COORDINADOR GENERAL DE TECNOLOGIAS DE INFORMACIÓN GRUPO BIZ. P R E S E N T E

Con fundamento en lo dispuesto en los artículos 34, fracciones II, III, IX, XI y XII de la Ley Orgánica de la Administración Pública del Distrito Federal; 111, fracciones I, IV, V, VI, VII, VIII, X, XIII Y XIV, del Reglamento Interior de la Administración Pública del Distrito Federal, 512, 513 y 513 fracción I del Código Financiero del Distrito Federal para el 2012 y 59 párrafo primero del Decreto de Presupuesto de Egresos del Distrito Federal para el Ejercicio 2012, se llevará a cabo la auditoría número AU-SABT-03/12, denominada “Requerimientos Técnicos para el Servicio de Aula Base Telemática (SABT) de la SEP”, cuyo objetivo es verificar que el documento que se utiliza para la licitación de SABT de la SEP este alineado con el manual de mejores practicas de ITIL V3 dentro del apartado Incident Management .

Para tal efecto, Grupo Biz ha designado para su realización a la Lic. Mariana Maravilla

Ramírez como Responsable de la Auditoria, al Ing. Gabriel Carlos Anaya como Coordinador de la misma, y a las Ing. Elbin Adeli Martínez López, Iris Guadalupe Soto Mata y Marlene Becerril Castillo como auditores comisionados para la ejecución de la auditoría, por lo que se solicita el Requerimiento Técnico de SABT, así como también la documentación conformada por registros, reportes, informes, manuales, y demás efectos relativos a la operación y todos los datos e información que se soliciten para la ejecución de la auditoría.

La auditoría iniciará a la presentación de este documento y revisará lo correspondiente

en un periodo de marzo del 2012 a Abril del 2012, lo cual es enunciativo, más no limitativo, ya que el período y objetivo de la auditoría podrán ser ampliados según se considere pertinente.

Sin otro particular, quedo de usted.

A T E N T A M E N T E

Lic. Mariana Maravilla Ramírez Responsable de la Auditoria



78

ANEXO 7. CARTA DE PLANEACIÓN

CARTA DE PLANEACIÓN

SERVICIO AULA BASE TELEMÁTICA.

No. de auditoría: AU-SABT-03/12 Área a auditar: Requerimientos técnicos de SABT de la

SEP

Fecha: 01/MARZO/2012

Clave y rubro

auditado:

Soporte a Tecnologías de la Información. Bimestre Segundo

Antecedentes

No se cuenta con antecedentes de auditorías en éste rubro efectuadas al Requerimiento del Servicio de Aula Base Telemática de la Secretaria de

Educación Pública.

Objetivo de la auditoría

Auditar los requerimientos técnicos para el Sistema de Aula Base Telemática (SABT) de la Secretaria de Educación Pública y verificar que

cumplan con el manual de mejores prácticas de ITIL V3 dentro del apartado Incident Management.

Alcances / Universo

La auditoria se basa en el documento de «requerimientos técnicos para el Servicio Aula Telemática» que envía la Secretaria de Educación

Publica para la concurso de licitación del servicio para el periodo escolar 2012-2013.

Muestra

Para la auditoria solo se toma en cuenta el capitulo 4,8 y el anexo 1, que son los que directamente se relacionan con la gestión de incidentes de TI.

Problemática

La principal problemática que se tiene en este proyecto es el no tener acceso a información detallada para realizar una auditoria más a

fondo puesto que el documento no especifica los detalles sin embargo cuenta con estadísticas que proporcionan datos generales.

Estrategia / Procedimientos

Su inicio se formalizará mediante la orden y la firma del acta respectiva, en ese mismo acto será entregada la solicitud de información; la cual,

una vez proporcionada, será analiza cuantitativa y cualitativamente a efecto de realizar las pruebas sustantivas y de cumplimiento. Posterior al

análisis y demás procedimientos y técnicas de auditoría aplicados, se recabará únicamente la documentación que sustente los hallazgos detectados

que deberán ser incluidos en el Reporte e Informe de Observaciones.

La auditoría está planeada y calendarizada sistemáticamente; su ejecución se realiza conforme a los preceptos y técnicas establecidos en la Guía

General de Intervenciones, las Normas de Auditoría generalmente aceptadas y los formatos para tal efecto establecidos; el análisis cuantitativo y

cualitativo de la información, así como las entrevistas y/o cuestionarios a aplicar a los responsables de la función, servirán para identificar, entre

otros aspectos:

El área, sus procesos e información general y detallada, para determinar las pruebas a realizar.

Los puntos críticos de los controles para la gestión de incidencias generales, entrada, tratamiento, actualización y salida de datos, así como

los controles de seguridad y documentales.

Personal Comisionado:

Nombre Cargo Firma

Mariana Maravilla Ramírez Responsable de la Auditoria

Gabriel Carlos Anaya Coordinador de la Auditoria

Elbin Adeli Martínez López Auditor 1

Marlene Becerril Castillo Auditor 2

Iris Guadalupe Soto Mata. Auditor 3

Elaboró:

LIC. MARIANA MARAVILLA

RAMÍREZ

Vo. Bo. del responsable:

ING. JOAB CERVANTES BERCHIMAN

Nombre y firma Nombre y firma



79

ANEXO 8. SUPERVICION INTEGRACIÓN DE EXPEDIENTE SUPERVISIÓN DE LA INTEGRACIÓN DEL EXPEDIENTE DE LA AUDITORÍA

Dependencia: Grupo Biz.

Área auditada: Requerimientos Técnicos de SABT de la SEP

Número de auditoría: AU-SABT-03/12

Fecha de inicio: 01 de Marzo del 2012 Fecha de término: 21 de abril del 2012

Personal participante: Mariana Maravilla Ramírez, Gabriel Carlos Anaya, Elbin Adeli Martínez López, Marlene Becerril Castillo,

Iris Guadalupe Soto Mata.

CONCEPTO

EVALUACIÓN

COMENTARIOS

SI NO N/A

1. ¿Se encuentra en el expediente de la auditoría la Carta de

Planeación autorizada por el coordinador responsable de la

revisión?

x

2. ¿En la carta de Planeación para auditar cada rubro, se

incluyó el universo de las operaciones, los alcances, las

muestras y los procedimientos?

x

3. ¿Se cumplió con el Programa de Trabajo? x

4. ¿Fueron adecuadas las bases para determinar los alcances y

muestras de la auditoría? x

5. ¿La auditoría se realizó conforme a lo establecido en las

mejores prácticas de ITIL V3 y los formatos establecidos

de auditoría?

x

6. ¿Se encuentran en papeles de trabajo bien definidos y

soportados legalmente las observaciones determinadas? x

7. ¿Existe evidencia fehaciente de que se hayan revisado los

papeles de trabajo de la auditoría?

x

8. ¿Los papeles de trabajo fueron elaborados de acuerdo con

las especificaciones de la Guía respectiva, incluyendo

cruces, marcas y notas aclaratorias y mostrando claramente

los procedimientos utilizados?

x

9. ¿Se observó durante el desarrollo de la auditoría el apego a

las Normas de Auditoría? x

10. ¿Se cuenta en el expediente con el informe o el proyecto

respectivo en donde consten las observaciones

determinadas en la auditoría?

x

11. ¿Los expedientes de la auditoría están debidamente

integrados y completos? x

Elaboro

LIC. MARIANA MARAVILLA

RAMÍREZ

Vo. Bo. del

responsable:

ING. JOAB CERVANTES BERCHIMAN

NOMBRE Y FIRMA NOMBRE Y FIRMA



80

ANEXO 9. CRONOGRAMA DE TRABAJO



81

ANEXO 10. ACTA DE REUNION DE EQUIPO AUDITOR

MINUTA DE LA REUNIÓN DE TRABAJO CON MOTIVO DEL INICIO DE LA AUDITORÍA NÚMERO AI-DET-02/07 “REQUERIMINTOS TECNICOS DE SABT”, PARA VERIFICAR UE

CUMPLAN LAS MEJORES PRACTICAS DE ITIL V3. Fecha: 02 de marzo del 2012 Hora de inicio: 18:15 horas Hora de término: 22:00 horas

1.- ASISTENTES:

Mariana Maravilla Ramírez Responsable de la Auditoria

Gabriel Carlos Anaya Coordinador de la Auditoria

Elbin Adeli Martínez López Auditor 1

Marlene Becerril Castillo Auditor 2

Iris Guadalupe Soto Mata. Auditor 3

2.- ASUNTOS A TRATAR

A. PROGRAMA ESPECÍFICO DE AUDITORÍA

O B J E T I V O: Auditar los requerimientos técnicos para el Sistema de Aula Base Telemática (SABT) de la Secretaria de Educación Pública y verificar que cumplan con el manual de mejores prácticas de ITIL V3 dentro del apartado Incident Management D E P E N D E N C I A: Grupo Biz. O B J E T I V O S E S P E C Í F I C O S: Auditar específicamente: - Capitulo 4,8 y el anexo 1, de los Requerimientos Técnicos del Servicio de una Aula Base Telemática de la Secretaria de Educación Pública que son los que directamente se relacionan con la gestión de incidentes de TI. A L C A N C E: La auditoría se basa en el documento de requerimientos técnicos para el Servicio ABT que se envía para licitar el servicio.

B. PLANEACION ACTIVIDADES:

a) Estudio general del documento a Auditar b) Conocer marco normativo aplicable y antecedentes. c) Elaboración de la carta de planeación d) Carta de planeación



82

e) Elaborar cronograma y programa específico de auditoría f) Programa especifico g) Preparar y turnar a firma la orden de auditoría h) Orden de inicio i) Preparar y turnar a firma oficio de solicitud de inf. y doctos. j) Oficio de petición k) Preparar acta de inicio de auditoría l) Acta de inicio

C. EJECUCIÓN:

ACTIVIDADES:

a) Reunión de notificación de inicio de auditoría b) Informar al área el objetivo de la verificación c) Entrega de orden de inicio de auditoría d) Recabar sello y firma del Titular e) Levantamiento de acta de inicio de auditoría f) Recabar firma de Titular y Encargado de atender la auditoría g) Entrega de oficio de requerimiento de inf. y documentación h) Recabar sello de recibido de la petición i) Entrevistas con responsables de la actividad j) Recabar información sustantiva del área operativa k) Análisis de la información l) Elaborar cédulas de análisis4 m) Evaluación del control interno n) Elaborar cédulas de análisis de la información sustantiva o) Pruebas sustantivas y de cumplimiento. p) Comprobar la correcta ejecución de las actividades q) Identificación de irregularidades r) Documentación y comprobación de hallazgos s) Reunión para comentar irregularidades t) Comentar con el área la situación de los hallazgos.

D. ELABORACIÓN Y PRESENTACIÓN DE INFORMES

ACTIVIDADES:

1) Elaboración de los reportes de observaciones 2) Reporte de observaciones 3) Elaboración del informe de auditoría 4) Informe final de resultados. 5) Reunión de confronta y levantar acta de cierre de auditoría 6) Informar resultados y recabar fecha compromiso atención



83

7) Elaborar oficio de envío de informe y reportes de auditoría 8) Oficializar envío del Informe y reportes de auditoría

Elaboró Revisó C. Mariana Maravilla Ramírez C. Gabriel Carlos Anaya Responsable de la Auditoria Coordinador de la Auditoria

Autorizó Ing. Joab Cervantes Berchiman

Coordinador General de Tecnologías de la Información de Grupo Biz.



84

ANEXO 11. ACTA DE CIERRE DE AUDITORIA No de Oficio: 04/ECA/03/2012

México, D. F., a 21 de abril del 2012

Asunto: Acta de cierre de auditoría

ING. JOAB CERVANTES BERCHIMAN COORDINADOR GENERAL DE TECNOLOGIAS DE INFORMACIÓN GRUPO BIZ. P R E S E N T E

De conformidad con lo establecido en los artículos 34, fracciones II, III, IX, XI y XII de la

Ley Orgánica de la Administración Pública del Distrito Federal; 111, fracciones I, IV, V, VI, VII, VIII, X, XIII, XIV del Reglamento Interior de la Administración Pública del Distrito Federal, 512 y 514 del Código Financiero del Distrito Federal para el 2012, y en referencia al oficio 03/ECA/03/2012 , de fecha 9 de noviembre de 2012, mediante el cual se comunicó la práctica de la auditoría número AU-SABT-03/12, denominada “Requerimientos Técnicos de SABT de la SEP”. Específicamente para verificar que el documento de los Requerimientos SABT cumpla con las mejoras practicas de ITIL V3 para obtener la licitación de la SEP y hacer la diferencia entre las 80 empresas que participan , para que con esto el servicio cuente con la confiabilidad de la operación en sus aspectos de los elementos tecnológicos de ABT,el software académico, el software de monitoreo y el medio de monitoreo ; remito el reporte que contiene las observaciones detectadas, efectos y recomendaciones que se consideran procedentes para mejorar el Requerimiento SABT, así como el informe de los resultados obtenidos, mismo que contiene el objetivo y alcance de la auditoría, las observaciones generadas, las conclusiones obtenidas y las recomendaciones , se estimó pertinente hacerlo de su conocimiento a fin de coadyuvar a mantener la transparencia, legalidad, eficacia, imparcialidad y eficiencia de su gestión, así como el adecuado control interno del servicio encomendado .

De los resultados obtenidos, se considera relevante señalar por su importancia, que el

escalonamiento para la atención de incidentes no específica como es, que se tiene que realizar. Dentro de este mismo rubro el documento no especifica que el centro de servicio encargado sea capaz de evaluar en primera instancia si el servicio requerido se incluye el SLA del cliente y en caso contrario reenviarlo a una autoridad competente, por lo cual aquí se podrían generar los lineamientos que nos ayuden a atacar este punto. Es necesario definir e implementar las políticas, lineamientos y procedimientos que permitan una operación estructurada, eficiente y consistente, alineada a las necesidades de las áreas usuarias a las que se atiende, a efecto de contribuir al logro de las metas y objetivos. Se sugiere como relevante la observancia de la normatividad oficial aplicable en la materia y la adopción de marcos de referencia internacionales, los cuales permitirán mejorar su operación.



85

Las dos observaciones fueron comentadas a los responsables, mismos que signaron

los reportes que se remiten, señalándose la fecha compromiso para su atención tal y como quedó asentado en los reportes de referencia, solicitando atentamente que la documentación que se envíe a Grupo Biz para solventar las citadas observaciones y estas sean en copias debidamente certificadas por el Coordinador General de Tecnologías de la Información que cuenta con facultades para ello.

Asimismo, le agradezco las facilidades otorgadas y la colaboración brindada al grupo

de auditores designado para llevar a cabo la auditoría aludida por parte de Grupo Biz que nos atendieron, esperando que los resultados y recomendaciones de la auditoría coadyuven a una mejor aportación para mejorar el Requerimiento de Servicio Aula Base Telemática.

Sin más por el momento, reitero a usted mi distinguida consideración.

A T E N T A M E N T E

Lic. Mariana Maravilla Ramírez Responsable de la Auditoria

ANEXO: UN SOBRE CERRADO



86

INDICE DE FIGURAS

Figura 1.1 Estructura de la seguridad informática ................................................................... 14

Figura 2.1 Gestión de servicios TI ........................................................................................... 40 Figura 2.2 Gestión de Incidentes ............................................................................................. 43 Figura 2.3 Diagrama de prioridades ........................................................................................ 45 Figura 2.4 Proceso de escalado .............................................................................................. 46 Figura 2.5 Proceso de la Gestión de Incidentes ...................................................................... 46

INDICE DE TABLAS

Tabla 1.1 Indicadores de Gestion ............................................................................................. 24

Tabla 5.1 Niveles de Accesibilidad .......................................................................................... 59 Tabla 5.2 Elementos de Criticidad ........................................................................................... 60

Tabla 5.3 Índice de tiempo de respuesta para la atención y Resolución de Incidentes ........... 60



87

GLOSARIO

Termino Significado

ABT Aula Base Telemática, es el aula de 5° y 6° de primaria que tiene instalados los “elementos tecnológicos de ABT”.

Acuerdos de niveles de servicio (SLAs)

Son los indicadores sobre los niveles y métricas de cumplimiento asociadas al servicio a ser prestado por parte del proveedor adjudicado.

Aula Lista Se refiere aquella aula de 5° y 6° de primaria notificadas por la SEP para instalar una ABT y que cuenta con las siguientes características: Construcción: • Paredes de adoquín, ladrillo, concreto, tablaroca, adocreto omateriales similares. • Techo impermeabilizado • Acabado enyesado liso, pintura o directamente del material • Piso de concreto, cemento o material similar • Vidrios o celosías y ventanas colocadas • Puerta de acceso Seguridad: • Puerta con chapa o candado • Ventanas aseguradas y colocadas con vidrios o celosías Energía eléctrica: • Tomacorriente doble polarizado (mínimo 1, de preferencia 2) • 120 Volts CA +/- 13% a 60 Hz de frecuencia • Cableado eléctrico hasta el aula calibra 14

Autoridad estatal Significa las autoridades educativas de la Entidad Federativa, designadas como representantes de la Secretaría en materia educativa

Caso fortuito o de fuerza mayor

Se considerará caso fortuito los hechos de la naturaleza que impiden o retardan el cumplimiento de la obligación, y al caso de fuerza mayor se le identifica con acciones del hombre que obran el mismo efecto.

CCT Siglas de Clave de Centro de Trabajo que es el identificador único que utiliza la Secretaría para las escuelas en el país.

Elementos del servicio

Se refiere a todos y a cada uno de los diferentes elementos que conforman el SABT.

Elementos tecnológicos

Son todos aquellos elementos de hardware y software que se encuentran instalados y configurados dentro del SABT.

Elementos tecnológicos de ABT

Son todos aquellos elementos de hardware y software: PC del maestro, pizarrón interactivo, equipo proyector, impresora monocromática y fuente de poder ininterrumpible; y el mueble de la PC del maestro.

Entidades federativas Se refiere a los treinta y un (31) Estados y un (1) Distrito Federal que conforman la República Mexicana.

Falta Se considera una falta en el cumplimiento del contrato de servicio cuando el proveedor adjudicado NO cumple con los períodos definidos en el Anexo Técnico sobre: la atención y resolución, notificación y comprobación de Incidentes; la instalación de ABT; la entrega de información detallada de ABT instalados para el cierre del contrato.

Falta grave Se considera falta grave en el cumplimiento del contrato cuando, se reiteran las faltas o afectan a la disponibilidad del servicio.



88

Termino Significado

Incidente Se entenderá como cualquier evento que impacte de manera negativa la funcionalidad o disponibilidad de una ABT.

Incidente resuelto Se refiere cuando el proveedor adjudicado da solución al Incidente que generó un ticket.

Incidente sin atención Se refiere al incumplimiento del proveedor adjudicado de los plazos establecidos para atender y resolver o notificar y comprobar comoresuelto un ticket de un Incidente.

MSSC Mesa de Soporte y Servicio Central definida por la Secretaría.

Número de Ticket (NT o TICKET)

Un número que se asigna a cada uno de los Incidentes registrados en la MSSC, que permite identificarlos permanentemente y turnarlo al proveedor adjudicado. En caso de controversias son considerados prueba plena.

Penas Se entiende como la sanción económica por incumplimiento en la prestación del servicio de acuerdo a los niveles de servicio y la resolución de Incidentes.

Registro de Incidentes Acción mediante la cual la MSSC turna al proveedor adjudicado un Incidente identificado por su NT con el que se registró.

SABT Servicio de Aula Base Telemática, se refiere a todos los servicios descritos en éste Anexo Técnico.

Secretaría o SEP Se refiere a la Secretaría de Educación Pública.

Software de monitoreo

Se refiere a un sistema de monitoreo que se incorporan a una ABT con el objeto de contar con información sobre el estado que guardan los elementos tecnológicos.

Software académico Se refiere a las acciones que el proveedor adjudicado deberá realizar para mantener las ABT disponibles.

TIC Tecnologías de la Información y Comunicaciones.

Versión electrónica del software

académico

Significa el archivo o conjunto de archivos que forman una versión del software académico, la cual puede o no contar con un software de instalación.



89

BIBLIOGRAFIA

PAGINAS

http://www.airac.org/Actividades%20de%20la%20Asocacion/Talleres%20y%20Seminarios/Tec.de%20Informacion/Auditoria%20de%20la%20tec.de%20informacion.pdf

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_la_continuidad_del_servicio/proceso_gestion_de_la_continuidad_del_servicio/evaluacion_riesgo_continuidad_del_servicio.php

http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/fundamentos_de_la_gestion_TI/que_es_ITIL/que_es_ITIL.php

http://enciclomediaylaensenanza.blogspot.mx/2009/12/no-8-integracion-educativa-en-mexico-y.html

http://www.consorcio-grupo.biz/

http://www.hdt.gob.mx/hdt/assets/HDT/Faseexperimental.pdf

www.sepiensa.org.mx/

http://redescolar.ilce.edu.mx

http://edusat.ilce.edu.mx

www.enciclomedia.edu.mx LIBROS

ITIL version3: el manual de las buenas prácticas de ITIL, Maria Del Pilar Patiño, universidad nacional de colombia marzo de 2010

Formación ITIL versión 3 Fundamentos de la Gestión de Servicios TI

Secretaría de Educación Pública (2009), “Proyecto Aula Telemática: Informe de Resultados 2008”, Coordinación Nacional del Programa Habilidades Digitales para Todos, Dirección General de Materiales Educativos, Subsecretaría de Educación Básica, mayo.

López Sanjurio Catherin tecnologías de la información: Conceptos básicos. Primera edición, España 2004

Jan Van Bon FUNDAMENTOS DE LA GESTION DE SERVICIOSDE TI BASADA EN ITIL V3. Tercera edición, Holanda 2008

Secretaría de Educación Pública PROGRAMA ENCILOMEDIA: Libro blanco 2006

Universidad tecnológica de Nezahualcóyotl Organismo público descentralizado del gobierno del estado de méxico EVALUACIÓN DE LA FASE EXPERIMENTAL DEL PROYECTO "AULA TELEMÁTICA. México 2010










http://www.consorcio-grupo.biz/

http://www.hdt.gob.mx/hdt/assets/HDT/Faseexperimental.pdf

http://www.sepiensa.org.mx/

http://redescolar.ilce.edu.mx/

http://edusat.ilce.edu.mx/

http://www.enciclomedia.edu.mx/

AUDITORIA A LOS REQUERIMIENTOS TECNOLOGICOS PARA …

Documents

Transcript of AUDITORIA A LOS REQUERIMIENTOS TECNOLOGICOS PARA …