tesis en la ucv piura

Universidad César Vallejo – Piura Escuela de Ingeniería de Sistemas

Auditoría Gestión en Redes- OTI-Piura 1 Burgos & Namuche

UNIVERSIDAD CÉSAR VALLEJO

PIURA

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA DE SISTEMAS

EVALUACIÓN DE LA GESTIÓN EN REDES, COMUNICACIONES Y

SERVIDORES EN LA OFICINA DE TECNOLOGÍAS DE

INFORMACIÓN DE LA UNIVERSIDAD CÉSAR VALLEJO – PIURA

MEDIANTE LA APLICACIÓN DE UNA AUDITORÍA INFORMÁTICA

BASADA EN COBIT

Tesis para obtener el Título Profesional de Ingeniero de Sistemas

Autores

Jorge Armando Burgos Merino

Adrián Leonardo Namuche Correa

Asesor

Ing. CIP. Mario Nizama Reyes

Piura-Perú

2011



EVALUACIÓN

TÍTULO:

EVALUACIÓN DE LA GESTIÓN EN REDES, COMUNICACIONES Y

SERVIDORES EN LA OFICINA DE TECNOLOGÍAS DE INFORMACIÓN DE LA

UNIVERSIDAD CÉSAR VALLEJO-PIURA MEDIANTE LA APLICACIÓN DE UNA

AUDITORÍA INFORMÁTICA BASADA EN COBIT

AUTORES:

BURGOS MERINO, JORGE ARMANDO

NAMUCHE CORREA, ADRIÁN LEONARDO

ASESOR:

___________________________

ING. CIP MARIO NIZAMA REYES

JURADOS:

____________________________ ______________________________

JURADO 01 JURADO 02

____________________________

JURADO 03



DEDICATORIA

A nuestros profesores, por brindarnos sus conocimientos,

guía y apoyo para ejercer con éxito esta maravillosa

profesión.

A nuestros padres, por brindarnos su apoyo y por su

preocupación de que nosotros seamos mejores personas

A Dios, por darnos esta maravillosa vida que apenas

estamos empezando a vivir.



AGRADECIMIENTOS

Agradecemos a la Universidad César Vallejo – Filial Piura, al personal de las subáreas de

redes y soporte de la Oficina de Tecnologías de Información a nuestro asesor

especialista, y al asesor metodológico quienes nos han apoyado para poder culminar esta

investigación que ayudará a mejorar la evaluación de la gestión de redes,

comunicaciones y servidores que realiza la Oficina de Tecnologías de Información.



PRESENTACIÓN

Señores Miembros del Jurado:

Colocamos en sus manos, el presente el trabajo de Investigación, cuyo título es

“Evaluación de la Gestión en Redes, Comunicaciones y Servidores en la Oficina de

Tecnologías de Información de la Universidad César Vallejo – Piura mediante la

aplicación de una Auditoría Informática basada en COBIT”, el mismo que solicitamos sea

aceptado para su sustentación y defensa.

Esperando contar con una respuesta aprobatoria a lo solicitado, nos despedimos.

Atentamente.

____________________________ ______________________________

Jorge Armando Burgos Merino Adrián Leonardo Namuche Correa

DNI: 70482758 DNI: 46042820



Índice

CAPÍTULO I .................................................................................................................................... 23

GENERALIDADES ........................................................................................................................ 23

1.1. Titulo: ............................................................................................................................... 24

1.2. Tipo de Investigación: ................................................................................................... 24

1.3. Área de Investigación: .................................................................................................. 24

1.4. Localidad o institución donde se realiza la investigación: ....................................... 24

1.5. Autores: ........................................................................................................................... 24

1.6. Asesor: ............................................................................................................................ 24

1.7. Duración del Proyecto: ................................................................................................. 24

CAPÍTULO II .................................................................................................................................. 25

PLAN DE INVESTIGACIÓN ........................................................................................................ 25

2.1. Descripción de la Realidad Problemática .................................................................. 26

2.2. Formulación del Problema ........................................................................................... 29

2.2.1. Pregunta General .................................................................................................. 29

2.2.2. Preguntas de Investigación .................................................................................. 29

2.3. Objetivos ..................................................................................................................... 29

2.3.1. Objetivo General .................................................................................................... 29

2.3.2. Objetivos Específicos ............................................................................................ 29

2.4. Justificación de la Investigación .................................................................................. 30

2.5. Limitaciones de la Investigación ................................................................................. 30

2.6. Marco Referencial Científico ........................................................................................ 31

2.6.1. Antecedentes (internacional, nacional, regional y local) ................................. 31

2.7. Marco Teórico ................................................................................................................ 36

2.7.1. La Institución: La Universidad César Vallejo Piura ......................................... 36

2.7.2. Oficina de Tecnologías de Información .............................................................. 39

2.7.3. Descripción de la Red de la Universidad César Vallejo – Filial Piura. .......... 42

2.7.4. La Gestión de Redes, Comunicaciones y Servidores ..................................... 43

2.7.5. El Control Interno Informático y la Auditoría Informática ................................. 48

2.7.6. La Auditoría en Redes .......................................................................................... 51

2.7.7. COBIT y otros estándares aplicados a auditoría informática ......................... 53

2.8. Marco Conceptual ......................................................................................................... 56



2.8.1. Auditoría Informática ............................................................................................. 56

2.8.2. Control Interno ....................................................................................................... 57

2.8.3. COBIT ...................................................................................................................... 57

2.8.4. Red Informática ...................................................................................................... 58

2.9. Hipótesis ......................................................................................................................... 58

2.10. Variables e Indicadores ............................................................................................ 58

2.10.1. Variables ................................................................................................................. 58

Variable Independiente ................................................................................................. 58

Variable Dependiente ................................................................................................... 59

Variable Interviniente .................................................................................................... 59

2.10.2. Indicadores ......................................................................................................... 59

CAPÍTULO III ................................................................................................................................. 63

METODOLOGÍA ............................................................................................................................ 63

3.1. Tipo de Estudio .............................................................................................................. 64

3.2. Diseño del Estudio......................................................................................................... 64

3.3. Población y Muestra ...................................................................................................... 65

3.4. Métodos de Investigación............................................................................................. 65

3.5. Técnicas e instrumentos de recolección de datos ................................................... 66

3.6. Métodos de análisis de datos ...................................................................................... 69

CAPÍTULO IV ................................................................................................................................. 70

DESARROLLO DE LA PROPUESTA ........................................................................................ 70

4.1. Introducción .................................................................................................................... 71

4.2. Planificación de la Auditoría ......................................................................................... 73

4.2.1. Definición del Objetivo y alcance de la auditoria .............................................. 73

4.2.2. Análisis del ambiente a auditar............................................................................ 78

4.2.3. Actividades a realizar en la Auditoría ................................................................. 83

4.2.4. Recursos a utilizar en la Auditoría Informática ................................................. 88

4.3. Ejecución de la Auditoría .............................................................................................. 90

4.3.1. Evaluación del Entorno de Control ..................................................................... 90

4.3.2. Evaluación de la Gestión de Riesgos ............................................................... 103

4.3.3. Evaluación de las Actividades de Control Interno de la Gestión de la Red.

114

CAPÍTULO V ................................................................................................................................ 168

RESULTADOS ............................................................................................................................. 168



5.1. Marco Lógico ................................................................................................................ 169

5.2. Comparación de la situación actual con la situación deseada ............................. 171

5.3. Plan de Mejora ............................................................................................................. 186

5.3.1. Indicador N° 01: Número de procesos críticos de negocio no incluidos en un

plan de contingencia. (NPC) .............................................................................................. 186

5.3.2. Indicador N° 02: Porcentaje de Incidentes de Red resueltos en un tiempo

óptimo (PIR) ......................................................................................................................... 187

5.3.3. Indicador N° 03: Número promedio de horas perdidas por usuario al mes,

debido a interrupciones de red (NHP) .............................................................................. 190

5.3.4. Indicador N° 04: Número de controles aplicados a terceros (NCT) ............ 192

5.3.5. Indicador N° 05: Porcentaje de inversión para cubrir los costos en TI (PIATI)

193

5.3.6. Indicador N° 06: Número promedio de veces por mes que se ha realizado

mantenimiento a la red (NMR) .......................................................................................... 194

5.3.7. Indicador N° 07: Número de controles físicos para garantizar la continuidad

del servicio (NCF) ................................................................................................................ 195

5.3.8. Indicador N° 08: Número de controles lógicos para garantizar la continuidad

del servicio (NCL) ................................................................................................................ 197

5.3.9. Indicador N° 09: Nivel de Madurez de la Gestión de Redes de la OTI

(NMGR) 198

5.4. Post-Test ....................................................................................................................... 199

5.4.1. Indicador N° 01: Número de procesos críticos de negocio no incluidos en un

plan de contingencia. (NPC). ............................................................................................. 199

5.4.2. Indicador N° 02: Porcentaje de incidentes de red resueltos en un tiempo

óptimo (PIR) ........................................................................................................................ 201

5.4.3. Indicador N° 03: Número promedio de horas perdidas por usuario al mes,

debido a interrupciones a la red. (NHP) ......................................................................... 201

5.4.4. Indicador N° 04: Número de controles aplicados a servicios de terceros.

(NCT) 202

5.4.5. Indicador N° 05: Porcentaje de inversión para cubrir los costos en TI (PIATI)

203


mantenimiento a la red (NMR) .......................................................................................... 204

5.4.7. Indicador N° 07: Número de controles físicos para garantizar la continuidad

del servicio (NCF) ................................................................................................................ 205

5.4.8. Indicador N° 08: Número de controles Lógicos para garantizar la continuidad

del servicio (NCL) ................................................................................................................ 206

5.4.9. Indicador N° 09: Nivel de madurez de la gestión de redes de la OTI (NMGR)

207



CAPÍTULO VI ............................................................................................................................... 209

CONCLUSIONES Y RECOMENDACIONES .......................................................................... 209

6.1. Conclusiones ................................................................................................................ 210

6.2. Contrastación de Hipótesis ........................................................................................ 211

6.3. Recomendaciones ....................................................................................................... 211

CAPÍTULO VII .............................................................................................................................. 214

REFERENCIAS BIBLIOGRÁFICAS ......................................................................................... 214

ANEXOS ....................................................................................................................................... 220

ANEXO 1 ................................................................................................................................. 221

CUADRO DE CONSISTENCIA DEL PROYECTO ............................................................ 221

ANEXO 2 .................................................................................................................................. 223

ENCUESTA: DOCUMENTACIÓN MANEJADA POR LA OFICINA DE TECNOLOGÍAS

DE LA INFORMACIÓN (OTI) DE LA UCV - PIURA .......................................................... 223

ANEXO 3 .................................................................................................................................. 225

SOLICITUD 01: FACILIDADES PARA REVISAR DOCUMENTACIÓN ......................... 225

ANEXO 4 .................................................................................................................................. 226

SOLICITUD 02: FACILIDADES PARA REVISAR REGISTROS DE INCIDENTES ..... 226

ANEXO 5 .................................................................................................................................. 227

FICHAS BIBLIOGRÁFICAS ................................................................................................... 227

ANEXO 6 .................................................................................................................................. 229

GUÍA DE ENTREVISTA N°01: APLICACIÓN DE POLÍTICAS Y PROCEDIMIENTOS

DE SEGURIDAD EN EL ÁREA DE REDES DE LA OFICINA DE TECNOLOGÍAS DE

INFORMACIÓN ....................................................................................................................... 229

ANEXO 7 .................................................................................................................................. 231

GUÍA DE ENTREVISTA N°02: APLICACIÓN DE GESTIÓN DE RIESGOS Y PLAN DE

CONTINGENCIA EN EL ÁREA DE REDES DE LA OFICINA DE TECNOLOGÍAS DE

INFORMACIÓN ....................................................................................................................... 231

ANEXO 8 .................................................................................................................................. 234

GUÍA DE ENTREVISTA N°03: EVALUACIÓN DE LA ATENCIÓN DE INCIDENTES EN

LA RED ..................................................................................................................................... 234

ANEXO 9 ................................................................................................................................. 235

GUÍA DE ENTREVISTA N°04: MANTENIMIENTO A LA RED DE LA UNIVERSIDAD

.................................................................................................................................................... 235

ANEXO 10 ............................................................................................................................... 236

GUÍA DE ENTREVISTA N°05: CONTROLES FÍSICOS IMPLEMENTADOS EN LA RED

DE LA UNIVERSIDAD ............................................................................................................ 236



ANEXO 11 ............................................................................................................................... 237

GUÍA DE ENTREVISTA N°06: CONTROLES LÓGICOS IMPLEMENTADOS EN LA

RED DE LA UNIVERSIDAD .................................................................................................. 237

ANEXO 12 ............................................................................................................................... 238

GUÍA DE ENTREVISTA N°07: EVALUACIÓN DE CONTROLES APLICADOS A

TERCEROS .............................................................................................................................. 238

ANEXO 13 ............................................................................................................................... 239

CUESTIONARIO Nº01: GESTIÓN DE RIESGOS DE RED ............................................. 239

ANEXO 14 ............................................................................................................................... 240

CUESTIONARIO Nº02: MANTENIMIENTO DE LA RED .................................................. 240

ANEXO 15 ............................................................................................................................... 241

CUESTIONARIO Nº03: CUESTIONARIO Nº04: INVERSIÓN EN TI (REDES) ............ 241

ANEXO 16 ............................................................................................................................... 242

PROYECTO Nº01 ................................................................................................................... 242

ANEXO 17 ............................................................................................................................... 245

PROYECTO Nº02 ................................................................................................................... 245

ANEXO 18 ............................................................................................................................... 248

PROYECTO Nº03 ................................................................................................................... 248

ANEXO 19 ............................................................................................................................... 251

PROYECTO Nº04 ................................................................................................................... 251

ANEXO 20 ............................................................................................................................... 254

PROYECTO Nº05 ................................................................................................................... 254

ANEXO 21 ............................................................................................................................... 256

PROYECTO Nº06 ................................................................................................................... 256

ANEXO 22 ............................................................................................................................... 258

PROYECTO Nº07 ................................................................................................................... 258

ANEXO 23 ............................................................................................................................... 260

PROYECTO Nº08 ................................................................................................................... 260

ANEXO 24 ................................................................................................................................ 262

GUÍA DE ENTREVISTA N°08 ............................................................................................... 262

ANEXO 25: GUÍA DE OBSERVACIÓN N°01 ..................................................................... 263

ANEXO 26: GUÍA DE OBSERVACIÓN N°02 ..................................................................... 265

ANEXO 27 ................................................................................................................................ 267

GUÍA DE OBSERVACIÓN N°03 ........................................................................................... 267

ANEXO 28 ................................................................................................................................ 268



PRESUPUESTO ...................................................................................................................... 268

ANEXO 29 ................................................................................................................................ 269

CRONOGRAMA DE ACTIVIDADES .................................................................................... 269

ANEXO 30 ................................................................................................................................ 270

CONSTANCIA DE DESARROLLO DE TESIS ................................................................... 270

ANEXO 31 ................................................................................................................................ 271

CARTA DE PRESENTACIÓN DE INFORME DE AUDITORÍA ....................................... 271



Índice de Tablas

Tabla N°01: Tabla de Indicadores del Proyecto ...................................................................... 61

Tabla N°02: Personal (población) para medir los instrumentos de investigación (OTI -

Piura). .......................................................................................................................................... 64

Tabla N°03: Técnicas e Instrumentos usados ......................................................................... 68

Tabla N°04: Plan de Trabajo de la Auditoría Informática ....................................................... 72

Tabla N°05: Comparación de los indicadores del proyecto con los procesos de COBIT

(Dominio: Dar Soporte) ............................................................................................................. 77

Tabla N°06: Planificación de la Auditoría – Actividades del plan de trabajo. ...................... 84

Tabla N°07: Evaluación del Entorno de Control – Actividades del plan de trabajo ............ 84

Tabla N°08: Evaluación de la Gestión de Riesgos – Actividades del plan de trabajo ....... 85

Tabla N°09: Evaluación de las Actividades de Control Interno de la Gestión de la Red. –

Actividades del plan de trabajo ............................................................................................... 87

Tabla N°10: Revisión y Análisis de Resultados. – Actividades del plan de trabajo ........... 88

Tabla N°11: Elaboración del Informe de Auditoría. – Actividades del plan de trabajo ...... 88

Tabla N°12: Presupuesto de la ejecución de la auditoría informática .................................. 89

Tabla N°13: Procesos Críticos considerados en el plan de contingencia ......................... 107

Tabla N°14: Valores de Impacto .............................................................................................. 109

Tabla N°15: Probabilidad de Ocurrencia ................................................................................. 110

Tabla N°16: Probabilidad de Ocurrencia para Riesgos Físicos .......................................... 110

Tabla N°17: Probabilidad de Ocurrencia para Riesgos Lógicos ......................................... 111

Tabla N°18: Impacto para riesgos físicos ............................................................................... 111

Tabla N°19: Impacto para riesgos lógicos .............................................................................. 112



Tabla N°20: Tiempo de atención de incidentes ..................................................................... 123

Tabla N°21: Incidentes resueltos dentro del tiempo óptimo ................................................ 127

Tabla N°22: Tiempo de atención de interrupciones de red .................................................. 133

Tabla N°23: Frecuencia de atención de incidentes de Enero a Setiembre (2011). ......... 136

Tabla N°24: Cálculo del NHP.(2011). ...................................................................................... 137

Tabla N°25: Cálculo del NHP (2011). ...................................................................................... 142

Tabla N°26: Cálculo del NHP (2011). ...................................................................................... 143

Tabla N°27: Precios unitarios de equipos y elementos de red usado en la UCV - Piura 146

Tabla N°28: Frecuencia de atención de incidentes de mantenimiento de Red de Enero a

Setiembre(2011). ..................................................................................................................... 152

Tabla N°29: Controles físicos aplicados por OTI a la red de la UCV- Piura. .................... 156

Tabla N°30: Controles lógicos aplicados por OTI a la red de la UCV- Piura .................... 160

Tabla N°33: Resumen de Cuestionario Nº03: Mantenimiento de la Red. ......................... 166

Tabla N°34: Comparación situación real vs deseada para el indicador NCP ................... 172

Tabla N°35: Comparación situación real vs deseada para los indicadores PIR y NHP .. 175

Tabla N°36: Comparación situación real vs deseada para el indicador NCT ................... 176

Tabla N°37:Comparación situación real vs deseada para el indicador PIATI ................... 177

Tabla N°38: Comparación situación real vs deseada para el indicador NMR .................. 178

Tabla N°39: Comparación situación real vs deseada para el indicador NCF ................... 181

Tabla N°40: Comparación situación real vs deseada para el indicador NCL ................... 184

Tabla N°41:Plan de mejora para el indicador NPC ............................................................... 186

Tabla N°42: Plan de mejora para el indicador PIR ................................................................ 189

Tabla N°43: Plan de mejora para el indicador NHP .............................................................. 191

Tabla N°44: Plan de mejora para el indicador NCT .............................................................. 192

Tabla N°45: Plan de mejora para el indicador PIATI ............................................................ 193

Tabla N°46: Plan de mejora para el indicador NMR ............................................................. 194



Tabla N°47: Plan de mejora para el indicador NCF .............................................................. 196

Tabla N°48: Plan de mejora para el indicador NC ................................................................. 197

Tabla N°49: Análisis Pre-Test y Post-Test para el indicador NPC ..................................... 199

Tabla N°50: Análisis Pre-Test y Post-Test para el indicador PIR ....................................... 200

Tabla N°51: Análisis Pre-Test y Post-Test para el indicador NHP ..................................... 201

Tabla N°52: Análisis Pre-Test y Post-Test para el indicador NCT ...................................... 202

Tabla N°53: Análisis Pre-Test y Post-Test para el indicador PIATI .................................... 203

Tabla N°54: Análisis Pre-Test y Post-Test para el indicador NMR ..................................... 203

Tabla N°55: Análisis Pre-Test y Post-Test para el indicador NCF ...................................... 204

Tabla N°56: Análisis Pre-Test y Post-Test para el indicador NCL ...................................... 205

Tabla N°57: Análisis Pre-Test y Post-Test para el indicador NMGR .................................. 206



Índice de Gráficos

Gráfico Nº01: Diagrama de Flujo para el procedimiento de dar de alta a un usuario ....... 94

Gráfico Nº02: Diagrama de Flujo para el procedimiento de dar de baja a un usuario ...... 95

Gráfico Nº03: Diagrama de Flujo para el procedimiento de verificación de accesos ........ 96

Gráfico Nº04: Diagrama de Flujo para el procedimiento de chequeo del tráfico de la red

...................................................................................................................................................... 97

Gráfico Nº05: Diagrama de Flujo para el procedimiento de resguardo de copias de

seguridad .................................................................................................................................... 98

Gráfico Nº06: Diagrama de Flujo para el procedimiento de monitoreo de los puertos en la

red ................................................................................................................................................ 99

Gráfico Nº07: Diagrama de Flujo para el procedimiento de dar a conocer las nuevas

normas de seguridad implantadas ........................................................................................ 100

Gráfico Nº08: Diagrama de Flujo para el procedimiento para recuperar información .... 101

Gráfico Nº09: Diagrama de Flujo para el procedimiento para la atención de incidentes 102

Gráfico Nº10: Proporción de procesos críticos no incluidos en plan de contingencia de

OTI ............................................................................................................................................. 108

Gráfico Nº11: Tiempo Promedio de Atención de Incidentes (TPAI) por OTI en la UCV -

Piura .......................................................................................................................................... 129

Gráfico Nº12: Tiempo Perdido Mensual por Interrupciones de Servicio de acuerdo a tipo

de incidente en la UCV - Piura .............................................................................................. 138

Gráfico Nº13: Proporción de los controles aplicados a terceros aplicados por las áreas de

OTI y Logística ......................................................................................................................... 143

Gráfico Nº14: Porcentaje de inversión para cubrir los costos de TI ................................... 148

Gráfico Nº15: Frecuencia mensual de tareas de mantenimiento en la UCV - Piura ....... 153



Gráfico Nº16: Controles físicos aplicados para mitigar riesgos a la infraestructura física

de la redde la UCV - Piura ..................................................................................................... 156

Gráfico Nº17: Diagrama deflujo para la gestión de software malicioso aplicado por OTI

.................................................................................................................................................... 159

Gráfico Nº18: Controles lógicos aplicados para mitigar riesgos a la infraestructura física

de la red de la UCV - Piura .................................................................................................... 161

Gráfico N°19: Análisis Pre-Test y Post-Test para el indicador NPC .................................. 199

Gráfico N°20: Análisis Pre-Test y Post-Test para el indicador PIR .................................... 200

Gráfico N°21: Análisis Pre-Test y Post-Test para el indicador NHP .................................. 201

Gráfico N°22: Análisis Pre-Test y Post-Test para el indicador NCT .................................. 202

Gráfico N°23: Análisis Pre-Test y Post-Test para el indicador PIATI ................................ 203

Gráfico N°24: Análisis Pre-Test y Post-Test para el indicador NMR ................................. 204

Gráfico N°25: Análisis Pre-Test y Post-Test para el indicador NCF .................................. 205

Gráfico N°26: Análisis Pre-Test y Post-Test para el indicador NCF .................................. 206

Gráfico N°27: Análisis Pre-Test y Post-Test para el indicador NMGR .............................. 207



Índice de Ilustraciones

Ilustración N°01: Estructura Organizacional de la Universidad César Vallejo - Piura ...... 37

IlustraciónN°02: Estructura organizacional de la Oficina de Tecnologías de Información

de la Universidad César Vallejo - Piura ................................................................................. 39

Ilustración Nº03: Fórmula Diseño Cuasi-experimental Post-Prueba .................................. 63

Ilustración Nº04: Desarrollo de los Procesos Académicos de la Universidad ................. 105

Ilustración Nº05: Prioridades de Atención ............................................................................. 113



INTRODUCCIÓN

En la actualidad, las tecnologías de información (TI) han dejado de ser una rara

curiosidad para convertirse en una necesidad de las organizaciones contemporáneas; no

obstante la percepción de la mayoría de personas parece detenida en el tiempo.

La necesidad de contar con el último grito de las tecnologías emergentes, de jugar con

soluciones tecnológicas exóticas sin considerar su impacto, de solucionar un problema de

conectividad o de software y olvidarse de él, entre otras prácticas que, si bien es cierto,

no son malas, (la curiosidad es buena) se convierten en inapropiadas dentro del contexto

equivocado. En casa podemos experimentar, en una organización debemos gestionar.

Gestionar las tecnologías de información (o cualquier otro tipo de gestión) no es tarea

fácil, porque implica planificar, administrar, evaluar y controlar, lo que significa que las

tecnologías de información son elevadas al nivel de recursos que de no ser bien

gestionados significan pérdidas para la organización, para evitarlo, surgen los conceptos

(entre muchos otros relacionados con la gestión) de control interno y de auditoría.

El control interno es una evaluación constante de los recursos informáticos, ya sean las

TI propiamente dichas como la información que procesan o las personas que los

manejan. La auditoría es la evaluación de la gestión en una determinada situación en el

tiempo y el espacio, pero todavía persiste el problema de cómo hacerlo o qué se va a

auditar.

Afortunadamente las buenas prácticas de gestión están agrupadas en estándares,

marcos de trabajo o metodologías que permiten que los gestores de TI se acerquen,

explícita o implícitamente a la visión de un FODA del departamento de TI a su cargo. Lo

que los convierten en una guía inefable para los altos directivos, gestores de TI, personal

de soporte, personal de desarrollo, administradores de red, personal administrativo,

auditores, responsables del control interno, etc.

Por las razones expuestas se considera necesario aplicar una auditoría informática al

área de redes de la Oficina de Tecnologías de Información (OTI) de la UCV – Piura

usando el marco de trabajo COBIT. La decisión de basar esta auditoría, solamente a

redes (y no a las TI en general), radica en la importancia de ésta en el desarrollo de las

actividades educativas y administrativas de la Universidad César Vallejo porque éstas se

basan en una red en la cual depositan toda su confianza. Por otro lado, se escogió

COBIT (como estándar de buenas prácticas) porque brinda una visión general de la

gestión de TI gracias a sus dominios que tratan los aspectos de una gestión, de los



cuales se han escogido sólo los que son más relevantes al alcance y objetivos de esta

investigación.

Para finalizar, es deseo de los investigadores, que el proyecto, una vez terminado,

contribuya al mejoramiento del Área de Redes de la OTI en la gestión de la red de la UCV

Piura y, además, sirva de referente para futuras investigaciones al respecto.



RESÚMEN

Este trabajo de investigación se realizó con el objetivo de mejorar la gestión de redes,

comunicaciones y servidores en la Universidad César Vallejo – Piura, para ello se aplicó

una auditoría informática basada en COBIT a la Oficina de Tecnologías de

Información(OTI) - Subárea de redes y comunicaciones que es la que se encarga de la

gestión y administración de la red de la universidad, para lo cual fue necesario un análisis

previo del ambiente a auditar con el propósito de utilizar COBIT con el enfoque adecuado

acorde a la realidad de la subárea de redes y a las posibilidades y limitaciones del grupo

investigador.

Finalizado el análisis, se entrevistó al jefe del área sobre la documentación que se

maneja y los procedimientos y políticas de seguridad aplicados, donde se pudo

comprobar algunas deficiencias como el no tener la documentación organizada.

Concluida la revisión de documentación y políticas se procedió a evaluar la gestión de

redes utilizando, para ello, nueve indicadores basados en los procesos de los dominios:

Dar Soporte y Planear y Organizar de COBIT (consultar tabla de indicadores en los

apartados 2.10.2 y 4.2.1).La evaluación se basó en entrevistas, revisiones bibliográficas y

cuestionarios, complementando a lo anterior la observación directa de los procedimientos

y actividades realizados en la OTI.

Como resultado de esta evaluación, se encontraron algunas deficiencias primero, en lo

relacionado a la documentación la cual es poca y está desorganizada y, en algunos

casos, desactualizada; segundo, en lo que respecta a la seguridad, porque OTI aplica

controles físicos y lógicos básicos pero que no son los adecuados para salvaguardar los

activos de información de la universidad, además OTI no realiza seguimiento a los

incidentes más frecuentes ni tampoco realiza tareas de mantenimiento preventivo con

regularidad; tercero, en lo que respecta a inversión, OTI no invierte lo suficiente en

actualización de equipos. En la siguiente tabla se presentaran los resultados obtenidos en

cada indicador respectivamente.



Nº Indicador Resultado

1

Número de procesos críticos de

negocio no incluidos en un plan de

contingencia. (NPC)

OTI no incluye 3 Procesos críticos de

negocio en el plan de contingencia.

2

Porcentaje de incidentes de red

resueltos en un tiempo óptimo (PIR)

El 81.81 % de los incidentes de red son

resueltos en un tiempo optimo no mayor

de 5.5 horas.

3

Número promedio de horas perdidas

por usuario al mes, debido a

interrupciones a la red (NHP)

Se pierden aproximadamente 15 horas

(14.990) por interrupciones al servicio al

mes.

4 Número de controles aplicados a

servicios de terceros. (NCT)

Se aplican 4 controles a servicios de

terceros.

5 Porcentaje de inversión para cubrir los

costos en TI (PIATI)

El porcentaje de inversión para cubrir los

costos en TI son de 14.92 %.

6 Número promedio de veces por mes que se ha realizado mantenimiento a la red.(NMR)

Se realiza 7 veces por mes

mantenimiento a la red.

7

Número de controles físicos para garantizar la continuidad del servicio (NCF)

Son 6 los controles físicos que se aplican

para garantizar la continuidad del

servicio.

8

Número de controles lógicos para garantizar la continuidad del servicio (NCL)

Son 6 los controles lógicos que se

aplican para garantizar la continuidad del

servicio.

9

Nivel de madurez de la gestión de redes de la OTI (NMGR)

La gestión de Redes de OTI se

encuentra en un nivel de madurez que

se ubica entre el nivel Repetible y el

nivel Definido, según la escala que

establece COBIT.

Los hallazgos anteriores se resumen en el cálculo del nivel de madurez del área, el cual

ubica a OTI entre el nivel 2 REPETIBLE y el nivel 3 o DEFINIDO según la escala

establecida por COBIT lo que significa que el área aplica la mayoría de sus procesos de

manera empírica, no obstante el área maneja cierta documentación (plan de

contingencia, instructivo de funciones, mapa topológico de la red, descripción de la red de

la UCV - Piura) y aplica algunos estándares; para todos estos hallazgos se proponen

mejoras las cuales se sustentan en base a propuestas de proyectos (Del anexo 17 al 24)



los cuales se espera se ejecuten en el corto o mediano plazo y se hace una comparación

entre los hallazgos de auditoría (Pre-Test) junto con la aplicación de las propuestas que

corrigen las deficiencias encontradas (Post-Test) para definir una línea de acción en caso

de aplicarse las propuestas recomendadas, con lo que según ala proyección que se

obtuvo el nivel de madurez subiría un nivel más, se encontrara en un nivel 4 o

Administrado en el cual los procesos están en constante mejora y se aplican buenas

prácticas con las cuales se disminuye el nivel de riesgo.



CAPÍTULO I

GENERALIDADES



1.1. Titulo:

Evaluación de la Gestión en Redes, Comunicaciones y Servidores en la Oficina de

Tecnologías de Información de la Universidad César Vallejo – Piura mediante la

aplicación de una Auditoría Informática basada en COBIT.

1.2. Tipo de Investigación:

Investigación Explicativa

1.3. Área de Investigación:

Área Tecnológica

1.4. Localidad o institución donde se realiza la investigación:

Universidad César Vallejo S.A.C – Filial Piura

1.5. Autores:

Burgos Merino, Jorge Armando

Namuche Correa, Adrian Leonardo

1.6. Asesor:

Ing. CIP. Mario Nizama Reyes

1.7. Duración del Proyecto:

Inicio: 29 Marzo de 2011

Fin: 17 Diciembre de 2011



CAPÍTULO II

PLAN DE INVESTIGACIÓN



2.1. Descripción de la Realidad Problemática

La Oficina de Tecnologías de Información (OTI) se encarga de apoyar las labores

administrativas de la universidad (RIEGA 2010) originalmente formaba una sola área

junto al Centro de Informática y Sistemas, sin embargo a partir del 2009, éste último

sólo se avocó a la parte académica mientras que OTI se encarga de administrar,

hasta el día de hoy, las tecnologías de información de la universidad. Actualmente

laboran, en la oficina, nueve personas, con el apoyo de tres practicantes.

OTI se conforma en tres subáreas: La subárea de redes, la subárea de desarrollo y

la subárea de soporte técnico. A partir de este año, la oficina de Audiovisuales ha

pasado formar parte de OTI.

La subárea de redes está a cargo del Ing. Alfredo Enrique Iwasaki Vargas entre

cuyas principales funciones (Descripción de la Red UCV – Piura, 2009) tenemos:

Administración y configuración de dispositivos de comunicación: Switches,

routers, Access point.

Administración del servicio de internet para administrativos y laboratorios.

Administración de dispositivos de seguridad (Firewall).

Configuración de VLANs

Instalación, administración y monitoreo de servidores: Servidores de dominio

(Windows 2003), servidores Proxy, etc.

Cableado estructurado de voz y datos.

Implementación del sistema de videoconferencia sobre IP-VPN.

Implementación de telefonía IP.

El responsable de la subárea de redes refiere que el servidor Web es el más

propenso a recibir ataques de hackers (ataques externos) incluso refiere que, en

Febrero de 2011, hubo una infección por virus por parte de un hacker chino aunque

no fue nada grave como para reinstalar el servidor. En cuanto a la red de la

universidad, no se ha registrado ataques internos, sin embargo siempre existe la

posibilidad de que suceda o peor aún, los responsables de la subárea de redes

desconocen que exista esta posibilidad.



En el año 2009 se hizo una auditoría en seguridad a las Tecnologías de Información

(TI) de la universidad a cargo del Ing. Marco Antonio Riega Reto1 como marco de su

trabajo de tesis de pregrado. Este trabajo fue el primero en su tipo ya que

anteriormente (según la realidad problemática presentada por el autor) nunca se

había realizado una auditoría a las TI de la universidad.

La auditoría tuvo un alcance demasiado general, de acuerdo a la estructura del

estándar, y abarcó las funciones de todas las subáreas de OTI desde el punto de

vista de la seguridad de la información; si bien la auditoría no analizó casos de

violación de seguridad por intrusión, situaciones muy comunes en el ámbito de redes,

servidores y comunicaciones, no obstante dio alcance de varias carencias presentes

en OTI hasta esa fecha, de las cuales algunas todavía persisten.

Es necesario recalcar que la situación en la que se desarrolló el trabajo de

investigación no es la misma que la situación actual, por ende jamás existirán dos

auditorías iguales, ninguna de las dos encontrará los mismos problemas y

excepciones ni obtendrán los mismos resultados.

Además del problema principal mencionado, la Oficina de Tecnologías de

Información presenta los siguientes problemas.

El área de OTI no cuenta con una persona que puede reemplazar al

administrador de la red en caso se requiera

La persona encargada de administrar y monitorear las redes, comunicaciones y

servidores es el Ing. Alfredo Iwasaki quien además es el jefe de la OTI; él recibe

el apoyo del personal de soporte (cuatro personas) y del personal de la subárea

de desarrollo, específicamente los encargados de los sistemas web (una

persona); no obstante, es el único administrador de la red con el que cuenta el

área y, en caso de ausencia, lo reemplaza en funciones el ingeniero de mayor

antigüedad quien es el jefe de la subárea de desarrollo pero él no es el

administrador de la red, ni está autorizado a realizar procedimientos que sólo el

administrador puede hacer como el alta (o baja) de usuarios de dominio, la

configuración de equipos de redes y comunicaciones y el monitoreo de la red de

la universidad. Cuando se requiere cumplir con cualquiera de estos

procedimientos, se comunica al administrador de la red, pero esto no evita una

1Auditoría basada en ISO/IEC 17799 para la Gestión de Seguridad de las Tecnologías de Información en la

Universidad César Vallejo. Tesis realizada para alcanzar el título profesional de Ingeniero de Sistemas.



mayor demora al hacerlo lo que puede causar malestar en el usuario, este

retraso, aparentemente inofensivo, puede ser grave si ocurriese una violación en

la seguridad de las redes y los servidores de la universidad.

No se ha efectuado una auditoría informática previa a las redes,

comunicaciones y servidores de la UCV- Piura.

Como se mencionó antes, el trabajo anterior de auditoría no tomó el aspecto de

redes, servidores y comunicaciones a profundidad.

Inconvenientes como la caída relativamente frecuente del servidor Web no

se han solucionado del todo.

Al revisar la bitácora de atenciones de OTI (Ficha Bibliográfica - Anexo 5), se

constató que entre Enero y Abril del 2011 se registraron 9 caídas del servidor

web, lo que impide el acceso a la página institucional de la UCV Piura, por medio

de la cual los trabajadores pueden ingresar a la Intranet y al correo corporativo;

además existen otros sucesos frecuentes a considerar como los problemas de

conectividad en el chat interno de la universidad (se utiliza el Pidgin) el cual ha

fallado en 6 ocasiones entre Enero y Abril del 2011.

Además se han registrado otros problemas de conectividad en la red de la

universidad que sumados, dan un total de 52 incidentes entre Enero y Abril del

2011

Las funciones de la subárea de redes no están formalmente documentadas

OTI no cuenta con manuales de los principales procedimientos del área, ni

manuales de configuración de los equipos de redes y comunicaciones. La

documentación de OTI (subárea de redes) se basa en una breve descripción de

las funciones y responsabilidades de OTI, el mapa topológico de la red, un

documento que describe brevemente la red de la universidad, una bitácora de

atenciones y un plan operativo que se realiza cada año; pero esa documentación

está desorganizada, siendo susceptible de perderse.

El área cuenta también con un plan de contingencia que fue producto de una

tesis de pregrado desarrollada en el 2010, dicho documento no tiene la

presentación formal de lo que debería ser un plan de contingencia.



2.2. Formulación del Problema

2.2.1. Pregunta General

¿De qué manera la aplicación de una auditoria informática basada en

COBIT permitirá la evaluación de la gestión en redes, comunicaciones y

servidores en la Universidad César Vallejo – Piura?

2.2.2. Preguntas de Investigación

¿En qué momentos y circunstancias la Oficina de Tecnologías de

Información aplica controles internos a la red de la universidad?

¿De qué manera la Oficina de Tecnologías de Información alinea la

gestión de la red con las metas de la universidad?

¿En qué momento la Oficina de Tecnologías de Información reporta

los riesgos, el control, el cumplimiento y el desempeño de la gestión

de la red de la universidad?

¿De qué manera la Oficina de Tecnologías de Información basa su

gestión de la red de la universidad con el cumplimiento de un

estándar de buenas prácticas como COBIT?

2.3. Objetivos

2.3.1. Objetivo General

Evaluar la gestión en redes, comunicaciones y servidores en la

Universidad César Vallejo – Piura.

2.3.2. Objetivos Específicos

Evaluar en qué momentos y circunstancias la Oficina de Tecnologías

de Información aplica controles internos a la red de la universidad.

Evaluar el alineamiento de la gestión de redes con las metas de la

universidad.

Evaluar si la Oficina de Tecnologías de Información reporta los

riesgos, el control, el cumplimiento y el desempeño de la red de la

universidad.

Determinar el nivel de madurez de la gestión de la red de la

universidad de acuerdo a COBIT.

Determinar controles a implementar de acuerdo a las deficiencias

encontradas.



2.4. Justificación de la Investigación

Justificación de los Investigadores

La realización de este trabajo de investigación nos permitió obtener un mayor

conocimiento acerca de la gestión de redes realizadas por los departamentos,

oficinas o áreas de TI presentes en las organizaciones actuales y, también, sobre

cómo esta gestión puede evaluarse para mejorar mediante la aplicación de una

auditoría informática.

Justificación de la Organización

Actualmente, las empresas necesitan de las TI para cumplir con sus metas y

objetivos. Por este motivo se aplicó una auditoría informática a la gestión de

redes, servidores y comunicaciones de la Oficina de Tecnologías de Información

de la UCV Piura, la cual evaluó si la gestión de la red (por parte de OTI) está

alineada con los objetivos de la organización en beneficio de ésta.

Justificación Tecnológica

La aplicación de una auditoría informática basada en COBIT ha permitido mejorar

la gestión de la red de la universidad por parte de la Oficina de Tecnologías de

Información mediante la evaluación de los controles efectuados por la OTI de

acuerdo a lo recomendado por COBIT lo que permitió que el área determine

controles que ayuden a mejorar las deficiencias encontradas durante la aplicación

de la auditoría.

Justificación Científica

La realización de este trabajo de investigación permitió comparar la situación real

de la gestión de la red (por OTI) con la situación ideal recomendada por COBIT.

Además, este trabajo servirá de referente para futuras investigaciones

relacionadas con el tema.

2.5. Limitaciones de la Investigación

El acceso a las fuentes primarias fue limitado debido a la falta de disponibilidad de

tiempo del personal que labora en el área (área de redes de la OTI).

La consulta de las fuentes secundarias se vio dificultada por la falta de

disponibilidad de toda la documentación que detalla los procesos y las funciones

de la OTI.



No se tuvo acceso a todas las fuentes secundarias de OTI, porque algunos

documentos eran demasiado confidenciales.

No se tuvo a acceso a los activos de información de la información como

servidores, switches y otros equipos de telecomunicaciones, tampoco fue posible

realizar pruebas de penetración o escaneos de puertos.

El tiempo de investigación asignado fue muy corto (4 meses) para poder evaluar

el impacto positivo del plan de mejora propuesto, lo que significaría aplicar la

auditoría nuevamente para lo cual demandaría un tiempo mínimo de 5 meses

más.

2.6. Marco Referencial Científico

2.6.1. Antecedentes (internacional, nacional, regional y local)

Antecedentes Internacionales

Auditoría de la gestión de seguridad en la red de datos del

Swissotel basada en COBIT.

MATUTE Macías, María del Carmen & QUISPE Cando, Tránsito del

Rosario. 2006. Escuela Politécnica Nacional, Quito, Ecuador.

Metodología: Marco de trabajo COBIT, el cual, si bien es cierto no es

una metodología, proporciona un conjunto de normas y buenas

prácticas para el gobierno de las TI. Los investigadores han abarcado

todos los cuatro dominios de COBIT (descritos en el concepto de

COBIT dentro del marco conceptual) pero de ellos han seleccionado

algunos procesos y uno o dos objetivos de control para cada uno

(como se aprecia en el índice del trabajo de investigación). La

metodología usada ha tomado en cuenta evaluar, primero, la

planificación y organización de TI; luego, la adquisición de TI; a

continuación, el servicio de soporte y, por último, el monitoreo de los

procesos de gestión de TI, poniendo énfasis en la seguridad, que se

refleja en la evaluación del servicio de soporte (garantizar la

continuidad del servicio y garantizar la seguridad de los sistemas).

Los investigadores, respecto a la metodología usada, concluyen lo

siguiente:

COBIT proporciona una visión general de las fortalezas y

debilidades en la gestión de TI de una empresa pero no da una

respuesta tecnológica.



COBIT no es una metodología, pero presenta un conjunto de

guías que permiten analizar y evaluar las actividades de control

interno en TI realizadas por una empresa (por el área

responsable).

COBIT es un proceso estándar, demasiado general, por eso es

necesario, primero, conocer la empresa y el área a auditar y

alinearlo con lo que sugiere COBIT.

Este trabajo proporcionó, a nuestra investigación, una guía para

realizar una auditoría informática basada en COBIT porque nos

permitió adecuar un framework tan general, como COBIT, en el

marco de una investigación que tiene limitaciones tanto de fuentes de

información como de tiempo de investigación, no obstante el alcance

se limitó solo a un dominio de COBIT, aspecto del cual tuvieron

influencia los demás antecedentes consultados. Este trabajo fue la

primera referencia que se consultó para contar con una primera

impresión de lo que sería la auditoría informática que estamos

presentando.

Seguridad en Informática (Auditoría de Sistemas).

BASALDÚA Álvarez, Luis Daniel. 2005. Institución: Universidad

Iberoamericana, México D.F, México

Metodología: El investigador, propone una serie de lineamientos (que

se asume como metodología) a tomar en cuenta al desarrollar una

auditoría en Seguridad en Informática. Los puntos tratados se

distribuyen en cinco capítulos (el trabajo consta de seis capítulos).

Los temas tratados hablan de las políticas de seguridad, uso y

responsabilidades de la red, planeación de seguridad en redes, etc.

(consultar el índice del trabajo).

El sexto capítulo trata sobre los estándares usados en auditoría de

seguridad, en este capítulo se describe el marco de trabajo COBIT.

Para finalizar, el investigador engloba las conclusiones de su trabajo

en una sola conclusión de la cual rescatamos algunas ideas

importantes

La información tiene un valor muy alto en las organizaciones, por

eso debe protegerse junto a la tecnología usada para su manejo y

tratamiento (Tecnologías de Información)



Una auditoría informática en seguridad, primero, debe detectar los

fallos en seguridad de la organización, documentar esos resultados,

informar a los responsables y sugerir medidas correctivas.

Una auditoría en seguridad permite la gestión proactiva de las

tecnologías de información.

Una auditoría informática permite conocer la situación actual y

exacta de las TI.

Este trabajo proporcionó, a nuestra investigación, una guía para

definir qué buenas prácticas, usos y responsabilidades deben

aplicarse para la administración de la red en una organización,

lineamientos que recogimos y aplicamos para desarrollar los

indicadores de la investigación referidos a cuestiones técnicas, los

cuales son: PIR, NHP, NMR, NCF y NCL (ver tabla de indicadores en

sección 2.10.2)

Modelo para la Auditoría de la Seguridad Informática en la Red

de Datos de la Universidad de los Andes.

MAYOL Arnao, Reinaldo N.2006. Universidad de los Andes,Mérida,

Venezuela

Metodología: El investigador aclara que su trabajo desarrolla un

modelo no una metodología porque, éste se aplica sólo a la realidad

de la RedULA (no es universal), sin embargo se conoce que el autor

empleó la Metodología Abierta para Pruebas de Seguridad (HMAST).

La estructura del modelo se conforma de cuatro módulos: Definición

de las condiciones, Definición de las características técnicas,

Pruebas de Penetración y Revisión.

Algunas de las conclusiones más resaltantes son:

El modelo se usó para auditar la red del Rectorado de la

universidad Los Andes demostrando que es válido.

Este modelo puede evolucionar y convertirse en un estándar de

buenas prácticas.



Este modelo puede trascender del contexto aplicado porque

aplica una visión intermedia: ni tan alejada de la arquitectura ni

muy dependiente de la misma.

Este trabajo proporcionó, a nuestra investigación, una noción para

medir el número de controles lógicos y físicos aplicados a la red de

la universidad (secciones 4.3.3.5 y 4.3.3.6 respectivamente),

aunque evaluar estos controles de acuerdo a lo indicado por Mayol

no iba a ser posible porque implicaba una manipulación directa a

los activos de información de la organización (UCV - Piura) lo que

era imposible de hacer (consultar limitaciones del proyecto en la

sección 2.5), pero si indicaba una visión general de los controles

que deben aplicarse.

Antecedentes Nacionales

Sistema de Gestión de Seguridad de Información para una

Institución Financiera.

VILLENA Aguilar, Moisés Antonio. 2006. Pontificia Universidad

Católica del Perú - Facultad de Ciencias e Ingeniería- Lima

El investigador utiliza el Modelo de seguridad de información de

McCumber, el cual es un modelo que se caracteriza por ser,

independiente del entorno, arquitectura o tecnología que gestiona la

información de una organización. El modelo se aplica para todo tipo

de organizaciones (es universal).

Las principales conclusiones del autor son las siguientes:

Se concluye que no necesariamente la tecnología de información

por sí sola garantiza la seguridad de información. Se vuelve

imperativo gestionarla de acuerdo siempre a los objetivos de

negocio.

De nada sirve contar con los últimos adelantos tecnológicos, si no

se da la importancia debida a la protección de la información, la

cual se verá reflejada en el cumplimiento de todas las políticas de

seguridad de información, siempre actualizadas de acuerdo a los

cambios constantes en los negocios propios de una institución

financiera.

Este trabajo proporcionó, a nuestra investigación, el enfoque dado

durante el desarrollo de la auditoría informática donde no sólo

importa la evaluación del aspecto técnico puro, sino de la gestión de



estos TI (que nuestra investigación se centró en la parte de redes y

comunicaciones). La influencia más concreta se nota en el criterio

que tomamos en cuenta para evaluar los procedimientos de

seguridad que OTI debe realizar para la administración de la red

(sección 4.3.3.1), criterio que se reforzó con la ayuda del propio

framework COBIT.

Metodología para la Auditoría Integral de la Gestión de la

Tecnología de Información

ALFARO Paredes, Emigdio Antonio. 2008. Pontificia Universidad

Católica del Perú – Facultad de Ciencias e Ingeniería – Lima

El investigador propone una metodología de auditoría integral

(MAIGTI) la cual divide en 63 procedimientos diseñados para

elaborar una auditoría a las TI, basados en los siguientes estándares:

COBIT, ISO/IEC 12207, ISO/IEC 17799, ISO/IEC 20000, PMBOK

(estándar para gestión de proyectos), ISO 19001.

Al finalizar su investigación el autor concluye que se ha cumplido el

objetivo de elaborar una metodología basada en los estándares

internacionales, lo que ayudaría en su rápida aceptación por parte de

auditores informáticos y expertos en TI.

Este trabajo ha desarrollado una metodología cuyos procesos son

muy similares a COBIT, además están redactados de manera simple

y directa de tal forma que mediante este documento se pudieron

reforzar algunos objetivos y procesos de COBIT lo que sirvió de

mucho para plantear la auditoría informática basada en COBIT que

proponemos.

Antecedentes Locales

Auditoría basada en ISO/IEC 17799 para la gestión de seguridad

de las T.I en la UCV-Piura.

RIEGA Reto, Marco Antonio. 2010. Universidad Cesar Vallejo - Piura

Metodología: El investigador aplica el estándar ISO/IEC 17799, el

cual se organiza en diez secciones que tratan diversos tópicos en

gestión de seguridad de las TI: Planificación contínua del Negocio,

Sistema de Control de Acceso, Sistema de Desarrollo y

Mantenimiento, Seguridad Física y del Entorno, Conformidad,

Seguridad Personal, Seguridad Organizacional, Administración de



Redes y Ordenadores, Clasificación y Control de Activos, y Políticas

de Seguridad.

El investigador concluye que la aplicación de la auditoría ayuda a

mejorar la gestión de la seguridad de las T.I en los aspectos

siguientes de los cuales citaré algunos:

Identificación de amenazas que afectan a la seguridad de las T.I

Debe implementarse, en OTI, un procedimiento formal para la

concesión, administración de derechos y perfiles.

Se recomienda desarrollar e implementar un procedimiento de

respaldo (uso de backups).

Este trabajo proporcionó, a nuestra investigación, el conjunto de

actividades que deben tenerse en cuenta para el desarrollo de la

auditoría, las cuales se plasmaron en el plan de trabajo que es

presentado, en detalle, en la sección 4.2.3

2.7. Marco Teórico

2.7.1. La Institución: La Universidad César Vallejo Piura

La Universidad César Vallejo S.A.C (UCV) fue fundada el 12 de noviembre

de 1991 por el Ing. César Acuña Peralta en Trujillo y entró en

funcionamiento el 1 de abril de 1992. En la actualidad cuenta con filiales en

las ciudades de Chiclayo, Piura, Chimbote, Tarapoto y Lima e integra un

consorcio universitario junto con la Universidad Señor de Sipán (USS) y la

Universidad Autónoma del Perú (UA) denominada Consorcio USS-UCV-

UA. (<http://www.creditosperu.com.pe/pp-universidad-cesar-vallejo-s-a-

c.php>,2011).

La razón de ser de la Universidad César Vallejo – Piura, está reflejada en

su Misión institucional la cual, según su portal Web, es la siguiente:

“La UCV forma profesionales idóneos, productivos, competitivos,

creativos con sentido humanista y científico; comprometidos con el

desarrollo socioeconómico del país; constituyéndose en un referente

innovador y de conservación del medio ambiente.”

(<http://www.ucvpiura.edu.pe/>,20111).



Así mismo la Visión Institucional (hallada en su mismo portal Web) de la

Universidad es la siguiente:

“La UCV será reconocida como una de las mejores universidades a

nivel nacional, por la calidad de sus graduados, su producción

académica y su contribución al desarrollo de la sociedad”


La Universidad César Vallejo filial Piura cuenta actualmente con quince

carreras profesionales: Administración, Administración en Turismo y

Hotelería, Contabilidad, Derecho, Educación Inicial, Educación Primaria,

Enfermería, Estomatología, Idiomas, Ingeniería Agroindustrial, Ingeniería

de Sistemas, Ingeniería Industrial, Marketing, Medicina y Psicología


Además de las Escuelas, la UCV-Piura está conformada por diversas

áreas las cuales forman parte de su estructura organizacional plasmada en

el organigrama de la institución (Imagen N°01); una de ellas es la Oficina

de Tecnologías de Información (OTI), la cual (según el organigrama

institucional) ocupa un lugar clave dentro de la organización de la

Universidad porque depende directamente de Dirección General. Sobre la

OTI hablaremos más detalladamente en la siguiente sección.



Ilustración N°01: Estructura Organizacional de la Universidad César Vallejo - Piura

Fuente: Dirección General de la UCV



2.7.2. Oficina de Tecnologías de Información

La Oficina de Tecnologías de Información (OTI) es, según su guía de

Planeamiento Estratégico, “un área que brinda soporte, mantenimiento

y controles informáticos y tecnológicos en la comunidad

universitaria”; esto se traduce en la responsabilidad que tiene la OTI de

intervenir en los procesos vitales de la organización debido a que estos se

soportan en las tecnologías de información (Hardware y Software) (Guía

de planeamiento estratégico, instructivo de funciones y propuesta de

proyecto para (OTI), 2010,p.1).

La oficina, como área independiente, inició formalmente sus funciones en

el mes de noviembre del año 2010, siendo antes parte del Centro de

Informática y Sistemas (CIS). La jefatura de la oficina está a cargo del

Ingeniero Alfredo Enrique Iwasaki Vargas y, actualmente, laboran diez

personas junto a tres practicantes.

La Misión de la OTI es la siguiente:

“La oficina de tecnologías de la información (OTI), tiene el

compromiso de gestionar el uso de las tecnologías informáticas para

optimizar los procesos de la comunidad universitaria UCV- Piura”.

(Guía de planeamiento estratégico, instructivo de funciones y propuesta

de proyecto para (OTI), 2010, p. 2)

La Visión de la OTI es la siguiente:

“La oficina de tecnologías de la información (O.T.I), será reconocida

como el área líder en la Universidad César Vallejo - Piura; por la

calidad, eficacia y eficiencia en los servicios brindados”. (Guía de

planeamiento estratégico, instructivo de funciones y propuesta de proyecto

para (OTI), 2010, p. 2).

La estructura organizacional de la OTI se plasma en su organigrama

(Imagen N°02) según el cual la oficina se subdivide en tres subáreas:

Soporte Técnico, Desarrollo de Sistemas, Redes y Comunicaciones.

Estas subáreas las describiremos a continuación:



IlustraciónN°02: Estructura organizacional de la Oficina de Tecnologías de

Información de la Universidad César Vallejo - Piura

Fuente: Guía de Planeamiento Estratégico, Instructivo de Funciones y Propuesta

de Proyecto para OTI, 2010, p. 5.

Subárea de Soporte Técnico

La Subárea de Soporte Técnico se encarga de “reparar equipos de

cómputo en software y hardware en la UCV-Piura” (Guía de

planeamiento estratégico, instructivo de funciones y propuesta de

proyecto para (OTI), 2010, p. 7). Dentro del marco de sus funciones, la

subárea de soporte colabora con la subárea de redes, especialmente

cuando se trata de dar mantenimiento al cableado de la red y a la

instalación de puntos de red en los diversos ambientes de la

universidad, además, la subárea se encarga de:

Mantenimiento y configuración de las PCs de la Universidad.

Mantenimiento, instalación, configuración y reparación de otros

equipos tales como: laptops, impresoras, teléfonos I.P, cañones

multimedia, fuentes de alimentación, etc.

Realizar y verificar que el inventario físico de equipos coincida con

el que posee Patrimonio.

Subárea de Desarrollo de Sistemas



La Subárea de Desarrollo de Sistemas se encarga de “Analizar,

diseñar e implementar Sistemas de Información en la UCV-Piura”


de proyecto para (OTI), 2010, p. 6) y de verificarlos y controlarlos. La

subárea también se encarga de desarrollar nuevos sistemas de

información, de capacitar a los usuarios en su uso, de administrar las

bases de datos, y administrar los servidores de la Universidad.

La subárea se divide en: El Área de Desarrollo de Sistemas para

Plataforma Web y el Área de Desarrollo de Sistemas para Plataforma

Windows.

El Área de Desarrollo de Sistemas para Plataforma Web tiene la función

de administrar los portales Web de la UCV Piura, de la I.E.A Harvard

College, campus virtual, sistema PEL (Programa de Experiencia

Laboral) y otros servicios virtuales.

El Área de Desarrollo de Sistemas para Plataforma Windows tiene la

función de administrar los principales sistemas, bajo plataforma

Windows, de la universidad (tales como Premium .NET y SEUSS) y

sistemas externos.

Área de Redes y Telecomunicaciones

La subárea de redes y telecomunicaciones se encarga de “la

administración y configuración de los dispositivos de conexión:

Switches, routers, Access point” (Guía de planeamiento estratégico,

instructivo de funciones y propuesta de proyecto para (OTI), 2010, p. 8)

en otras palabras el área gestiona la red de la UCV-Piura.

De esta función principal se desglosan las siguientes funciones

específicas:

“Administración y Monitoreo del Servicio de Internet para

administrativos y laboratorios”.

“Administración y Monitoreo de Dispositivos de Seguridad

(Firewall)”.

“Configuración y Actualización de VLAN’s”.



“Instalación, administración y monitoreo de Servidores:

Servidores de Dominio (Windows 2003); Servidores Proxy,

servidor Web y servidor de Datos”.

“Habilitación, Revisión y Verificación de Cableado

Estructurado de voz y datos”.

“Administración del Sistema de Videoconferencia sobre IP-

VPN”.

“Instalación de Teléfonos IP”.


de proyecto para (OTI), 2010, p. 8).

Uno de los objetivos de la subárea de Redes y Telecomunicaciones,

para este año, es supervisar las actividades de cableado en el nuevo

edificio de medicina actualmente en proceso de construcción.

2.7.3. Descripción de la Red de la Universidad César Vallejo – Filial Piura.

La Red de la Universidad César Vallejo- Filial Piura cuenta, en primer

lugar, con un switch de fibra óptica, marca Allied Telesis, modelo AT-

9816GB que interconecta todos los edificios del campus, conformando el

backbone de fibra óptica; además cuenta con servidores de dominio

(Windows server 2003); servidores proxy, servidor web (Windows server

2008); todos estos equipos señalados anteriormente se ubican en el

datacenter, ubicado en el tercer piso del edificio principal. (Descripción de

la Red UCV – Piura, 2010, p. 1).

Se cuenta con 22 switches administrables, distribuidos en diferentes

edificios y ambientes del campus.

La Red de la universidad está dividida en las siguientes VLAN’s (Red de

Área Local Virtual) (Descripción de la Red UCV-Piura, 2010, p. 1):

Administrativos

Laboratorios

DMZ

Internet

Servicios

IP-VPN



Telefonía

Para el acceso a Internet, la red de la universidad cuenta con 2 Circuitos

Digitales en fibra óptica, contratados con Telefónica, con velocidad de 2

Mbps cada uno (Descripción de la Red UCV-Piura, 2010,p. 1 ).

Para el acceso a la IP-VPN la red cuenta con un Circuito Digital adicional

con 512 Kbps de ancho de banda, también en fibra óptica(Descripción de

la Red UCV-Piura, 2010, p. 1).

A partir del año pasado se implementó el sistema de Telefonía IP, el cual

también utiliza el enlace IP-VPN; además se cuenta con un Acceso

Primario contratado con Telefónica (30 líneas), para la comunicación con el

exterior.

Con la sección 2.6.3 hemos terminado de describir el escenario donde se

desarrollara este trabajo de investigación, el cual estará enfocado (tal

como dice el titulo) en la Oficina de Tecnologías de Información de la UCV-

Piura; específicamente en la subárea de Redes y Telecomunicaciones. Las

secciones siguientes trataran acerca de lo que es una auditoria, su relación

con el control interno y el marco de trabajo a usar.

2.7.4. La Gestión de Redes, Comunicaciones y Servidores

Dado el importante papel de la información en la actualidad, las

organizaciones se han visto en la necesidad de invertir en tecnologías que

permitan su manejo eficiente para lograr sus metas y objetivos

(Tecnologías de Información o TI), sin embargo, no sólo basta con tener la

tecnología o contar con el personal que sepa usarla, sino, en saber

gestionarla, he aquí es donde entra el casi omnipresente término de

gestión en el ambiente empresarial y, en el caso de las TI, la gestión

aplicada a ellas puede subdividirse. En este caso particular y ateniéndonos

a los fines de nuestra investigación, hablaremos de la gestión de redes.

Una definición, a primera mano, de gestión de redes la hallamos en el blog

de Mejía (2009): “La gestión de red consiste en monitorizar y controlar

los recursos de una red con el fin de evitar que esta llegue a

funcionar incorrectamente degradando sus prestaciones”

(<http://servidorespararedes.blogspot.com/2009/01/que-es-aplicaciones-

web.html >, 2009).



Otra definición, según Roberto Hernando (2002), refiere que la gestión de

red es “el conjunto de actividades dedicadas al control y vigilancia de

recursos de telecomunicación. Su principal objetivo es garantizar un

nivel de servicio en los recursos gestionados con el mínimo coste”

(<http://www.rhenardo.net/modules/tutorials/doc/redes/Gredes.html>,2002).

De acuerdo a Mendoza (2010), la gestión de redes se compone de los

elementos de toda gestión, en otras palabras, es la “planificación,

organización, operación, mantenimiento y control de los elementos

que forman una red para garantizar un nivel de servicio de acuerdo a

un costo.”

(<http://www.slideboom.com/presentations/84669/Gesti%C3%B3n-de-

Redes-de-Telecomunicaciones >, 2010,p. 3).

T.Saydam y T.Magedanz (1996) refieren puntualmente que los elementos

que una gestión de redes debe considerar:

La gestión de redes incluye el despliegue, integración y

coordinación del hardware, software y los elementos humanos

para monitorizar, probar, sondear, configurar, analizar, evaluar y

controlar los recursos de la red para conseguir los requerimientos

de tiempo real, desempeño operacional y calidad de servicio a un

precio razonable

(<http://lacnic.net/documentos/lacnicx/Intro_Gestion_Redes.pdf>, p. 2)

De todas estas definiciones podemos concluir que la gestión de redes no

se diferencia de cualquier otro tipo de gestión en lo que respecta a los

elementos de control: Planificación, organización, dirección y control); a la

consideración de los elementos humanos y a la persecución de un mismo

fin: El eficiente uso de recursos para evitar pérdidas. Lo nuevo de este tipo

de gestión es que se mueve en el marco de las Tecnologías de

Información (TI) lo que implica considerar hardware y software de los

equipos a gestionar.

De las definiciones anteriores se infiere que la importancia fundamental de

una gestión en redes es minimizar los gastos y, sobretodo, pérdidas, que

pueden producirse de darse una mala gestión. Para Mendoza (2010), esta

importancia general puede desglosarse en las siguientes (de las cuales

citamos algunas):

“Los sistemas de información son imprescindibles y están

soportados sobre las redes.”



“La información manejada tiende a ser cada día mayor y estar

más dispersa.”

“Aumentar la satisfacción de los usuarios.”

“Tecnología heterogénea: Existen productos y servicios de

múltiples fabricantes los cuales incorporan diversas

tecnologías que provocan un aumento constante de la

complejidad de los recursos gestionados tanto en cantidad

como en heterogeneidad”

(<http://www.slideboom.com/presentations/84669/Gesti%C3%B3n-de-

Redes-de-Telecomunicaciones>, 2010, p. 5, p. 6)

A estas razones podemos agregar la exigencia de los usuarios quienes,

cada vez, requieren un servicio de mayores prestaciones: mayor ancho de

banda, realizar videoconferencia con los altos directivos de la organización

o instalar cañones multimedia en todas las aulas de una universidad,

interconexión de un nuevo edificio, etc. Requerimientos que deben ser

atendidos dentro de los plazos previstos. Otra importancia es el adecuado

manejo de problemas, la empresa, especialmente, el área responsable de

gestionar las TI debe saber qué hacer para evitar, según Mendoza (2010),

un aumento de costos de operación, entonces, para disminuirlos,

recomienda la aplicación de “una gestión más proactiva que

reactiva”(<http://www.slideboom.com//presentations/84669/Gestión-de-

Redes-de-Telecomunicaciones>, 2010, p. 9), para la “detección de fallos

antes de que estos sucedan”

(Orozco, 2010, <http://www.slideshare.net/pakus/gestion-de-red>, p. 51),

en otras palabras minimizar los riesgos.

La gestión de redes con un enfoque proactivo debe abarca varios aspectos

(áreas funcionales) a tomarse en cuenta, según lo recomendado por la

OSI, son:

“Configuración: Facilidades que permiten controlar, identificar,

recoger y proporcionar datos a objetos gestionados, con el

propósito de asistir a operar servicios de interconexión.”

“Prestaciones: Facilidades dedicadas a evaluar el

comportamiento de objetos gestionados y la efectividad de

determinadas actividades.”



“Supervisión y Fallos: Conjunto de facilidades que permiten la

detección, aislamiento y corrección de una operación

anormal.”

“Seguridad: Aspectos que son esenciales en la gestión de red

y que permiten proteger los objetos gestionados.”

“Contabilidad: Facilidades que permiten establecer cargos por

el uso de determinados objetos e identificar costes por el uso

de éstos.”

(<http://www.edicionsupc.es/ftppublic/pdfmostra/TL01304M.pdf>,1998,p. 1)

Para Mendoza (2010), las áreas funcionales de la gestión definen lo que se

va a gestionar (¿qué?), la forma cómo se gestiona la red (¿cómo?) se

realiza por medio del monitoreo (monitorización) y control de la misma. La

monitorización, según Roberto Hernando (2002), “se ocupa de la

observación y análisis del estado y el comportamiento de los

recursos gestionados.” y la parte del control (según el mismo autor) es:

“la encargada de modificar parámetros e invocar acciones en los

recursos gestionados.”

(<http://www.rhernando.net/modules/tutorials/doc/redes/Gredes.html>,2002

)

En otras palabras, la monitorización observa y analiza; el control aplica y

modifica. Ambas actividades requieren un personal de TI calificado con

amplia y con experiencia así como una sólida formación moral y

compromiso con la organización.

En el aspecto estrictamente tecnológico, la gestión de redes se basa, por

lo general, en el modelo o paradigma Gestor-Cliente el cual agrupa los

componentes de una red sean de hardware o de software en gestores y

clientes.

Tal como dice Roberto Hernando (2002), los gestores son “los elementos

que interaccionan con los operadores humanos, y desencadenan las

acciones pertinentes para llevar a cabo las operaciones solicitadas”,

por otro lado, los agentes (según el mismo autor) “llevan a cabo las

operaciones de gestión invocadas por los gestores de la red”.

(<http://www.rhernando.net/modules/tutorials/doc/redes/Gredes.html>,2002

)

Junto a este paradigma encontramos los modelos normalizados de

gestión, los cuales según Mendoza (2010), son:



“TMN: Gestión de las redes de telecomunicación. Más que un

modelo de gestión, define una estructura de red de gestión,

basada en modelos de más bajo nivel.”

“Gestión OSI: Gestión de la torre de protocolos OSI. Emplea

CMIS/CMIP ”

“Gestión Internet: Gestión de redes TCP/IP. Emplea SNMP.”

(<http://www.slideboom.com/presentations/84669/Gestión-de-Redes-de-

Telecomunicaciones>, 2010, p. 25).

Cualquier modelo que se aplique, siempre requerirá la ayuda de

herramientas tecnológicas que apoyen (no realicen) la gestión de redes.

Según Thortonm, Garibaldi y Mahdi (1998), la incorporación de estas

herramientas a la gestión de redes facilita la incorporación de una gestión

proactiva porque la información de rendimiento que se puede recuperar de

una red es tan extensa que urge la necesidad de emplear medios

automáticos que ayuden al personal de TI (de redes en particular) a

elaborar data histórica para tomar las salvaguardas del caso que

minimicen los riesgos. (<http://tonet.0catch.com/doc/datamine1.pdf>,1998,

p. 2).

Además las herramientas permiten que los administradores de redes las

configuren a su medida y permiten la integración con otras herramientas de

gestión (Mendoza, 2010). Las principales herramientas en el mercado son:

Netsaint

ISM (Bull)

Nessus

Netflow, etc.

A manera de conclusión, la gestión de redes abarca varios aspectos que

van más allá de lo tecnológico (como vimos en los primeros párrafos de la

sección), su propósito es no tener la mejor tecnología en redes sino es

cumplir con los objetivos de la organización minimizando costos,

disminuyendo los riesgos y minimizando pérdidas (consecuencia no

deseable de los riesgos). La tecnología presente en la gestión de las redes

(herramientas tecnológicas y desarrollo tecnológico) forma parte, junto con

los recursos humanos (personal capacitado y responsable) y los métodos

de trabajo (preferir una gestión proactiva a una reactiva), de un sistema

integrado de gestión de redes. (Mendoza, 2010) la cual engloba todos los



elementos y factores que influyen en la eficiencia de la operación de la red

de una organización.

2.7.5. El Control Interno Informático y la Auditoría Informática

En la sección anterior (2.6.4) se afirmó que uno de los “cómos” de la

gestión de redes era el control (junto con la monitorización), este control se

le puede tipificar dentro del marco de control interno, que está muy

asociado con lo que es una auditoría; en la actualidad podemos hablar de

control interno informático y de auditoría interna informática.

Llevar el control interno en una organización fue, durante mucho tiempo,

un enfoque que no iba más allá de la información financiera y de las

auditorías internas orientadas en ese punto. Este enfoque tradicional

desechaba el impacto que las actividades operativas clave pueden tener

en las finanzas de la empresa lo que originaba la quiebra de numerosas

cajas de ahorro que, supuestamente, estaban bajo control. (Piattini &

Valriberas, 2008, 3)

Dada esta situación se necesitaba otro enfoque de control interno. Un

referente de mucho prestigio que apoya la visión contemporánea de control

interno es el informe COSO (citado por Amat, 2006, 5), el cual define el

control interno como:

El proceso que se encarga de realizar el Consejo de

Administración, La Dirección y el colectivo restante de una entidad,

con el propósito de otorgar un nivel razonable de confianza en la

consecución de los siguientes objetivos:

Asegurar la exactitud y confiabilidad de los datos de la

contabilidad y de las operaciones financieras.

Proteger los recursos contra el despilfarro, el fraude o el uso

ineficiente, así como evaluar el desempeño de todas las

divisiones administrativas y funcionales de la entidad

(eficiencia y eficacia de las operaciones).

(<http://www.gestiopolis.com/recursos6/Docs/Eco/contrinter.htm>,

2006,p. 5).



El informe COSO (Commitee Of Sponsoring Organization of the Treadway

Commission), de acuerdo al artículo Los Nuevos Conceptos de Control

Interno (2008) tiene “el objetivo de definir un nuevo marco conceptual

de control interno capaz de integrar las diversas definiciones y

conceptos que se utilizan sobre este tema”.

(<http://www.auditoria.uady.mx/arts/INFORME COSO (RESUMEN).pdf

>,2008, p. 1).

Según COSO (citando a del Toro y Segura, 12-25) existen cinco elementos

interrelacionados del control interno:

“Ambiente de Control: Se debe considerar la existencia de:

Integridad y valores éticos, compromiso de competencia

profesional, consejo de Administración o un Comité de

Auditoría, políticas y prácticas de Recursos Humanos.”

“Análisis de Riesgos: Tiene en cuenta los siguientes aspectos:

Objetivos organizacionales globales, identificación de riesgos,

administración del riesgo y del cambio.”

“Actividades de Control: Entre las cuales tenemos: Análisis

efectuados por la dirección, indicadores de rendimiento, control

de los procesos de información, control en la segregación de

funciones, etc.”

“Información y Comunicación: Tiene en cuenta los siguientes

aspectos: El uso de la información (interna y externa) para el

establecimiento de objetivos organizacionales, la descripción de

funciones y responsabilidades, canales adecuados de

comunicación para denunciar actos indebidos, etc.”

“Monitoreo: El monitoreo debe ser continuo. Existen varios

aspectos de la organización que deben ser supervisados como

la eficacia de las actividades de auditoría interna y receptividad

ante las recomendaciones de auditoría.”

COSO agrega al control interno puramente financiero tres aspectos

nuevos: La necesidad de controlar las funciones administrativas y

funcionales de la empresa; la noción de seguridad, es decir, proteger los



recursos de la organización y la noción de totalidad, lo que significa que el

control interno involucra a toda la organización como si fuera, citando el

artículo de Amat (2006, 6), “el sistema nervioso de una empresa”.

Piattini afirma que el control interno se encuentra ligado al concepto de

auditoría (Piattini & Valriberas, 2008, 8) el cual, según Sánchez (2006)

un proceso sistemático para obtener y evaluar de manera objetiva

las evidencias relacionadas con informes sobre actividades

económicas y otros acontecimiento relacionados, cuyo fin

consiste en determinar el grado de correspondencia del

contenido informativo con las evidencias que el dieron origen, así

como establecer si dichos informes se han elaborado observando

los principios establecidos para el caso.

(<http://www.gestiopolis.com/canales5/fin/funteadu.htm>,2005).

Por otra parte, citando nuevamente a Sánchez (2006), la auditoría es “una

herramienta de control y supervisión que contribuye a la creación de

una cultura de la disciplina de la organización y permite descubrir

fallas en las estructuras o vulnerabilidades existentes en la

organización”.

Al definir una auditoría como una herramienta de control, reafirma la

analogía a la que se refiere Piattini, lo que permite que los encargados del

control interno puedan auditar una empresa.

Pese a estas similitudes, control interno y auditoría no son procesos

idénticos por dos diferencias determinantes: La primera, que el control

interno es efectuado por el personal de la organización, por el contrario,

una auditoría puede pertenecer (auditor interno) o no pertenecer (auditor

externo) a la empresa. La segunda diferencia es la frecuencia de

realización. Los controles internos son constantes, en algunos casos

pueden ser diarios (controles día a día), por el contrario las auditorías

analizan un momento dado, por ese motivo no existen dos auditorías que

arrojen los mismos resultados pese a realizarse en la misma organización.

Con el desarrollo e implantación de las TI se comienza a hablar de

controles internos informáticos y de auditorías informáticas lo que significa



el arribo de un nuevo tipo de profesionales quienes sean capaces de

conocer las técnicas informáticas.

El control interno informático sugiere abarcar varios niveles de control, si

nos enfocamos en el alcance de nuestra investigación (seguridad en redes,

comunicaciones y servidores) podemos identificar dos niveles (Piattini &

Valriberas, 2008, 11)

“Entorno de Red: Esquema de la red, descripción de la

configuración hardware de comunicaciones, descripción del

software que se utiliza como acceso a las telecomunicaciones,

control de red, situación general de los computadores de

entornos de base que soportan aplicaciones críticas y

consideraciones relativas a la seguridad de la red.”

“Seguridad del Computador Base: Identificar y verificar

usuarios, control de acceso, registro e información, integridad

del sistema, controles de supervisión.”

Las nuevas técnicas requeridas para el control interno informático y la

auditoría informática no significan un desligamiento de los controles

anteriores porque las tecnologías de información deben alinearse con los

objetivos de la organización, no obstante imposible negar que exista un

cambio respecto a los controles existentes (financieros, de personal,

organizacionales) respecto a los procedimientos empleados en las

auditorías informática.

Este motivo explica la existencia del COBIT como herramienta de control

interno y auditoría informáticos que no significa que el COSO quede

relegado, por el contrario, COBIT toma muchas referencias de COSO pero

el alcance del primero sólo es para Tecnologías de Información, por el

contrario COSO es más general abarcando toda la organización.

2.7.6. La Auditoría en Redes

La auditoría en redes es un tipo de auditoría informática junto a la auditoría

en base de datos, de aplicaciones o de Internet, según la clasificación

propuesta por Piattini (2008).

La auditoría en redes consiste en la evaluación de la gestión de la

telemática (informática más comunicaciones) que se ha convertido en una



función clave de la empresa, por ese motivo la seguridad de la red y las

comunicaciones es muy importante, en este ámbito, los riesgos presentes

en la red pueden darse por causas propias de la tecnología o por causa de

personas malintencionadas.

Por problemas técnicos, la transmisión de datos en la red puede fallar

debido a alteración de bits (error en los medios de transmisión), alteración

de secuencia (orden de los paquetes enviados no coincide) o por ausencia

de paquetes (desaparición de las tramas por sobrecarga, error del medio o

error del direccionamiento)

Por causas dolosas (delitos informáticos) los riesgos principales son:

Indagación (lectura de un paquete por un tercero), Suplantación

(Introducción de un paquete por un tercero que el receptor del mensaje

cree que es legítimo), Modificación (Un tercero modifica el contenido de un

paquete) (Piattini & Boixo, 2008, 497).

Un aspecto que debe tenerse en cuenta y que lo avalan tanto Piattini

(2008) como Miranda, es el conocimiento que el auditor informático debe

conocer sobre el modelo OSI (Open System Interconection) y las siete

capas que lo conforman. Además, ambos autores concuerdan que tanto la

red física como la red lógica deben ser auditadas.

(<http://www.slideshare.net/GeekMelomano/auditora-de-redes>, p.4).

Por otro lado, Muñoz propone la ejecución de un análisis de vulnerabilidad

usando cualquiera de los métodos existentes: El de la caja negra (el

auditor intentará vulnerar la red sin conocer nada de ella) y el de caja

blanca (donde la empresa le facilita cierta información de la red).

(<http://www.slideshare.net/GeekMelomano/auditora-de-redes>, p. 15).

A pesar de ser dos tipos de pruebas muy interesantes no son de carácter

obligatorio y, puede ser, que la organización no permita a cualquier auditor

realizarla salvo que éste pertenezca a alguna empresa certificada en

“Hacking ético” cuyos servicios son muy costosos.

El monitoreo de la red puede ser efectuado sin problemas por los

administradores de la red de una empresa como parte del control interno

informático de la red (que puede incluir o no las pruebas propuestas por

Muñoz o ceñirse a los niveles propuestos por Piattini, depende de lo



establecido por los responsables de la red) lo que ayuda a la gestión

proactiva (recordemos la sección de gestión de redes) que se ayuda

mediante herramientas tecnológicas que facilitan la labor de los

responsables, sin embargo estas actividades se verán facilitadas si el

departamento de TI, especialmente el área de redes cuenta con una

política de seguridad “escrita, aprobada formalmente, actualizada,

entendible, entendida y seguida”(Piattini & Boixo, 2008, 505), que

permita al personal del área conocer lo que deben defender de lo contario

no se tomarán las decisiones correctas en caso de sobrevenir situaciones

que rompen la rutina de la administración de la red. El error de muchas

empresas y organizaciones es no alinear la administración de las TI con

sus principios, objetivos o metas corporativas, además muchos expertos

en redes, sistemas informáticos o soporte adoptan una postura demasiada

técnica olvidando las implicaciones de su labor en los objetivos de la

empresa. Consideramos que este aspecto no debe ser obviado por

ninguna auditoría informática de redes sea la metodología o marco de

trabajo que se use. Sobre el marco de trabajo con el que se basará la

auditoría a hacerse hablaremos en la siguiente sección incidiendo en la

justificación de nuestra elección de COBIT (estándar con el que

trabajaremos) por sobre otras metodologías o estándares.

2.7.7. COBIT y otros estándares aplicados a auditoría informática

La investigación que estamos desarrollando aplica COBIT para aplicar una

auditoría a la OTI (área de redes), por tal motivo, dedicaremos esta

sección a explicar brevemente en qué consiste COBIT y justificar la

elección de este estándar por sobre el MAGERIT y el ITIL.

COBIT (Control Objectives for Information and related Tecnology) es un

modelo, marco de trabajo (framework) o marco de referencia creado por

ISACA y lanzado en 1996; la última versión estable es la 4.1 y su última

actualización es la 5 (disponible sólo en inglés).

COBIT permite a la gerencia cerrar la brecha con respecto a los

requerimientos de control, temas técnicos y riesgos de negocio, y

comunicar ese nivel de control a los interesados, con ese fin, COBIT

incorpora las mejores prácticas de gestión de TI (se incluye COSO, ITIL,

Norma ISO/IEC 17799, etc.). La misión de COBIT es “investigar,

desarrollar, hacer público y promover un marco de control de



gobierno de TI autorizado, actualizado, aceptado internacionalmente

para la adopción por parte de las empresas y el uso diario por parte

de gerentes de negocio, profesionales de TI y profesionales de

aseguramiento” (COBIT 4.1, 2007,9). El gobierno o administración de las

TI, según COBIT, significa que las TI están orientadas al negocio

(alineación estratégica) y, por tanto, maximizan los beneficios de la

organización (entrega de valor); que las TI son administradas

responsablemente (administración de recursos) y los riesgos de las TI son

administrados apropiadamente (administración de riesgos); lo anterior es

sometido a medición y monitoreo constante (medición del desempeño).

COBIT está orientado al negocio, orientado a procesos, basado en

controles y orientado por la medición.

COBIT está orientado al negocio porque está diseñado como guía integral

para la gerencia y para los dueños de los procesos de negocio (COBIT 4.1,

2007,10) dándole un papel importante a la información para que la

empresa u organización alcance sus objetivos, cuando los objetivos y

metas se han definido.

Los dominios de COBIT engloban 34 procesos que son útiles para

identificar si las actividades y responsabilidades de la organización se

cumplen, y a pesar de que no se recomienda aplicar todos los procesos del

COBIT, el marco de trabajo reúne una lista completa de ellos.

COBIT está basado en controles porque reconoce que cada proceso

necesita ser controlado para asegurar que los objetivos del negocio

puedan llevarse a cabo y para detectar, corregir y prevenir sucesos no

deseados. (COBIT 4.1, 2007,13)

Aunque se quisiera, todos los controles del COBIT no pueden ser

implementados, sino que deben seleccionar aquéllos que se van a aplicar,

decidir los que se van a implementar y, por último, aceptar el riesgo de no

implementar los controles que podrían aplicarse.

COBIT está impulsado por la medición porque proporciona una visión del

nivel en el que la empresa se encuentra, en el que se está proyectando, el

avance hacia esa meta y la relación costo beneficio por alcanzar ese nivel

deseado; para ello COBIT propone modelos de madurez para conocer qué

tan bien una organización está administrando las TI de tal manera que



puede estar en uno de los seis niveles de madurez desde el nivel 0, es

decir, no existente, hasta un nivel 5 u optimizado (COBIT 4.1, 2007,17).

Los niveles de madurez son inversamente proporcionales al riesgo

existente en la administración de las TI; a mayor madurez en los procesos,

menos nivel de riesgo y viceversa.

Los niveles de madurez no sólo se dirigen a la comprensión de la situación

actual de la empresa sino que es una herramienta de benchmarking en la

que se compara la empresa con el estatus actual de la industria, con lo

cual se crea(n) el(los) objetivos(s) para mejorar la situación actual. A

continuación y para terminar con esta breve descripción del marco de

trabajo propuesto por COBIT describimos los niveles de madurez según el

modelo genérico de madurez (COBIT 4.1, 2007, 19)

“0 No Existente: carencia completa de cualquier proceso

reconocible dentro de la empresa”.

“1 Inicial: La empresa ha reconocido que existen problemas

que deben ser resueltos, pero no existen procesos estándar

sino procesos “ad-hoc” y una administración con enfoque aún

no organizado”.

“2 Repetible: Los procesos siguen procedimientos similares en

áreas diferentes que realizan la misma tarea, pero todavía no

son estandarizados”.

“3 Definido: Los procedimientos se han estandarizado y

documentado y se han difundido a través de entrenamiento”.

“4 Administrado: Los procesos están en constante mejora y

proporcionan buenas prácticas. Se usa la automatización

fragmentada y limitadamente”.

“5 Optimizado: Los procesos están al nivel de mejor práctica y

se encuentran en mejoramiento continuo”.

COBIT es un marco de trabajo recomendado para la gestión de TI, otro

marco similar que pudiese haber escogido es el ITIL, el cual incluso tiene

la ventaja de ser más específico que el COBIT porque, según Velázquez

(2008), COBIT define el ¿qué? e ITIL define el ¿cómo? , sin embargo se



critica a ITIL de que sus medidas no puedan implementarse en pequeños y

medianos departamentos de TI (como es el caso de OTI). El otro candidato

era MAGERIT, esta metodología propone realizar un análisis de riesgos y,

luego, aplicar las salvaguardas necesarias para minimizarlos.

Si bien es una opción interesante, MAGERIT sólo se aplica al análisis de

riesgos (que corresponde al proceso PO9 de COBIT) y es más idóneo para

realizar un plan de contingencia que una auditoría.

COBIT reúne características de ITIL y MAGERIT, lo que posibilita una

visión más amplia, sin embargo la desventaja de COBIT es su generalidad,

en otras palabras se limita al qué debe hacerse y no cómo hacerse, lo que

significa que debe ayudarse de otras metodologías y estándares para

estudiar un aspecto es particular, por ejemplo, citando el caso de

MAGERIT. En el proceso PO9, COBIT recomienda un análisis de riesgos

pero no dice cómo, en cambio MAGERIT propone los procedimientos y

técnicas a aplicarse; lo mismo sucede respecto a las auditorías en redes,

para ese fin existen numerosos estándares muchos de ellos son modelos y

paradigmas como los que tratamos brevemente en la sección de gestión

de redes (paradigma gestor agente o la gestión OSI) o también son

estándares de organizaciones prestigiosas como la IEEE o la ISO que

especifican características tecnológicos del hardware y software de las

redes.

Estos estándares enmarcados en COBIT servirán de base para el

desarrollo de esta auditoría en redes en la OTI de la UCV- Piura.

2.8. Marco Conceptual

2.8.1. Auditoría Informática

Es el conjunto de técnicas, actividades y procedimientos, destinados a

analizar, evaluar, verificar y recomendar en asuntos relativos a la

planificación, control, eficiencia, seguridad y adecuación del servicio

informático en la empresa, por lo que comprende un examen metódico,

puntual y discontinuo del servicio informático, con vistas a mejorar en:

Rentabilidad

Seguridad



Eficacia

(<http://www.ctmsoftware.es/wp/servicios-2/auditoria-informatica/>,2011).

Este tipo de Auditoria se llevará a cabo en la Oficina de Tecnologías de

Información de la UCV – Piura.

2.8.2. Control Interno

El control interno es un proceso ejecutado por el consejo de directores, la

administración y todo el personal de una entidad, diseñado para

proporcionar una seguridad razonable con miras a la consecución de

objetivos en las siguientes áreas:

Efectividad y eficiencia en las operaciones.

Confiabilidad en la información financiera.

Cumplimiento de las leyes y regulaciones aplicables.

Comprende el plan de organización y el conjunto de métodos y medidas

adoptadas dentro de una entidad para salvaguardar sus recursos, verificar

la exactitud y veracidad de su información financiera y administrativa,

promover la eficiencia en las operaciones, estimular la observación de las

políticas prescrita y lograr el cumplimiento de las metas y objetivos

programados.

(<http://www.gestiopolis.com/canales/financiera/articulos/no11/controlintern

o.htm>, 2001).

2.8.3. COBIT

COBIT (Control Objectives for Information and related Tecnology) es un

modelo, marco de trabajo (framework) o marco de referencia creado por

ISACA en 1996 con la misión de investigar, desarrollar, hacer público y

promover un marco de control de gobierno de TI autorizado,

actualizado, aceptado internacionalmente para la adopción por parte

de las empresas y el uso diario por parte de gerentes de negocio,

profesionales de TI y profesionales de aseguramiento” (COBIT 4.1,

2007,9).

COBIT toma en cuenta 4 dominios:

1. Planear y Organizar: Proporciona dirección para la entrega de

soluciones y la entrega del servicio



2. Adquirir e Implementar: Proporciona las soluciones y las pasa

para convertirlas en servicios.

3. Entregar y Dar Soporte: Recibe las soluciones y las hace

utilizables para los usuarios finales.

4. Monitorear y Evaluar: Monitorear todos los procesos para

asegurar que se sigue la dirección provista.

(COBIT 4.1, 2007, 12)

El cuarto dominio de COBIT será tomado en cuenta para la aplicación de la

Auditoría informática en redes, comunicaciones y servidores de la Oficina

de Tecnologías de la Información de la UCV – Piura.

2.8.4. Red Informática

Una red informática está formada por un conjunto de ordenadores

intercomunicados entre sí que utilizan distintas tecnologías de hardware y

software. Las tecnologías que utilizan (tipos de cables, de tarjetas,

dispositivos) y los programas (protocolos) varían según la dimensión y

función de la propia red. De hecho, una red puede estar formada por sólo

dos ordenadores, aunque también por un número casi infinito; muy a

menudo, algunas redes se conectan entre sí creando, por ejemplo, un

conjunto de múltiples redes interconectadas, es decir, lo que conocemos

por Internet.(MailxMail. Recuperado el 21 de abril del 2011, de

http://www.mailxmail.com/curso-introduccion-internet-redes/que-es-red).

2.9. Hipótesis

La aplicación de una auditoría basada en COBIT permitirá determinar el nivel de

madurez de la gestión de redes, comunicaciones y servidores aplicada por la Oficina

de Tecnologías de Información (OTI) a la red de la Universidad César Vallejo – Piura.

2.10. Variables e Indicadores

2.10.1. Variables

Variable Independiente

Auditoría informática



Variable Dependiente

Evaluación de la gestión en redes, comunicaciones y servidores de

la Oficina de Tecnologías de Información de la UCV – Piura.

Variable Interviniente

Marco de trabajo COBIT.

2.10.2. Indicadores



N° Indicador Definición Conceptual

Definición Operacional

Unidad de Medida

Técnica Instrumento Fuente Informante

1

Número de procesos críticos de negocio no incluidos en un plan de contingencia. (NPC)

Es el total de procesos críticos que no están considerados en un plan de contingencia y que, de presentarse una eventualidad, pueden afectar las actividades administrativas de la universidad

NPC =Num. P.C.N.P Donde: Num.P.C.N.P= Número de proceso crítico no incluido en el plan.

Número

Revisión Bibliográfi

ca, Entrevista

Fichas Bibliográficas,

Guía de Entrevista 02

Área de Redes OTI Jefe y Asistente del Área de Redes de la OTI

2

Porcentaje de incidentes de red resueltos en un tiempo óptimo (PIR)

Es el porcentaje de incidentes de red, comunicaciones y servidores que el área de redes ha resuelto en el menor tiempo posible (estimado en 5.5 h)

Donde: Num.I.R = Número de Incidentes de Red Total.I= Número total de incidentes. n=número de meses i=mes

Porcentaje


ca, Entrevista



Área de Redes OTI Jefe y Asistente del Área de Redes de la OTI

3

Número promedio de horas perdidas por usuario al mes, debido a interrupciones a la red. (NHP)

Es el total de horas perdidas promedio por interrupciones del servicio planeadas (mantenimiento de líneas telefónicas) como no planeadas (corte del fluido eléctrico)

Donde: TPMISi= Tiempo perdido mensual por interrupción del servicio de cada interrupción n=número de interrupciones

Número


ca, Entrevista



Área de Redes (OTI) Área de Soporte Técnico (OTI)

Jefe y Asistente del Área de Redes de la OTI Jefe y Asistente del Área de Soporte Técnico





Unidad de Medida

Técnica Instrumento Fuente Informante

4

Número de controles aplicados a servicios de terceros. (NCT)

Es el total de controles aplicados a proveedores (terceros) de servicio de cableado de red.

NCT=Num. CT Donde: CT= Número de controles aplicado a terceros.

Número Entrevista Guía de

Entrevista 07

Área de Redes OTI

Jefe y Asistente del Área de Redes de la OTI

5

Porcentaje de inversión para cubrir los costos en TI (PIATI)

Es el porcentaje del presupuesto invertido en la actualización en TI (hardware y software) para mejorar la red de la universidad.

(∑

)

Donde: IATI =Inversión en actualización de TI P = Presupuesto i=año n=número de años

Porcentaje Revisión Bibliográfi

ca

Fichas Bibliográficas

Área de Redes OTI


6

Número promedio de veces por mes que se ha realizado mantenimiento a la red.(NMR)

Es el total (suma) de veces que se ha realizado mantenimiento preventivo a la red de la universidad por parte de la OTI.

Donde: Num M. R = Numero de mantenimiento a la red (por mes) n=número de meses i=mes

Número Entrevista, Observaci

ón

Guía de Entrevista 04,

Guía de Observación

01

Área de Redes OTI






Unidad de

Medida Técnica Instrumento Fuente Informante

7

Número de controles físicos para garantizar la continuidad del servicio (NCF)

Es el total de controles aplicados a la red física de la universidad por parte de la OTI. (Por ej: controles biométricos al datacenter, infraestructura de cableado )

NCF=CF

Donde: NCF= Número de controles físicos. CF= Controles Físicos.

Número Entrevista,

Observación

Guía de Entrevista05,


02

Área de Redes OTI Área de Soporte Técnico (OTI)


8

Número de controles lógicos para garantizar la continuidad del servicio (NCL)

Es el total de controles lógicos aplicados a la red lógica de la universidad (Por ej: Encriptación de datos, cambio de contraseñas, detección de virus y malware, etc.)

NCL=CL Donde: NCL= Número de controles lógicos. CL= Controles lógicos.

Número Entrevista,

Observación

Guía de Entrevista06,


03



9

Nivel de madurez de la gestión de redes de la OTI (NMGR)

Es la sumatoria de los niveles de madurez de los controles aplicados a la red de la Universidad dividido entre el total de controles considerados.

∑

Donde: NMC = Nivel de Madurez de un control aplicado a la red de la Universidad. i = Control “i” aplicado a la red de la universidad N = Número de controles aplicados a la red de la Universidad considerados.

Nivel de Madurez

Encuesta

Cuestionario 01

Cuestionario 02

Cuestionario 03

Cuestionario 04


Jefe y Secretaria de cada escuela. Jefe y Asistente del Área de Soporte Técnico

Tabla N°01: Tabla de Indicadores del Proyecto

Fuente: Elaborado por los autores.



CAPÍTULO III

METODOLOGÍA



3.1. Tipo de Estudio

Según Vásquez (2005), el tipo de estudio determina el “el tipo de información que

espera obtener, así como el nivel de análisis que deberá realizar”.

Nuestra investigación siguió el paradigma cuantitativo porque se ha probado una

hipótesis, es de función aplicada y es de tipo Cuasi- Experimental porque no es

posible crear grupos de forma aleatoria debido a que la muestra de estudio (personal

del área de redes de OTI) fue muy pequeña para realizar un estudio experimental, en

cambio, fue posible adoptar ciertos aspectos del diseño experimental en la

programación de procedimientos para la recolección de datos (Campbell y Stanley,

1973).

3.2. Diseño del Estudio

Según Cabrero y Martínez (2011), el diseño del estudio (o de la investigación)

“constituye el plan general del investigador para obtener respuestas a sus

interrogantes o comprobar la hipótesis de la investigación” (<http://www.aniorte-

nic.net/apunt_metod_investigac4_4.htm >,2011).

El diseño de investigación se basó en el tipo de investigación cuasi-experimental,

tomando como modelo un solo grupo al que se le aplicó un pre-test y post-test bajo

un esquema de marco lógico. Su representación simbólica es la siguiente

Ilustración Nº03: Fórmula Diseño Cuasi-experimental Post-Prueba

Fuente: Investigadores basándose en el modelo presentado por Guevara y Tejada (2010).

En este trabajo de investigación, se consideró, como pre-test, la evaluación de la

situación actual de la OTI, mediante la aplicación de la auditoría informática.

Fórmula

G1 -- O1

G1 X O2

Donde:

G1: Trabajadores Administrativos de la OTI

O1-O2: Observación del grupo de Investigador

X: Tratamiento al grupo de trabajo (usando marco

lógico)



Dada la imposibilidad de aplicar un post-test “tradicional” (lo que significaría volver a

aplicar nuevamente la auditoría después de emitidas las recomendaciones), se optó

por usar un modelo de marco lógico causa-efecto, en el que se analizaron las causas

y efectos de los problemas identificados durante el pre-test (desarrollo de la

auditoría), a partir del cual se elaboraron, primero, una comparación entre la situación

actual (pre-test) y la situación deseada (lo que recomienda COBIT) y, segundo, un

plan de mejora donde se enumeran las recomendaciones para cada uno de los

problemas identificados durante la auditoría. Estas recomendaciones se compararon

con la situación actual a manera de proyección del impacto positivo que generará la

aplicación de las recomendaciones por parte de OTI en un futuro inmediato.

3.3. Población y Muestra

Levin & Rubin (1996) definen como población al “conjunto de todos los elementos

que estamos estudiando, acerca de los cuales intentamos sacar conclusiones.”

Por otro lado, muestra, en palabras de Murria R. Spiegel (1991) es “una parte de la

población a estudiar que sirve para representarla”.

En nuestra investigación, se consideró a la muestra equivalente a la población dado

que el grupo de estudio (Personal de la OTI) fue pequeño, tal como se detalla en la

siguiente tabla.

Área Encargados Cantidad

Área de la Oficina de Tecnología de Información

Jefe del Área de OTI 1

Personal de la Sub-área de Redes 1

Personal de la Sub-área de Desarrollo 3

Personal de la Sub-área de Soporte 4

Total de Informantes 9

Tabla N°02: Personal (población) para medir los instrumentos de investigación (OTI - Piura).

Fuente: Elaborado por los autores

3.4. Métodos de Investigación

El método de investigación se basó en tres etapas:

Etapa 1: Se recopiló información de la OTI mediante los instrumentos de medición.



Etapa 2: Se aplicó la auditoria informática a la gestión de redes de la OTI.

Etapa 3: Se aplicó un marco lógico causa-efecto donde, a partir de él, se elaboró un

plan de mejora para cada indicador, por último se comparó la situación real (recogida

en etapa 1 y 2) con la situación deseada (que se especificó en el plan de mejora)

3.5. Técnicas e instrumentos de recolección de datos

3.5.1. Técnicas

Entrevista:

Edison Morales Lizarazo las define como las técnicas que “se utilizan para

obtener información de forma verbal, a través de preguntas, acerca de

las necesidades de la organización. Los entrevistados deben ser

personas relacionadas de alguna manera con la organización, el

sistema actual o el sistema propuesto”.

En nuestro trabajo de investigación se realizaron entrevistas al personal de

la OTI mediante la aplicación de Guías de entrevistas.

Encuestas:

Para Edison Morales Lizarazo “es una técnica para recopilar

información tomando una muestra de la población objetivo, se obtiene

información sobre las necesidades y preferencias de usuarios o

clientes, difiere de un censo en donde toda la población es estudiada,

se pueden obtener datos estadísticos de la información recolectada,

las preguntas suelen ser cerradas”.

(http://www.slideshare.net/edimor72/la-recoleccin-de-datos-1384547 ,2009)

Se realizó esta técnica al personal de OTI mediante la aplicación de

cuestionarios.

Revisión Bibliográfica:

Reyero Eusebio dice “Es el proceso por cual se considera la literatura

existente sobre el tema que se va a investigar”.

(http://wwff.thespacer.net/blog/revision-bibliografica/ ,2010).



Para nuestro trabajo de investigación utilizamos esta técnica para la

revisión de fuentes bibliográficas existentes en la OTI.

Observación:

Para María Soledad Fabbri, la observación es “un proceso cuya función

primera e inmediata es recoger información sobre el objeto que se

toma en consideración”

(http://www.fhumyar.unr.edu.ar/escuelas/3/materiales%20de%20catedras/tr

abajo%20de%20campo/solefabri1.htm)

Se realizó está técnica mediante la aplicación de guías de observación.

3.5.2. Instrumentos

Los Cuestionarios:

Para Eunice Ugel Garrido, los cuestionarios “pueden ser la única forma

posible de relacionarse con un gran número de personas para conocer

varios aspectos del sistema, se pueden obtener respuestas más

honestas debido al anonimato de los participantes, las preguntas

estandarizadas pueden arrojar datos más confiables”.

En nuestro proyecto se utilizaron cuestionarios para recolectar información en

el indicador de Nivel de madurez de la gestión de redes de la OTI (NMGR)

definidos en el apartado 2.9.2.

Guía de Entrevista:

Eunice Ugel Garrido expresa que “es una guía que contiene los temas,

preguntas sugeridas y aspectos a analizar en una entrevista de trabajo.

Dentro de los temas que se encuentran: Experiencia profesional,

estudios y formación, historia familiar entre otros”.

(http://www.formasminerva.com/BancoForma/G/guia_de_entrevista/guia_de_e

ntrevista.asp?CodIdioma=ESP, 2010).

Las guías de entrevista se utilizaron para los indicadores: PIR, NHP, NCT,

NMR, NCF y NCL definidos en el apartado 2.9.2.



Fichas Bibliográficas:

Quiroz Víctor manifiesta que “es una ficha pequeña, destinada a anotar

meramente los datos de un libro o articulo. Estas fichas se hacen para

todos los libros o documentos que eventualmente son útiles a nuestra

investigación”.

(http://es.scribd.com/doc/44263841/FICHAS-BIBLIOGRAFICAS)

Las fichas bibliográficas se utilizaron para recoger información de los

documentos de OTI en los indicadores NPC y PIATI

Guías de Observación:

Según Carmina Makar, es un documento que “propone algunas líneas

sobre las cuales puedes trabajar al momento de hacer tu diagnóstico”

(http://mail.udgvirtual.udg.mx/biblioteca/bitstream/20050101/1290/1/Guia_de_o

bservaci%C3%B3n.pdf)

Las guías de observación se utilizaron para recoger información para los

indicadores NMR, NCF y NCL

Técnicas Instrumentos Fuente de Investigación

Entrevista

Revisión Bibliográfica


Fichas Bibliográficas Área de Redes OTI.

Entrevista




Entrevista




Entrevista Guía de Entrevista 07 Área de Redes (OTI), Área

de Soporte Técnico (OTI).

Revisión Bibliográfica Fichas Bibliográficas Área de Redes OTI.

Entrevista, Observación Guía de Entrevista 04,

Guía de Observación 01 Área de Redes OTI.


Guía de Observación 02

Área de Redes (OTI), Área



Guía de Observación 03





Encuesta

Cuestionario 01

Cuestionario 02

Cuestionario 03

Cuestionario 04



Tabla N°03: Técnicas e Instrumentos usados


3.6. Métodos de análisis de datos

El análisis de la información se realizará utilizando los siguientes métodos de análisis

de datos:

Análisis estadístico: Para la recolección, análisis e interpretación de datos. Se

aplicó el análisis estadístico para cada uno de los indicadores considerados (9

indicadores). El análisis estadístico se realizó en base a los resultados reflejados en

la tabulación de datos y en los gráficos estadísticos realizados para cada indicador (9

indicadores).

Tabulación: Se aplicó tabulación en los indicadores PIR, NHP y NMR ya que en los

tres se requirió consultar y contra el tipo de incidente registrado en la bitácora de

atenciones de la OTI.

Representaciones gráficas: Se aplicaron representaciones gráficas parar cada uno

de los indicadores aplicados.

Se elaboraron de gráficos estadísticos de barras, aplicados en los indicadores: PIR,

NHP, NMR, NCF y NCL; y gráficos estadísticos de torta (para datos muy pequeños o

para comparaciones porcentuales), aplicados en los indicadores: NPC, NCT y PIATI.

Además se aplicaron gráficos de barras para comparar el pre-test (resultados de

auditoría) con el post-test (medidas del plan de mejora) para cada indicador.



CAPÍTULO IV

DESARROLLO DE LA PROPUESTA



4.1. Introducción

Como se indicó en el planteamiento del problema, la Universidad Cesar Vallejo –

Piura, al contar con sistemas informáticos que automatizan gran parte de sus

procesos, la OTI se convierte en una de las áreas más importantes y con gran

responsabilidad en apoyar a la Universidad a lograr sus objetivos, por lo que la

aplicación de la Tesis “Evaluación de la Gestión en Redes, Comunicaciones y

Servidores en la Oficina de Tecnologías de Información de la Universidad César

Vallejo – Piura mediante la aplicación de una Auditoría Informática basada en

COBIT.” permitirá mejorar la gestión de la red de la universidad de la Oficina de

Tecnologías de Información mediante la evaluación de los controles efectuados por la

OTI de acuerdo a lo recomendado por COBIT lo que permitirá que el área determine

controles que ayuden a mejorar las deficiencias encontradas durante la aplicación de

la auditoría, por lo que estaría apoyando considerablemente a lograr los objetivos

definidos por la Universidad. Para el desarrollo de la propuesta nos basamos en el

marco de trabajo COBIT, específicamente del dominio Dar Soporte (DS), porque

abarca actividades diarias de OTI destinadas directamente al cliente y, por tanto más

asequibles de medir, cuestión que no sucedía con los demás dominios (Planificar y

Organizar y Adquirir e Implementar) dado que requerían la revisión exhaustiva de

documentos, como por ejemplo, los planes operativos del área, los cuales no tuvimos

acceso por ser muy confidenciales, no obstante se hizo una excepción con el proceso

P09, porque consideramos que la gestión de riesgos un punto esencial dentro de la

gestión de redes y de las TI en general, por tanto (y dada la asequibilidad del plan de

contingencia del área) se trata de un punto aspecto de suma importancia que no debe

de dejar de ser evaluado.2

Considerando lo anterior, hemos considerado las siguientes actividades a realizar para

llevar a cabo la propuesta, las cuales definimos en el siguiente cuadro:

2 El dominio Monitorear y evaluar (ME) está considerado implícitamente dado que considera los dominios

anteriores pero dándole un enfoque de evaluación y monitoreo constante.



Actividades Procedimientos

Planificación de la Auditoría

Definición de los Objetivos y alcances

de la auditoria.

Análisis del ambiente a auditar.

Determinar actividades a realizar en la

auditoria.

Determinar recursos para la auditoria

informática.

EJECUCIÓN DE LA AUDITORÍA

Evaluación del Entorno de

Control

Revisión de manuales y documentación

del Área y recopilación de políticas y

estándares aplicados a los procesos del

área

Evaluación de la Gestión de

Riesgos

Evaluación de la gestión de riesgos y

plan de contingencia del Área

Evaluación de las Actividades

de Control Interno de la

Gestión de la Red

Evaluación de la atención de incidentes

en la red

Evaluación de las interrupciones a la

Red

Evaluación de los costos para cubrir la

inversión en actualización en TI

Evaluación de controles aplicados a

terceros

Evaluación de la frecuencia de las

tareas de mantenimiento de la red

Evaluación de controles físicos a la red

Evaluación de controles lógicos a la red

Evaluación de las actividades de

actualización del personal del área de

redes

Determinar el Nivel de Madurez de la

gestión de Redes de la OTI



REVISIÓN Y ANÁLISIS DE RESULTADOS

Revisión de los papeles de trabajo

Análisis de Resultados y contrastación

de Resultados con las normas del

framework COBIT

Determinación del Diagnóstico de

acuerdo a los indicadores considerados

Determinación de recomendaciones en

base del diagnóstico

ELABORACIÓN DEL INFORME DE AUDITORÍA

Elaboración del Informe de Auditoría

Tabla N°04: Plan de Trabajo de la Auditoría Informática


4.2. Planificación de la Auditoría

4.2.1. Definición del Objetivo y alcance de la auditoria

En este punto definimos lo que la propuesta va a estudiar (alcances) y con

qué propósito (objetivos), estableciendo que actualmente, las empresas

necesitan de las TI para cumplir con sus metas y objetivos. La Universidad

Cesar Vallejo – Piura no es la excepción por lo que la evaluación de la

gestión en redes, comunicaciones y servidores de su OTI (Oficina de

Tecnologías de la Información) comprueba el alineamiento de la gestión de la

Red de la UCV – Piura con los objetivos de la misma, como también ayudar a

la mejora de la gestión de la red de la universidad por parte de la OTI en

función de lo especificado por COBIT, del cual abarcaremos el dominio de Dar

Soporte (DS), debido a la naturaleza de los procesos realizados (procesos de

atención al usuario), a la asequibilidad de los mismos y, por último, a la falta

de acceso a documentos muy confidenciales como los planes operativos

anuales del área; tomando como base el DS se han determinado los

indicadores los cuales también están alineados con las preguntas de

investigación y los objetivos de la auditoría los cuales son los siguientes:

Evaluar la efectividad de la aplicación de controles internos a la red de la

universidad.



Evaluar el alineamiento de la gestión de redes con las metas de la

universidad.

Analizar el riesgo inherente a la gestión de la red de la universidad.

Determinar el nivel de madurez de la gestión de la red de la universidad

de acuerdo a COBIT.

Determinar controles a implementar de acuerdo a las deficiencias

encontradas.

Para poder lograr estos objetivos, se han implementado 9 indicadores los

cuales se han relacionado con los procesos de COBIT de la siguiente manera:



Ítem Indicadores Procesos COBIT

1 Número de procesos críticos de

negocio no incluidos en un plan

de contingencia. (NPC)

PO9: Evaluar y Administrar los riesgos de TI.

Identificación de eventos (P09.3)

2 Porcentaje de incidentes de red

resueltos en el tiempo acordado

(PIR)

DS8: Administrar la mesa de servicio y los incidentes.

Porcentaje de incidentes resueltos dentro de un

lapso de tiempo aceptable/acordado.

DS10: Administrar los problemas.

Porcentaje de problemas resueltos dentro del

período de tiempo solicitado.

3 Número de horas perdidas por

usuario al mes, debido a

interrupciones a la red. (NHP)

DS4: Garantizar la continuidad del servicio.

Número de horas perdidas por usuario por mes,

debido a interrupciones no planeadas.

4 Número de controles aplicados a

servicios de terceros. (NCT)

DS2: Administrar los servicios de terceros.

Identificación de todas las relaciones con los

proveedores. (DS2.1)

5 Porcentaje de inversión en

actualización de TI (PIATI)

DS6: Identificar y asignar costos

Porcentaje de costos totales de TI que son

distribuidos de acuerdo con los modelos acordados.

6 Número de veces por mes que

se ha realizado mantenimiento a

la red.(NMR)

DS13: Administración de Operaciones

Programación de tareas (DS13.2)



Monitoreo de la infraestructura de TI. (DS13.3)

7 Número de controles físicos para

garantizar la continuidad del

servicio (NCF)

DS12: Administración del ambiente físico

Medidas de seguridad física (DS12.2)

Acceso físico (DS12.3)

Protección contra factores ambientales (DS12.4)

8 Número de controles lógicos

para garantizar la continuidad del

servicio (NCL)

DS5: Garantizar la seguridad de los sistemas

Administrar las cuentas de usuario (DS5.4)

Pruebas, Vigilancia y Monitoreo de la Seguridad.

(DS5.5).

Prevención, Detección y Corrección de Software

Malicioso. (DS5.9).

Seguridad de la red (DS5.10)

9 Nivel de madurez de la gestión

de redes de la OTI (NMGR)

PO9: Evaluar y Administrar los riesgos de TI.

Identificación de eventos (P09.3)

DS2: Administrar los servicios de terceros

Identificación de todas las relaciones con los

proveedores. (DS2.1)


Número de horas perdidas por usuario por mes,

debido a interrupciones no planeadas.

DS5: Garantizar la seguridad de los sistemas.

Administrar las cuentas de usuario (DS5.4)



Pruebas, Vigilancia y Monitoreo de la Seguridad.

(DS5.5).

Prevención, Detección y Corrección de Software

Malicioso. (DS5.9).

Seguridad de la red (DS5.10)

DS6: Identificar y asignar costos.

Porcentaje de costos totales de TI que son

distribuidos de acuerdo con los modelos acordados.

DS10: Administración de problemas

Porcentaje de problemas resueltos dentro del

período de tiempo solicitado.

DS12: Administración del Ambiente Físico.

Medidas de seguridad física (DS12.2)

Acceso físico (DS12.3)

Protección contra factores ambientales (DS12.4)

DS13: Administración de Operaciones.

Programación de tareas (DS13.2)

Monitoreo de la infraestructura de TI. (DS13.3)

Tabla N°05: Comparación de los indicadores del proyecto con los procesos de COBIT (Dominio: Dar Soporte)




Donde:

DS2: Administrar los servicios de terceros.

DS3: Administrar el desempeño y la capacidad.


DS5: Garantizar la seguridad de los sistemas.

DS6: Identificar y asignar costos.

DS7: Educar y entrenar a los usuarios.

DS8: Administrar la mesa de servicios y los incidentes.

DS9: Administrar la configuración.

DS10: Administración de problemas.

DS11: Administración de datos.

DS12: Administración del ambiente físico.

DS13: Administración de Operaciones.

4.2.2. Análisis del ambiente a auditar

Se describe la realidad problemática y la forma de trabajo de la Oficina de

Tecnologías de Información (OTI), información que se obtuvo gracias a la

aplicación de entrevistas (Guía de entrevista realizada para conocer la

realidad de la oficina tecnologías de información (OTI) – Anexo 25) y revisión

bibliográfica (Ficha Bibliográfica – Anexo 5) a los trabajadores del área, como

también a la observación del ambiente.

La OTI se encarga de apoyar las labores administrativas de la universidad

originalmente formaba una sola área junto al Centro de Informática y

Sistemas, sin embargo a partir de noviembre del 2010, éste último sólo se

avocó a la parte académica mientras que OTI se encarga de administrar,

hasta el día de hoy, las tecnologías de información de la universidad. Al inicio

de esta investigación laboraban, en la oficina, trece personas y tres

practicantes, no obstante, debido a los últimos cambios de personal,

solamente laboran nueve personas, quienes se reparten en las tres áreas que

conforman la OTI de la siguiente manera:

Área de Soporte Técnico: cuatro trabajadores y un practicante.



Área de Desarrollo de Sistemas: tres trabajadores y dos practicantes,

de los cuales, un trabajador (ayudado de un practicante) pertenece a la

subárea de desarrollo para Windows; los otros dos trabajadores (junto

al otro practicante) pertenecen a la subárea de desarrollo Web.

Área de Redes y Comunicaciones: 1 trabajador (administrador de la

red)

El administrador de la red tiene a cargo la jefatura del área (OTI) lo que le

obliga a tomar mayor prioridad a las responsabilidades del cargo de mayor

jerarquía (jefatura de la OTI) descuidando sus funciones como administrador.

El personal técnico de la OTI es de sólo 8 personas resulta insuficiente para

atender las necesidades de todas las áreas de la universidad. De todas las

áreas, soporte técnico es la que recibe mayor número de peticiones de

atención y, como vemos en la distribución de personal, sólo cuenta con cuatro

trabajadores y un practicante a medio tiempo. Según Soporte, las áreas de la

Universidad con el mayor índice de atenciones son: Caja, admisión,

promoción, unidades móviles, seguridad y CEPRE (Centro de Preparación

para la Vida Universitaria). Ha habido casos en que el personal de Soporte no

puede atender a determinados usuarios de manera inmediata porque se

encuentra en otra área solucionando un problema o realizando tareas de

mantenimiento a la red o sus equipos.

Cuando el jefe de la OTI se ausenta por motivo de viaje o por vacaciones. La

jefatura de la oficina pasa al trabajador de mayor antigüedad, esa persona

pertenece al área de Desarrollo de Sistemas, no obstante, él no es el

administrador de la Red. Esta ausencia se hace notar, cuando se requiere

realizar procedimientos que sólo el administrador está autorizado a ejecutar,

por ejemplo, el alta de la cuenta de usuario, procedimiento3 que se ejecuta con

regularidad después de formatear una PC infectada por malware. En ese

caso, se llama al administrador de red vía celular o anexo (si se encuentra en

otra filial), quien se encarga de crear un usuario de dominio vía remota por

medio de la conexión VPN, de ocurrir un incidente más serio relacionado con

el tráfico de la red se perdería tiempo valioso contactando al único

3 Este procedimiento se explica con mayor detalle en el punto siguiente.



administrador disponible con la autorización de monitorear el tráfico de la red

con las herramientas adecuadas.

Ambas situaciones (alta de usuarios y monitoreo del tráfico de la red) nos

hacen pensar que el administrador es el único responsable de la gestión de la

red, pero, revisando la Guía de Planeamiento Estratégico (2009) de la OTI, se

colige que las actividades de la gestión de redes se reparten entre las tres

áreas como se observa en un extracto de este documento4

Área de Desarrollo de Sistemas (Subárea de Desarrollo Web)

Administrar y Monitorear la Replica de Datos de la Filial - Piura.

Administrar y Monitorear Backups y Trazas de la BD

Yaesta_Piura.

Área de Soporte Técnico

Mantenimiento y/o reparación de PCs, Impresoras, Laptop,

Monitores, Cañón Multimedia, Fuentes de Alimentación y

Teléfonos I.P.

Mantenimiento en el Cableado y ubicación de puntos de Red.

Revisión de instalaciones de equipos de red en todo el edificio.

Área de Redes y Comunicaciones

Administración y Monitoreo del Servicio de Internet para

administrativos y laboratorios.

Administración y Monitoreo de Dispositivos de Seguridad

(Firewall).

Configuración y Actualización de VLAN’s.

Instalación, administración y monitoreo de Servidores: Servidores

de Dominio (Windows 2003); Servidores Proxy, servidor Web y

servidor de Datos

4 Se han seleccionado sólo las funciones relacionadas con la Gestión de Redes.



Habilitación, Revisión y Verificación de Cableado Estructurado de

voz y datos.

Administración del Sistema de Videoconferencia sobre IP-VPN

Instalación de Teléfonos IP.

Este documento data del 2009 y no se ha actualizado acorde al último cambio

que se ha dado este año en el que el servidor de datos han pasado a ser

gestionado totalmente por Trujillo, dejando a Piura el servidor de dominio y el

servidor web. De acuerdo a este documento, OTI todavía tiene

responsabilidad con este servidor.

Respecto a los servidores, éstos se hallan en el datacenter ubicado en el

tercer piso de la universidad, en ese mismo recinto también se ubican los

equipos siguientes:

Firewall CISCO ASA.

Servidor de dominio

Servidor de distribución del grupo administrativos

Servidor Web

2 proxys: Para administrativos y para laboratorios.

Router de voz para uso multimedia.

El Firewall CISCO ASA se conecta con los tres servidores de la Universidad

(Dominio, distribución y web) y con el router de voz; a su vez existe una

conexión entre el servidor web y el de dominio. Los edificios del campus se

interconectan por medio de fibra óptica y la interconexión con Trujillo, por

VPN.

El mantenimiento de estos equipos es responsabilidad del área de Soporte

(como se consta en la Guía de Planeamiento Estratégico), lo que les

convierte, junto al administrador de la red, en personas autorizadas en

acceder al datacenter de la universidad.

Para proteger el ingreso físico no autorizado, el datacenter cuenta con una

puerta de madera con ventana de vidrio, cerrada con llave (igual a las puertas



de las aulas de clases que están alrededor). Para ser el recinto que guarda los

activos de información más importantes de la universidad, debería contar con

un medio de protección contra accesos físicos no autorizados más eficiente,

ya que la puerta puede ser forzada con relativa facilidad.

En una primera impresión la seguridad del datacenter se está dejando de lado,

lo mismo ocurre con las medidas para asegurar la continuidad del servicio en

caso de cortes no planeados del suministro eléctrico ya sea en Piura como en

Trujillo5.

Otra causa de interrupción no deseada es provocada por saturación que hace

a los sistemas lentos mermando la productividad, aunque, los responsables de

soporte (cuando se le preguntó al respecto) perciben este inconveniente como

un problema menor, lo que explica que las interrupciones por saturación (la

causa más común de la caída del servicio de mensajería instantánea del

campus) sean un problema latente de la red de la universidad; pero no todo es

negativo para la OTI, porque recientemente las áreas de redes y soporte han

estado trabajando en etiquetar y ordenar el cableado de los gabinete de red

de los edificios del campus, uno de esos gabinetes de red se encuentra en la

misma OTI, donde se ha podido observar, de primera mano, estas tareas de

mantenimiento y mejora.

De la situación analizada podemos inferir lo siguiente: Primero, la

administración de la red es responsabilidad de una sóla persona, segundo, los

documentos no se actualizan lo que es una señal de una posible falta de

atención a la documentación en OTI, tercero, no existe una cultura de

seguridad preventiva, el hecho de que el datacenter no cuente protección

contra accesos no autorizado o el no considerar las interrupciones de la red

(por saturación o por corte de energía) como problemas que requieren

atención, significa que no ha pasado ningún incidente o problema serio para

que surja un cambio importante en las medidas de seguridad.

5 En Trujillo se encuentran instalados los sistemas informáticos. Sólo los sistemas Web de campus virtual

están en Piura



Un análisis más detallado será posible después de haber revisado la

documentación del área y de realizar entrevistas enfocadas a aspectos

específicos de la gestión.

Como conclusión final, el análisis ha demostrado la necesidad de aplicarse

una auditoría informática a la OTI para que la oficina pueda mejorar la gestión

de la red de la universidad.

4.2.3. Actividades a realizar en la Auditoría

Este punto abarca la descripción breve de las actividades que se llevaron a

cabo durante el desarrollo de la auditoria. Estas actividades (incluyendo las

dos primeras actividades de la fase de planificación) son las siguientes:

PLANIFICACIÓN DE LA AUDITORÍA

Definición de los objetivos y alcance de la auditoría

Descripción Se establece lo que la auditoría en redes va a

estudiar (alcance) y con qué propósito

(objetivos).

Producto Objetivos y Alcances definidos

Fecha Inicio 12/09/2011

Fecha Fin 12/09/2011

Análisis del ambiente a auditar

Descripción El análisis consiste en describir la realidad problemática

y la forma de trabajo del Área de Redes, información que

ha sido recogida gracias a la observación del ambiente y

a entrevistas aplicadas a los trabajadores del área.

Producto Enfoque definido del Ambiente a Auditar



Determinar actividades a realizar en la auditoría

Descripción Se describen brevemente las actividades que se

ejecutarán en el desarrollo de la auditoría informática

Producto Plan de Trabajo





Determinar recursos para la auditoría informática

Descripción Se enumeran y consignan costos de los materiales y

servicios que se usarán durante el desarrollo de la


Producto Recursos para la Auditoría Informática determinados



Tabla N°06: Planificación de la Auditoría – Actividades del plan de trabajo.


EJECUCIÓN DE LA AUDITORÍA

Evaluación del Entorno de Control

Revisión de manuales y documentación del Área y recopilación de

políticas y estándares aplicados a los procesos del área

Descripción Se realiza una entrevista previa para familiarizarse con

los procedimientos y políticas del área de redes (OTI),

luego, se solicita la documentación correspondiente al

jefe de OTI para su revisión donde se puede contrastar

lo obtenido en la entrevista con la documentación.

Producto Políticas y procedimientos revisados



Tabla N°07: Evaluación del Entorno de Control – Actividades del plan de trabajo.




Evaluación de la Gestión de Riesgos

Evaluación de la gestión de riesgos y plan de contingencia del Área

Descripción Se solicita al jefe de OTI el plan de contingencia del área

para su revisión para conocer y evaluar la gestión de

riesgos del área de redes.

Producto Informe sobre la gestión de la seguridad de la OTI,

Procesos no incluidos en el plan de contingencia



Tabla N°08: Evaluación de la Gestión de Riesgos – Actividades del plan de trabajo.


Evaluación de las Actividades de Control Interno de la Gestión de

la Red

Evaluación de la atención de incidentes en la red

Descripción Se evalúa la atención de incidentes y se determina el

número de incidentes de red atendidos y desarrollados

en un tiempo óptimo

Producto Porcentaje de incidentes de red resueltos en el tiempo

acordado.



Evaluación de las interrupciones a la Red

Descripción Se evalúa el número de horas perdidas por interrupción

del servicio de red en la universidad.

Producto Número de horas perdidas por usuario al mes, debido a

interrupciones a la red



Evaluación de los costos para cubrir la inversión en actualización en TI

Descripción Se evalúa los costos destinados para la inversión en TI,



de ello se obtiene un porcentaje destinado para ello.

Producto Porcentaje de costos para la inversión en actualización de TI



Evaluación de controles aplicados a terceros

Descripción Se identifican y evalúan los controles aplicados a

terceros (personas externas a OTI)

Producto Número de controles aplicados a servicios de terceros



Evaluación de la frecuencia de las tareas de mantenimiento de la

red

Descripción Se evalúan las tareas de mantenimiento de la red y su

frecuencia de realización

Producto Número de veces por año que se ha realizado

mantenimiento a la red



Evaluación de controles físicos a la red

Descripción Se evalúa si los controles físicos son los adecuados, así

como cuántos de ellos se aplican.

Producto Número de controles físicos aplicados a la red



Evaluación de controles lógicos a la red

Descripción Se evalúa si los controles lógicos son los adecuados, así

como cuántos de ellos se aplican.

Producto Número de controles lógicos aplicados a la red



Evaluación de las actividades de actualización del personal del

área de redes

Descripción Se evalúa si los profesionales de OTI (área de redes)

cuentan con un programa de capacitación idóneo.

Producto Nivel de Madurez de la Gestión de Redes de la OTI





Determinar el Nivel de Madurez de la gestión de Redes de la OTI

Descripción Se determina el nivel de madurez de la OTI basándose

en la escala propuesta por el framework COBIT

Producto Nivel de Madurez de la Gestión de Redes de la OTI



Tabla N°09: Evaluación de las Actividades de Control Interno de la Gestión de la Red.

– Actividades del plan de trabajo.


REVISIÓN Y ANÁLISIS DE RESULTADOS

Revisión de los papeles de trabajo

Descripción Se revisan los cuestionarios, entrevistas y productos

obtenidos en cada actividad del desarrollo de la auditoría

como primer paso para redactar un informe consolidado.

Producto Papeles de trabajo revisados



Análisis de Resultados y contrastación de Resultados con las normas del framework COBIT

Descripción Se analizan los resultados tomando como base los

procesos y buenas prácticas del framework COBIT.

Producto Hallazgos de auditoría



Determinación del Diagnóstico de acuerdo a los indicadores considerados

Descripción Se elaboran las conclusiones en base a los hallazgos de

auditoría. Con ello se diagnostica la situación actual de

la OTI



Producto Conclusiones de auditoría



Determinación de recomendaciones en base del diagnóstico

Descripción Se elaboran las recomendaciones de mejora de acuerdo

al diagnóstico de auditoría

Producto Recomendaciones en base a los hallazgos encontrados



Tabla N°10: Revisión y Análisis de Resultados. – Actividades del plan de trabajo.


ELABORACIÓN DEL INFORME DE AUDITORÍA

Elaboración del Informe de Auditoría

Descripción Se consolidan los hallazgos, conclusiones y

recomendaciones en un solo informe final que se

presentará a la OTI.

Producto Informe de Auditoría



Tabla N°11: Elaboración del Informe de Auditoría. – Actividades del plan de trabajo.


4.2.4. Recursos a utilizar en la Auditoría Informática

Definimos y consignamos costos de los materiales y servicios que se usaran

durante el desarrollo de la auditoria.

Para la auditoría informática se usarán los siguientes recursos:



RECURSO DESCRIPCIÓN CANTIDAD PREC. UNIT SUBTOTAL

MATERIAL

DE

ESCRITORIO

Papel Bond A4 1 millar S/. 22.00 S/. 22.00

CD – ROM 5 unidades S/. 0.80 S/. 4.00

Lapiceros Faber

Castell 5 unidades S/. 0.50 S/. 2.50

Corrector Faber

Castell 2 unidades S/. 2.50 S/. 5.00

Resaltador 2 unidades S/. 2.00 S/. 4.00

Fólder Manila A4 10 unidades S/. 0.50 S/. 5.00

Clips 1 caja S/. 0.50 S/. 0.50

Cartucho de Tinta HP

negra 1 unidades S/. 75.00 S/. 75.00

Cartucho de Tinta HP

a color 1 unidad S/. 120.00 S/. 120.00

Grapas 1 caja S/. 2.00 S/. 2.00

FastenerArtesco 1 caja S/. 3.50 S/. 3.50

Perforador Artesco 1 unidad S/. 12.00 S/. 12.00

SUBTOTAL S/. 255.50

SERVICIOS

Fotocopias:

1000

unidades S/. 0.10 S/. 100.00

Internet 3 Meses S/. 99.00 S/. 297.00

Anillados 10 unidades S/. 5.00 S/. 50.00

Empastados 5 unidades S/. 8.50 S/. 42.50

Impresiones

1000

Unidades S/. 0.10 S/. 100.00

Transporte 2 personas S/. 150.00 S/. 300.00

SUBTOTAL S/. 889.50

TOTAL S/. 1,145.00

Tabla N°12: Presupuesto de la ejecución de la auditoría informática.




4.3. Ejecución de la Auditoría

4.3.1. Evaluación del Entorno de Control

4.3.1.1. Revisión de manuales y documentación del Área y recopilación

de políticas y estándares aplicados a los procesos del área

Este punto se conforma de dos procedimientos realizados, el primero

consistió en realizar un cuestionario (Encuesta: Documentación del Área.

Anexo 2) al jefe del área sobre la documentación que manejaba el área

(OTI), para luego solicitar la documentación correspondiente (Solicitud:

Facilidad para revisar documentos, y Solicitud: Facilidad para revisar el

registro de incidentes. Anexos 3 y 4 respectivamente). El segundo

procedimiento consistió en realizar una entrevista (Guía de Entrevista:

Aplicación de Políticas y Procedimientos de Seguridad en el Área de

Redes de la Oficina de Tecnologías de Información. Anexo 6)al jefe de

OTI, con la intensión de definir los procedimientos y políticas que se

realizan en el área (OTI).

Estos procedimientos se realizaron con la finalidad de revisarla y

contrastarlos con la información obtenida con la entrevista realizada al jefe

de la OTI.

A. Revisión Preliminar de Manuales y Documentación del Área

Se consultó al jefe del área, mediante un cuestionario (Encuesta:

Documentación del Área. Anexo 2), sobre la documentación que

maneja el área; como resultado del cuestionario, la OTI maneja los

siguientes documentos:

Guía de Planeamiento Estratégico, Instructivo de Funciones

y Propuesta de Proyecto

Tal como su título describe, el documento consta de un

planeamiento estratégico, una descripción de funciones

específicas de cada subárea y una propuesta de trabajo donde,

como refiere la introducción del documento, “como parte de

atención al cliente” (Guía de planeamiento estratégico,

instructivo de funciones y propuesta de proyecto para (OTI),



2010). De las tres partes del documento sólo tuvimos acceso a

las dos primeras las cuales comentaremos y analizaremos a

continuación:

El planeamiento estratégico en su primera parte se limita

solamente a la exposición de la misión, visión y valores de la

institución. El documento no cuenta con un análisis del

ambiente interno o externo o de una matriz FODA, los cuales

son fundamentales en un planeamiento estratégico.

El instructivo de funciones es más detallado, primero, expone

los objetivos del documento, luego, presenta el organigrama del

área y, por último, menciona cada una de las funciones de las

subáreas de la OTI, pero, cada función está presentada de

manera enunciativa no entra en detalles de los pasos de los

procedimientos que implica cada función del área, además

(como se ha señalado en el análisis del ambiente a auditar) es

un documento de dos años de antigüedad y se han dado

cambios importantes que han afectado las funciones del área.

Descripción de la Red UCV – Piura

El documento consta de dos partes en realidad, la primera

aborda la descripción de la red y la segunda menciona las

funciones de la subárea de Redes y Comunicaciones.

La descripción (de la red y las funciones) es muy ligera y breve,

además no se incluye el mapa topológico, el cual se maneja

como un documento aparte.

Plan de Contingencia

El plan que maneja el área es el resultado del trabajo de tesis

de dos alumnos egresados de la Universidad César Vallejo –

Piura, el cual fue propuesto y desarrollado durante el año 2010.

Además es importante aclarar que el área cuenta con un trabajo

de tesis no con un documento formal.



Mapa Topológico de la Red

Es un documento que data del 2009 y que se ha ido

actualizando conforme los cambios se han venido dando.

Tuvimos acceso a una versión del mapa que no presentaba

información sensible como las direcciones IP de los equipos.

Bitácora de incidentes y problemas en la red

La bitácora se gestiona manualmente mediante archivos en

Excel los cuales son manejados por la asistente de la oficina.

En estos archivos se anota el tipo de problema y el usuario.

Como todo sistema manual la búsqueda de incidentes

registrados es tediosa e incluso existe el riesgo de que los

registros se pierdan, aunque se está implementando un sistema

web que permitirá no solo registrar sino gestionar los incidentes.

El módulo de registro estuvo usándose hasta mitad de año,

luego se volvió a gestionar los incidentes de forma manual.

Bitácora de registro de atenciones al usuario

Se registra en archivos de Excel (como en el caso de los

incidentes) por la asistente. Con el nuevo sistema de gestión de

incidentes se tomarán en cuenta, además las atenciones al

usuario.

De los documentos anteriores, sólo el plan de contingencia y las

bitácoras de atenciones e incidentes se guardan en formato físico

(Registro en plantillas que luego son archivados), los demás

documentos se almacenan en la PC del jefe de la OTI, en formato

digital específicamente archivos de Word. Los documentos que no

están en formato físico no se encuentran organizados dándose el

riesgo de pérdida de estos documentos.

De la documentación propuesta en el cuestionario, el área no

maneja los siguientes documentos:

Bitácora de Acceso al Datacenter



No se registra el acceso de las personas al datacenter. No

existe un documento ni físico ni virtual

Manuales de configuración para servidores, firewall,

routers, etc.

El área no cuenta con manuales de configuración de los

equipos del datacenter. La gestión de ambos es, como se refirió

en al análisis del ambiente a auditar, empírica, cada trabajador

de las subáreas de redes y de soporte, sabe lo que tiene que

hacer debido a su propia experiencia.

B. Recopilación de Políticas y Estándares aplicados a los procesos

del Área de Redes

Se realizó una entrevista al jefe del área de redes, Ing. Alfredo Enrique

Iwasaki Vargas quien es el administrador de la red del campus de la

UCV – Filial Piura.

La entrevista se basó en una guía (Guía de Entrevista: Aplicación de

Políticas y Procedimientos de Seguridad en el Área de Redes de la

Oficina de Tecnologías de Información – Anexo 6) que trató las

políticas y procedimientos de seguridad que debe implementar un área

de TI, las cuales están referidas en el COBIT 4.1 y en el ISO 270016.

Los puntos tratados fueron los siguientes:

6 El framework COBIT trata de integrar las mejores prácticas en TI. Por tanto muchos procesos del COBIT

guardan relación con otros estándares y metodologías como MAGERIT, ISO 27001, ISO 27002, entre otras.



Procedimiento de dar de alta una cuenta de Usuario

El procedimiento para dar de alta a un usuario es el siguiente:

Gráfico Nº01: Diagrama de Flujo para el procedimiento de dar de alta a un

usuario

Fuente: Guía de Entrevista: Aplicación de Políticas y Procedimientos de

Seguridad en el Área de Redes de la Oficina de Tecnologías de Información –

Anexo 6. Elaborado por los autores

Para crear el identificador de un usuario se toma la primera

letra de su nombre más el apellido paterno completo.

La contraseña no la establece el administrador, sino el mismo

usuario cuando inicia sesión (con sus usuarios de dominio) por

primera vez.

El área no regula si los usuarios usan contraseñas seguras o

“fuertes” para sus cuentas.

No

Si

Terminar

OTI Valida al

trabajador con RR.HH

Inicio

Solicitud enviada a

OTI por parte del

Área responsable

del trabajador.

Es

Trabajador

Crear Cuenta

Informar al Usuario



El administrador no establece restricciones horarias para los

usuarios. El acceso está habilitado para cualquier día de la

semana sea laborable o no.

Sólo el Ing. Iwasaki (Administrador de la red) está autorizado a

dar alta o baja a las cuentas de usuario.

Procedimiento de baja de cuenta de usuario.

El procedimiento para dar de baja a un usuario es el siguiente:

Gráfico Nº02: Diagrama de Flujo para el procedimiento de dar de baja a un

usuario




La baja de un usuario consiste en la desactivación, no en la

eliminación de una cuenta, porque, ha habido casos de

trabajadores que han vuelto a laborar en la Universidad.

Terminar

Desactivar Cuenta

Solicitud de

desactivación de

cuenta por parte

del responsable

del área

Inicio



Procedimiento de verificación de accesos.

El procedimiento para verificación de accesos es el siguiente:

Gráfico Nº03: Diagrama de Flujo para el procedimiento de verificación de

accesos.



Anexo 6. Elaborado por los autores.

La revisión del log de sucesos se realiza semanalmente por el

administrador de la red.

Los sucesos son registrados en una bitácora.

No se tiene control sobre el tiempo de permanencia (se

desconoce) de los logs en el servidor.

Procedimiento de chequeo del tráfico de la red.

El chequeo de tráfico de la red es el siguiente:

Terminar

Inicio

Revisar log de

sucesos del servidor

Se registran los

sucesos externamente



Gráfico Nº04: Diagrama de Flujo para el procedimiento de chequeo del tráfico de

la red.




Se monitorea el trafico de la red mediante 02 herramientas de

software: Wireshark y el CISCO ASDM.

No

Si

No

Si

Se soluciona el

problema

Se monitorea mediante las

herramientas: Wireshark y el

CISCO ASDM

Inicio

Inconveniente

en el tráfico de

la red

Se identifica el origen y

se verifica el problema

El problema

es grave

Se aísla el equipo

Se procede a dar

mantenimiento al

equipo

Terminar



Si no hay inconvenientes en el tráfico de red, entonces el

proceso se da por concluido, caso contrario si se identifica el

origen y se verifica el problema.

Si el problema presentado no es grave (problema con el

conector de red) se da una solución inmediata, caso contrario

se aísla el equipo y se procede a dar solución a esta

(Mantenimiento del equipo o formateo) dependiendo cual sea

el problema.

5. Procedimiento para el monitoreo de los volúmenes de

correo.

El correo corporativo se maneja desde Trujillo (Departamento de

Tecnologías de Información - DTI) por lo tanto, no es gestionado

por OTI.

Procedimientos para el resguardo de copias de seguridad.

Gráfico Nº05: Diagrama de Flujo para el procedimiento de resguardo de copias

de seguridad.




Terminar Grabar copias

en DVD

Realizar copias

de respaldo

Inicio



Las copias de respaldo (backup) se realizan al servidor de

datos y al servidor Web, dos veces al día: una copia en la

mañana y otra en la noche. Las copias de respaldo se

almacenan en DVD, en un armario, pero dentro de la misma

oficina de OTI, lo que no es conveniente porque existe el

riesgo de pérdida de los backups de ocurrir un incendio o

terremoto.

Se usa el software CoverBackup.

Los responsables de realizar los backups son los integrantes

del área de Desarrollo de Sistemas.

Procedimientos para el monitoreo de los puertos en la red.

Gráfico Nº06: Diagrama de Flujo para el procedimiento de monitoreo de los

puertos en la red.



Anexo 6. Elaborado por los Autores.

Si No

Verificar switch Terminar

Existe un

problema

Monitorear

switches

Inicio



Para monitorear los switches se usan las herramientas:

Wireshark y CISCO ADSM.

Procedimientos de cómo dar a conocer las nuevas normas

de seguridad implantadas.

Gráfico Nº07: Diagrama de Flujo para el procedimiento de dar a conocer las

nuevas normas de seguridad implantadas.




OTI organiza capacitaciones para el manejo de los sistemas

principales pero ninguna relacionada con política de

seguridad.

El medio para hacer conocer una nueva norma es mediante

documento interno.

Terminar

Envío de norma por correo a

todas las áreas

Asistente redacta nueva

norma

Inicio



Procedimientos para la determinación de identificación de

usuario y grupo de pertenencia por defecto.

Los usuarios cuentan con perfiles iguales, no obstante, existen

restricciones de acceso a ciertas páginas de Internet.

Las restricciones no son las mismas en todas las áreas.

Procedimientos para recuperar información.

Gráfico Nº08: Diagrama de Flujo para el procedimiento para recuperar

información.


Seguridad en el Área de Redes de la Oficina de Tecnologías de Información. –


Si

No

Terminar

Restaurar copias de

respaldo

Pérdida de

información

Inicio



De acuerdo al administrador de la red, hasta la fecha, no ha

existido un suceso lo suficientemente grave como para

restaurar la data del servidor web

Procedimientos para la Atención de Incidentes.

Gráfico Nº09: Diagrama de Flujo para el procedimiento para la atención de

incidentes.


Seguridad en el Área de Redes de la Oficina de Tecnologías de Información. –


No

Si

Escalamiento

de Incidentes

Terminar

¿Incidente

resuelto?

Llamada a experto

Registro de

Incidentes.

Solicitud de

Atención

Inicio



La atención de incidentes se realiza con ayuda de un escritorio

de ayuda (helpdesk) que atiende solicitudes por línea

telefónica o por correo electrónico.

4.3.2. Evaluación de la Gestión de Riesgos

La evaluación de la gestión de riesgos tomó como base la revisión y análisis

del plan de contingencia que maneja la OTI (Plan de Contingencia, 2010),

mediante Guías Bibliográficas (Anexo 5). Este plan fue elaborado como

trabajo de tesis de dos alumnos egresados de la Universidad César Vallejo –

Piura, uno de ellos labora en la OTI.

El plan tuvo como alcance el área de OTI, y tomó la metodología del INEI de

gestión de riesgos, la cual, de acuerdo a los tesistas, es más completa y

detallada que MAGERIT.

Cuando se le preguntó al jefe de la OTI, respecto a este plan, él se refirió que

aún no cuentan con un plan organizado, lo cual es un indicador de que todavía

no se ha aplicado el plan de contingencia ni se ha revisado para mejorarlo,

esto podría deberse a que se trata de un documento relativamente reciente,

elaborado y corregido por los tesistas durante el segundo semestre del 2010 y

los primeros meses del 2011, fecha en el que le fue entregada al jefe de la

OTI por lo tanto aún es muy poco tiempo como para que el área lo implemente

completamente, pero debe considerarse su revisión como una tarea

primordial.

Respecto a la evaluación de la gestión de riesgos de OTI, ésta se hará desde

dos frentes: Primero se evaluará si el plan ha incluido todos los procesos de

negocio críticos de la universidad y, luego se evaluará la gestión de riesgos en

sí, basándonos en:

Clasificación del riesgo, de donde se tomarán los riesgos de mayor

ocurrencia y más alto impacto para evaluar si las medidas de

contingencia se cumplen o no en la organización.

Contrastación de procedimientos del plan con la información obtenida

en las entrevistas.



Medidas de contingencia para redes, ya sea de seguridad física o

lógica, lo cual se realizará a lo largo de toda la auditoría

4.3.2.1. Procesos Claves del Negocio

El siguiente gráfico, extraído del plan de contingencia ilustra los procesos

críticos de la universidad.



Ilustración Nº04: Desarrollo de los Procesos Académicos de la Universidad

Fuente: Plan de Contingencia - 2010.

R.R.H.H

REGISTRA PERSONAL

ASIGNA COSTOS

CREA PERFIL

ADMISIÓN

CAJA

ASISTENTA

SOCIAL

SEUUS

REGISTROS

ACADEMICOS

ESCUELA

REGISTRO HORARIO

ASIGNAR HORARIO A DOCENTE

REGISTRO MATRICULA

CAMPUS VIRTUAL

DOCENTES ALUMNOS

SÍLABOS

NOTAS

CREA PERFIL

VER NOTAS

ENVIAR TRABAJOS

LINK DE INTERÉS

1

2

3



Como punto siguiente, el plan de contingencia analiza las operaciones

críticas del sistema de información sobre los que se soportan los procesos

del gráfico superior, seguido del análisis de las operaciones actuales,

mediante la observación de este gráfico y la lectura de las operaciones

críticas en el documento (plan de contingencia) se encontrará el Número

de procesos críticos de negocio no incluidos en un plan de

contingencia, indicador que operacionalmente se define así.

NPC =Num. P.C.N.P

Dónde:

NPC: Número de Procesos Críticos no incluidos en un plan de

contingencia

P.C.N.Pi: Cada procesos crítico no incluido en el plan de

contingencia analizado

Considerando lo anterior, hemos observado y constatado que el plan de

contingencia no menciona los procesos de matrícula para los cursos de

inglés, computación ni actividades integradoras, por tanto los procesos

críticos no considerados son los siguientes:

Proceso de matrícula a los cursos de computación.

Proceso de matrícula a los cursos de inglés (Centro de idiomas)

Proceso de matrícula a los cursos de actividades integradoras

Identificamos 3 procesos críticos no considerados en el plan de

contingencia; con ayuda de la fórmula el resultado se obtiene así:

NPC = 3

Se estableció la proporción de los procesos no incluidos con respecto a

los procesos críticos considerados (en el plan de contingencia), para ello



se enumeraron los procesos críticos de la Ilustración 4 que se incluyen en

la siguiente tabla

Área o Persona (que ejecuta

proceso)

Proceso Crítico

RR.HH

Registro de Personal

Asignación de costos

Creación de perfiles de los

colaboradores

Escuela

Registro de Horarios

Asignación de horarios a docentes

Registro de matrícula

Docente

Subir sílabos al Campus virtual

Registro de notas de los alumnos.

Crear perfiles de alumnos.

Alumnos

Ver notas

Enviar trabajos

Acceder a links de interés

TOTAL DE PROCESOS 12

Tabla N°13: Procesos Críticos considerados en el plan de contingencia


Se han considerado 12 procesos críticos, junto con los 3 procesos no

considerados suman 15 procesos, de ese total, la proporción de los

procesos críticos no considerados se reflejan en el siguiente gráfico:



Gráfico Nº10: Proporción de procesos críticos no incluidos en plan de

contingencia de OTI

Fuente: Plan de Contingencia – 2010. Elaborado por los autores

De acuerdo al gráfico, Los procesos críticos no considerados representan

el 20% del total de procesos críticos.

Estos procesos se consideran críticos porque un alumno no puede

graduarse si no ha llevado estos cursos durante el tiempo que dura el

estudio de la carrera, de ocurrir un problema con los sistemas, OTI se ve

involucrada en el problema.

Otra carencia que hemos encontrado es la no consideración de

operaciones críticas de la administración de la red de la universidad para

cada proceso crítico considerado en el plan de contingencia; el plan se

limita sólo a describir los procesos críticos desde el punto de vista de la

usabilidad de los sistemas informáticos que soportan las operaciones.

80%

20%

Procesos Críticos

Procesos considerados Procesos no considerados



Es recomendable que esta visión, se amplíe considerando estas

operaciones y procesos desde el punto de vista de las redes,

comunicaciones e, incluso de soporte. Esta visión, creemos será posible

si se analizan los registros de atenciones que las subáreas de redes y

soporte realizan a las áreas involucradas en los procesos críticos, aspecto

que se evaluará en los puntos siguiente

4.3.2.2. Gestión de Riesgos y Plan de Contingencia

Los riesgos que considera el plan de contingencia se dividen en riesgos

físicos y lógicos:

Riesgos Físicos: Altas temperaturas de calor, fenómeno de El

Niño, terremotos, inundaciones, incendios, vandalismo/terrorismo,

robo de equipos, fraude, acceso no autorizado a recursos, errores

humanos. (Plan de Contingencia, 2010).

Riesgos Lógicos: Robo de datos, fallo de servicio de telefonía IP,

fallo de servicios eléctricos, software malicioso, ausencia del

personal de OTI, falta de concientización en seguridad en TI. (Plan

de Contingencia, 2010).

El plan de contingencia de OTI gestiona los riesgos teniendo en cuenta el

impacto y la probabilidad de ocurrencia. El impacto se mide usando una

escala del 5 al 20 cada una de ellas tiene una definición conceptual

llamada Nivel de Impacto como lo muestra la siguiente tabla.



Tabla N°14: Valores de Impacto.

Fuente: Plan de Contingencia 2010

Para las probabilidades, la escala va desde el 1 al 3, su definición

conceptual se denomina Nivel de probabilidad como se observa a

continuación:

Valor de

Probabilidad

Nivel de

Probabilidad Descripción

1 Bajo (Rara vez) Puede ocurrir solo en circunstancias excepcionales(una vez en 1 año)

2 Medio (Posible) Es posible que ocurra algunas veces (entre 1 y 3 veces al año)

3 Alto (Casi cierto) Se espera que ocurra en la mayoría de las circunstancias (más de 3 veces al año)

Tabla N°15: Probabilidad de Ocurrencia.

Fuente: Plan de Contingencia 2010

El plan de contingencia considera como riesgos más probables a suceder,

los siguientes (aquellos cuya probabilidad sea igual o mayor al 50%)

Valor de

Impacto

Nivel de

Impacto Descripción

5 Leve Pérdidas insignificantes, lo que genera el menor grado de incumplimiento en metas y objetivos.

10 Moderado Pérdidas considerables, con posibilidad de un alto grado de incumplimiento en metas y objetivos

20 Catastrófico Pérdidas enormes, con daño en la imagen de la entidad, alto grado de incumplimiento en metas y objetivos



Descripción Probabilidad

Inundaciones 0.53

Altas temperaturas 0.53

Fenómeno de El Niño 0.57

Vandalismo y/o Terrorismo 0.57

Errores Humanos 0.53

Tabla N°16: Probabilidad de Ocurrencia para Riesgos Físicos

Fuente: Plan de Contingencia 2010. Elaborado por los autores

Descripción Probabilidad

Robo de Datos 0.50

Fallo de Telefonía IP 0.70

Fallo de Servicios eléctricos 0.60

Software malicioso 0.67

Errores Humanos 0.53

Ausencia del Personal de OTI 0.67

Falta de concientización en seguridad de TI 0.70

Tabla N°17: Probabilidad de Ocurrencia para Riesgos Lógicos


De acuerdo al impacto, el plan de contingencia considera como riesgos

de alto y medio impacto los siguientes:

Riesgo Impacto

Incendios Alto

Altas temperaturas Alto

Fenómeno de El Niño Alto

Vandalismo y/o Terrorismo Medio



Robo de Equipos Alto

Acceso no autorizado a

recursos/Información física

Alto

Errores humanos Medio

Tabla N°18: Impacto para riesgos físicos


Riesgo Impacto

Robo de datos Alto

Fallo de servicio de telefonía Ip Medio

Fenómeno de El Niño Alto

Fallo de servicios eléctricos Medio

Software malicioso Alto

Ausencia del Personal de OTI Medio

Falta de Concientización y Seguridad de TI Medio

Tabla N°19: Impacto para riesgos lógicos


El plan especifica acciones a seguir para cada uno de estos riesgos los

cuales se tomarán como ítems de evaluación para los controles físicos y

lógicos de la red.

La evaluación de los riesgos está bastante clara, no obstante, en la

clasificación de los riesgos (físicos y lógicos) deben hacerse unas

aclaraciones:

Las siguientes amenazas: Ausencia del personal de OTI y falta de

concientización en seguridad de TI quedarían mejor definidas si se les

considera como riesgos de un nivel administrativo superior a un error

lógico.



El plan ordena las áreas por orden de prioridad de atención de incidentes,

como se muestra en el gráfico siguiente:

Ilustración Nº05: Prioridades de Atención.

Fuente: Plan de Contingencia - 2010

Según el jefe de la OTI, las dos áreas con mayor prioridad de atención

son Caja y Dirección General, pero el gráfico ubica a Dirección General en

cuarto lugar, lo que indica que, en la práctica la realidad es diferente.

Otro aspecto a considerar es que el plan de contingencia no considera los

laboratorios de cómputo de la Escuela de Ingeniería de Sistemas dentro

de su análisis, sólo considera los laboratorios del CIS (Centro de

Informática y Sistemas).

Como observación final, debe recalcarse que el plan de contingencia debe

revisarse y actualizarse, cuando se le preguntó al jefe de la OTI si

actualizaban el plan, el respondió que no era necesario porque se tratan

de normas estándar, no obstante consideramos que el plan debe

revisarse y actualizarse por las siguientes razones:

Caja

Contabilidad

Tesorería

Dirección General

Registros Académicos

Escuelas

Laboratorios de Cómputo



La OTI debe formalizar su plan de contingencia a través de la

aprobación y aceptación por parte de las autoridades responsables

de la universidad.

Es un trabajo de pregrado que puede tener errores, por tanto debe

revisarse.

La situación interna (del área y de la universidad) puede cambiar y

afectar a OTI como área dentro de una organización.

La situación externa (llegada de nuevas tecnologías) puede cambiar

y consigo trae nuevos riesgos junto a las soluciones.

4.3.3. Evaluación de las Actividades de Control Interno de la Gestión de la Red.

4.3.3.1. Evaluación de la Gestión de Atención de Incidentes (de Redes)

y de la Gestión de la Continuidad del Servicio en la OTI.

Se entrevistó al Jefe de la OTI (Anexo 7) sobre cómo se llevaba la gestión

de incidentes y la gestión de la continuidad del servicio en el área (Guía

de Entrevista: Gestión de Riesgos en la Oficina de Tecnologías de

Información – UCV Piura). La descripción que sigue a continuación es

producto de la información obtenida en la entrevista.

La gestión de incidentes de OTI está conformada por un helpdesk que

utiliza dos canales de comunicación para atender a los usuarios:

Por llamada telefónica (marcando el número de anexo del helpdesk)

Por envío de solicitud mediante el correo corporativo.

La gestión de incidentes que maneja OTI se caracteriza por lo siguiente:

El registro de incidentes es manual. Se usa una bitácora de

incidentes (ver el ítem de revisión preliminar de documentación)

donde se indica el incidente dado, el tipo de incidente (si es un

incidente de soporte, de red o de los sistemas de información) y la

persona que lo va a atender.

Es un proceso empírico, porque se basa en la experiencia diaria de

los participantes del proceso de atención: Asistente, clientes y



expertos de cada área. La asistente, por la naturaleza del incidente,

sabe a quién llamar; el experto, por su propia experiencia, sabe qué

hacer, y el cliente, en algunos casos, sabe a qué experto llamar (la

asistente se limita a llamar al experto)

Se tiene una noción de urgencia por atención de incidentes de

acuerdo al área que solicita una atención, según ello existen áreas

con mayor prioridad que otras. De acuerdo al administrador de la red

(jefe de la oficina), las áreas a las cuales les da mayor prioridad son

Caja y Dirección General.

Considera el escalamiento de incidentes. En el caso de redes, el nivel

más bajo lo ocupan los trabajadores del área de soporte, luego, le

sigue el administrador de la red y, en el nivel más alto, se encuentran

los encargados de DTI de Trujillo. En el caso de Trujillo, sólo se

derivan problemas que se relacionen con el servidor de datos.

De la información anterior se detectaron algunas deficiencias en la gestión

de incidentes de la OTI:

No se ha estandarizado el uso del correo corporativo como canal para

el envío de solicitud de servicio. Muchos clientes usan sus correos

personales.

Los incidentes no se analizan una vez terminados, no se hace un

análisis de tendencias ni se construye una base de conocimiento.

No se clasifican los incidentes por impacto.

Por otro lado, respecto a la gestión de la continuidad del servicio, el jefe

del área nos refirió (durante la entrevista) que las siguientes

interrupciones de red son las más comunes:

Corte de fluido eléctrico.

Corte de las líneas VPN.

Infección por virus al servidor Web.



Problemas con el IIS del servidor Web.

De acuerdo al jefe del área, OTI no tiene un plan o procedimiento para

atender las dos primeras interrupciones del servicio, porque en el primer

caso (corte del fluido eléctrico), la universidad no cuenta con generador y,

en la segunda situación, ocurre cuando hay un corte de fluido eléctrico en

Trujillo, pero, el jefe del área nos aseguró, que el servicio se repone lo

más rápido posible.

La infección de virus al servidor Web, según el jefe del área, no es un

evento común pero reconoce que es probable que pueda darse

nuevamente.

Respecto al IIS, el jefe del área nos refirió que estaba dando muchos

problemas a principios del 2011, porque se trataba de una versión antigua

(que venía junto al Windows Server 2003) que provocaba que el servidor

se cayera con mucha frecuencia. La situación mejoró cuando se actualizó

el sistema operativo a Windows Server 2008 (actualizándose el IIS), pero

no significa que la situación puede volver a repetirse.

Al finalizar la entrevista se revisaron las bitácoras de atenciones que

maneja el área (los registros del sistema Web y los archivos de Excel)

usando fichas bibliográficas (Anexo 5).

De acuerdo a esa fuente descubrimos que las interrupciones son más

numerosas de lo que se recogió en la entrevista:

Problemas de Conectividad: No hay red o no hay Internet

Se “colgó” un switch

El punto de red está dañado

El cable está cortado

La tarjeta de red está dañada

Bucle en la red (poco probable)

Conflicto de direcciones IP



Problemas con el Anexo (Problemas con los teléfonos IP)

No hay red VPN (Trujillo)

Se cae el servicio de Telefónica

Punto no está ubicado en la VLAN correcta

El power injector7 está dañado (común)

Problemas con la conectividad en el Pidgin8 (no hay conectividad)

Problema con el servidor de Trujillo.

Usuarios malogran el pidgin.

Problemas con la red inalámbrica

El Access Point debe ser reiniciado

El Access Point se ha desconfigurado totalmente

Problemas al ingresar al SEUSS9 por escritorio remoto

El Firewall de las PC está activo.

La PC de destino está apagada.

PC infectada por virus (se muestra pantalla del Active

Desktop)

Problemas con los marcadores10

El marcador se “cuelga”

7Son equipos que usan la tecnología POE (Power Over Ethernet) que les permite tomar energía de la

conexión LAN. Se utilizan en los teléfonos IP. 8 Cliente de mensajería Instantánea. Es software libre.

9 Sistema Estandarizado de la Universidad Señor de Sipán. Es un sistema integral que gestiona los procesos

académicos y económicos del consorcio UCV-USS 10

Los nuevos marcadores para el personal son sistemas de identificación biométrica (huella digital). Existe un marcador en cada edificio de la UCV-Piura.



En la bitácora también se han encontrado los siguientes incidentes de red

(que no generan interrupción del servicio).

Configuración e Instalación de Equipos

Instalación de marcadores

Configuración de marcadores

Configuración del pidgin

Configuración del escritorio remoto

Configuración de un switch

Configuración de cuentas de outlook

Ordenamiento de cableado y colocación de canaletas

La revisión de la bitácora de incidentes e interrupciones11 fue tediosa

debido a aspectos relacionados íntimamente con la gestión de estos

registros entre los cuales tenemos:

Se manejan dos fuentes: La primera es un sistema informático

(sistema web) y la segunda son archivos de Excel. El sistema se

usó hasta principios de setiembre del año en curso (2011).

No se pueden filtrar los incidentes y/o interrupciones por área que

los atendió (Desarrollo, Redes y Soporte).

No se maneja un lenguaje uniforme para describir un incidentes y

/o interrupción. Algunas descripciones son muy generalizadas por

ejemplo: “Problema en la red”, y otras son más específicas como:

“Falla en la tarjeta de red”, aludiendo ambos a una problemática

muy similar por no decir idéntica.

En algunos incidentes se indica la solución del problema, otros no.

11

Consideramos que las interrupciones forman un subconjunto de los incidentes, porque existen incidentes que no necesariamente implican una interrupción del servicio.



Un aspecto positivo de la bitácora es que se registra los tiempos

de demora para cada atención. Se ha registrado los tiempos que

se demora en atender cada tipo de incidente/interrupción hallado

en la bitácora; en algunos casos se ha estimado un tiempo mínimo

y un tiempo máximo para lo cual se calcula el tiempo promedio de

esta manera:

Donde:

TP: Tiempo Promedio

TMin: Tiempo Mínimo

TMax: Tiempo Máximo

Como la bitácora no maneja denominaciones uniformes para un tipo de

incidentes, se ha agrupado los incidentes para formar un incidente

general, por ejemplo: Si el switch se “cuelga” o existe un bucle en la red,

son sucesos que se agrupan en el incidente general Problemas de

Conectividad.

Cada incidente general tiene un tiempo promedio el cual se calcula de la

siguiente manera:

Donde:



TPAI: Tiempo Promedio de Atención de Incidentes

TPi: Tiempo Promedio (para cada incidente)

n: Número de incidentes

A continuación presentamos una tabla donde se muestran los incidentes

que implican la interrupción del servicio. Para cada incidente se calculan

el TP y el TPAI de acuerdo a las fórmulas definidas:



Incidentes

Tiempo de Atención Estimado (horas)

Tiempo Mínimo Tiempo Máximo Tiempo Promedio

(TP)

PROBLEMAS DE CONECTIVIDAD

Se “colgó” un switch --- --- 0.033

El punto de red está dañado --- --- 0.067

El cable está cortado 0.333 0.5 0.4165

La tarjeta de red está dañada 0.167 47.5 23.8335

Bucle en la red 0.033 0.167 0.1

Conflicto de direcciones IP 0.167 0.25 0.2085

Tiempo Promedio de Atención de Incidente (TPAI) 4.109

PROBLEMAS CON LOS ANEXOS (PROBLEMAS CON LOS TELÉFONOS IP)

No hay red VPN 0.083 1 0.542

Se cae el servicio de Telefónica 0.083 1 0.542

Punto no está ubicado en la VLAN correcta --- --- 0.083

El powerinjector está dañado 38 47.5 42.75


PROBLEMAS CON LA CONECTIVIDAD EN EL PIDGIN (NO HAY CONECTIVIDAD)

Problema con el servidor de Trujillo 0.167 0.25 0.2085

Usuarios malogran el pidgin --- --- 0.033




PROBLEMAS CON LA RED INALÁMBRICA

El Access Point debe ser reiniciado --- --- 0.033

El Access Point se ha desconfigurado totalmente --- --- 0.167


PROBLEMAS AL INGRESAR AL SEUSS POR ESCRITORIO REMOTO

El Firewall de las PC está activo --- --- 0.033

La PC de destino está apagada --- --- 0.083


Desktop)

0.167 14.5 14.667


PROBLEMAS CON LOS MARCADORES

El marcador se “cuelga” --- --- 0.067


PROBLEMAS CON EL SERVIDOR

Ataque por malware --- --- 4

Reiniciar servidores --- --- 0.083


CORTE DE FLUIDO ELÉCTRICO

Corte de fluido eléctrico 1 5 3

Tiempo Promedio de Atención de Incidente (TPAI) 3

CONFIGURACIÓN E INSTALACIÓN DE EQUIPOS DE RED Y SOFTWARE

Instalación de un marcador --- --- 0.083



Configuración de un marcador --- --- 0.033

Instalación del pidgin --- --- 0.033

Configuración de un switch --- --- 0.167

Configuración de cuenta de Outlook --- --- 0.133

Sincronización de archivos (Outlook) 0.167 1 0.5835


COLOCACIÓN DE CANALETAS Y ORDENAMIENTO DE CABLEADO.

Colación de canaletas (Habilitar puntos de red) --- --- 4

Ordenamiento de cableado 4 19 11.5


CREACIÓN DE USUARIOS Y PERMISOS.

Crear usuario de dominio --- --- 0.033

Habilitación de acceso al facebook --- --- 0.033


Tabla N°20: Tiempo de atención de incidentes

Fuente: Bitácora de atenciones de la OTI (2011). Elaborado por los autores



Una vez calculado el TPAI, podemos determinar los siguientes

indicadores (consultar ítem Indicadores):

Porcentaje de incidentes de red resueltos en un tiempo óptimo

Número promedio de horas perdidas por usuario al mes, debido a

interrupciones de red.

Empecemos por los incidentes de red, especificados en la tabla 20, de los

cuales identificaremos aquellos que se atendieron en un tiempo

considerado óptimo, que hemos establecido en 5.5 horas, lo que equivale

a media jornada de trabajo. Es necesario aclarar que la OTI no ha

establecido un tiempo óptimo de servicio, no obstante, en la práctica,

siempre procuran no dejar atenciones pendientes antes de cumplirse la

media jornada de trabajo que coincide con la hora de descanso de los

trabajadores administrativos de la UCV. (De 1:00 pm a 2:00 pm).

Para identificarlos mejor, mostramos, a continuación, la misma tabla 20

pero resaltando los incidentes atendidos en un tiempo (TPAI de cada

incidente) menor o igual a las 5.5 horas (tiempo óptimo)



Incidentes



(TP)






Bucle en la red 0.033 0.167 0.1




No hay red VPN 0.083 1 0.542



El power injector está dañado 38 47.5 42.75
















Desktop)

0.167 14.5 14.667












CONFIGURACIÓN E INSTALACIÓN DE EQUIPOS DE RED Y SOFTWARE

Instalación de un marcador --- --- 0.083

Configuración de un marcador --- --- 0.033



Instalación del pidgin --- --- 0.033

Configuración de un switch --- --- 0.167

Configuración de cuenta de Outlook --- --- 0.133

Sincronización de archivos (Outlook) 0.167 1 0.5835


COLOCACIÓN DE CANALETAS Y ORDENAMIENTO DE CABLEADO.

Colación de canaletas (Habilitar puntos de red) --- --- 4

Ordenamiento de cableado 4 19 11.5


CREACIÓN DE USUARIOS Y PERMISOS.

Crear usuario de dominio --- --- 0.033

Habilitación de acceso al facebook --- --- 0.033


Tabla N°21: Incidentes resueltos dentro del tiempo óptimo


Incidentes resueltos en un tiempo menor o igual a 5.5 horas (tiempo óptimo)



Los incidentes junto a sus tiempos promedio (TPAI) pueden reflejarse en

el siguiente gráfico:



Gráfico Nº11: Tiempo Promedio de Atención de Incidentes (TPAI) por OTI en la UCV - Piura

Fuente: Bitácora de Atenciones de OTI (2011). Elaborado por los autores

4.109

10.979

0.121 0.1

4.928

0.067

2.0415

3

0.1722 0 0.033 0

2

4

6

8

10

12

Tiempo Promedio de Atención de Incidentes



Una vez identificados los incidentes resueltos en el tiempo óptimo, se

saca un porcentaje respecto del total de incidentes, de esta manera:

Donde:

PIR: Porcentaje de Incidentes de Red resueltos en un tiempo óptimo

Num.I.R: Número total de incidentes de Red resueltos en un tiempo

óptimo

Total.I: Total de Incidentes de Red.

Se han contabilizado un total de 11 incidentes (Total.I), de los cuales 9

fueron solucionados en u tiempo óptimo. Con estos datos aplicamos la

fórmula anterior

Se obtiene que el 81.81% de los incidentes de red son atendidos en un

tiempo óptimo, es decir en un tiempo no mayor de las 5.5 horas. De ellos

(haciendo referencia a la tabla 21), la creación de usuarios de dominio es

el que demora menos con un tiempo de 0.033 horas (2 minutos) y donde

se invierte más tiempo es la solución de problemas con la conexión al

escritorio remoto (para conectarse al sistema SEUSS) con un tiempo de

4.198 horas en promedio.12

De las actividades que pasan el tiempo óptimo concluimos lo siguiente:

Los problemas de anexo rebasan el tiempo de atención óptimo

cuando se malogra un power injector. Para repararlo se invierten

aproximadamente unas 42.75 horas.

12

Para este caso los tiempos de atención son cortos salvo cuando una PC se infecta con virus, para lo que se invierte unas 14.5 horas en el peor de los casos. (ver tabla 8).



La colocación de canaletas y el ordenamiento de cableado son

actividades de muy larga duración, especialmente, el

ordenamiento de cableado que puede llevar unas 19 horas como

máximo.

Se concluye que OTI tiene en cuenta que los incidentes deben atenderse

lo más rápido posible. No obstante la labor mejoraría bastante si el

personal de soporte (principal apoyo el área de redes) aumentase y

también, que la administración de la red y la jefatura de la OTI recaigan en

dos personas diferentes, situación que se explicó en el análisis del

ambiente a auditar.

Finalizado el análisis de incidentes, nos toca abordar el tema de solución

de interrupciones de red.

Como se explicó anteriormente, se ha considerado a las interrupciones

como un subconjunto de los incidentes del área, que ya han sido

especificados en las tablas 20 y 21, sin embargo el análisis de las

interrupciones de red se enfocará a encontrar el número de horas

perdidas por usuario al mes. Lo que corresponde al indicador 3 del

proyecto (ver Indicadores), de acuerdo a esto consideramos las siguientes

interrupciones de red que han sido registradas en la bitácora de

atenciones:



Interrupción



(TP)






Bucle en la red 0.033 0.167 0.1




No hay red VPN 0.083 1 0.542



El power injector está dañado 38 47.5 42.75
















Desktop)

0.167 14.5 14.667












Tabla N°22: Tiempo de atención de interrupciones de red.

Fuente: Bitácora de atenciones de la OTI (2011). Elaborado por los autores.



A las interrupciones anteriores se hizo seguimiento desde Enero hasta

Setiembre del 2011, esto con el objetivo de establecer la frecuencia de la

atención por mes. El cálculo de esta frecuencia se obtiene del promedio

del número de veces que se ha atendido un incidente en un mes

determinado.

Donde:

F: Frecuencia Promedio de Atención de Incidentes

fi: Frecuencia de Atención de Incidentes por mes

n: Número de meses

Para el caso de las interrupciones, la frecuencia F se multiplica por el

valor de TPAI para cada interrupción, obteniendo un Tiempo perdido

mensual por interrupción del servicio (TPMIS):

Donde:

TPMIS: Tiempo Perdido Mensual por Interrupción del

Servicio

F: Frecuencia Promedio de Atención de Incidentes

TPAI: Tiempo Promedio de Atención de Incidentes

El TPMIS de cada interrupción se suma y se saca un promedio que es el

Número promedio de horas perdidas por usuario al mes, debido a

interrupciones a la red. (NHP).



Donde:

NHP: Número promedio de horas perdidas por usuario al

mes, debido a interrupciones a la red.

TPMISi: Tiempo Perdido Mensual por Interrupción del

Servicio de cada interrupción

n: Número de interrupciones

A continuación mostramos el cuadro de la frecuencia de atención de

interrupciones junto a los cuadros donde se calculan el TPMIS y el NHP.

Además presentamos los resultados del TPMIS en un gráfico para una

mejor visualización



Incidente/Interrupción

Mes N° de

Atenciones

Promedio

(mensual) (F)

Ene Feb Mar Abr May Jun Jul Ago Set

Problemas de Conectividad 17 19 16 22 21 14 12 11 14 16.22 16

Problemas con los Anexos (Problemas con los

teléfonos IP)

8 7 0 4 8 3 2 3 4 4.33 4

Problemas con la conectividad en el Pidgin (no

hay conectividad)

4 2 0 0 2 2 0 0 2 1.33 1

Problemas con la red inalámbrica 0 0

1 1 1 0 0 0 1 0.44 1

Problemas al ingresar al SEUSS por escritorio

remoto

0 1 0 1 7 0 0 0 0 1

Problemas con los marcadores 0 1 1 1 2 0 0 0 0 0.55 1

Problemas con el Servidor 8 0 0 1 0 0 0 0 0 1

Corte de Fluido Eléctrico 1 0 1 0 0 0 0 0 0 1

Tabla N°23: Frecuencia de atención de incidentes de Enero a Setiembre (2011).




Interrupción

N° de

Atenciones

Promedio

(mensual)

(F)

Tiempo

perdido por

interrupción

del servicio

(en horas)

(TPAI)

Tiempo

perdido

mensual por

interrupciones

de servicio (en

horas)

(TPMIS)

Problemas de Conectividad 16 4.109 65.744

Problemas con los Anexos (Problemas con los

teléfonos IP)

4 10.979 43.916

Problemas con la conectividad en el Pidgin (no

hay conectividad)

1 0.121 0.121

Problemas con la red inalámbrica 1 0.1 0.1

Problemas al ingresar al SEUSS por escritorio

remoto

1 4.928 4.928

Problemas con los marcadores 1 0.067 0.067

Problemas con el Servidor 1 2.0415 2.0415

Corte de Fluido Eléctrico 1 3 3

Número total de horas perdidas por mes debido a interrupciones de red 119.918

Número promedio de horas perdidas por usuario al mes, debido a interrupciones a

la red. (NHP)

14.990

Tabla N°24: Cálculo del NHP(2011).




Gráfico Nº12: Tiempo Perdido Mensual por Interrupciones de Servicio de acuerdo a tipo de incidente en la UCV - Piura


65.744

43.916

0.121 0.1 4.928

0.067 2.0415 3

0

10

20

30

40

50

60

70

Tiempo perdido mensual por interrupciones de servicio



De los resultados anteriores se observa lo siguiente:

Los usuarios pierden aproximadamente 15 horas (14.990) por

interrupciones al servicio por mes. Considerando que en un día se

trabajan 9.5 horas diarias y, en un mes se hacen un total de 285

horas, entonces la pérdida de horas por interrupción del servicio (15

horas) representa el 5.2 % de las horas mensuales trabajadas.

Los problemas más comunes son los relacionados con la

conectividad, ya sea que no tiene red o que no tiene internet (16

veces al mes); le siguen, en frecuencia, los problemas con los

anexos que usan telefonía IP (4 veces al mes).

Respecto al tiempo perdido mensual (TPMIS), las interrupciones que

provocan más pérdida de horas son las interrupciones de red (65.74

horas/mes), seguido de los problemas con los anexos (43.92

horas/mes).

Los problemas por ingresar al SEUSS (por escritorio remoto), el corte

de fluido eléctrico y los problemas con los servidores, son las

interrupciones de mayor duración entre las que registran la menor

frecuencia de ocurrencia.

Tomando en cuenta los resultados del análisis de incidentes y de

interrupciones podemos observar:

La mayoría de interrupciones se solucionan en el tiempo óptimo

observado (menor o igual a 5.5 horas)

Los problemas con el anexo son el único tipo de interrupciones que

no solucionan en el tiempo óptimo (10.98 horas) pese a ser la

segunda más frecuente.

Como conclusión general, podemos afirmar que la atención de incidentes

se maneja bien en OTI pero no de la manera óptima porque adolece de

aspectos como la creación de un sistema completo de gestión de

incidentes, que permita reportar incidentes, filtrarlos por el área que los

atendió y, sobretodo, usar un lenguaje estándar para definir un incidente.

El resultado arrojado por la pérdida de horas no está mal (15 horas), no

obstante es preocupante que los problemas de conectividad sean los



más frecuentes de los problemas de Red porque inciden en la calidad de

servicio que puedan ofrecer otras áreas de la universidad.

4.3.3.2. Evaluación de controles aplicados a terceros.

En este punto se evaluarán los controles a terceros que OTI realiza,

comenzando por una descripción de las relaciones de OTI con terceros13,

luego se identificarán los controles aplicados y, finalmente, se enunciarán

las conclusiones y recomendaciones de acuerdo a las deficiencias

encontradas.

Para conocer las relaciones de OTI con terceros, se entrevistó al jefe de

la OTI (Guía de Entrevista: Evaluación de Controles aplicados a Terceros

– Anexo 12) y se obtuvo la siguiente información.

La principal relación de tercerización que mantiene OTI es con Telefónica

del Perú, empresa que proporciona los enlaces VPN y el enlace a

Internet al campus Piura.

Pero Telefónica no es la única empresa proveedora de productos y

servicios; OTI también se relaciona con los siguientes proveedores:

J&C Telecomunicaciones (Trujillo)

Brinda servicios de cableado estructurado, fibra óptica, y equipos

de comunicaciones (switches, routers y antenas).

Red Hardware (Piura)

Empresa proveedora de PCs, tarjetas de red, Access Point y otros

componentes de Hardware.

Logicalis (Lima)

Empresa proveedora de equipos de telefonía IP.

Viditek (Lima)

Empresa proveedora de equipos para videoconferencias.

Es importante destacar que OTI no mantiene relaciones de tercerización

directas sino que tiene un intermediario que es el área de Logística, quien

13

Se refiere con terceros a empresas externas a la Universidad César Vallejo que son prestadoras de servicios o son proveedores.



gestiona los contratos con proveedores de servicios y equipos14, no

obstante OTI puede asumir ciertos controles sobre estos proveedores,

por lo general (según el jefe de la OTI) en dos situaciones:

La primera es cuando se va a cablear un nuevo edificio del campus

(situación que ya se ha dado y se dará de nuevo con el nuevo edificio de

medicina), tarea que OTI puede realizar, pero, prefiere dejarla a manos

de un tercero debido a la certificación de que el trabajo (cableado) ha

sido realizado por una empresa o marca autorizada, dicha certificación

tiene una duración de 20 a 25 años.

La segunda situación es cuando se va a efectuar la compra de un nuevo

equipo de red o de telecomunicaciones ya sea para implementar

soluciones nuevas (como los marcadores de los docentes) o para tener

en stock en caso de averías. En este caso, OTI, dado su conocimiento en

TI, puede sugerir a Logística el/los proveedores con las propuestas más

idóneas teniendo en cuenta la calidad y el precio; además puede

supervisar las propuestas de éstos (enviadas por Logística vía correo

corporativo al jefe de OTI) para su aprobación, para que Logística

gestione la compra del equipo correspondiente.

OTI también se asegura de estar presente cuando el área de Logística

visita al proveedor para realizar la compra.

De la descripción anterior, obtendremos el resultado del indicador

Número de Controles aplicados a terceros (NCT), el cual

operacionalmente se define:

NCT=CT

Donde:

NCT: Número de controles aplicados a terceros.

CT: Control a terceros

Para aplicar esta fórmula, primero debemos determinar cada uno de los

controles, de los cuales sólo tomaremos aquéllos que aplica la OTI.

14

Las funciones del área de Logística son mucho más amplias, pero nos referimos a esta área desde el contexto de OTI a quien provee de equipos tales como PC, cable, conectores, etc.



N° Control Tercero (a quien se dirige

el control)

1

Apoyo y supervisión

de las tareas de

cableado de un

edificio nuevo

J&C Telecomunicaciones

2

Inspección al

finalizar las tareas de

cableado de un

edificio nuevo

J&C Telecomunicaciones

3

Revisión de

propuestas de

proveedores

Red Hardware, Logicalis,

Viditek, Telefónica del Perú

4

Supervisión

presencial durante la

compra de equipos

Red Hardware, Logicalis,

Viditek

Tabla N°25: Controles de OTI aplicados a terceros


Aplicando la fórmula del indicador

NCT=4

Según la descripción brindada por el jefe de la OTI, el área aplica 4

controles para con los terceros con los que se relaciona. Esta cifra puede

compararse con los controles aplicados por Logística pudiendo obtener la

proporción de la participación de OTI respecto a los controles a terceros.

Para ello, preguntamos al jefe del área de Logística, cómo es el proceso

de compra de equipos y elementos de redes y comunicaciones (en

conjunto de OTI), producto de esta narración pudimos identificar los

siguientes controles.



N° Control

1 Selección de proveedores considerando criterios de calidad

de servicio y precios.

2 Supervisión del cumplimiento de los términos de los contratos

3 Trato directo con los proveedores (Visita personal)

4 Manejo de documentos mercantiles: Facturas, órdenes de

compra y cotizaciones

5 Archivar documentos mercantiles: Facturas, órdenes de

compra y cotizaciones

6 Negociar los términos de las líneas de crédito con los

proveedores.

Tabla N°26: Controles de Logística aplicados a terceros


Del lado de Logística se contabilizan 6 controles aplicados a terceros,

por tanto, el siguiente gráfico refleja la proporción de la participación de

OTI con respecto a los controles aplicados a terceros.

Gráfico Nº13: Proporción de los controles aplicados a terceros aplicados por las

áreas de OTI y Logística


60%

40%

Controles aplicados a Terceros

Controles aplicados por Logística Controles aplicados por OTI



De lo anterior (resultado del indicador y gráfico) podemos concluir lo

siguiente:

Los controles a terceros, referidos a TI, son aplicados por la OTI y

por Logística.

OTI tiene una participación menor que Logística pero ésta no es

nada despreciable porque abarca con el 40% de los controles a

terceros

OTI aplica los controles de índole técnico, mientras que Logística

cumple con los controles referidos al contrato y al cumplimiento

del mismo.

OTI acude a la tercerización cuando se requiere de nuevo

cableado estructurado para certificar la calidad del trabajo.

De lo anterior se recomienda que OTI debe intervenir más en la relación

con proveedores de servicios y equipos de TI, porque el área de Logística

no se ocupa sólo de TI sino de proveer materiales diversos a las diversas

áreas como útiles de escritorio y bidones de agua y esto puede provocar

demoras en la atención de pedidos de equipos de TI y cableado (si no

están en stock) en caso se deterioren.

4.3.3.3. Evaluación de los costos para cubrir la inversión en TI

En este punto se tratarán cuáles son los costos que cubren la inversión

en TI. Durante los últimos años, OTI ha invertido en los siguientes que

forman parte de la infraestructura de la red de la universidad.

Power Injector para Teléfono IP (Cisco Unified IP Phone Power

Injector)

Teléfonos IP Cisco 7911g

Reloj Marcador de Asistencia IClock 2500 (marcador biométrico)

Switch AT-8326GB

Switch AT-8524M

Switch AT-9816GB

Switch AT-8000SF



Switch AT-8000S

Switch AT-9000GB

Switch Cisco 2960 (48p)

Switch Cisco 3750 G12

Switch Cisco 2960 (24p)

ASA Cisco 5510

Gateway de Voz Cisco 2821

Router Cisco 2800

Servidor Hp-Proliant ML 350 (G3)

Para conocer el costo de inversión es necesario conocer el precio de

cada uno de estos equipos, multiplicarlo por la cantidad con los que la

universidad cuenta y obtener un total invertido, por último se comparar

ese resultado con el presupuesto asignado a OTI durante todo ese

período de tiempo.

Para la evaluación se necesitó consultar los planes operativos de OTI,

donde se consigna el presupuesto asignado al área y la inversión

requerida por cada proyecto de TI que el área desee implementar para

cada una de sus subáreas (desarrollo, redes y soporte),

desgraciadamente se trataba de un documento demasiado confidencial

para poder ser revisado, no obstante se tuvo acceso a algunos registros

del último inventario que realizó OTI (documento revisado mediante

fichas bibliográficas – Anexo 5) a los equipos de la universidad, de esta

manera se pudo listar los equipos de comunicaciones indicados en el

párrafo anterior.

Los precios para cada equipo tuvieron que ser investigados por los

autores, los cuales se consignan en la siguiente tabla



Equipo o elemento de infraestructura de Red

Precio Unitario (s/.)

Cantidad Precio Total (s/.)

Cisco Unified IP Phone Power Injector

255.66 80 20452.8

Teléfono IP Cisco 7911g 264.18 80 21134.4

Reloj Marcador de Asistencia IClock 2500

2548.94 4 10195.76

Switch AT-8326GB 179.21 3 537.63

Switch AT-8524M 1049.44 6 6296.64

Switch AT-9816GB 234.74 1 234.74

Switch AT-8000SF 1469.93 3 4409.79

Switch AT-8000S 1175.49 2 2350.98

Switch AT-9000GB 3023.78 2 6047.56

Switch Cisco 2960 (48p) 7449.35 4 29797.4

Switch Cisco 3750 G12 20967.20 1 20967.20

Switch Cisco 2960 (24p) 2478.23 1 2478.23

ASA Cisco 5510 9505.37 1 9505.37

GW Voz Cisco 2821 3688.96 1 3688.96

Router Cisco 2800 12169.25 3 36507.75

Servidor HP-Proliant ML 350 (G3)

1497.87 3 4493.61

TOTAL (IATI) s/. 179098.82

Tabla N°27: Precios unitarios de equipos y elementos de red usado en la UCV -

Piura


El jefe de la OTI nos refirió que el monto anual asignado al área es,

aproximadamente, s/. 600000, de los cuales se invierte el 0.20 como

máximo (en ocasiones hasta menos); si se conoce que el área ha estado

funcionando desde el 2001 (en ese tiempo estaba unido con el CIS), es

posible hacer un estimado de la cantidad invertida en esos año por la

compra de equipos de comunicaciones y contrastarla con el presupuesto

asignado al área, desde cuando empezó a funcionar, para obtener un

porcentaje, que representa el Porcentaje de inversión para cubrir los

costos en TI (PIATI) el cual es uno de los indicadores considerados en el

proyecto.

Antes de exponer el cálculo el PIATI es importante recalcar que se trata

de una cifra aproximada ya que no se tuvo acceso a los documentos

oficiales donde se consigna lo que OTI ha invertido o está a punto de

invertir.



Para empezar, primero se calculó el total de inversión (TI) obtenido de la

multiplicación del monto asignado (MA) con el número de años de

servicio (N), la fórmula usada fue la siguiente.

TI = MA * N

TI = (s/.600000*0.20)*10 = s/.1200000

Considerando que MA es el 20% de s/.600000y que han transcurrido 10

años (N), el TI en ese tiempo se estimó en 1200000 soles.

Conociendo que el total invertido por la compra de equipos es de

179098.82 soles, es posible calcular el Porcentaje de inversión para

cubrir los costos en TI (PIATI) el cual operacionalmente se define

(∑

)

Donde:

IATI = Inversión en actualización en TI

P = Presupuesto

i = año

n = número de años

Siendo el IATI el total de inversión estimado en s/. 179098.82 y el TI en

s/. 1200000, entonces:

PIATI = (

PIATI = 14.92 %

El PIATI puede ser reflejado en el siguiente gráfico estadístico.



Gráfico Nº14: Porcentaje de inversión para cubrir los costos de TI


El gráfico muestra un PIATI de 13%, un valor muy cercano al

calculado mediante la fórmula, pero despreciando la diferencia de

resultados, se puede llegar a las siguientes conclusiones.

La utilización del 13% del presupuesto es demasiado bajo para

TI, lo que es un indicador de que los equipos de

comunicaciones no se han renovado.

Un indicador de la no renovación de equipos es el bajo precio

con el que actualmente se venden algunos switches en la

actualidad, como se puede constatara en la tabla N°27

Se recomienda que OTI, en lo futuro invierta más en lo que es equipos

de comunicaciones, sobretodo en la renovación de equipos que ya

tienen cierta antigüedad así como también en la adquisición de nuevos

equipos para mejorar la infraestructura de la red.

4.3.3.4. Evaluación de la frecuencia de las tareas de mantenimiento de

la Red.

En este punto procederemos a evaluar las tareas de mantenimiento de la

Red ejecutadas por OTI comenzando por una breve descripción de las

13%

87%

Cálculo del PIATI

Inversión en actualización de TI Presupuesto



tareas de mantenimiento, la evaluación y juicio de las mismas para

finalizar con determinar la frecuencia de tareas de mantenimiento

realizadas en OTI.

Para conocer cómo se efectúan las tareas de mantenimiento de la Red

en OTI, se entrevistó al jefe del área de Redes (Guía de Entrevista:

Mantenimiento a la Red de la Universidad- Anexo 9) con lo que

obtuvimos la siguiente información:

Las actividades de mantenimiento del área de Redes se planifican

anualmente y se indican dentro del plan operativo. De estas actividades,

las principales realizadas en el transcurso del 2011 son las siguientes:

Limpieza de equipos del datacenter.

Ampliación de puntos de red y cambio de cableado (activación de

puntos y colocación de canaletas)

Ordenamiento de cableado

Etiquetado de cableado.

Reinicio de switches (en caso de borrarse la configuración por

causa de un apagón)

Análisis de switches para resolver problemas detectados por

monitoreo de red (ver Diagrama de Flujo del Procedimiento para

el monitoreo de puertos en la red)

Las actividades de mantenimiento se registran en la Bitácora de

atenciones de la OTI15, tal como vimos en la evaluación de la gestión de

incidentes e interrupciones. De las actividades mencionadas, las más

usuales son las relacionadas con el cableado de la Red (ampliación de

puntos y ordenamiento de cableado), pero no se trata de mantenimientos

preventivos sino de mantenimientos correctivos; el jefe del área explicó

que la causa de ello es el constante deterioro de los patch,(

especialmente en los laboratorios de cómputo) porque no se usan patch

15

La limpieza de equipos y el etiquetado de cableado se han realizado durante el mes de octubre del 2011, por ese motivo no se ha considerado en el análisis de incidentes del apartado anterior que toma una muestra desde Enero hasta Setiembre del 2011.



de fábrica (cable multifilal y es más flexible) sino patch artesanales (cable

común unifilal).

Respecto a la limpieza de equipos de equipos del datacenter, ésta se da

pero no se trata de una actividad común, según el encargado del área de

Soporte, no se ha hecho limpieza a los equipos del datacenter desde

hace tres años aproximadamente, no obstante el ambiente físico del

datacenter es limpiado con mayor regularidad labor que se encarga el

área de Soporte. El jefe de la OTI no refirió en la entrevista sobre la

regularidad de las tareas de limpieza de equipos del datacenter, pero, en

base a la observación directa (Guía de Observación N°01 – Anexo 26) y

a la revisión de la bitácora de atenciones, no se ha encontrado la

realización de esta actividad en la muestra de meses considerada (De

Enero a Setiembre del 2011)

El etiquetado de cableado es una actividad que se está realizando en el

transcurso del mes de Octubre del 2011 que se consideró para el plan

operativo del 2011 y que se hablaba de su ejecución desde abril del

mismo año.

Respecto al monitoreo de red, no se encontró ninguna entrada de este

tipo en la bitácora (por mantenimiento correctivo de problema detectado

por el monitoreo), por lo que se infiere que no ha ocurrido un problema lo

suficientemente grave que obligue a revisar los equipos de Red

(específicamente switches) para darles mantenimiento (correctivo), no

obstante, el jefe de la OTI refirió que el monitoreo es constante.

Las actividades anteriores, según lo refirió el jefe de la OTI, son

realizadas por las Subáreas de Redes y Soporte, la asignación de

responsabilidades de las actividades entre las dos Subáreas son las

siguientes:

Subárea de Redes (Administrador de la Red):

Cambio de equipos de Red, configuración de equipos de Red y

medición del desempeño de la Red

Subárea de Soporte:

Instalación de puntos de red, ordenamiento de cableado,

etiquetación de cableado.



Es conocido también que las actividades de mantenimiento pueden

acarrear el riesgo de producir una interrupción del servicio; por eso,

según lo que dijo el jefe de OTI en la entrevista, las actividades de

mantenimiento se programan para los fines de semana o después de

terminado el horario de trabajo (6:00 pm), si se trata de darle

mantenimiento a los equipos del datacenter (limpieza) o del etiquetado de

cableado en los gabinetes de red.

El mantenimiento de los laboratorios (cambio de patch) se realiza en

horarios cuando éstos están libres. No obstante, algunas tareas de

instalación (ampliación) de puntos de red y ordenamiento de cableado, se

realizan dentro de los horarios de trabajo (si no es un cambio de gran

magnitud) pero esto causa cierta incomodidad en los usuarios.

Al término de la entrevista, el jefe de la OTI refirió que el área se ha

propuesto el objetivo (dentro del plan operativo para el 2012) de realizar

el cambio de todos los equipos que conforman la Red de la Universidad,

debido a la antigüedad de los mismos (el tiempo promedio de vida de los

equipos es de 5 años) excepto el edificio de biblioteca por tratarse de

equipos recientes.

Descritas las actividades de mantenimiento procederemos a medir la

frecuencia de las tareas de mantenimiento de la Red, que se define

conceptualmente en el indicador: Número de veces por mes que se ha

realizado mantenimiento a la red. Para lo cual tomaremos la

información de las actividades registradas en la bitácora de atenciones

tomando las tareas de mantenimiento de la Red. En la bitácora, se

encuentra de manera recurrente las actividades de cableado, las

actividades de limpieza de equipos, análisis de switches, reinicio de

switches y etiquetado de cableado son actividades que se dan rara vez y,

en el lapso tomado no se han producido.

Las actividades de cableado las hemos agrupado en el ítem: Colocación

de Canaletas y Ordenamiento de Cableado, la cual engloba las

siguientes actividades: (consultar Tablas 20 y 21)

Colocación de canaletas (habilitar de puntos de red)




De esta actividad hemos registrado la frecuencia por mes. De Enero a

Setiembre del 2011, para obtener una frecuencia promedio mensual para

cada actividad, de esta manera

Donde:

NMR: Número Promedio de Mantenimiento Mensual de la

Red.

: Frecuencia de Atención de Incidentes por mes

: Número de meses

Incidente (Tareas

de

mantenimiento)

Mes

N° de

Atenciones

Promedio

(mensual) (F) Ene Feb Mar Abr May Jun Jul Ago Set

Colocación de

canaletas y

ordenamiento de

cableado.

1 6 6 39 8 1 0 1 2 7.11 7

Tabla N°28: Frecuencia de atención de incidentes de mantenimiento de Red de Enero a

Setiembre(2011).


Los mismos datos se reflejan gráficamente en el siguiente gráfico:



Gráfico Nº15: Frecuencia mensual de tareas de mantenimiento en la UCV - Piura


Con los datos obtenidos aplicamos la fórmula anterior

Aplicando la fórmula obtenemos que el Número de veces que se realiza

mantenimiento, en promedio es de 7 veces al mes, no obstante el

mantenimiento es netamente correctivo más que proactivo y se basa por lo

general al mantenimiento de cableado.

4.3.3.5. Evaluación de Controles Físicos a la Red.

Se entrevistó al Jefe de la OTI sobre Control Físicos aplicados a la red de

la Universidad (Guía de entrevista: Controles físicos implementados en la

red de la Universidad, Anexo 10), de la cual pudimos obtener los

siguientes datos.

Los controles físicos aplicados a la red se caracterizan por lo siguiente:

0

5

10

15

20

25

30

35

40

Mantenimiento a la Red

Mantenimiento a la Red



Desastres Naturales:

Controles aplicados a Incendios. Se cuenta con extinguidores

implementados en el DataCenter y el personal cuenta con el

conocimiento necesario para el uso de estos.

Altas temperaturas. Se cuenta con aire acondicionado dentro del

Datacenter.

Robo de Equipos. Para lo que es equipos en el data center se cuenta

con gabinetes con sus respectivas llaves, las cuales son manejadas

por el administrador de red

Errores Humanos. Se maneja mediante las cuentas de usuario, las

cuales manejan sus respectivos privilegios.

Fallo de servicio eléctrico. Se cuenta con UPS conectados a los

servidores dentro del DataCenter.

Respaldo de información. Los respaldos de información se

almacenan en DVD y se almacenan en un lugar adecuado fuera del

DataCenter.

De la información anterior y por medio de la observación directa (Guía de

Observación N°02 – Anexo 27) se detectaron algunos controles físicos

que no se aplican:

Para lo que concerniente a desastres naturales, el aire

acondicionado dentro del DataCenter no es de precisión, lo cual no

es adecuado, no aplican controles para los movimientos sísmicos

(terremotos), por lo que el jefe del área nos refirió (durante la

entrevista) que estos se debieron de haber considerado en el diseño

de la infraestructura del edificio central donde se encuentra el

DataCenter.

Solo se controla el robo de equipos que se encuentran en el

DataCenter, y no para equipos en las diferentes áreas de la

Universidad, en las cuales el personal ajeno a OTI puede tener un

mayor contacto con equipos y donde pueden hay mayor posibilidad

de pérdida de estos.



La documentación que se maneja en OTI es digital y no se lleva una

adecuada gestión de esta, y que nos refirió el jefe del área (durante

la entrevista) que en una oportunidad había perdido parte de esta

documentación, debido a infecciones de virus en la PC (PC del jefe

del área, donde se contiene la mayor parte de la documentación)

donde se encontraba almacenada la documentación.

No se cuenta con un grupo electrógeno en la universidad con lo que

se podrá mitigar las fallas en el servicio eléctrico.

No se controla el ingreso al DataCenter, pero el jefe nos refirió que

es uno de los puntos considerados dentro del plan operativo del

siguiente año.

A continuación mostramos un cuadro, el cual implica los controles físicos

aplicados a la red de la UCV-Piura por parte de la OTI. Con los datos del

siguiente cuadro calculamos el NCF de acuerdo a la fórmula definida:

Riesgo Físico N° Controles

ALTAS TEMPERATURAS DE CALOR

Aire acondicionado dentro del DataCenter 1

N° total de controles físicos aplicados 1

FENÓMENOS DEL NIÑO


TERREMOTOS


INUNDACIONES


INCENDIOS

Extintores 1


VANDALISMO / TERRORISMO


ROBO DE EQUIPOS

Gabinetes con llave 1




ACCESO NO AUTORIZADO A RECURSOS Y/ INFORMACIÓN FÍSICA


ERRORES HUMANOS

Se manejan mediantes las cuentas de usuario 1


FALLOS EN EL SERVICIO ELÉCTRICO

Servidores con UPS implementados 1


RESPALDO DE LA INFORMACIÓN

Se realizan en DVD’s 1


Tabla N°29: Controles físicos aplicados por OTI a la red de la UCV- Piura.


Gráfico Nº16: Controles físicos aplicados para mitigar riesgos a la infraestructura física

de la red de la UCV - Piura

Fuente: Guía de entrevista: Controles físicos implementados en la red de la

Universidad, Anexo 10 (2011). Elaborado por los autores

1

0 0 0

1

0

1

0

1 1 1

N° Controles Físicos N° Controles Físicos



Una vez identificados los controles físicos aplicados a la red de la UCV,

procedemos a definir el número total de estos controles, de la siguiente

manera:

NCF=CF

Donde:

NCF: Número de controles físicos.

CF: Controles Físicos.

I: Mes.

N: Número de meses.

Se identificaron 6 controles físicos aplicados. Con estos datos obtenidos

aplicamos la fórmula anterior

Como conclusión final, podemos afirmar que OTI cuenta con controles

físicos básicos como la regulación de temperatura, presencia de un UPS

en el datacenter, señalización y extintores, no obstante, se pasan por alto

controles físicos muy importantes que podemos agrupar en dos:

Controles relacionados con la seguridad de acceso al datacenter

(protección contra robos)

Controles relacionados con la seguridad de los equipos respecto

a bajas de corriente o a interrupciones del suministro eléctrico

(continuidad del servicio)

Se recomienda que OTI considere mejorar los controles en estos dos

aspectos dentro de sus próximos planes operativos para mejorar la

seguridad de la infraestructura física de la red de la universidad.

4.3.3.6. Evaluación de Controles Lógicos a la Red.

De la misma manera se entrevistó al Jefe de la OTI sobre Controles

Lógicos aplicados a la red de la Universidad (Guía de entrevista:

Controles lógicos implementados en la red de la Universidad, Anexo 11),

de la cual pudimos obtener los siguientes datos.



Los controles lógicos aplicados a la red se caracterizan por lo siguiente:

Robo de Datos:

Accesos no autorizados. Estos se gestionan desde las mismas

cuentas de usuario, ya que cada una de estas cuentas con sus

respectivos privilegios, y restringe el acceso a recursos de la red.

Revisión de accesos no autorizados. Se monitorea el acceso no

autorizado mediante una herramienta informática llamada

“Wireshark”.

Software Maliciosos.

Se cuentan con software (Antivirus) de detección de

software maliciosos, Kaspersky.

Para gestionar estos software maliciosos, se aplican los

siguientes procedimientos:



Gráfico Nº17: Diagrama de flujo para la gestión de software malicioso aplicado por OTI

Fuente: Guía de entrevista: Controles lógicos implementados en la red de la Universidad,

Anexo 11(2011). Elaborado por los autores

Software no autorizados

Se cuenta con una relación de software licenciado con los

que cuenta la universidad.

Mediante los privilegios de las cuentas de usuario, se

gestiona la instalación de software no autorizados en los

equipos de la red de la universidad, ya que las cuentas

de usuarios comunes no cuentan con los privilegios para

la instalación de software, este procedimiento se realiza

SI

Terminar Se formatea el equipo

Se moviliza el equipo a

Soporte Informático

Se eliminó el

virus y

soluciono el

problema

Se analiza el equipo con el

antivirus

Identifica el equipo infectado

Gestión de Software

Maliciosos

NO



con una cuenta de administrador, las cuales solo maneja

el personal de soporte informático y jefe de red de la OTI.

En el siguiente cuadro definimos los controles lógicos aplicados a la red

de la UCV-Piura por parte de la OTI. Con dichos datos calculamos el NCL

de acuerdo a la fórmula definida.

Riesgo Lógicos N° Controles

ROBO DE DATOS

Accesos no autorizados (Se manejan mediante los

privilegios de las cuentas de usuarios). 1

Revisión de accesos no autorizados (se lleva un

monitoreo de los accesos mediante la herramienta

“Wireshark”)

1

N° total de controles lógicos aplicados 2

SOFTWARE MALICIOSO

Software de detección de virus (antivirus) en todos

los equipos de la red de la universidad. 1

Procedimientos aplicados para la gestión de software

maliciosos 1


SOFTWARE NO AUTORIZADOS

Inventario de software licenciado (Se cuenta con un

listado de software licenciados pertenecientes a la

universidad).

1

Instalación de software no autorizado en los equipos

de la red (Se manejan mediante los privilegios de las

cuentas de usuario).

1


Tabla N°30: Controles lógicos aplicados por OTI a la red de la UCV- Piura.




Gráfico Nº18: Controles lógicos aplicados para mitigar riesgos a la

infraestructura física de la red de la UCV - Piura

Fuente: Guía de entrevista: Controles lógicos implementados en la red de la

Universidad, Anexo 11(2011). Elaborado por los autor

Una vez identificados los controles lógicos aplicados a la red de la UCV,

procedemos a definir el número total de dichos controles, de la siguiente

manera:

NCL=CL

Dónde:

NCL: Número de controles lógicos.

CL: Controles Lógicos.

I: Mes.

N: Número de meses.

Se identificaron 6 controles lógicos aplicados. Con estos datos obtenidos

aplicamos la fórmula anterior

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Robo Datos Soft. Maliciosos Soft. Noautorizados

N° Controles Lógicos

N° Controles Lógicos



NCL=6

Se aplican los controles básicos, en cuanto a la seguridad lógica, no

obstante se identificó, por observación directa (Guía de Observación

N°03 – Anexo 28) una deficiencia en cuanto al acceso de archivos

compartidos, ya que, desde cualquier máquina de la universidad que

haya iniciado sesión con un usuario de dominio puede visualizar las

carpetas compartidas de cualquier PC incluyendo las de la OTI, con lo

que un usuario puede copiar contenido de sistemas y base de datos de

estos equipos y llevarse información vital.

Por lo que se recomienda restringir el acceso a estas carpetas, desde los

privilegios de los usuarios del dominio.

Otro control de seguridad extra es encriptar los archivos de vital

importancia de los sistemas, tales como los sistemas de la universidad

y/o Bases de Datos.

4.3.3.7. Determinar el Nivel de Madurez de la gestión de Redes de la

OTI

Para determinar el Nivel de Madurez de la Gestión de Redes de la OTI

se aplicaron tres cuestionarios al personal de la OTI, por medio de los

cuales se definió el Nivel de Madurez de la OTI, cada cuestionario trató

un aspecto de la gestión de redes tal como se muestra a continuación:

Gestión de Riesgos (Cuestionario Nº01: Gestión de riesgos de

red)

Mantenimiento de la red (Cuestionario Nº03: Mantenimiento de

la Red)

Inversión de TI (Cuestionario Nº04: Inversión en TI (redes)).

Los cuestionarios se conforman por un conjunto de controles (45 en

total), a los cuales se le asigna un nivel de madurez (del 0 al 5), estos

niveles se suman y se dividen por el número de controles considerados

obteniendo el nivel de madurez, tal como se refleja en la siguiente

fórmula:



∑

Donde:

NMGR: Nivel de Madurez de la Gestión de Redes

NMC: Nivel de Madurez de un control aplicado a la red de la

Universidad.

i: control “i” aplicado a la red de la universidad

N: Número de controles aplicados a la red de la universidad

considerados.

A continuación calculamos el nivel de madurez según el método

propuesto.



Nivel de Madurez de los controles aplicados a la red de la

Universidad César Vallejo - Piura

Nº PREGUNTAS

NIVEL DE MADUREZ

0 1 2 3 4 5 NIVEL ALCANZADO

1 ¿Se monitorea la red y servidores constantemente?

X 2

2 ¿El monitoreo de la red se rige en base a estándares ya establecidos o mediante el uso de software que cumplen dichos estándares?

X 2

3 ¿Se realizan evaluaciones de vulnerabilidad de manera regular?

X 1

4 ¿Existen procedimientos de control para mitigar los riesgos identificados?

X 1

5 ¿Se han clasificado los incidentes de red según su impacto?

X 0

6 ¿Se han documentado los procedimientos de control interno del área de redes?

X 3

7 ¿La misma se encuentra disponible y es conocida por los responsables del área?

X 3

8 ¿Los responsables y colaboradores de la administración de la red cuentan con funciones bien definidas y documentadas?

X 3

9 ¿El área cuenta con un plan de contingencia para TI (redes)?

X 3

10 ¿Los procedimientos del plan de contingencia son de conocimiento de los responsables del área?

X 2

11 ¿Se documentan los principales incidentes de red?

X 3

12 ¿Se analizan los anteriores para mejorar el control interno y realimentar la gestión de riesgos?

X 2

13 ¿La documentación de incidentes de red es la adecuada?

X 2

14 ¿Se revisan con frecuencia las políticas y procedimientos de gestión de riesgos en el área?

X 2

15 ¿Se actualizan las políticas y procedimientos de gestión de riesgos en el área?

X 1



16 ¿Se establece un proceso de planificación para la revisión del desempeño y la capacidad de los recursos de redes?

X 3

17 ¿Se reporta continuamente los monitoreos de la red de la universidad?

X 2

18 ¿Las tareas de mantenimiento interrumpen el servicio momentáneamente?

X 0

19 ¿Lo anterior está previamente documentado junto con las medidas a ejecutarse?

X 4

20 ¿Se realiza mantenimiento a la configuración de servidores y proxys?

X 4

21 ¿Se notifican las fallas encontradas? X 3

22 ¿Se les da seguimiento a las anteriores? X 3

23 ¿Existen salvaguardas para mitigar los riesgos a presentarse durante el mantenimiento?

X 2

24 ¿Las anteriores se consideran dentro de un plan de contingencia?

X 3

25 ¿Se controla el acceso a los espacios físicos cuando se está realizando las actividades de mantenimiento?

X 3

26 ¿Se lleva un registro de mantenimientos realizados?

X 3

27 ¿Se realizan mediciones del desempeño futuro de los recursos de red?

X 1

28 ¿Existe un procedimiento para determinar si un equipo necesita ser cambiado?

X 2

29 ¿Existe un programa de mantenimiento correctivo para los equipos de la red?

X 1

30 ¿Se maneja un inventario de equipos de red dentro del datacenter y fuera de él?

X 3

31 ¿Se considera significativa la inversión en TI?

X 2

32 ¿Se considera el presupuesto dentro del plan estratégico del área?

X 4

33 ¿Las políticas y procesos para inversiones se encuentran documentados?

X 3

34 ¿Se analizan las propuestas de inversiones?

X 3

35 ¿Se establecen prioridades dentro del presupuesto asignado a TI?

X 2



36 ¿Se asignan responsables para administrar el presupuesto de TI?

X 0

37 ¿Se realizan pronósticos y asignación de presupuestos?

X 2

38 ¿Se realiza seguimiento al presupuesto de TI de acuerdo a la estrategia de TI y decisiones de inversión?

X 1

39 ¿Se identifican y se resuelven las diferencias en el presupuesto?

X 1

40 ¿Se planifica la inversión en TI a largo plazo?

X 3

41 ¿Se da mantenimiento al portafolio de proyectos del área?

X 3

42 ¿Se da mantenimiento al portafolio de programas de inversión?

X 2

43 ¿El área maneja un plan de infraestructura tecnológica?

X 3

44 ¿Se miden los resultados después de una inversión?

X 3

45 ¿El área define un procedimiento de adquisición después de planificada la inversión?

X 1

TOTAL 100

Tabla N°33: Tabla de los Niveles de madurez de los controles aplicados por la

OTI a la red de la Universidad César Vallejo – Piura.


Por último calculamos el nivel de madurez dividiendo la sumatoria de los

NMC de los controles considerados por el número de controles

considerados

El resultado obtenido al no dar un número entero (que corresponda a un

nivel de madurez de acuerdo a la escala de valores de 0 al 5) debe

interpretarse que está entre dos valores de madurez, en este caso



particular el resultado 2.22 indica que el nivel de madurez se ubica entre

los niveles 2 y 3, que corresponden a los niveles REPETIBLE y

DEFINIDO respectivamente, lo que significa que OTI utiliza varios

procedimientos que no están formalmente documentados y son

aplicados prácticamente de manera empírica, lo que le ubica

prácticamente en el nivel 2 o REPETIBLE; no obstante, OTI ha

comenzado a manejar cierto tipo de documentación como el plan de

contingencia, el mapa topológico de la red, el plan operativo o el uso de

una bitácora de atenciones que demuestra que el área está iniciando un

proceso de mejora de sus procesos con miras a una estandarización, lo

que le aproxima al nivel 3 o DEFINIDO.



CAPÍTULO V

RESULTADOS



5.1. Marco Lógico Con el desarrollo de la auditoría se han entrado hallazgos que nos permiten conocer

la situación actual de la gestión de redes y telecomunicaciones de la OTI, dichos

hallazgos se han reunido en un consolidado que se presentará en este punto de la

auditoría, el cual se dividirá, a su vez, en tres partes: En la primera parte se

presentará el marco lógico de la auditoría mediante un diagrama causa –efecto.

En la segunda parte de hará una comparación de los hallazgos (situación actual) con

el marco de trabajo COBIT (situación deseada o ideal), dicha comparación se hará

por cada indicador.

Para terminar, la tercera parte presentará el plan de mejora que condensará la

comparación con la situación ideal y los hallazgos específicos de la auditoría por

cada indicador.

A continuación se muestra el Marco Lógico, el cual está constituido por cada uno de

los indicadores definidos y evaluados anteriormente:



5.2. Comparación de la situación actual con la situación deseada Para detallar el Marco Lógico presentado anteriormente, se procedió a realizar las

siguientes tablas de comparación en donde se detalla por cada indicador la situación

actual (Producto de la evaluación realizada) y la situación deseada (Lo que establece

el marco de trabajo COBIT), las cuales nos ayudaran a tener una visión más amplia

de la manera como se lleva a cabo la gestión por parte de la OTI y de cómo se debe

de manejar.



Indicador Nº1 Número de procesos críticos de negocio no incluidos en un plan de contingencia. (NPC)

Situación actual (Evaluación) Situación deseada (Según COBIT)

La OTI cuenta con un plan de contingencia el cual fue elaborado

como trabajo de tesis de PRE-GRADO, el cual no cuanta con el

formato adecuado de un plan de contingencia.

COBIT propone considerar la documentación de evaluación de riesgos,

la que incluye:

Un marco adecuado para los resultados y propuestas de mejora

de cada riesgo hallado.

una descripción de la metodología de evaluación de riesgos,

la identificación de exposiciones significativas y los riesgos

correspondientes,

los riesgos y exposiciones correspondientes considerados,

se incluyen técnicas de probabilidad, frecuencia y análisis de

amenazas en la identificación de riesgos,

el personal asignado a evaluación de riesgos está

adecuadamente calificado

No se lleva una revisión regular de los procedimientos de

contingencia que maneja.

Evaluar de forma recurrente la probabilidad e impacto de todos los

riesgos identificados, usando métodos cualitativos y cuantitativos.

El plan de contingencia hace referencia a los procesos críticos de

la organización sólo desde la óptica del área de sistemas

(subárea de desarrollo)

Identificación de Eventos Identificar eventos (una amenaza importante y

realista que explota una vulnerabilidad aplicable y significativa) con un

impactopotencial negativo sobre las metas o las operaciones de la

empresa, incluyendo aspectos tales como:



Tabla N°34: Comparación situación real vs deseada para el indicador NCP.


De negocio,

regulatorios,

legales,

tecnológicos,

sociedad comercial,

de recursos humanos y operativos.



Indicador Nº2

Indicador Nº3

Porcentaje de incidentes de red resueltos en el tiempo acordado (PIR)

Número promedio de horas perdidas por usuario al mes, debido a interrupciones en la red. (NHP)


La gestión de incidentes de OTI está conformada por un

helpdesk que utiliza dos canales de comunicación para atender

a los usuarios:

Por llamada telefónica (marcando el número

de anexo del helpdesk)

Por envío de solicitud mediante el correo

corporativo.

COBIT propone gestionar la atención de incidentes considerando los

siguientes puntos:

Contar con un Buró de Ayuda (helpdesk), del cual en cuanto a su

naturaleza sea efectiva, esto en cuanto a la forma en la que las

requisiciones de ayuda son procesadas y la ayuda es proporcionada.

Registro de incidentes. El registro de incidentes es

manual. Se usa una bitácora de incidentes (ver el ítem

de revisión preliminar de documentación) donde se

indica el incidente dado, el tipo de incidente (si es un

incidente de soporte, de red o de los sistemas de

información) y la persona que lo va a atender.

Registro de preguntas del Usuario

Debe existir un proceso real para registrar requisiciones de

servicios y si se hace uso de dicha bitácora, del cual podamos

luego generar una lista o reporte de los problemas reportados

durante un período representativo, incluyendo la fecha de

ocurrencia, la fecha de solución y los tiempos de solución.

Manejo de Incidentes

Es un proceso empírico, porque se basa en la

experiencia diaria de los participantes del proceso

de atención: Asistente, clientes y expertos de cada

Sistema de manejo de Problemas

Existe un proceso de manejo de problemas que asegure

que todos los eventos operacionales que no son parte de

las operaciones estándar son registrados, analizados y



área. La asistente, por la naturaleza del incidente,

abe a quien llamar, el experto, por su propia

experiencia, sabe qué hacer, y el cliente, en

algunos casos, sabe a qué experto llamar (la

asistente se limita a llamar al experto)

resueltos de manera oportuna.

Existen procedimientos de manejo de problemas para:

o Definir e implementar un sistema de manejo de

problemas,

o Registrar, analizar y resolver de manera oportuna

todos los eventos no-estándar,

o Establecer reportes de incidentes para los eventos

críticos y la emisión de reportes para usuarios,

o Identificar tipos de problemas y metodología de

priorización que permitan una variedad de soluciones

tomando el riesgo como base,

o Distribuir salidas con una base de “necesidad de

conocimiento”,

o Notificar los escalamientos al nivel apropiado de

administración,

o Determinar si la administración evalúa periódicamente

el proceso de manejo de problemas en cuanto a una

mayor efectividad y eficiencia,

o Asegurar la integración entre los cambios, la

disponibilidad, el sistema y el personal de manejo de la

configuración

Tiempo de atención al incidente. Se tiene una noción Monitoreo de atención a clientes



Tabla N°35: Comparación situación real vs deseada para los indicadores PIR y NHP.


de urgencia por atención de incidentes de acuerdo al

área que solicita una atención, según ello existen áreas

con mayor prioridad que otras. De acuerdo al

administrador de la red (jefe de la oficina), las áreas a

las cuales les da mayor prioridad son Caja y Dirección

General.

El período de tiempo para atender las preguntas recibidas es

adecuado,

Tiempo apropiado de respuesta tomando como base la

prioridad del evento.

Considera el escalamiento de incidentes. En el caso

de redes, el nivel más bajo lo ocupan los trabajadores

del área de soporte, luego, le sigue el administrador de

la red y, en el nivel más alto, se encuentran los

encargados de DTI de Trujillo. En el caso de Trujillo,

sólo se derivan problemas que se relacionen con el

servidor de datos.

Escalamiento de preguntas del cliente

Escalamiento de problemas para eventos críticos,

El proceso para la escalación de preguntas y la intervención

de la administración para su solución son suficientes.



Tabla N°36: Comparación situación real vs deseada para el indicador NCT.


Indicador Nº4 Número de controles aplicados a servicios de terceros. (NCT)


Los controles aplicados a terceros por la OTI son los siguientes,

en donde cabe recalcar que OTI no mantiene relaciones de

tercerización directas sino que tiene un intermediario que es el

área de Logística, quien gestiona los contratos con proveedores

de servicios y equipos, pero si en cuanto a la implementación

del cableado red de edificio nuevo, como también en la compra

de equipos de cómputo nuevos.

Apoyo y supervisión de las tareas de cableado de un

edificio nuevo,

Inspección al finalizar las tareas de cableado de un

edificio nuevo,

Revisión de propuestas de proveedores

En cuanto a controles aplicados a terceros, COBIT establece los

siguientes

Monitoreo

El monitoreo continuo de liberación y entrega de servicios

por parte de terceros es llevado a cabo por la administración,

Se llevan a cabo auditorías independientes de las

operaciones de la parte contratante.



Tabla N°37: Comparación situación real vs deseada para el indicador PIATI.


Indicador Nº5 Porcentaje de inversión en actualización de TI (PIATI)


La OTI gestiona la inversión en actualización de TI de la siguiente

manera:

Definición de TI necesarias: La OTI implementa su plan

operativo cada año, en donde se especifica las TI

necesarias a adquirir para seguir con la continuidad y

mejora del servicio

En cuanto a la Identificación y asignación de costos OBIT establece:

Definición de servicios

Crear un plan anual de desarrollo y mantenimiento Generar un presupuesto anual para la función de servicios

de información, incluyendo: o Cumplimiento con los requerimientos organizacionales

en cuanto a la preparación de presupuestos

o Consistencia en cuanto a cuáles costos deben ser

asignados por los departamentos

o Actualización de las TI, con nuevas TI que surgen.



Tabla N°38: Comparación situación real vs deseada para el indicador NMR.


Indicador Nº6 Número de veces por mes que se ha realizado mantenimiento a la Red. (NMR)


Las actividades de mantenimiento del área de Redes se

planifican anualmente y se indican dentro del plan operativo.

De estas actividades, las principales realizadas en el

transcurso del 2011 son las siguientes:

Limpieza de equipos del datacenter.

Ampliación de puntos de red y cambio de cableado

(activación de puntos y colocación de canaletas)


Etiquetado de cableado.

Reinicio de switches (en caso de borrarse la

configuración por causa de un apagón)

Análisis de switches para resolver problemas

detectados por monitoreo de red (ver Diagrama de

Flujo del Procedimiento para el monitoreo de puertos

en la red).

Programación de Tareas

Para lo que COBIT establece:

Organizar la programación de trabajos, procesos y tareas en

la secuencia más eficiente, maximizando el desempeño y la

utiliza para cumplir con los requerimientos del negocio.

Deben autorizarse los programas iníciales así como los

cambios a estos programas.

Los procedimientos deben implementarse para identificar,

investigar y aprobar las salidas de los programas estándar

agendados.



Indicador Nº7 Número de controles Físicos para garantizar la continuidad del servicio (NCF)


Se aplican controles físicos comunes; tales como:

Desastres Naturales: se cuenta con aire acondicionado

dentro del data center para controlar el aumento de

temperatura, así como también de extintores en caso de

incendios.

Protección contra Factores Ambientales

Políticas y procedimientos aplicados a factores ambientales, tales

como: Altas temperaturas, Inundaciones, terremotos.

Revisión de los procedimientos de control de aire acondicionado,

ventilación, humedad y las respuestas esperadas en los distintos

escenarios de pérdida o extremos no anticipados.

Robo de equipo: se cuenta con gabinetes con sus

respectivos candados dentro del datacenter.

Errores Humanos: mediante las cuentas de usuario se

controla lo correspondiente a la instalación de software

ajeno a los de la universidad, como también la

eliminación de archivos del sistema que puedan afectar

a este.

Seguridad Física

Se debe contar con:

Los procedimientos y prácticas de administración de llaves

son adecuados.

Coordinan los escenarios de prueba de penetración física

Realización de pruebas de penetración física a la red

La organización es responsable del acceso físico, por lo que se

debe tener en cuenta:

Desarrollo, mantenimiento y revisiones continuas de

políticas y procedimientos de seguridad,

Establecimiento de relaciones con proveedores

relacionados con la seguridad,

Contacto con la administración de las instalaciones en

cuanto a problemas de tecnología relacionados con



seguridad,

Coordinación del entrenamiento y conciencia sobre

seguridad para la organización,

Coordinación de actividades que afecten en control de

acceso lógico vía aplicaciones centralizadas y software de

sistema operativo,

Proporcionar entrenamiento y crear conciencia de

seguridad no sólo dentro de la función de servicios de

información, sino para los servicios de usuarios.

Servicio Eléctrico: Se cuanta con UPS implementados

en los servidores dentro del DataCenter.

Suministro Ininterrumpido de Energía

Se debe contar con un grupo electrógeno y su correspondiente

abastecimiento permanente de combustible para asegurar el

suministro de energía en caso de apagones, además debe

contarse con una subestación para evitar las bajas de voltaje en

los demás edificios del campus para evitar el deterioro de los

equipos.

DataCenter: Se cuenta con la señalización adecuada

dentro del data center, así como de elementos de

seguridad (extintores) en caso de algún problema.

Escolta de Visitantes. Son apropiadas para áreas más sensibles

tales como el DataCenter , por lo que debe contar con:

Políticas de acceso y autorización de entrada/salida.

Escolta, Registro, Pases temporales requeridos,

cámaras de vigilancia.

Se lleva a cabo una revisión de los siguientes registros:



Tabla N°39: Comparación situación real vs deseada para el indicador NCF


visitantes,

Asignación de pases,

Escolta,

Persona responsable del visitante,

Bitácora.

Se debe contar con elementos de infraestructura específicos

alternativos necesarios para implementar seguridad:

Fuente de poder ininterrumpida (UPS)

Alternativas o reruteo de líneas de telecomunicación

Recursos alternativos de agua, gas, aire acondicionado.

Respaldo de información. Los procedimientos para los

respaldos de información se realizan de la siguiente

manera:

Se realizan en DVD y

Aplicando controles tales como:

El contenido del centro de cómputo de respaldo está

actualizado

Almacenamiento de la información fuera del centro de

cómputo.

Además de contar con la información logística de la localización de

recursos clave, incluyendo el centro de cómputo de respaldo para

la recuperación de sistemas operativos, aplicaciones y archivos de

datos.



Indicador N°8 Número de controles Lógicos para garantizar la continuidad del servicio (NCL)


Los controles lógicos aplicados a la red por parte de la OTI

son los siguientes:

Robo de Datos:

El robo datos se mitiga mediante los siguientes

controles:

Accesos no autorizados. Estos se gestionan

desde las mismas cuentas de usuario, ya que

cada una de estas cuentas con sus respectivos

privilegios, y restringe el acceso a recursos de la

red.

Revisión de accesos no autorizados. Se

monitorea el acceso no autorizado mediante una

herramienta informática llamada “Wireshark”.

Considerar los siguientes controles lógicos, según COBIT:

Seguridad de Acceso a Datos en Línea

Se deben aplicar los siguientes controles:

procedimientos de administración de cuentas de usuario

Política de seguridad del usuario o de protección de la

información

Esquema de clasificación de datos

Plano de los edificios/habitaciones que contienen recursos de

sistemas de información

Inventario o esquema de los puntos de acceso físico a los

recursos de sistemas de información (por ejemplo, módems,

líneas telefónicas y terminales remotas).

Al entrar, aparece un mensaje de advertencia preventivo en

relación al uso adecuado del hardware, software o conexión, y

que los accesos no autorizados podrían causar

responsabilidades legales.

Control de acceso a carpetas compartidas mediante políticas

de grupos de usuarios.

Encriptación de archivos importantes, como códigos fuente,



registros de bases de datos, mapa topológico, planes

operativos, etc.

Software Maliciosos.

Los controles aplicados para este punto son los

siguientes:

Se cuentan con software (Antivirus) de

detección de software maliciosos, Kaspersky.

Para gestionar estos softwares maliciosos, se

aplican procedimientos específicos para

mitigar estos softwares maliciosos.

Prevención, Detección y Corrección del Software Dañino

Aplicar controles aplicados software maliciosos tales como:

Procedimientos de control de cambios de software de

seguridad

Procedimientos de seguimiento, solución y escalamiento de

problemas

Por lo que se debe considerar los siguientes procedimientos para la

protección contra software maligno:

Todo el software adquirido por la organización se revisa contra

los virus antes de su instalación y uso,

Existe una política por escrito para bajar archivos (downloads),

aceptación o uso de aplicaciones gratuitas y compartidas y

esta política está vigente,

Los usuarios tienen instrucciones para la detección y reportes

de virus, como el desempeño lento o crecimiento misterioso

de archivos.

Software no autorizados

Se cuenta con una relación de software licenciado

con los que cuenta la universidad.

Mediante los privilegios de las cuentas de usuario,

Protección de las Funciones de Seguridad

Inventario de software de control de acceso,

procedimientos de control de cambios de software de

seguridad



se gestiona la instalación de software no

autorizados en los equipos de la red de la

universidad.

El hardware y software de seguridad, están protegidos contra

la intromisión o divulgación.

Se cuenta con perfiles de seguridad de usuario que

representen “los menos accesos requeridos” y que muestren

revisiones regulares a los perfiles por parte de la

administración con fines de reacreditación.

Tabla N°40: Comparación situación real vs deseada para el indicador NCL


Como se pudo apreciar en la comparación realizada, es necesario implementar procesos a la gestión de Redes de la UCV-Piura por parte

de la OTI, los que proponemos en un Plan de Mejora(Definido en el siguiente apartado) para la gestión, con lo que se contrasto la

hipótesis planteada “La aplicación de una auditoría basada en COBIT permitirá determinar el nivel de madurez de la gestión de

redes, comunicaciones y servidores aplicada por la Oficina de Tecnologías de Información (OTI) a la red de la Universidad César

Vallejo – Piura” (CAPITULO II: PLAN DE INVESTIGACIÓN - 2.9: Hipótesis).

.



5.3. Plan de Mejora

Se presenta el plan de mejora para cada indicador considerado en la auditoría. El

plan de mejora consta de un conjunto de recomendaciones para mitigar las

deficiencias encontradas durante el desarrollo de la auditoría.

5.3.1. Indicador N° 01: Número de procesos críticos de negocio no incluidos

en un plan de contingencia. (NPC)

En el análisis efectuado se encontró con la siguiente situación:

“De acuerdo al gráfico, Los procesos críticos no considerados

representan el 20% del total de procesos críticos.

Estos procesos se consideran críticos porque un alumno no puede

graduarse si no ha llevado estos cursos durante el tiempo que dura el

estudio de la carrera, de ocurrir un problema con los sistemas, OTI se ve

involucrada en el problema.

Otra carencia que hemos encontrado es la no consideración de

operaciones críticas de la administración de la red de la universidad

para cada proceso crítico considerado en el plan de contingencia; el

plan se limita sólo a describir los procesos críticos desde el punto de

vista de la usabilidad de los sistemas informáticos que soportan las

operaciones”.(CAPITULO IV: DESARROLLO DE LA PROPUESTA –

4.3.3.1Evaluación de la Gestión de Atención de Incidentes (de Redes) y de la

Gestión de la Continuidad del Servicio en la OTI.)

Para lo cual las recomendaciones que deben llevar a cabo para mitigar estas

deficiencias son las siguientes:

Hallazgo de Auditoría Recomendación

El área no maneja un plan de contingencia

formal, sino tiene por tal a una tesis de

pregrado.

OTI debe revisar la propuesta de plan de

contingencia (tesis de pregrado), para

obtener un documento formal el cual, una

vez finalizado, debe ser aprobado por las

autoridades de la universidad. (Proyecto

N°01 – Anexo 17)

El área no revisa regularmente los

procedimientos de contingencia que

maneja.

OTI debe revisar el plan de contingencia

continuamente y actualizarlo conforme

cambios de índole técnico o administrativo

se vayan dando.



El plan de contingencia hace referencia a

los procesos críticos de la organización

sólo desde la óptica del área de sistemas

(subárea de desarrollo)

OTI debe recopilar los procedimientos de

cada subárea no considerada e identificar

los que son críticos. Se recomienda que

esta actividad se haga en el marco de las

revisiones para obtener un documento

formal.

Tomando la afirmación anterior. El plan no

trata sobre procedimientos críticos de la

subárea de redes.

OTI debe identificar los procedimientos

críticos de la subárea de redes, además

debe identificar los riesgos específicos a

redes y aplicar controles preventivos,

detectivos y correctivos.

El plan de contingencia no considera los

siguientes procesos críticos: Matrícula en

los cursos de inglés, matrícula en los

cursos de computación, matrícula en las

actividades integradoras.

OTI, en primer lugar, debe estudiar el

impacto de estos procedimientos para

determinar que tan críticos pueden ser para

darles un orden de prioridad de atención a

las áreas que manejan estos

procedimientos desde la óptica de las tres

subáreas. (redes, desarrollo y soporte)

Tabla N°41: Plan de mejora para el indicador NPC


5.3.2. Indicador N° 02: Porcentaje de Incidentes de Red resueltos en un tiempo

óptimo (PIR)


“Se obtiene que el 81.81% de los incidentes de red son atendidos en un

tiempo óptimo, es decir en un tiempo no mayor de las 5.5 horas. De ellos

(haciendo referencia a la tabla 8), la creación de usuarios de dominio es

el que demora menos con un tiempo de 0.033 horas (2 minutos) y el en

que se invierte más tiempo es la solución de problemas con la conexión

al escritorio remoto (para conectarse al sistema SEUSS) con un tiempo

de 4.198 horas en promedio.

De las actividades que pasan el tiempo óptimo concluimos lo siguiente:



Los problemas de anexo rebasan el tiempo de atención óptimo

cuando se malogra un power injector. Para repararlo se invierten

aproximadamente unas 42.75 horas.

La colocación de canaletas y el ordenamiento de cableado son

actividades de muy larga duración, especialmente, el ordenamiento

de cableado que puede llevar unas 19 horas como máximo”.

(CAPITULO IV: DESARROLLO DE LA PROPUESTA – 4.3.3.1Evaluación

de la Gestión de Atención de Incidentes (de Redes) y de la Gestión de la

Continuidad del Servicio en la OTI.)




El registro de incidentes de OTI es manual

usando software de hoja de cálculo (MS

Excel 2007)

Se debe implementar un sistema

informático de gestión de incidentes que

permita automatizar el registro de

incidentes. (Proyecto N°03 – Anexo 19 )

Los incidentes registrados (en la bitácora

de incidentes) no son analizados; tampoco

pueden ser filtrados por subárea que los

atendió.

El sistema informático debe permitir

reportar los incidentes atendidos de

acuerdo a subáreas (también por intervalo

de fechas), además, se recomienda que los

históricos de incidentes sean sometidos a

un análisis de tendencia para identificar

problemas recurrentes (COBIT DS8.2), los

incidentes deben clasificarse por impacto y

por ocurrencia.

Si el incidente es demasiado recurrente (en

OTI los incidentes más recurrentes son los

problemas de conectividad) debe rastrearse

y darle solución (COBIT DS10.2).

De esta manera la calidad de servicio

mejorará y la resolución de incidentes

tomará menos tiempo porque éstos ya se

tendrían formalmente identificados.

La bitácora de incidentes no maneja un

lenguaje estándar para referirse a los

Se deben clasificar los incidentes de la

bitácora por tipo (previamente deben



incidentes, es común ver varios incidentes

“diferentes” pero que en realidad

constituyen ser el mismo tipo.

clasificarse por subárea), luego, identificar

aquellos que tienen una causa común o

que presentan el mismo impacto negativo,

por ultimo englobar ese grupo de incidentes

en una denominación general y

estandarizada, pero es recomendable,

incluir, dentro de un campo ”detalle” las

implicancias específicas de cada incidente.

Una vez hecho esto comunicar al personal

de OTI acerca de las medidas adoptadas,

y, finalmente, documentar el criterio de

clasificación como una nueva disposición

del área.

Algunos incidentes (de la bitácora) no se

indica la solución lo que dificulta la

posterior tarea de clasificación de

incidentes y de creación de una base de

conocimiento

Se recomienda que el sistema informático

propuesto solicite (como campo obligatorio)

la solución a un determinado incidente, y

sólo así el sistema pueda reconocer a un

incidente como terminado o cerrado

(COBIT DS8.4 y COBIT DS10.3)

Se maneja un orden de prioridad de

atención por áreas, no obstante lo que está

registrado en la documentación (OTI)

difiere del criterio que se lleva en la

práctica.

La prioridad de atención debe definirla el

jefe de la OTI en consenso con los

trabajadores del área, una vez definida, la

asistente del área debe actualizar el plan de

contingencia donde se consigna el orden de

prioridad de atención.

OTI cuenta con personal insuficiente en las

subáreas de soporte y de redes cuando los

incidentes que involucran estas subáreas

son los más frecuentes. Se comprobó que

el incidente que más tiempo toma es la

reparación de un power injector (42.75 h)

que es responsabilidad de la subárea de

soporte.

OTI debe coordinar con el departamento de

RR.HH para solicitar más personal para

esas dos subáreas. En el caso específico

de la subárea de redes, OTI debe contar

con un segundo administrador de la red,

porque el actual administrador comparte las

responsabilidades propias de su función

con las de la jefatura de OTI y, a veces, se

ausenta de la universidad.

OTI no maneja un tiempo óptimo de

atención. Sólo se maneja la consigna de

OTI debe establecer un tiempo óptimo de

atención estándar para tener una referencia



atender un incidente “en el menor tiempo

posible”

que indique la calidad de las atenciones de

la OTI.

Tabla N°42: Plan de mejora para el indicador PIR


5.3.3. Indicador N° 03: Número promedio de horas perdidas por usuario al

mes, debido a interrupciones de red (NHP)


“Los usuarios pierden aproximadamente 15 horas (14.990) por

interrupciones al servicio por mes. Considerando que en un día se

trabajan 9.5 horas diarias y, en un mes se hacen un total de 285

horas, entonces la pérdida de horas por interrupción del servicio (15

horas) representa el 5.2 % de las horas mensuales trabajadas.

Los problemas más comunes son los relacionados con la

conectividad, ya sea que no tiene red o que no tiene internet (16

veces al mes); le siguen, en frecuencia, los problemas con los

anexos que usan telefonía IP (4 veces al mes).

Respecto al tiempo perdido mensual (TPMIS), las interrupciones que

provocan más pérdida de horas son las interrupciones de red (65.74

horas/mes), seguido de los problemas con los anexos (43.92

horas/mes).

Los problemas por ingresar al SEUSS (por escritorio remoto), el

corte de fluido eléctrico y los problemas con los servidores, son las

interrupciones de mayor duración entre las que registran la menor

frecuencia de ocurrencia.

Tomando en cuenta los resultados del análisis de incidentes y de

interrupciones podemos observar:

La mayoría de interrupciones se solucionan en el tiempo óptimo

observado (menor o igual a 5.5 horas)

Los problemas con el anexo son el único tipo de interrupciones que

no solucionan en el tiempo óptimo (10.98 horas) pese a ser la

segunda más frecuente”.

(CAPITULO IV: DESARROLLO DE LA PROPUESTA – 4.3.3.1Evaluación de

la Gestión de Atención de Incidentes (de Redes) y de la Gestión de la

Continuidad del Servicio en la OTI.)






Las interrupciones más comunes son

aquellos relacionados con la conectividad:

Problemas con la red, problemas con

Internet y problemas con los anexos

(teléfonos IP)

Se debe revisar estas interrupciones y

catalogarlas como problemas para

encontrar una solución o para mitigar su

impacto negativo (COBIT DS10.3). Además

debe realizarse un plan de monitoreo y

mejora del servicio de la red de la

Universidad. (ProyectoN°02 – Anexo 18)

Las anteriores también son las que más

tiempo perdido generan a los usuarios.

A la aplicación de la recomendación

anterior se le adiciona monitorear

constantemente la interrupción detectada

para determinar cuáles son aquellas con el

mayor impacto negativo (pérdida de tiempo

por caída del servicio)

El plan de contingencia de OTI no contiene

medidas para mitigar el riesgo de

interrupción por falta de conectividad.

Se recomienda, primero, identificar los

riesgos más frecuentes y más peligrosos

(mayor impacto negativo), luego, formular

las medidas de contingencia y las acciones

a seguir antes, durante y después de la

interrupción, por último, las nuevas medidas

deben darse a conocer a los involucrados

de las subáreas de redes y soporte para su

conocimiento y aprobación.

No se ha podido constar (en la

documentación revisada) la identificación

de los recursos críticos de la red de la

universidad.

La subárea de redes debe identificar los

recursos críticos que pueden verse

afectados al producirse una interrupción a

la red de la universidad (COBIT DS4.3). El

resultado de este estudio debe consignarse

dentro del plan de contingencia (Revisar las

recomendaciones para el indicador 1 para

más información sobre la actualización del

plan de contingencia)

OTI almacena los backups dentro de un El área debe almacenar una copia de los



Tabla N°43: Plan de mejora para el indicador NHP


5.3.4. Indicador N° 04: Número de controles aplicados a terceros (NCT)


“Los controles a terceros, referidos a TI, son aplicados por la OTI y

por Logística.

OTI tiene una participación menor que Logística pero ésta no es

nada despreciable porque abarca con el 40% de los controles a

terceros

OTI aplica los controles de índole técnico, mientras que Logística

cumple con los controles referidos al contrato y al cumplimiento del

mismo.

OTI acude a la tercerización cuando se requiere de nuevo cableado

estructurado para certificar la calidad del trabajo”.

(CAPITULO IV: DESARROLLO DE LA PROPUESTA – 4.3.3.2 Evaluación de

controles aplicados a terceros)



armario ubicado en la misma oficina. backups en un lugar fuera de la oficina

(donde funciona OTI) o incluso fuera del

campus (COBIT DS4.9)

El datacenter no cuenta con equipos

replicadores, muy útiles en caso de

interrupciones.

OTI debe considerar adquirir equipos

replicadores, para ello, debe consignar esta

necesidad en los próximos planes

operativos.

La universidad no cuenta con un grupo

electrógeno en caso de apagones. (una de

las interrupciones registradas en la

bitácora)

OTI debe solicitar la adquisición de un

grupo electrógeno lo antes posible para

evitar retrasos innecesarios de los procesos

de la universidad.




Los documentos mercantiles (facturas,

órdenes de compra y cotizaciones) son

manejadas sólo por el área de Logística.

El área debe contar con una copia de estos

documentos para identificar las relaciones

de los proveedores con los que Logística

tiene contacto (COBIT DS2.1). Sería

recomendable si estos documentos deben

gestionarse con la ayuda de un sistema

informático (Proyecto N°04 – Anexo 20)

Del lado de OTI, no hay constancia de

medidas de contingencia con respecto a la

administración de riesgos del proveedor.

OTI debe fijar medidas de contingencia para

mitigar riesgos del proveedor en consenso

con el área de Logística. Esta actividad

debe realizarse en el marco de la revisión y

actualización del plan de contingencia de la

OTI referida en las recomendaciones el

indicador 1

Tabla N°44: Plan de mejora para el indicador NCT


5.3.5. Indicador N° 05: Porcentaje de inversión para cubrir los costos en TI

(PIATI)


“El porcentaje de actualización de TI es de 13%, un valor muy cercano al

calculado mediante la fórmula (14.92%), pero despreciando la diferencia

de resultados, se puede llegar a las siguientes conclusiones.

La utilización del 13% del presupuesto es demasiado bajo para TI, lo

que es un indicador de que los equipos de comunicaciones no se

han renovado.

Un indicador de la no renovación de equipos es el bajo precio con el

que actualmente se venden algunos switches en la actualidad, como

se puede constatar en la tabla N°27

Se recomienda que OTI, en lo futuro invierta más en lo que es

equipos de comunicaciones, sobretodo en la renovación de equipos

que ya tienen cierta antigüedad así como también en la adquisición



de nuevos equipos para mejorar la infraestructura de la

red”.(CAPITULO IV: DESARROLLO DE LA PROPUESTA – 4.3.3.3

Evaluación de los costos para cubrir la inversión en TI)




El porcentaje en actualizaciones de TI es

muy bajo, por lo que OTI no ha realizado

una actualización de las diferentes TI con

las que cuenta.

La OTI debe realizar una mayor inversión

en equipos de comunicación y actualizar

los equipos con mayor antigüedad para

mejorar la infraestructura de la red de la

universidad. (Proyecto N°05 – Anexo 21)

Tabla N°45: Plan de mejora para el indicador PIATI



mantenimiento a la red (NMR)


“El mantenimiento es netamente correctivo más que proactivo y se basa

por lo general al mantenimiento de cableado”.(CAPITULO IV:

DESARROLLO DE LA PROPUESTA – 4.3.3.4Evaluación de la frecuencia de

las tareas de mantenimiento de la Red)




Las actividades de mantenimiento son, en

su mayoría, reactivas, es decir, cuando

ocurre el problema

OTI debe realizar actividades de

mantenimiento proactivo, es decir aquél

que se adelanta a los problemas o errores

que pueden darse en la red. (Proyecto

N°06 – Anexo 22)

No son comunes las tareas de limpieza de

los equipos del datacenter (no se encontró

entradas en la bitácora de atenciones entre

Enero y Setiembre del 2011)

Las tareas de limpieza de equipos deben

darse con mayor frecuencia, además debe

realizarse un cronograma de actividades

de limpieza de equipos y, por extensión,



de todas las actividades de mantenimiento

a realizarse

En el plan de contingencia no hay mención

de acciones para mitigar el riesgo de las

actividades de mantenimiento de equipos de

redes y telecomunicaciones.

OTI debe considerar acciones de

contingencia para mitigar riesgos como

imprevistos, o fallas en el servicio durante

las tareas de mantenimiento. Dichas

acciones deben considerarse dentro del

marco de actualización del plan de

contingencia (referido en el indicador 1)

Las actividades de monitoreo de la red

(análisis de switches) no se registran en la

bitácora de atenciones

Las actividades de monitoreo deben

registrarse en la bitácora y no limitarse a

sucesos extraordinarios o fuera de lo

común

Tabla N°46: Plan de mejora para el indicador NMR


5.3.7. Indicador N° 07: Número de controles físicos para garantizar la

continuidad del servicio (NCF)


“OTI cuenta con controles físicos básicos como la regulación de

temperatura, presencia de UPS en el datacenter, señalización y

extintores, no obstante, se pasan por alto controles físicos muy

importantes que podemos agrupar en dos:

Controles relacionados con la seguridad de acceso al datacenter

(protección contra robos)

Controles relacionados con la seguridad de los equipos respecto a

bajas de corriente o a interrupciones del suministro eléctrico

(continuidad del servicio)”.

(CAPITULO IV: DESARROLLO DE LA PROPUESTA – 4.3.3.5 Evaluación de

Controles Físicos a la Red)






En cuanto a controles físicos aplicados a

desastres naturales, la OTI solo aplica para

el aumento de temperatura e incendios,

para los cuales se ha implementado aire

acondicionado (el cual no es el adecuado ya

que no es de precisión) y extintores dentro

del datacenter

OTI debe implementar aire acondicionado

de precisión al igual de un constante

análisis de desastres ambientales a los

cuales es propensa la región de Piura,

tales como las lluvias e inundaciones, asi

como el riesgo del fenómeno del niño, e

implementar controles físicos para estos

riesgos. Además OTI debe mejorar la

seguridad de acceso al datacenter

(Proyecto N°07 – Anexo 23)

La OTI solo aplica controles físicos

relacionados con el robo de equipos a

aquellos que se encuentran dentro del

DataCenter, y no a todos los quipos de

cómputo de la red (Oficinas, Laboratorios).

Se debe implementar controles físicos

para los procedimientos y prácticas de

administración de llaves.

Para garantizar la seguridad de la red se

debe realizar pruebas de penetración

física a la red, así como desarrollo, dar

mantenimiento y revisiones continúas de

las políticas y procedimientos de

seguridad implementadas por la OTI

además proporcionar entrenamiento y

crear conciencia de seguridad a los

usuarios.

Solo se cuenta con la implementación de

UPS como controles para mitigar la pérdida

del fluido eléctrico.

Para mitigar el problema de la perdida de

fluida eléctrico la OTI debería implementar

controles tales como de contar con un

grupo electrógeno y su correspondiente

abastecimiento permanente de

combustible para asegurar el suministro

de energía en caso de apagones, además

debe contarse con una subestación para

evitar las bajas de voltaje en los demás

edificios del campus para evitar el

deterioro de los equipos.



El DataCenter solo se cuenta con

señalización adecuada, así como de

elementos de seguridad (extintores) en caso

de algún problema, UPS y gabinetes con

llave, los cuales son muy pocos tratándose

del DataCenter.

Por lo que la OTI debe también

implementar además de lo recomendado

anteriormente, políticas que gestionen el

ingreso al DataCenter, asi como

actualización y revisión de las mismas.

Los respaldos de información, los cuales se

realizan en DVD no se alma en un lugar

adecuado fuera del DataCenter.

Para lo que la OTI debe aplicar controles

para gestionar las copias de respaldo

(este actualizado y que se encuentre fuera

del datacenter).

Tabla N°47: Plan de mejora para el indicador NCF


5.3.8. Indicador N° 08: Número de controles lógicos para garantizar la

continuidad del servicio (NCL)


“Se aplican los controles básicos, en cuanto a la seguridad lógica, no

obstante se identificó (por observación directa) una deficiencia en

cuanto al acceso de archivos compartidos, ya que, desde cualquier

maquina de la universidad que haya iniciado sesión con un usuario de

dominio puede visualizar las carpetas compartidas de cualquier PC

incluyendo las de la OTI, con lo que un usuario puede copiar contenido

de sistemas y base de datos de estos equipos y llevarse información

vital.

Por lo que se recomienda restringir el acceso a estas carpetas, desde

los privilegios de los usuarios del dominio.

Otro control de seguridad extra es encriptar los archivos de vital

importancia de los sistemas, tales como los sistemas de la universidad

y/o Bases de Datos”.(CAPITULO IV: DESARROLLO DE LA PROPUESTA –

4.3.3.6 Evaluación de Controles Lógicos a la Red)






La OTI aplica controles lógicos para evitar el

robo de datos, tales como: Controles para

evitar los accesos no autorizados y una

revisión de estos

La OTI debería también aplicar controles

como encriptación de archivos

importantes, así como controles a accesos

a carpetas compartidas, que como hemos

especificado en la evaluación de este

indicador, cualquier usuario puede

visualizar y realizar una copia de la

información de los equipos de la red, así

como políticas de seguridad del usuario y

sanción a usuarios que hurtan

información. Se propone la creación de

nuevas políticas para regular el acceso a

las carpetas compartidas (Proyecto N°08 –

Anexo 24)

Para mitigar los software maliciosos, la OTI

aplica controles como de contar con

software (Antivirus) de detección de virus y

procedimientos para gestionar estos

software maliciosos.

La OTI debe implementar controles

aplicados al análisis de software adquirido

por la UCV-Piura, así como también de

políticas para la descarga de archivos por

parte de los usuarios de la red.

Tabla N°48: Plan de mejora para el indicador NCL


5.3.9. Indicador N° 09: Nivel de Madurez de la Gestión de Redes de la OTI

(NMGR)


“Se Pudo definir que el Nivel de madurez de la gestión de redes de la

OTI se encuentra en un nivel intermedio entre el Repetible y el Definido,

donde sus procesos son mayormente empíricos, y se maneja una

incipiente documentación de los mismos que le permitirá ir en pos de la

estandarización de los mismos, por lo que se recomienda que la OTI

debe mejorar la forma como se está gestionando los procesos dentro de



ella con los que propone COBIT e identificar las acciones necesarias

para mejorarlos y hacer que aporten al negocio el valor necesario”.

(CAPITULO IV: DESARROLLO DE LA PROPUESTA – 4.3.3.6 Determinar el

Nivel de Madurez de la gestión de Redes de la OTI)

Como se especifico en la evaluación del indicador (Nivel de Madurez de la

Gestión de Redes de la OTI), la OTI se encuentra en un nivel de madurez

intermedio, por lo que debería implementar los controles especificados en los

puntos anteriores y de esa forma mejorar la Gestión de redes y elevar su nivel

de madurez. Lo que implica la aplicación de las propuestas de proyectos

recomendadas (Del Anexo 17 al 24)

5.4. Post-Test

En el punto 5.3 se ha concluido los puntos que obligatoriamente debe contener todo

informe técnico de auditoría, pero, desde el punto de vista de un trabajo de

investigación, sería interesante saber si la aplicación del plan de mejora tendrá un

impacto positivo, sin embargo esto no es posible debido a las restricciones del

tiempo asignado a la investigación (ver Limitaciones de la Investigación en el

apartado 2.5), no obstante, lo anterior no es ninguna limitación para comparar los

resultados de auditoría con la situación deseada si se implementasen las

recomendaciones del plan de mejora, en otras palabras, un supuesto de la situación

de OTI (área de subredes) en un futuro cuando implemente las mejoras, sustentadas

en propuestas de proyectos, para cada indicador evaluado durante el desarrollo de la


Esta situación deseada (que sería un post-test tradicional de implementarse y

evaluarse) cumple, además, la función de servir de referencia para que la subárea de

redes de la OTI establezca metas con el propósito de mejorar las deficiencias

encontradas.

Por esas dos razones hemos creído conveniente presentar el apartado 5.4. Post-

Test.

5.4.1. Indicador N° 01: Número de procesos críticos de negocio no incluidos

en un plan de contingencia. (NPC).

A continuación de muestran los resultados finales de los procesos críticos de

negocio no incluidos en un plan de contingencia, tanto en el Pre-Test como

Post-Test, como se pudo observar en el estudio del indicador N°1 (Número de



procesos críticos de negocio no incluidos en un plan de contingencia. (NPC)),

se encontraron 15 procesos críticos de negocio existentes, de los cuales se

consideran 12 dentro del plan de contingencia y a otros 3 procesos no se

consideran, los cuales son:

Proceso de matrícula a los cursos de computación.

Proceso de matrícula a los cursos de inglés (Centro de idiomas)

Proceso de matrícula a los cursos de actividades integradoras

Realizado el plan de mejora, se procedió a realizar un nuevo análisis (Post-

Test) del indicador, de cual obtuvimos el siguiente resultado y comparaciones:

Análisis N° Procesos no incluidos

Pre-Test 3

Post-Test 0

Tabla N°49: Análisis Pre-Test y Post-Test para el indicador NPC


Gráfico N°19: Análisis Pre-Test y Post-Test para el indicador NPC


0

0.5

1

1.5

2

2.5

3

3.5

Pre-Test Post-Test

Total Procesos No Incluidos

Pre-Test

Post-Test



5.4.2. Indicador N° 02: Porcentaje de incidentes de red resueltos en un tiempo

óptimo (PIR)

Como se observo en el estudio del indicador N°2 (Porcentaje de incidentes de

red resueltos en un tiempo óptimo (PIR)), se encontró que el 81.81% de los

incidentes de red la OTI resuelve en un tiempo óptimo (5.5 Horas). Propuesto

el plan de mejora, se procedió a realizar el un nuevo análisis (Post-Test) al

indicador N°2, del cual se pudo obtener los siguientes resultados y

comparaciones:

Análisis Porcentaje (%)

Pre-Test 81.81

Post-Test 92.55

Tabla N°50: Análisis Pre-Test y Post-Test para el indicador PIR.


Gráfico N°20: Análisis Pre-Test y Post-Test para el indicador PIR


5.4.3. Indicador N° 03: Número promedio de horas perdidas por usuario al

mes, debido a interrupciones a la red. (NHP) En el análisis del indicador N°3 (Número promedio de horas perdidas por

usuario al mes, debido a interrupciones a la red. (NHP)), se encontró que los

76

78

80

82

84

86

88

90

92

94

Pre-Test Post-Test

Porcentaje de Incidentes atendidos en un tiempo óptimo

Pre-Test

Post-Test



usuarios pierden un aproximado de 15 horas (14.990 horas), en donde los

problemas que mayormente afectan al constante servicio por parte de los

usuarios son los problemas con la conectividad.

Implementado el plan de mejora para mitigar las horas perdidas por los

usuarios, se procedió a realizar el un nuevo análisis (Post-Test) al indicador

N°3, del cual se pudo obtener los siguientes resultados y comparaciones:

Análisis Horas Perdidas

Pre-Test 15

Post-Test 7

Tabla N°51: Análisis Pre-Test y Post-Test para el indicador NHP


Gráfico N°21: Análisis Pre-Test y Post-Test para el indicador NHP


5.4.4. Indicador N° 04: Número de controles aplicados a servicios de terceros.

(NCT)

En el análisis del indicador N°4 (Número de controles aplicados a servicios

de terceros. (NCT)), se encontró que la OTI solo aplica 4 controles a servicios

de terceros, cabe recalcar que es el área de Logística quien se encarga del

establecer un contacto directo los servicios brindados por terceros (contratos

0

2

4

6

8

10

12

14

16

Pre-Test Post-Test

Horas perdidas por usuario al mes

Pre-Test

Post-Test



y cumplimiento de estos), mientras que la OTI aplica controles de índole

técnico.

Implementado el plan de mejora para, se procedió a realizar el un nuevo

análisis (Post-Test) al indicador N°4, del cual se pudo obtener los siguientes

resultados y comparaciones:

Análisis N° Controles

Pre-Test 4

Post-Test 6

Tabla N°52: Análisis Pre-Test y Post-Test para el indicador NCT


Gráfico N°22: Análisis Pre-Test y Post-Test para el indicador NCT


5.4.5. Indicador N° 05: Porcentaje de inversión para cubrir los costos en TI

(PIATI)

En el análisis del indicador N°5 (Porcentaje de inversión para cubrir los costos

en TI(PIATI)), se encontró que la OTI solo invierte un 13% del porcentaje que

la Universidad le asigna, lo cual es un porcentaje muy bajo, tal y como se

0

1

2

3

4

5

6

7

Pre-Test Post-Test

Controles aplicados a terceros

Pre-Test

Post-Test



detalla en el análisis del indicador (4.3.3.3 Evaluación de los costos para

cubrir la inversión en TI).




Análisis Porcentaje Inversión en

costos de TI (%)

Pre-Test 13

Post-Test 20

Tabla N°53: Análisis Pre-Test y Post-Test para el indicador PIATI


Gráfico N°23: Análisis Pre-Test y Post-Test para el indicador PIATI



mantenimiento a la red (NMR)

En el análisis del indicador N°6 (Número promedio de veces por mes que se

ha realizado mantenimiento a la red (NMR)), se encontró que la OTI realiza

mantenimiento a la red 7 veces al mes, cabe recalcar que el mantenimiento

0

5

10

15

20

25

Pre-Test Post-Test

Porcentaje invertido en costos de TI (%)

Pre-Test

Post-Test



que se realiza es netamente correctivo (4.3.3.4 Evaluación de la frecuencia de

las tareas de mantenimiento de la Red).




Análisis Número de veces

Pre-Test 7

Post-Test 13

Tabla N°54: Análisis Pre-Test y Post-Test para el indicador NMR


Gráfico N°24: Análisis Pre-Test y Post-Test para el indicador NMR


5.4.7. Indicador N° 07: Número de controles físicos para garantizar la

continuidad del servicio (NCF)

En el análisis del indicador N°7(Número de controles físicos para garantizar la

continuidad del servicio (NCF)), se encontró que la OTI solo aplica 7 controles

físicos a la red (4.3.3.5 Evaluación de Controles Físicos a la Red).

0

2

4

6

8

10

12

14

Pre-Test Post-Test

Veces que se realiza mantenimiento a la Red

Pre-Test

Post-Test






Análisis Número de Controles

Físicos

Pre-Test 7

Post-Test 15

Tabla N°55: Análisis Pre-Test y Post-Test para el indicador NCF


Gráfico N°25: Análisis Pre-Test y Post-Test para el indicador NCF


5.4.8. Indicador N° 08: Número de controles Lógicos para garantizar la

continuidad del servicio (NCL)

En el análisis del indicador N°8(Número de controles lógicos para garantizar

la continuidad del servicio (NCL)), se encontró que la OTI solo aplica 6

controles Lógicos a la red (4.3.3.6 Evaluación de Controles Lógicos a la Red).

0

2

4

6

8

10

12

14

16

Pre-Test Post-Test

Número controles físicos aplicados

Pre-Test

Post-Test






Análisis Número de Controles

Físicos

Pre-Test 6

Post-Test 13

Tabla N°56: Análisis Pre-Test y Post-Test para el indicador NCL


Gráfico N°26: Análisis Pre-Test y Post-Test para el indicador NCF


5.4.9. Indicador N° 09: Nivel de madurez de la gestión de redes de la OTI

(NMGR)

En el análisis del indicador N°9 (Nivel de madurez de la gestión de redes de la

OTI (NMGR)), en cual la OTI se encontraba en un nivel de madurez definido

(3), el cual es un nivel intermedio de madurez (4.3.3.7Determinar el Nivel de

Madurez de la gestión de Redes de la OTI)

0

2

4

6

8

10

12

14

Pre-Test Post-Test

Número controles lógicos aplicados

Pre-Test

Post-Test






Análisis Nivel de Madurez

Pre-Test 3

Post-Test 4

Tabla N°57: Análisis Pre-Test y Post-Test para el indicador NMGR


Gráfico N°27: Análisis Pre-Test y Post-Test para el indicador NMGR


0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

Pre-Test Post-Test

Nivel de Madurez

Pre-Test

Post-Test



CAPÍTULO VI

CONCLUSIONES Y RECOMENDACIONES



6.1. Conclusiones

De acuerdo a los resultados obtenidos en el indicador Nº04: Número de

controles aplicados a terceros (NCT), el indicador Nº06: Número

promedio de veces por mes que se ha realizado mantenimiento a la red

(NMR), el indicador Nº07: Número de controles físicos para garantizar la

continuidad del servicio (NCF) y el indicador Nº08: Número de controles

lógicos para garantizar la continuidad del servicio (NCL); se puede

apreciar que la Oficina de Tecnologías de Información (OTI) sí aplica

controles internos a la red de la universidad; estos controles se caracterizan

por implementar medidas de seguridad básica (controles físicos y lógicos)

que necesitan mejorar, sobretodo, en el aspecto de controles de acceso al

datacenter (controles físicos) y controles para el acceso de archivos

compartidos (controles lógicos); por ser estrictamente técnicos (controles a

terceros); y por ser, en su mayor parte, correctivos (controles asociados con

las tareas de mantenimiento, que pueden ser lógicos y físicos).

De acuerdo a los resultados obtenidos en el indicador Nº03: Número

promedio de horas perdidas por usuario al mes, debido a interrupciones

de red (NHP) y el indicador Nº05: Porcentaje de inversión para cubrir los

costos en TI(PIATI); se puede concluir que la Oficina de Tecnologías de

Información (OTI) sí alinea la gestión de la red con las metas de la

universidad, al existir un proceso definido de manejo de interrupciones, donde

se resalta el uso de una bitácora y el escalamiento de incidentes; y, también,

al destinar parte de su presupuesto para cubrir los costos en TI; no obstante

se han encontrado ciertas deficiencias que deben mejorarse, destacando la

necesidad de hacer un seguimiento detallado de los incidentes más

frecuentes registrados; y la necesidad de destinar una mayor parte del

presupuesto para invertir en la modernización de los equipos que forman

parte de la infraestructura de la red.

De acuerdo a los resultados obtenidos en el indicador Nº02: Porcentaje de

incidentes de red resueltos en un tiempo óptimo (PIR), el indicador N°07:

Número de controles físicos para garantizar la continuidad del servicio

(NCF) y el indicador N°08: Número de controles lógicos para garantizar la

continuidad del servicio (NCL) se concluye que OTI sí reporta los controles

y mide el desempeño de la gestión de la red, mediante el uso de una bitácora

de incidentes donde se consignan datos como la persona responsable, la

subárea que atendió, el área que solicitó la atención y el tiempo de atención,



sin embargo, existen deficiencias como es el caso de los problemas con los

anexos (teléfonos IP), que, pese a ser uno de los más frecuentes es uno de

los que lleva más tiempo en resolverse (10.98 h) a pesar que el tiempo

óptimo se estima en media jornada de trabajo (5.5 h); además algunos

controles (físicos y lógicos) necesitan mejorar para brindar mayor seguridad a

los activos de información(tal como se detalló en la conclusión 1).

De acuerdo a los resultados obtenidos en el indicador N°01: Número de

procesos críticos de negocio no incluidos en un plan de contingencia

(NPC) y el indicador N°09: Nivel de madurez de la gestión de redes de la

OTI (NMGR) se concluye que OTI sí aplica algunas prácticas de gestión de TI

recomendadas por los estándares de buenas prácticas, como es el caso de

COBIT, porque, el área cuenta un plan de contingencia y, además se ubica

en un nivel intermedio entre el nivel 2 REPETIBLE y un nivel 3 DEFINIDO,

pues OTI utiliza procesos que, en su mayoría son empíricos y que no están

documentados, pero se ha comprobado que ha establecido algunas prácticas

recomendadas por los estándares como el registro de incidentes o el

constante monitoreo de la red, y, además, cuenta con ciertos documentos

como su plan de contingencia, mapa topológico de la red, un instructivo de

funciones, etc. los cuales contienen varios aspectos que agregar, corregir y

mejorar, como la necesidad de revisar, mejorar, ampliar el plan de

contingencia del plan entre otras observaciones comentadas durante el

desarrollo de la auditoría, los resultados y las tres primeras conclusiones.

6.2. Contrastación de Hipótesis

Habiendo establecido la hipótesis “La aplicación de una auditoría basada en COBIT

permitirá determinar el nivel de madurez de la gestión de redes, comunicaciones y

servidores aplicada por la Oficina de Tecnologías de Información (OTI) a la red de la

Universidad César Vallejo – Piura”, se ha obtenido un nivel de madurez intermedio

entre el 2 REPETIBLE y el nivel 3 DEFINIDO, resultado que ha sido con los

hallazgos encontrados en cada indicador considerado, junto con las

recomendaciones expuestas para mejorar la situación actual, es posible afirmar que

la hipótesis se PRUEBA TOTALMENTE,

6.3. Recomendaciones

Para los hallazgos de auditoría del indicador Nº04: Número de controles

aplicados a terceros (NCT), el indicador Nº06: Número promedio de veces

por mes que se ha realizado mantenimiento a la red (NMR), el indicador



Nº07: Número de controles físicos para garantizar la continuidad del

servicio (NCF)y el indicador Nº08: Número de controles lógicos para

garantizar la continuidad del servicio (NCL), se recomienda que OTI, en

primer lugar, cuente con un sistema informático de gestión de documentos

(Proyecto N°04 – Anexo 20) que le permita manejar una copia de los

documentos mercantiles para realizar un control de terceros que vaya más

allá del punto de vista técnico; además, el área debe incidir en realizar tareas

de mantenimiento preventivo (Proyecto N°06 – Anexo 22) en el transcurso del

año 2012; por último, se recomienda que OTI mejore tanto sus controles

lógicos como físicos mediante la implementación de un plan de acceso al

datacenter mediante la implementación de un plan de mejoramiento de la

seguridad de acceso (Proyecto N°07 – Anexo 23) y, también, con la creación

de nuevas políticas de seguridad (Proyecto N°08 – Anexo 24) que regulen el

acceso a carpetas compartidas.

Para los hallazgos de auditoría del indicador Nº03: Número promedio de

horas perdidas por usuario al mes, debido a interrupciones de red (NHP)

y el indicador Nº05: Porcentaje de inversión para cubrir los costos en

TI(PIATI), se recomienda que OTI revise las interrupciones más frecuentes y

organice un plan de monitoreo y mejora (Proyecto N°02 – Anexo 18); además,

OTI debe realizar un plan de actualización de equipos para modernizar la

infraestructura de red de la universidad y elevar los niveles de seguridad

(Proyecto N°05 – Anexo 23), todo esto para corregir estas deficiencias y

mejorar el servicio para respaldar los objetivos y metas de la universidad.

Para los hallazgos de auditoría del indicador Nº02: Porcentaje de incidentes

de red resueltos en un tiempo óptimo (PIR), el indicador N°07: Número de

controles físicos para garantizar la continuidad del servicio (NCF) y el

indicador N°08: Número de controles lógicos para garantizar la

continuidad del servicio (NCL), se recomienda que OTI automatice la

gestión de incidentes mediante la ayuda de un sistema informático, el cual no

sólo le permitirá registrar sino realizar un análisis de incidentes a partir de los

registros históricos (Proyecto N°03 – Anexo 19), lo cual ayudará a mejorar,

también las medidas de control interno para la red de la universidad.

Para los hallazgos de auditoría del indicador N°01: Número de procesos

críticos de negocio no incluidos en un plan de contingencia (NPC) y el

indicador N°09: Nivel de madurez de la gestión de redes de la OTI



(NMGR), se recomienda que OTI realice una revisión y mejora de la

propuesta de plan de contingencia con el que cuenta para obtener un

documento formal y que pueda aplicarse. (Proyecto N°01 – Anexo 17);

además, OTI debe aspirar a un nivel de madurez ADMINISTRADO en el cual

los procesos están en constante mejora y se aplican buenas prácticas con las

cuales se disminuye el nivel de riesgo, aumentando, al mismo tiempo, el nivel

de madurez.



CAPÍTULO VII

REFERENCIAS BIBLIOGRÁFICAS



ALFARO Paredes, Emigdio Antonio. (2008). Metodología para la Auditoría

Integral de la Gestión de la Tecnología de Información. Recuperado el 15 de

abril del 2011:

http://tesis.pucp.edu.pe/repositorio/bitstream/handle/123456789/1048/ALFARO_

PAREDES_EMIGDIO_AUDITORIA_GESTION_TECNOLOGIA_INFORMACION.

pdf?sequence=1

ÁLVAREZ Amat. Gestiópolis (2006). El control interno en la economía

empresarial. Recuperado el 15 de junio del 2011:

http://www.gestiopolis.com/recursos6/Docs/Eco/contrinter.htm.

Áreas funcionales de gestión (1998). Recuperado el 15 de junio del 2011:

http://www.edicionsupc.es/ftppublic/pdfmostra/TL01304M.pdf.

Auditoría. Recuperado el 15 de junio del 2011:

http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&url=http

%3A%2F%2Fwww.itescam.edu.mx%2Fprincipal%2Fsylabus%2Ffpdb%2Frecurs

os%2Fr29412.PPT&rct=j&q=Es%20el%20conjunto%20de%20t%C3%A9cnicas%

2C%20actividades%20y%20procedimientos%2C%20destinados%20a%20analiz

ar%2C%20evaluar%2C%20verificar%20y%20recomendar%20en%20asuntos%2

0relativos%20a%20la%20planificaci%C3%B3n%2C&ei=OKz7Ta6tJcbw0gG6qYy

eAw&usg=AFQjCNECy8yibkMJSsyC30lt8-hS1aycYQ&cad=rja

http://www.ctmsoftware.es/wp/servicios-2/auditoria-informatica/.

BASALDÚA Álvarez, Luis Daniel (2005). Seguridad en Informática. Recuperado

el 15 de abril del 2011: http:5//www.bib.uia.mx/tesis/pdf/014663/014663.pdf

BRAVO Cervantes, Miguel (1995). Auditoría del Sistema Informático. (1° Ed.).

Edit. Manuel Chahu. Perú.

CABRERO García, J. & Richart Martínez, M. (2011). Diseño de la Investigación.

Recuperado el 23 de junio del 2011:

http://www.aniorte-nic.net/apunt_metod_investigac4_4.htm.

Comité Ejecutivo de COBIT &Information Systems Audit and Control Information

(1998). [version electrónica]. COBIT. Directrices de Auditoría



ECHENIQUE García, José (2001). Auditoría en Informática. (2°. Ed). McGraw

Hill. México

FABBRI, María Soledad. Las técnicas de observación: la observación.


http://www.fhumyar.unr.edu.ar/escuelas/3/materiales%20de%20catedras/trabajo

%20de%20campo/solefabri1.htm

GARIBALDI, J. & Mahdi, A.E. IEEE (1998). Gestión de Red Proactiva usando

Minería de Datos. Recuperado el 15 de junio del 2011:

http://tonet.0catch.com/doc/datamine1.pdf

GÓMEZ, G. Gestiópolis. (2001). Control Interno. Una responsabilidad de todos

los integrantes de la organización empresarial. Recuperado el 16 de junio del

2011:

http://www.gestiopolis.com/canales/financiera/articulos/no11/controlinterno.htm.

HERNANDO Roberto (2001). Gestión de red. Recuperado el 14 de junio del

2011: http://www.rhernando.net/modules/tutorials/doc/redes/Gredes.html

ISO/IEC. (2005). [versión electrónica]. Estándar Internacional 27001.

ISO/IEC. (2005). [versión electrónica]. Estándar Internacional 27002.

IT Governance Institute. (2007). [versión electrónica]. COBIT 4.1.

IT Governance Institute (2008). [versión electrónica]. Alineando COBIT, ITIL V3 e

ISO/IEC 27002 en beneficio del negocio. Un reporte para gestión del ITGI y la

OGC.

Los Nuevos Conceptos de Control Interno. Recuperado el 17 de junio del 2011:

http://www.auditoria.uady.mx/arts/INFORME COSO (RESUMEN).pdf

MATUTE Macías, María del Carmen & QUISPE Cando (2006), Tránsito del

Rosario. Auditoría de la Gestión de Seguridad en la Red de Datos del Swissôtel

basada en COBIT. Recuperado el 15 de abril del 2011:

http://biblioteca.epn.edu.ec/catalogo/fulltext/CD-0049.pdf



MAKAR, Carmina. (2006).Guía de Observación. Recuperado el 15 de junio:

http://mail.udgvirtual.udg.mx/biblioteca/bitstream/20050101/1290/1/Guia_de_obs

ervaci%C3%B3n.pdf

MAYOL Arnao, Reinaldo N (2006). Modelo para la Auditoría de la Seguridad

Informática en la Red de Datos de la Universidad de los Andes. Recuperado el

16 de abril del 2011:

http://tesis.ula.ve/postgrado/tde_busca/arquivo.php?codArquivo=114

MEJÍA Herrera, Luis Fernando. (2009). Qué es Gestión y monitoreo de red.


http://servidorespararedes.blogspot.com/2009/01/que-es-aplicaciones-web.html

MENDOZA, M & Toledo, A. (2010). Gestión de Redes de Telecomunicaciones.


http://www.slideboom.com/presentations/84669/Gesti%C3%B3n-de-Redes-de-

Telecomunicaciones.

MUÑOZ Alemán, Jonathan. Auditoría de Redes. Recuperado el 18 de junio del

2011: http://www.slideshare.net/GeekMelomano/auditora-de-redes.

MIRANDA Guevara, E. Auditoría de Redes. Recuperado el 18 de junio del 2011:

http://www.slideshare.net/GeekMelomano/auditora-de-redes

MORALES Lizarazo. E. La Recolección de Datos. Recuperado el 23 de junio del

2011: http://www.slideshare.net/edimor72/la-recoleccin-de-datos-1384547

OROZCO P. (2010). Gestión y Organización de Sistemas y Redes de

Comunicaciones en el Departamento de T.I. Recuperado el 16 de junio del 2011:

http://www.slideshare.net/pakus/gestion-de-red

PIATTINI Velthuis, Mario (2008). Auditoría de Tecnologías y Sistemas de

Información. (1° Ed.). Alfaomega Grupo Editor SA, México DF.

PIATTINI Velthuis, Mario (2001). Auditoría Informática: Un Enfoque Práctico (2°

Ed.). Alfaomega Grupo Editor SA, Bogotá, Colombia

QUIROZ, Víctor. Fichas Bibliográficas. Recuperado el 20 de junio del 2011:

http://es.scribd.com/doc/44263841/FICHAS-BIBLIOGRAFICAS



Resumen de Características COBIT. (2010). Recuperado el 28 de junio del 2011:

http://www.buenastareas.com/ensayos/Resumen-De-Caracteristicas-

Cobit/382208.html.

REUERO, Eusebio (2010). Revisión Bibliográfica. Recuperado el 28 de junio del

2011: http://wwff.thespacer.net/blog/revision-bibliografica/

RIEGA Reto, Marco Antonio (2010). Auditoría basada en ISO/IEC 17799 para la

gestión de seguridad de las T.I en la UCV-Piura.

SÁNCHEZ Gómez, A. R. (2005). Fundamentos teóricos de auditoría vinculados a

temas de calidad. Recuperado el 17 de junio del 2011:

http://www.gestiopolis.com/canales5/fin/funteadu.htm

Tech, V. Introducción a Internet y las redes. (2001). Recuperado el 16 de junio

del 2011: http://www.mailxmail.com/curso-introduccion-internet-redes/que-es-red

Técnicas de Investigación Social- Concepto de población y muestra. Recuperado

el 20 de julio del 2011:

http://www.edukanda.es/mediatecaweb/data/zip/940/page_07.htm

UGEL Garrido, E. Técnicas de Recolección de Datos. Recuperado el 23 de junio

del 2011:

http://www.ucla.edu.ve/dmedicin/departamentos/medicinapreventivasocial/SEB/i

nvestigacion/recoleccion.pdf

Universidad de León. (2004). Auditoría Informática. Recuperado el 07 de junio

del 2011: http://www.oocities.org/mx/alexbg_udl/AuditoriaInformatica.pdf.

VALENCIA del Toro, J. Generación de publicaciones creativas según el estilo

APA. [versión electrónica]. Adoptando los modelos de control interno COSO y

COBIT.

VELAZQUEZ Friederichsen, E (2008). ITIL vs COBIT. Recuperado el 17 de junio

del 2011: http://www.sg.com.mx/content/view/720/99999999/

VILLENA Aguilar, Moisés Antonio (2006). Sistema de Gestión de Seguridad de

Información para una Institución Financiera. Recuperado el 18 de abril del 2011:



http://tesis.pucp.edu.pe/repositorio/bitstream/handle/123456789/362/VILLENA_M

OIS%C3%89S_SISTEMA_DE%20GESTI%C3%93N_DE_SEGURIDAD_DE_INF

ORMACI%C3%93N_PARA_UNA_INSTITUCI%C3%93N_FINANCIERA.pdf?seq

uence=1

VICENTE, C. Universidad de Oregón. Introducción a la Gestión de Redes.


http://lacnic.net/documentos/lacnicx/Intro_Gestion_Redes.pdf



ANEXOS



ANEXO 1

CUADRO DE CONSISTENCIA DEL PROYECTO

Título del Proyecto Evaluación de la Gestión en Redes, Comunicaciones y Servidores en la Oficina de Tecnologías de Información de la Universidad César Vallejo – Piura mediante la aplicación de una Auditoría Informática basada en COBIT.

Localidad o institución donde se realiza la investigación

Universidad César Vallejo S.A.C – Filial Piura

Pregunta General ¿De qué manera la aplicación de una auditoria informática basada en COBIT permitirá la evaluación de la gestión

en redes, comunicaciones y servidores en la Universidad César Vallejo – Piura?

Preguntas de Investigación ¿En qué momentos y circunstancias la Oficina de Tecnologías de Información aplica controles internos a la red de la universidad?

¿De qué manera la Oficina de Tecnologías de Información alinea la gestión de la red con las metas de la universidad?

¿En qué momento la Oficina de Tecnologías de Información reporta los riesgos, el control, el cumplimiento y el desempeño de la gestión de la red de la universidad?

¿De qué manera la Oficina de Tecnologías de Información basa su gestión de la red de la universidad con el cumplimiento de un estándar de buenas prácticas como COBIT?

Objetivo General Evaluar de la gestión en redes, comunicaciones y servidores en la Universidad César Vallejo – Piura

Objetivos Específicos Evaluar la efectividad de la aplicación de controles internos a la red de la universidad.

Evaluar el alineamiento de la gestión de redes con las metas de la universidad.

Analizar el riesgo inherente a la gestión de la red de la universidad.

Determinar el nivel de madurez de la gestión de la red de la universidad de acuerdo a COBIT.

Hipótesis La aplicación de una auditoría basada en COBIT permitirá determinar el nivel de madurez de la gestión de redes,

comunicaciones y servidores aplicada por la Oficina de Tecnologías de Información (OTI) a la red de la

Universidad César Vallejo – Piura.

Variables e Indicadores Variable Independiente: Auditoría informática

Variable Dependiente: La gestión en redes, comunicaciones y servidores de la Oficina de Tecnologías de Información de la UCV – Piura.

Variable Interviniente: Marco de trabajo COBIT. Indicadores 1. Número de procesos críticos de negocio no incluidos en un plan de contingencia. (NPC)

2. Porcentaje de incidentes de red resueltos en el tiempo acordado (PIR) 3. Número de horas perdidas por usuario al mes, debido a interrupciones a la red. (NHP)



4. Número de controles aplicados a servicios de terceros. (NCT) 5. Porcentaje de inversión en actualización de TI (PIATI) 6. Número de veces por año que se ha realizado mantenimiento a la red.(NMR) 7. Número de controles físicos para garantizar la continuidad del servicio (NCF) 8. Número de controles lógicos para garantizar la continuidad del servicio (NCL) 9. Nivel de madurez de la gestión de redes de la OTI (NMGR)

Técnicas e Instrumentos (Los números enumeran los indicadores, la primera columna señala las técnicas y la segunda, los instrumentos)

1. Entrevista, Revisión Bibliográfica Guía de Entrevista 02, Fichas Bibliográficas 2. Entrevista, Revisión Bibliográfica Guía de Entrevista 03, Fichas Bibliográficas 3. Entrevista, Revisión Bibliográfica Guía de Entrevista 03, Fichas Bibliográficas 4. Entrevista Guía de Entrevista 07 5. Revisión Bibliográfica Fichas Bibliográficas 6. Entrevista, Observación Guía de Entrevista 04, Guía de Observación 01 7. Entrevista, Observación Guía de Entrevista 05, Guía de Observación 02 8. Entrevista, Observación Guía de Entrevista 06, Guía de Observación 03 9. Encuestas Cuestionario 01, Cuestionario 02, Cuestionario 03, Cuestionario 04

Tipo de Estudio Paradigma: Cuantitativo

Función: Aplicada

Tipo: Cuasi-experimental

Diseño del Estudio Se toma un solo grupo al que se le aplicará el pre-test y el post-test (modelo de marco lógico)

Población y Muestra La muestra se considera igual a la población (el grupo de estudio es muy pequeño) quienes lo conforman son el personal que labora en la OTI de la UCV- Piura.



ANEXO 2

ENCUESTA: DOCUMENTACIÓN MANEJADA POR LA OFICINA DE

TECNOLOGÍAS DE LA INFORMACIÓN (OTI) DE LA UCV - PIURA



ANEXO 3

SOLICITUD 01: FACILIDADES PARA REVISAR DOCUMENTACIÓN



ANEXO 4

SOLICITUD 02: FACILIDADES PARA REVISAR REGISTROS DE INCIDENTES



ANEXO 5

FICHAS BIBLIOGRÁFICAS



ANEXO 6

GUÍA DE ENTREVISTA N°01: APLICACIÓN DE POLÍTICAS Y

PROCEDIMIENTOS DE SEGURIDAD EN EL ÁREA DE REDES DE LA OFICINA

DE TECNOLOGÍAS DE INFORMACIÓN



ANEXO 7

GUÍA DE ENTREVISTA N°02: APLICACIÓN DE GESTIÓN DE RIESGOS Y

PLAN DE CONTINGENCIA EN EL ÁREA DE REDES DE LA OFICINA DE

TECNOLOGÍAS DE INFORMACIÓN



ANEXO 8

GUÍA DE ENTREVISTA N°03: EVALUACIÓN DE LA ATENCIÓN DE

INCIDENTES EN LA RED



ANEXO 9

GUÍA DE ENTREVISTA N°04: MANTENIMIENTO A LA RED DE LA UNIVERSIDAD



ANEXO 10

GUÍA DE ENTREVISTA N°05: CONTROLES FÍSICOS IMPLEMENTADOS EN

LA RED DE LA UNIVERSIDAD



ANEXO 11

GUÍA DE ENTREVISTA N°06: CONTROLES LÓGICOS IMPLEMENTADOS EN

LA RED DE LA UNIVERSIDAD



ANEXO 12

GUÍA DE ENTREVISTA N°07: EVALUACIÓN DE CONTROLES APLICADOS A

TERCEROS



ANEXO 13

CUESTIONARIO Nº01: GESTIÓN DE RIESGOS DE RED



ANEXO 14

CUESTIONARIO Nº02: MANTENIMIENTO DE LA RED



ANEXO 15

CUESTIONARIO Nº03: CUESTIONARIO Nº04: INVERSIÓN EN TI (REDES)



ANEXO 16

PROYECTO Nº01

I. DENOMINACIÓN

“ELABORACIÓN DEL PLAN DE CONTINGENCIA PARA LA OFICINA DE

TECNOLOGÍAS DE INFORMACIÓN”

II. RESPONSABLES

Jefe de la Oficina de Tecnologías de Información (OTI)

Representantes de las tres subáreas de OTI: Subárea de Desarrollo,

subárea de soporte técnico y subárea de redes y comunicaciones.

III. FUNDAMENTACIÓN

Actualmente la Oficina de Tecnologías de Información cuenta con una propuesta

para plan de contingencia producto de una tesis de pregrado desarrollada en el

2010, no obstante no es un documento formal que ha sido revisado y aceptado

por el toda el área, aprobado tanto por el jefe de la OTI como por las autoridades

de la Universidad.

Este es el motivo por el cual es necesaria una revisión de la propuesta de plan de

contingencia para la corrección del documento, su ampliación y su aceptación

final.

IV. OBJETIVOS

a) General

Obtener un documento formal de plan de contingencia revisado, ampliado

y aceptado por la Oficina de Tecnologías de Información (OTI)

b) Específicos

Revisar el documento de propuesta de plan de contingencia para

corregirlo y ampliarlo.

Revisar y aprobar la metodología de gestión de riesgos propuesta

Contar con un plan de contingencia que contenga las medidas de

contingencia antes, durante y después de un suceso y que involucre

las tres subáreas de la OTI



V. DESCRIPCIÓN

Con el objetivo de obtener un documento que refleje la gestión de riesgos del

área, se propone este proyecto de revisión y aprobación de la propuesta de plan

de contingencia con la que cuenta la Oficina de Tecnologías de Información. Esta

propuesta fue un trabajo de tesis de pregrado desarrollado en el 2010, el cual

propone un conjunto de acciones de contingencia para mitigar riesgos usando una

metodología del INEI. Este trabajo debe ser revisado y ampliado debido a un

conjunto de carencias que deben tenerse en cuenta, y que han sido detectadas

durante la realización de la auditoría informática en el 2011 entre los que

destacan.

Revisión de los procesos críticos de la universidad e inclusión, en el plan,

de los procesos que no se están considerando.

Documentación de los procedimientos críticos de las subáreas de soporte

y redes, que no están considerados.

Actualización del orden de atención de áreas por prioridad, en la auditoría

se encontró que el orden (propuesto por el documento) difería del criterio

tomado en la práctica.

Una vez revisado y ampliado estos aspectos, el documento debe ser aprobado

por las subáreas, luego, por el jefe de la OTI y, por último por las autoridades de la

universidad.

VI. METAS

Documentar los 10 procedimientos críticos aplicados al área de redes y

telecomunicaciones

Considerar este proyecto en el plan operativo del 2012.

Aprobar el plan de contingencia definitivo en el transcurso del 2012

VII. DURACIÓN

La fecha de inicio y finalización deben ser establecidos a criterio de la Oficina de

Tecnologías de Información de acuerdo al plan operativo establecido.

VIII. ORGANIZACIÓN



Conformación de una comisión revisora de la propuesta de plan de

contingencia.

Planificación de las tareas y actividades

Reuniones de la comisión para la revisión de la propuesta

Aprobación de la propuesta junto a las mejoras acordadas

Redacción de un documento formal de plan de contingencia

Aprobación del documento por parte de las tres subáreas, el jefe de OTI y

las autoridades de la universidad

Capacitación al personal de OTI de las medidas de contingencia

consideradas en el plan definitivo.

IX. PRESUPUESTO

El presupuesto lo determinará la jefatura de la OTI en conjunto con las tres

subáreas.

X. FUENTE DE FINANCIAMIENTO

La fuente de financiamiento proviene del presupuesto anual asignado a OTI.



ANEXO 17

PROYECTO Nº02

I. DENOMINACIÓN

“PLAN DE MONITOREO Y MEJORA DEL SERVICIO DE LA RED DE LA

UNIVERSIDAD CÉSAR VALLEJO - PIURA ”

II. RESPONSABLES


Jefe de la Subárea de Redes y Comunicaciones (Administrador de la Red)


Producto de la auditoría informática a redes comunicaciones y servidores que se

realizó en la Universidad César Vallejo – Piura se encontraron incidentes en la red

de la universidad que ya alcanzan el rango de problemas por su alta frecuencia

(Auditoría Informática a la OTI basada COBIT, 2011) los cuales deben mitigarse

para mejorar la disponibilidad del servicio de la red de la universidad.

IV. OBJETIVOS

a) General

Elaborar un plan de monitoreo y mejora del servicio de la red de la

Universidad César Vallejo para perfeccionar la calidad de la disponibilidad

de servicio de la red del campus.

b) Específicos

Establecer un procedimiento de análisis de incidentes para establecer

tendencias por ocurrencia de incidentes.

Contar con medidas específicas de mejora para cada incidente o

interrupción frecuente en la red.

Establecer un procedimiento constante de incidentes más comunes de

la red y que pueden ser potencialmente peligrosos.

V. DESCRIPCIÓN



Con el objetivo de mejorar la calidad del servicio de la red de la universidad, se ha

visto necesario la creación de un plan de monitoreo y mejora el cual debe

considerar dos aspectos fundamentales.

Mitigar el impacto de los incidentes más frecuentes identificados(mejora

del servicio) en la auditoría informática basada en COBIT realizada el

2011.

Establecer un plan de monitoreo para identificar incidentes más o menos

frecuentes, mediante revisiones de los registros de bitácora en conjunto

con el monitoreo constante a la red.

VI. METAS

Analizar y mitigar los dos incidentes más frecuentes identificados durante

la última auditoría informática (falta de conexión de internet y problemas

con los anexos)


VII. DURACIÓN



VIII. ORGANIZACIÓN

Conformación de una comisión para la elaboración del plan de

mantenimiento y mejora

Revisión del informe de auditoría (auditoría informática 2011)

Revisión de la bitácora de atenciones del área

Determinar medidas para mejorar el servicio teniendo en cuenta los

incidentes más frecuentes.

Definir un plan de monitoreo de los incidentes más frecuentes identificados

Determinar un equipo para que realice las tareas de monitoreo y mejora

Realización de reuniones periódicas para revisar los resultados.

IX. PRESUPUESTO



El presupuesto lo determinará la jefatura de la OTI en conjunto con las tres

subáreas.





ANEXO 18

PROYECTO Nº03

I. DENOMINACIÓN

“SISTEMA DE INFORMACIÓN PARA LA GESTIÓN DE INCIDENTES DE TI

PARA LA OFICINA DE TECNOLOGÍAS DE INFORMACIÓN”

II. RESPONSABLES





realizó a la Oficina de Tecnologías de Información (OTI) de la Universidad César

Vallejo – Piura se encontró que el área realiza el registro de incidentes de manera

manual usando planillas de Excel, registros que, luego, son almacenados sin que

se realice un análisis posterior de los incidentes lo que podría servir para construir

una base de conocimientos de incidentes más comunes registrados, por tal motivo

se propone la creación de un sistema informático para automatizar el proceso de

análisis y gestión de incidentes facilitando las tareas a las personas que laboran

en la OTI.

IV. OBJETIVOS

a) General

Elaborar un sistema informático que permita automatizar la gestión de

incidentes

b) Específicos

Elaborar un sistema informático que permita registrar los incidentes de

TI.

Elaborar un sistema informático que permita reportar los incidentes de

TI e imprimir estos reportes.

Elaborar un sistema informático que permita realizar un análisis de

tendencia de los incidentes registrados.



V. DESCRIPCIÓN

Con el objetivo de mejorar la gestión de incidentes de la OTI, se propone el

desarrollo de un sistema informático el cual permitirá lo siguiente:

Registrar los incidentes considerando: Denominación estándar de

incidente, área que solicita atención, responsable que solución el

incidente, subárea que atendió el incidente, hora de llamada al help-desk,

duración de solución de incidente.

Reportar los incidentes atendidos por fechas, por personas (que

atendieron los incidentes) o por subáreas.

Clasificar los incidentes por frecuencia de ocurrencia

VI. METAS

Generar por lo menos cuatro tipos de reportes: Reporte por subárea,

reporte por fechas, reporte por persona y reporte por frecuencia de

ocurrencia.


VII. DURACIÓN



VIII. ORGANIZACIÓN

Conformación de un equipo de desarrollo para el desarrollo del proyecto

Estudiar los tipos de incidentes registrados en la bitácora de atenciones de

OTI

Definir una denominación estándar para los incidentes registrados.

Toma de requerimientos para el proyecto.

Establecer roles dentro del equipo de desarrollo.

Creación de la base de datos y el diagrama de clases

Codificación y pruebas



Integración y presentación del software

Capacitación del manejo del software a todos los trabajadores del área.

IX. PRESUPUESTO

El presupuesto lo determinará la jefatura de la OTI en conjunto con la subárea de

desarrollo





ANEXO 19

PROYECTO Nº04

I. DENOMINACIÓN

“SISTEMA INFORMÁTICO PARA LA GESTIÓN DE DOCUMENTOS

COMERCIALES”

II. RESPONSABLES






Vallejo – Piura se encontró que el área no maneja una copia de los documentos

mercantiles (facturas, boletas, órdenes de compra) que maneja el área de

Logística con los cuales realiza un control a los proveedores de equipos de redes

y comunicaciones, de acuerdo a las recomendaciones emitidas en la última

auditoría informática (2011), es necesario que la OTI cuente con una copia de

estos documentos para controlar más de cerca el proceso de compra y venta de

equipos y que, además estos documentos sean gestionados mediante un sistema

informático

IV. OBJETIVOS

a) General

Elaborar un sistema informático que permita gestionar documentos

comerciales.

b) Específicos

Desarrollar un sistema informático que permita archivar documentos

mercantiles tales como: facturas, órdenes de compra, cotizaciones

Desarrollar un sistema informático que permita realizar seguimiento a

los documentos archivados



Desarrollar un sistema informático que permita el trabajo conjunto

entre OTI y el área de Logística en materia de control de terceros

(proveedores de equipos y servicios de TI).

V. DESCRIPCIÓN

Con el objetivo de mejorar el control a terceros, se propone crear un sistema de

gestión de documentos que le permitirá a OTI y a Logística poder trabajar en

conjunto con el control a terceros en lo que respecta a TI. Dicho sistema permitirá:

Archivar documentos mercantiles (archivos escaneados)

Filtrar documentos mercantiles por tipo de documento (facturas, órdenes

de compra, cotizaciones, contratos)

Rastrear un documento determinado para verificar si el proveedor cumple

con las condiciones del contrato.

VI. METAS

Aumentar el grado de participación de OTI (control de terceros de TI) en

un 50%


VII. DURACIÓN



VIII. ORGANIZACIÓN

Conformación de un equipo de desarrollo para el desarrollo del proyecto

Presentación formal de la propuesta al área Logística

Coordinar con el área de Logística para definir el alcance del proyecto.

Toma de requerimientos para el proyecto.

Establecer roles dentro del equipo de desarrollo.

Creación de la base de datos y el diagrama de clases

Codificación y pruebas



Integración y presentación del software

Capacitación del manejo del software al área de Logística y a la asistente

de OTI

IX. PRESUPUESTO


desarrollo y el área de Logística





ANEXO 20

PROYECTO Nº05

I. DENOMINACIÓN

“PLAN DE ACTUALIZACIÓN DE EQUIPOS QUE FORMAN LA

INFRAESTRUCTURA DE LA RED DE LA UNIVERSIDAD CÉSAR VALLEJO -

PIURA”

II. RESPONSABLES


Subárea de Redes y Comunicaciones




Vallejo – Piura se encontró que el área no ha invertido en actualizar algunos

equipos de redes y comunicaciones, por lo que se detectó la necesidad de crear

un plan de actualización para aumentar la inversión en equipos de comunicación.

IV. OBJETIVOS

a) General

Elaborar un plan de actualización de equipos que conforman la

infraestructura de red de la universidad.

b) Específicos

Renovar los equipos de comunicaciones más antiguos

Mejorar el servicio de TI de la universidad

V. DESCRIPCIÓN

Con el objetivo de actualizar los equipos de redes y comunicaciones se plantea la

creación de un plan de mejora en el cual se evaluarán los equipos teniendo en

cuenta dos criterios:

Equipos que por su antigüedad requieren su reemplazo inmediato para

prevenir fallas futuras.



Equipos que, se cree conveniente, reemplazarlos por otros que ofrecen

mayores prestaciones que los existentes.

VI. METAS


Reemplazar, por lo menos el 25% de equipos (de red) antiguos

Cumplir con los objetivos del plan al finalizar el 2012

VII. DURACIÓN



VIII. ORGANIZACIÓN

Formación de una comisión para la elaboración, seguimiento y

cumplimiento del plan.

Revisión de los equipos de redes y comunicaciones (durante las tareas de

mantenimiento de equipos o durante tareas de revisión de equipos)

Comunicar al área de Logística para coordinar la compra de equipos

Formación de una comisión de OTI para la supervisión de la compra de los

equipos.

Instalación y configuración de los equipos instalados.

IX. PRESUPUESTO


redes.





ANEXO 21

PROYECTO Nº06

I. DENOMINACIÓN

“PLAN DE ACTIVIDADES DE MANTENIMIENTO PREVENTIVO PARA LA RED

DE LA UNIVERSIDAD CÉSAR VALLEJO - PIURA”

II. RESPONSABLES



Subárea de Soporte Técnico




Vallejo – Piura se encontró que las tareas de mantenimiento preventivo son

mínimas respecto a las tareas de mantenimiento correctivo, por lo que se

pretende mejorar esta situación mediante la realización de un plan que programe

las tareas de mantenimiento preventivo durante un año.

IV. OBJETIVOS

a) General

Elaborar un plan de actividades de mantenimiento preventivo para la red

de la Universidad César Vallejo

b) Específicos

Elaborar un cronograma de actividades de mantenimiento preventivo

para un año.

Encontrar equipos que necesitan ser reemplazados.

Definir medidas para mitigar el riesgo existente en las tareas de

mantenimiento.

V. DESCRIPCIÓN



Con el objetivo de prevenir errores futuros es conveniente darle prioridad a tareas

de mantenimiento preventivo, dichas actividades se plasmarán en un plan que

permitirá organizar esas tareas en un cronograma de actividades a realizarse en

un año. Para cada actividad debe indicarse el o los responsables, el tipo de tarea,

los equipos que se les darán mantenimiento y duración de la tarea (incluyendo

fecha de inicio y fecha de finalización). Las tareas de mantenimiento pueden ser

de limpieza de equipos, revisión de la configuración de equipos, cambio de patch

en los laboratorios.

Otro objetivo de las tareas de mantenimiento es encontrar equipos que pueden

ser reemplazados, en este aspecto, se trabajaría junto con el plan de

actualización de equipos (Anexo 21)

VI. METAS


Realizar un mínimo de cinco tareas de mantenimiento preventivo por año

Cumplir con los objetivos del plan al finalizar el 2012

VII. DURACIÓN



VIII. ORGANIZACIÓN



Elaboración de un cronograma de actividades de mantenimiento

preventivo

Definir roles y responsabilidades

IX. PRESUPUESTO

El presupuesto lo determinará la jefatura de la OTI en conjunto con lassubáreas

de redes y soporte





ANEXO 22

PROYECTO Nº07

I. DENOMINACIÓN

“PLAN DE MEJORAMIENTO DE LA SEGURIDAD DE ACCESO AL

DATACENTER DE LA UNIVERSIDAD CÉSAR VALLEJO - PIURA”

II. RESPONSABLES






Vallejo – Piura se encontró que el datacenter cuenta con controles de seguridad

de acceso que no son los adecuados y que pueden ser burlados fácilmente, por

tal motivo, es necesaria el mejoramiento de la seguridad de acceso al datacenter

ya que en él se guardan los principales activos de la información de la

universidad.

IV. OBJETIVOS

a) General

Elaborar un plan de mejoramiento de la seguridad de acceso al datacenter

de la Universidad César Vallejo

b) Específicos

Mejorar las políticas de seguridad en torno al datacenter.

Mejorar la infraestructura de seguridad de acceso al datacenter

V. DESCRIPCIÓN

Con el objetivo de mejorar la seguridad física del datacenter, se ve conveniente

realizar un plan de mejoramiento de seguridad de acceso que propone lo

siguiente.

Adquisición de un equipo de acceso biométrico al datacenter



Adquisición de dos cámaras de seguridad, una al exterior y otra al exterior

del recinto

VI. METAS


Adquirir dos cámaras de seguridad

Adquirir un equipo biómetrico de acceso.

VII. DURACIÓN



VIII. ORGANIZACIÓN



Redacción de las nuevas políticas de seguridad.

Comunicar al área de Logística para coordinar la compra de equipos

Formación de una comisión de OTI para la supervisión de la compra de los

equipos.

Instalación y configuración de los equipos instalados

Capacitación y difusión de las nuevas políticas de seguridad de acceso

IX. PRESUPUESTO


redes





ANEXO 23

PROYECTO Nº08

I. DENOMINACIÓN

“CREACIÓN DE NUEVAS POLÍTICAS PARA REGULAR EL ACCESO DE LOS

USUARIOS A LAS CARPETAS COMPARTIDAS.”

II. RESPONSABLES






Vallejo – Piura se encontró que los perfiles de usuario de dominio tienen permisos

de lectura y escritura en las carpetas compartidas, lo cual expone información y

recursos sensibles que sólo el personal de una determinada área debe acceder,

por tal motivo se propone la creación y aplicación de nuevas políticas que

permitan regular los permisos de acceso.

IV. OBJETIVOS

a) General

Crear un conjunto de nuevas políticas para regular el acceso de los

usuarios a las carpetas compartidas.

b) Específicos

Definir grupos de usuario por cada área clave de la universidad

Definir los permisos y privilegios de cada grupo de usuario

Mejorar los controles lógicos de seguridad aplicados en OTI

Registrar las nuevas políticas de seguridad en un documento físico

V. DESCRIPCIÓN

Las nuevas políticas que deben proponerse se orientan a lo siguiente:



Creación de grupos por cada área considerada clave como: Logística,

Contabilidad, OTI, Planificación, Dirección General, etc.

Creación de políticas de acceso para cada grupo respecto a los recursos

manejados por su mismo grupo o por otro.

VI. METAS


Ejecutar este proyecto y redactar un informe a los tres mese de haber

iniciado.

VII. DURACIÓN



VIII. ORGANIZACIÓN



Redacción de las nuevas políticas de seguridad de acceso.

Aplicación de las políticas de seguridad

Capacitación al personal administrativo de la universidad.

Monitoreo de las políticas implantadas

IX. PRESUPUESTO


redes.





ANEXO 24

GUÍA DE ENTREVISTA N°08



ANEXO 25: GUÍA DE OBSERVACIÓN N°01



ANEXO 26: GUÍA DE OBSERVACIÓN N°02



ANEXO 27

GUÍA DE OBSERVACIÓN N°03



ANEXO 28

PRESUPUESTO

RECURSO DESCRIPCIÓN CANTIDAD PREC. UNIT SUBTOTAL

MATERIAL DE

ESCRITORIO

Papel Bond A4 1 millar S/. 22.00 S/. 22.00

CD – ROM 5 unidades S/. 0.80 S/. 4.00

Lapiceros Faber Castell 5 unidades S/. 0.50 S/. 2.50

Corrector Faber Castell 2 unidades S/. 2.50 S/. 5.00

Resaltador 2 unidades S/. 2.00 S/. 4.00

Fólder Manila A4 10 unidades S/. 0.50 S/. 5.00

Clips 1 caja S/. 0.50 S/. 0.50

Cartucho de Tinta HP negra 1 unidades S/. 75.00 S/. 75.00

Cartucho de Tinta HP a color 1 unidad S/. 120.00 S/. 120.00

Grapas 1 caja S/. 2.00 S/. 2.00

Fastener Artesco 1 caja S/. 3.50 S/. 3.50

Perforador Artesco 1 unidad S/. 12.00 S/. 12.00

SUBTOTAL S/. 255.50

SERVICIOS

Fotocopias 1000

unidades S/. 0.10 S/. 100.00

Internet 3 Meses S/. 99.00 S/. 297.00

Anillados 10 unidades S/. 5.00 S/. 50.00

Empastados 5 unidades S/. 8.50 S/. 42.50

Impresiones 1000

Unidades S/. 0.10 S/. 100.00

Transporte 2 personas S/. 150.00 S/. 300.00

SUBTOTAL S/. 889.50

TOTAL S/. 1,145.00



ANEXO 29

CRONOGRAMA DE ACTIVIDADES



ANEXO 30

CONSTANCIA DE DESARROLLO DE TESIS



ANEXO 31

CARTA DE PRESENTACIÓN DE INFORME DE AUDITORÍA

tesis en la ucv piura

Documents