Fundamentos de

Auditoría
Informática

Jorge Domínguez Chávez

IEASS, Editores
Venezuela, 2021
Copyright ® Jorge Domínguez Chávez.
ORCID: 0000-0002-5018-3242
Esta obra se distribuye licencia Creative Commons:

http://creativecommonsvenezuela.org.ve

Reconocimiento:
Atribución: Permite a otros copiar, distribuir, exhibir y realizar su trabajo con Derechos de Autor y trabajos
derivados basados en ella – pero sólo si ellos dan créditos de la manera en que usted lo solicite.
Compartir igual: Permite que otros distribuyan trabajos derivados sólo bajo una licencia idéntica a la que rige el
trabajo original.
Adaptar: mezclar, transformar y crear a partir de este material.

Siempre que lo haga bajo las condiciones siguientes:

Reconocimiento: reconocer plenamente la autoría de Jorge Domínguez Chávez, proporcionar un enlace a la

licencia e indicar si se ha realizado cambios. Puede hacerlo de cualquier manera razonable, pero no una que
sugiera que tiene el apoyo del autor o lo recibe por el uso que hace.
No Comercial: no puede utilizar el material para una finalidad comercial o lucrativa.

® 2021, Domínguez Chávez, Jorge

ISBN 9789806366107

Publicado por IEASS, Editores

ieass@blogspot.com
Venezuela, 2021
La portada y contenido de este libro fue editado y maquetado en TeXstudio 2.12.14
 Índice general

Prólogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Acrónimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV

1. Auditoría 1
1.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. ¿Qué es la auditoría? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Tipos de auditorías según ISO 19011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5. Los seis principios de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6. Otros tipos de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.1. Auditoría Financiera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.2. Auditoría de cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.3. Auditoría de operacional o de gestión . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6.4. Auditoría ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Normas de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8. Clasificación y objetivos de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.9. Resultados esperados de la auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.10. El Auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.11. Informe de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.11.1. La opinión del auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.11.2. Importancia de los informes auditorías . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Metodología 11
2.1. Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Auditoría interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Auditoría externa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1. Tipos de auditorías externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2. Auditorías externas de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3. Funciones de la auditoría externa . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.4. El papel del auditor externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
 2.4. Diferencias entre auditoría externa e interna . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5. Metodología para una auditoría administrativa . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6. Planeación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7. Asignación de la responsabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8. Capacitación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9. Actitud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.10. Diagnóstico preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10.1. Instrumentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10.2. Recopilación de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.10.3. Técnicas de recolección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.11. Seguimiento y supervisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3. Auditoría en informática 31
3.1. Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2. Diferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3. Importancia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5. Áreas a auditar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6. Beneficios y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7. Técnicas y Herramientas usadas por la auditoría informática . . . . . . . . . . . . . . . . . 36
3.7.1. Cuestionarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.2. Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8. Auditoría de sistemas de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9. Seguridad general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.10. Objetivos de la Auditoria de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4. Auditoría Física 40
4.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3. Alrededor del computador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4. ¿Qué activos proteger? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5. Seguridad física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6. Fuentes de información básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.7. Técnicas y herramientas del auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8. Los auditores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.9. Desastres naturales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.10. Fallas eléctricas y/o mecánicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.11. Robo, fraude, malversación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5. Auditoría de la ofimática 46
5.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2. Técnicas y herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.1. Observación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2. Software de apoyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3. Software a auditar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4. Controles de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.1. Los controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
 5.5. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6. Informe auditoría ofimática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6. Auditoría de la dirección 56
6.1. Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2. Acciones de un director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3. Posibles preguntas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7. Auditoría de la explotación 61
7.1. Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2. ¿Por qué? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3. ¿Para qué? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.4. Puntos a considerar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.5. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.6. Componentes del sistema de información según COBIT . . . . . . . . . . . . . . . . . . . . 63
7.7. Planificación estratégica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.8. Áreas de la auditoría de explotación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.9. Control de entrada de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.9.1. Procedimiento de control de entrada de datos . . . . . . . . . . . . . . . . . . . . . 65
7.10. Planificación y recepción de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.11. Centro de control y seguimiento de trabajos . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.12. Salas de servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.12.1. Equipos informáticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.12.2. Centro de control de red y Centro de diagnosis . . . . . . . . . . . . . . . . . . . . 71
7.13. Procedimiento de la auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8. Auditoría del desarrollo 72

8.1. Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.2. ¿Por qué y Para qué? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.3. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.4. Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.4.1. Participación de la gerencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.4.2. Definición del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.4.3. Controles de desarrollo, adquisición y mantenimiento . . . . . . . . . . . . . . . . . 74
8.4.4. Auditoría de la calidad del software . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.4.5. Procedimientos efectivos y documentados . . . . . . . . . . . . . . . . . . . . . . . 81
8.5. Estudio preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.5.1. Equipo de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.5.2. Requerimiento de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.5.3. Aprobación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5.4. Factibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5.5. Factibilidad tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5.6. Factibilidad operacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5.7. Factibilidad legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5.8. Factibilidad económica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5.9. Plan maestro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.5.10. Control de costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
 8.6. Diseño detallado del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.6.1. Especificaciones de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.6.2. Especificaciones de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.6.3. Especificaciones de los archivos y base de datos . . . . . . . . . . . . . . . . . . . . 85
8.6.4. Especificaciones de procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.6.5. Documentos fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.7. Diseño de controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.7.1. Pistas de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.8. Desarrollo e implantación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.8.1. Objetivo de la programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.8.2. Descripción de la programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.8.3. Software estandarizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.8.4. Programación por contrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.9. Documentación de los programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.9.1. Manual de operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.9.2. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.10. Pruebas del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

9. Auditoría de la red informática 90

9.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
9.2. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.3. La importancia de una auditoría de seguridad de red . . . . . . . . . . . . . . . . . . . . . . 92
9.3.1. Analizar riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.3.2. Trabajo en el laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.3.3. Trabajo en el sistema de producción . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.4. Centro de control de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.5. Centro de diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.6. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.7. Auditoría de la red corporativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
9.7.1. ¿Qué considerar en la auditoría de redes? . . . . . . . . . . . . . . . . . . . . . . . 98
9.7.2. ¿Auditoría física y/o lógica? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.7.3. La seguridad física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.7.4. La seguridad lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
9.8. Tipo de evaluación de las redes que existen . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.8.1. Nivel interno o externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.8.2. Sistemas de seguridad para empresas . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.9. ¿Red cableada o inalámbrica? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.9.1. Auditoría LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.9.2. Auditoría Wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.9.3. Auditoría Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.10. El acceso remoto a la red informática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.10.1. Pruebas de seguridad humana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.11. Auditoría técnica o de cumplimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.12. Revisar la documentación técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.13. Revisar configuración y funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.14. Etapas de la auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
 9.15. En cuanto a ataques a las redes de comunicación . . . . . . . . . . . . . . . . . . . . . . . . 107
9.15.1. Tipos de ataques informáticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.15.1.1. Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.15.1.2. Denegación de servicio distribuido (DDoS) . . . . . . . . . . . . . . . . . 108
9.15.1.3. Ingeniería social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.15.2. Penetración extremo a extremo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.16. Trabajo en componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.17. Potenciales amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.18. ¿Revisiones técnicas o de cumplimiento? . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.19. Posibles preguntas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10. Auditoría de bases de datos 111

10.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.2. Propósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.3. ¿Qué es y para qué sirve? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10.4. Los controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10.5. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.6. ¿Cuál es la importancia de la auditoría en la base de datos? . . . . . . . . . . . . . . . . . . 114
10.7. Marco legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.7.1. Ley de Protección de Datos Personales . . . . . . . . . . . . . . . . . . . . . . . . 115
10.7.2. Sanciones previstas por ley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.7.3. Marcos jurídicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.8. Tipo de auditoría en base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.8.1. De actividades de los usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.8.2. De transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.9. ¿Cómo hacer el proceso? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.10.Estudio y planificación previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.11.Construcción de bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.12.Selección del equipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.13.Diagramas y contenido de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.14.Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.15.Revisiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
10.16.Posibles Preguntas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

11. Auditoría de mantenimiento 126

11.1. Cómo Funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.2. Plan de recuperación de desastres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
11.3. Qué es una auditoría de mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.4. El modelo de excelencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.5. El perfil del auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.6. Las áreas analizadas en una auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.7. Herramientas informáticas para la auditoría de mantenimiento . . . . . . . . . . . . . . . . 130
11.8. Cuestionario de la auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
12. Auditoría de la seguridad 136
12.1. Objetivos de una auditoría de ciberseguridad . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.2. Tipos de auditorías de seguridad informática . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.3. Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
12.4. Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
12.5. ¿En qué consiste la auditoría en seguridad informática? . . . . . . . . . . . . . . . . . . . . 139
12.6. ¿Qué tipos de auditorías de seguridad informática se realizan? . . . . . . . . . . . . . . . . 140
12.7. ¿Qué beneficios tiene la auditoría informática? . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.8. Protección de un servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.9. Hacker, crackers, lamers, script kiddies y phreakers . . . . . . . . . . . . . . . . . . . . . . 141
12.10.Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
12.11.Consejos de seguridad en servidor Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

13. Auditoría forense 146

13.1. Agencias forenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
13.2. Antecedentes y conceptos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
13.3. Vulnerabilidades comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
13.4. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.5. Procedimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
13.6. Análisis forense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.7. Usos de la tecnología forense/herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . 152
13.8. Fases de un análisis forense digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
13.9. Técnicas para identificar delitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
13.10.Identificación del incidente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
13.11.Diagnóstico del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
13.12.Forma de recabar información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
13.13.Reconocimiento de la evidencia digital como evidencia formal y válida . . . . . . . . . . . 155
13.14.Acción que sigue al diagnostico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
13.15.Normas internacionalmente reconocidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
13.16.El Informe técnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
13.17.El Informe ejecutivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

14. Auditoría y los delitos informáticos 159

14.1. Motivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
14.2. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
14.3. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
14.4. Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
14.5. Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
14.6. Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
14.6.1. ¿Qué es calidad de datos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
14.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
14.7.1. ¿Qué son pruebas de software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.7.2. Tipo de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.7.2.1. Pruebas de unidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.7.2.2. Pruebas de integración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.7.2.3. Pruebas de aceptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
 14.7.2.4. Otros tipos de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
14.7.3. ¿Qué es validación de datos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
14.8. Tipos de migración de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
14.9. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
14.10.Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
14.11.Auditor y estos delitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
14.12.Características de este tipo de delitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
14.13.Tipificar los delitos de acuerdo a sus características principales . . . . . . . . . . . . . . . . 172
14.14.Fraude a través de computadoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
14.15.Papel del auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
14.16.Área de planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
14.17.Almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
14.18.Centro de cómputo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
14.19.Seguridad física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
14.20.Otras preguntas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
 Índice de figuras

2.1. Estructura sugerida para la auditoría interna. . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Áreas de la empresa para aplicar la auditoría informática. . . . . . . . . . . . . . . . . . . . 34

3.2. Definición de Auditoría de Sistemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3. Objetivos de Auditoría de Sistemas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1. Cuestionario No. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2. Cuestionario No. 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3. Cuestionario No. 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4. Cuestionario No. 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5. Guía de verificación No. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6. Formato para inventario No. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.7. Formato para evaluación de entorno informático No. 1 . . . . . . . . . . . . . . . . . . . . 51
5.8. Matriz de contraste de inventario No. 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1. Vista de un organigrama. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2. Revisión de la estructura orgánica de una empresa. . . . . . . . . . . . . . . . . . . . . . . 58

8.1. Atributos de calidad de la información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9.1. Elementos de seguridad a considerar en instituciones financieras. . . . . . . . . . . . . . . . 91

9.2. COBIT–Objetivos de control para la información pública y tecnologías Relacionadas . . . . 95
9.3. Esquema de una red informática corporativa. . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.4. Topología en estrella de las redes locales en la actualidad . . . . . . . . . . . . . . . . . . . 98
9.5. Topología de red informático en árbol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9.6. Topología de una red informática. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.7. Topología de una red WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
9.8. Pérdidas medias causadas por los incidentes de seguridad más comunes en las pymes. . . . . 107

13.1. Metodología Deming PHVA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

14.1. Traducción de las Áreas donde se generan datos incorrectos. . . . . . . . . . . . . . . . . . 163

VII
14.2. Diagrama sobre qué probar en una base de datos. . . . . . . . . . . . . . . . . . . . . . . . 167
14.3. Traducción del Modelo V con Migración a Base de Datos. . . . . . . . . . . . . . . . . . . 168
 Índice de tablas

3.1. Diferencias entre algunas auditoría. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2. Algunas de la auditorías actuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.1. Tabla de similitudes y diferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

12.1. Algortimos HASH más utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

13.1. Fases de la auditoría forense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

14.1. Ejemplo de un plan de migración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

14.2. Adaptación de requerimientos de diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

IX
 Prólogo

La auditoría, como cambio de paradigma de fiscalización, estuvo clasificada según la actividad que realiza-
ba, por los elementos que intervenían y actualmente, por el objetivo planteado. La auditoría, a partir del año
2010 se clasifica en financiera, operativa, socio-laboral, medioambiental, ética, informática, de procesos de
calidad, entre otros. Mora Quirós [50].
Las empresas desarrollan actividades en ambientes cada vez más complejos. Por lo cual, en los últimos años,
los sistemas de información, son uno de los principales ámbitos de estudio en el área de organización de
empresas.
La globalización de la empresa, la competencia en los mercados de bienes y servicios, las tecnologías de
información, los riesgos en el entorno, la reducción de los ciclos de vida de los productos y los delitos infor-
máticos, hacen que la información sea un elemento clave para la gestión, supervivencia y crecimiento de la
organización empresarial. Moreno Cevallos [48].
En 1970 nace la auditoría informática. Ésta, constituye una plataforma que gestiona las TIC en las empresas,
detectando de forma sistemática el uso de los recursos y los flujos de información dentro de la empresa y
determinar si la información es crítica para el cumplimiento de su misión y objetivos, identificando nece-
sidades, falsedades, costos, valor y barreras, que obstaculizan los flujos de información eficientes. En este
momento, las organizaciones tienen conciencia sobre la necesidad de aumentar el nivel de control sobre la
gestión de sus sistemas de información, Moreno Cevallos, [48].
Para Castillo Pérez [49] la información depende de la confiabilidad de los datos, de los procesos que la ge-
neran y de los modelos para procesarlos. Los usuarios están conscientes que la información ayuda a ser más
productivo para cumplir con los objetivos de la empresa; por lo que esta información debe ser útil, oportuna,
fácil de interpretar, actualizada, adecuada y precisa; con estas características de la calidad de la información
se toman decisiones relevantes de una manera rápida, mejora su desempeño y efectividad en el trabajo.
Para una empresa la auditoría informática es una práctica de trascendental importancia social y económica,
establece diversas relaciones entre los diversos agentes, ya que mediante su aplicación se obtiene informa-
ción fiable para tomar decisiones que soporten el desarrollo y productividad de la empresa.
Este libro pretende ser una introducción a la auditoría informática. estimular su estudio y aplicación. Sustenta
que debe regirse por los cuatro puntos básicos:

Políticas y procedimientos.

I
Recuperación de desastres y continuidad del negocio.

Supervisión en el sitio.

Seguridad.

Delitos informáticos.
 Acrónimos

ACID Atomicity, Consistency, Isolation Durability, es decir: atomicidad, consistencia, aislamiento y durabi-
lidad. Característica de los parámetros que se utilizan para clasificar transacciones en la gestión de bases de
datos.
AFI Auditoría Forense Informática.
AII Auditor Informático Interno.
AIE Auditor Informático Externo.
API Application Programming Interface, es decir, interfaz de programación de aplicaciones.
ASIAuditoría de sistemas de información.
BIOS Basic Input Output System, en español ”sistema básico de entrada y salida”.
BPR Business Process Re-engineering.
CISA Certified Information Systems Auditor.
COBIT Control Objectives for Information and Related Technologies. significa Objetivos de Control para
Tecnología de Información y Tecnologías relacionadas (Control Objectives for Information Systems and re-
lated Technology)
Bit Binary digit, dígito binario.
BOOTP Bootstrap Protocolo, es un protocolo de arranque que se utiliza para obtener una dirección IP auto-
máticamente.
CPD Centro de procesamiento de datos.
CODASYL Conference on Data Systems Languages. Es un consorcio de industrias informáticas fundado en
1959 para regular el lenguaje de programación.
CSCW Computed Supported Cooperative Work.
sitioweb Un sitio web o cibersitio es una colección de páginas web relacionadas y comunes a un dominio de
internet o subdominio en la World Wide Web en Internet.
DBA Administrador de la base de datos.
DPD Departamento de Procesamiento de Datos.
EMAS Eco Management and Audit Scheme) es una normativa de carácter voluntario a nivel de la Unión
Europea que pone el foco en facilitar a la gestión en materia ambiental a las empresas con un Sistema de

IV
Gestión Ambiental implantado.
ISACA Information Systems Audit and Control Association - Asociación de Control y Auditoría de Siste-
mas de Información. Desde su creación, ISACA es una organización global que establece las pautas para los
profesionales del gobierno, control, seguridad y auditoría de información. Sus normas de auditoría y control
de SI son seguidos por profesionales de todo el mundo y sus investigaciones abordan temas profesionales.
ISO19011 Directrices para la auditoría de los sistemas de gestión es una norma internacional desarrollada
por la Organización Internacional de Normalización, que establece las directrices para la auditoría de los
sistemas de gestión de la calidad. Última revisión de la norma fue en 2018.
RAID Redundant Array of Independent Disks, que significa ”conjunto redundante de discos independien-
tes”.
RPV / VPN en español red privada virtual y en inglés Virtual Private network.
MAN Metropolitan Area Network, es una red de área metropolitana, es decir una red de alta velocidad de
amplia cobertura.
Modem Modulator Demodulator. En español ”módem”. Dispositivo que convierte las señales digitales. En
analógicas (modulador) y las señales analógicas en digitales (demodulador).
NAGA Norma de Auditoría Generalmente Aceptadas.
OMS Organización Mundial de la Salud.
SGBD Sistemas de Gestión de Base de Datos.
SOAP single Object Access Protocol, es un protocolo estándar para que se comuniquen dos objetos en dife-
rentes procesos.
TQM Total Quality Management.
TIC Tecnología de Información y Comunicaciones.
UDS UNIDAD DE SISTEMAS - Identifica a una dirección/gerencia/unidad de desarrollo de sistema.
OSSTMM Manual de la Metodología Abierta de Testeo de Seguridad.
ISECOM Institute for Security and Open Methodologies.
WAM Wide area network, que en castellano significa red de área amplia.
WLAN Wireless local area network, o ”red de áreal local inalámbrica”.
Zeroconf Zero Configuration Networking, es decir, red de configuración cero. Es un conjunto de tecnologías
utilizadas para crear automáticamente una red informática.
 Auditoría
1
Los inicios de la auditoría se remontan a la revisión y el diagnóstico que se practicaba a los registros ope-
racionales contables de las empresas; después se pasó al análisis, verificación y evaluación de sus aspectos
financieros; posteriormente se amplió al examen de algunos rubros de la administración, siguiendo con el
análisis de aquellos aspectos que intervenían en todas sus actividades y, por último, su alcance se incrementó
conforme se avanzó en la llamada revisión integral.
La actividad de auditar consiste en realizar un examen de los procesos y de la actividad propia de una orga-
nización para confirmar si se ajustan a lo fijado por normas, objetivos, tiempos, leyes o buenos criterios.
Auditar es un término que hace referencia a tres cosas diferentes pero conectadas entre sí: a) se refiere al
trabajo que realiza un auditor, b) a la tarea de estudiar la actividad de una organización, y c) a la oficina
donde se realizan estas tareas (donde trabaja el auditor).
Por lo general, el término se refiere a la auditoría contable, que consiste en examinar las cuentas de una
entidad. Puede decirse que la auditoría es un tipo de examen o evaluación que se lleva a cabo siguiendo una
cierta metodología. Lo habitual es que el auditor no pertenezca a la entidad auditada.
Una auditoría es una de las formas en las que se aplican los principios científicos de la administración, donde
la verificación de los bienes patrimoniales, laborales y beneficios alcanzados por la organización son primor-
diales, pero no son lo único importante. La auditoría intenta proveer pautas que ayuden a los miembros de
una organización a desarrollar adecuadamente sus actividades, evaluándolos, recomendándoles determina-
das cosas y revisando detenidamente la labor que cada uno cumple dentro de la organización.
La evaluación, en lo que respecta al desempeño organizacional de toda la entidad, como unidad integral, es
fundamental para discernir si se han alcanzado los objetivos deseados. Dicha labor es la correspondiente a la
auditoría.

1.1. Definición
Una auditoría examina y evalúa el funcionamiento de una empresa desde una o varias perspectivas. Puede
centrarse en sus finanzas, en sus cuentas, en la calidad o la seguridad laboral. Puede orientarse a buscar una
meta específica, como la de sostenibilidad; o limitarse a garantizar que la organización se alinea con los
requisitos normativos exigibles.
La auditoría analiza cosas como los estados financieros, libros de contabilidad, los procesos y procedimien-
tos, los espacios de trabajo o los productos que se comercializarán. Muchas empresas tienen auditorías de

1
rutina una vez al año, mientras que otras las realizan puntualmente, con motivos concretos.
Lo que está claro es que la auditoría ayuda a detectar problemas dentro de la empresa y, a largo plazo,
contribuir a encauzarla impulsar sus resultados.

1.2. Objetivo
Toda auditoría tiene como objetivo la elaboración de un documento en el que se recojan los resultados del
proceso y que, a la vez, sirva de referencia para terceros agentes, ya sean integrantes de la propia empresa o
de algún organismo o institución oficial que la haya solicitado.

1.3. ¿Qué es la auditoría?

Auditar según ISO 19011 es comprobar, en el sitio en donde se ejecutan los procesos, el cumplimiento de
los requisitos solicitados por una norma. Esta sirve como marco de un determinado sistema de gestión, sea
este de calidad, medio ambiente, seguridad de la información o seguridad y salud en el trabajo, entre otros.
Y auditar dichos sistemas constituye un paso fundamental en la mejora continua de los mismos.
Para auditar es preciso conocer en profundidad el estándar suministrado por la norma ISO 19011, ver [9].
Esta ofrece directrices precisas en la realización de auditorías de sistemas de gestión. La norma está dividida
en 7 capítulos del siguiente modo:
Alcance.
Referencias Normativas.
Términos y Definiciones.
Principios de Auditoría.
Gestión de Auditoría.
Gestión de un Programa de Auditoría.
Competencia y Evaluación de Auditoría.
Los principios y directrices que indican cómo auditar según ISO 19011, están contenidos en el capítulo 4, [9].
La norma propone tres tipos de auditoría y seis principios esenciales que se presentan a continuación.

1.4. Tipos de auditorías según ISO 19011

Para auditar, debe entender que existen tres diferentes tipos de auditoría:
Auditoría operativa, para Gómez Morales [27] es un examen crítico y sistemático de la eficacia con
que los responsables de una empresa o parte de ella consiguen los objetivos establecidos y a la efi-
ciencia y economía con que se utilizan los recursos de la organización, con el propósito de emitir las
recomendaciones para mejorar su gestión.
Auditoría de producto: es una inspección de los procesos relacionados con la fabricación de un pro-
ducto o la prestación de un servicio en particular. Es el tipo de auditoría que se espera en un sistema
de calidad para verificar el cumplimiento de los requisitos, especificaciones y estándares de calidad
solicitados por los clientes.
 La auditoría de cumplimiento [26]: tiene por objeto determinar si se han mantenido los acuerdos
contractuales. Muchos contratos contienen cláusulas que condicionan la cantidad a pagar bajo contrato
por el rendimiento específico del contratado. La calidad del producto y el costo de producirlo son sólo
dos ejemplos de los muchos determinantes que regulan las cantidades a pagar en tales contratos. La
auditoría de cumplimiento determina si se han respetado los términos del contrato.

La auditoría de rendimiento [26]: no está sujeta a un contrato. De hecho, gran parte del trabajo del
auditor interno es relativo a la auditoría de rendimiento. Con el fin de lograr un control interno eficaz
en una organización, las personas deben efectuar actividades específicas de control. La auditoría de
rendimiento determina el acierto de estas actividades de control.

La auditoría especial [26]: es una categoría mixta que incluye las auditorías que no son considera-
das como financieras, operativas, de cumplimiento o de rendimiento. La competencia del auditor para
hacer una revisión especial y su independencia es esencial a realizar la auditoría, siendo sus únicas
limitaciones de importancia.

Auditoría de procesos: verifica el funcionamiento óptimo de los mismos y su alcance. También, com-
prueba el cumplimiento de las instrucciones o métodos que, en su conjunto, logran la conformidad con
la norma que rige al sistema de gestión.

Auditoría del sistema: es el proceso documentado realizado para comprobar que todos los elementos
que conforman un sistema de información opera de forma correcta y en conformidad con el estándar
implementado.

A continuación, las ramas de la auditoría que se centran en función del lugar que ocupan los auditores
respecto a la entidad sometida a este proceso:

1. Auditoría independiente.
Es aquella realizada por contadores públicos externos, lo que destaca la importancia del auditor in-
dependiente. Éste, aunque contratado por una empresa, asume la responsabilidad ante un público que
confía en su opinión acerca de los estados financieros de la empresa. En otros casos, cuando se trata
de la auditoría no financiera, el auditor independiente responde, principalmente, ante su cliente.

2. Auditoría interna.
Se resume a la ”actividad considerada independiente, dentro de una organización para la revisión de
la contabilidad y otras operaciones, y como una base de servicio a la dirección. Representa un activo
de la dirección que funciona para medir y evaluar la efectividad de sus controles”. A eso, StettIer
[26] agrega un objetivo ”...a todos los miembros de la dirección en relación al cumplimiento de sus
responsabilidades, al facilitarles análisis, evaluaciones, recomendaciones y comentarios pertinentes,
relativos a las actividades que revisan...”.

3. Auditoría gubernamental.
A su vez, -que es la rama más amplia- es ejercida por las agencias gubernamentales, cuyas investiga-
ciones, por lo general, quedan limitadas al nivel del departamento en cuestión.

Destaca que, aunque la tipología presentada tiene amplia aceptación mundial, autores como Slosse, Soy y
Jiménez, denominan de forma distinta, a la auditoría independiente calificándola como externa.
1.5. Los seis principios de auditoría
El objetivo de la empresa es una auditoría realizada bajo los principios y directrices de las normas estable-
cidas y conocer los tres tipos de auditoría que dicha norma diferencia. A continuación, los seis principios de
auditoría contenidos en ISO 19011:

Integridad: aborda los aspectos relativos al equipo de auditoría. Donde la honestidad, ética, respon-
sabilidad, dedicación, imparcialidad y el equilibrio son características relevantes de todo el equipo y
también de cada uno de sus miembros.

Presentación de informes veraces: trata la importancia de presentar las conclusiones de auditoría de

manera que se ajusten a la realidad y resulten objetivas. Teniendo en cuenta el registrar posibles dife-
rencias de opinión surgidas durante la auditoría.

Profesionalismo: se refiere a la agilidad que el auditor aplica durante la auditoría y la responsabilidad

que acarrean los juicios que haga durante su trabajo. Debe trabajar con diplomacia durante la auditoría,
actuar con profesionalismo y ética, para obtener la confianza de sus auditados.

Confidencialidad: trata de la discreción y cuidado que los auditores deben mostrar para proteger la
información obtenida durante la realización de su trabajo, de tal forma que no sea divulgada fuera de
la dirección o gerencia de la organización, ni utilizada de forma inadecuada, menos para beneficios
personales.

Independencia: trata sobre la imparcialidad y la objetividad en las conclusiones de auditoría, que sólo
se obtienen si el auditor realiza su trabajo de forma libre e independiente. Para ello, es fundamental
que el auditor mantenga la objetividad durante todo el proceso. En el caso de una auditoría interna,
cuando el auditor pertenece a la organización, es necesario que él no audite su área de trabajo.

Enfoque basado en evidencia: para obtener un proceso de auditoría sistemático, de forma que resulte
confiable y reproducible, es esencial que se sustente en un método planificado y racional. La evidencia
será repetible, cuantificable y comprobable desde el mismo momento en que se obtiene.

1.6. Otros tipos de auditoría

Los tres tipos básicos de auditoría mencionados, en conjunto, forman el marco de la auditoría integral que
ofrece una visión completa de una organización. Los otros tipos son:

1.6.1. Auditoría Financiera

Una auditoría de procedimientos, es la revisión de los mismos en una organización o ente jurídico (regional,
estatal y/o nacional) en base a normas previamente establecidas, dando como resultado la publicación de una
opinión independiente sobre si los procedimientos son relevantes, precisos, completos y son presentados con
justicia. Esta auditoría se realiza para obtener el conocimiento y estado de su información financiera. Para
llevarse a cabo, y como se ha anunciado previamente, existen una serie de normas o principios que regulan
la auditoría que emiten las autoridades de los países conforme a unos principios enunciados internacionales.
Además, la auditoría financiera es una de las muchas funciones proporcionadas por las firmas de adminis-
tración y auditoría autorizadas que son contratadas para emitir una opinión independiente en forma de una
información publicada.
1.6.2. Auditoría de cumplimiento
Es la comprobación de las operaciones financieras, administrativas, económicas y de otra índole de una
entidad para establecer que se han realizado conforme a las normas legales, reglamentarias, estatutarias y
procedimentales vigentes. Esta auditoría se practica mediante la revisión de los documentos que soportan
legal, técnica, financiera y contablemente las operaciones para determinar si los procedimientos utilizados
y las medidas de control interno están de acuerdo con las normas que le son aplicables y si dichos proce-
dimientos están operando de manera efectiva y son adecuados para el cumplimiento de los objetivos de la
entidad.

1.6.3. Auditoría de operacional o de gestión

La auditoría operacional es la acumulación sistemática de evidencias con el propósito de expresar una opi-
nión independiente sobre: a) la eficacia de los sistemas administrativos y de los instrumentos de control
interno incorporados en ellos, y b) la eficiencia, eficacia, y economía de las operaciones.
Para la interpretación y aplicación de las normas de auditoría operacional se definen los conceptos:

Sistema: es una serie de actividades relacionadas, cuyo diseño y operación conjunta tienen el propósito
de lograr uno o más objetivos preestablecidos.

Eficacia: es la capacidad que tiene un sistema de asegurar, razonablemente, la consecución de ob-

jetivos. En términos generales, el índice de eficacia es la relación entre los resultados logrados y el
objetivo previsto.

Eficiencia: es la capacidad de cumplir objetivos empleando la mínima cantidad de recursos posible

(como tiempo, humanos, materiales, financieros, etc.) En este sentido, un índice de eficiencia general-
mente utilizado es la relación entre los resultados obtenidos y la cantidad de recursos empleados.

Economía: es la capacidad de minimizar el costo unitario de los recursos empleados en la consecución

de objetivos, sin comprometerlos. En este sentido, un índice de economía generalmente empleado es
la relación entre los resultados obtenidos y el costo de los mismos.

En los últimos años han surgido tipos de auditoría propias del contexto del contexto actual, como la auditoría
medioambiental, la auditoría ética y la auditoría económico-social, entre otras.

Auditoría fiscal.

Auditoría contable ( de estados financieros )

Auditoría interna.

Auditoría externa.

Auditoría operacional.

Auditoría administrativa.

Auditoría integral.

Auditoría gubernamental.

Auditoría informática.
 Auditoría ambiental.

Auditoría forense.

1.6.4. Auditoría ambiental

Una empresa adquiere el compromiso de preservar el medio ambiente y para ello pretende identificar y mi-
nimizar los impactos en el medio que sus propias actividades generan. La norma ISO 14001 implica realizar
periódicamente una auditoría ambiental para obtener la certificación.
El medio ambiente es el soporte de la vida en cualquiera de sus formas, de ahí la importancia que tiene,
pero ¿existe consciencia de que dependemos de él? No, hay deforestaciones masivas, emisión de gases a la
atmósfera, contaminación con aguas residuales, etc. En el transcurso de los años, se ha deteriorado bastante
y las consecuencias de prestarle poca atención al ”cambio climático”.
Las auditorías ambientales surgen para controlar el desgaste y el abuso que las empresas de los países ejercen
sobre el medio natural, intentando reducir el daño que generan con sus actividades productivas y lograr la
mayor eficiencia energética posible.
La norma ISO 14001 agrupa los estándares que debe cumplir una empresa en cuanto a protección del medio
ambiente y la prevención de actividades contaminantes. Se establecen objetivos en función de la evaluación
del impacto que sus actividades tienen en el medio ambiente. La norma ISO 14001 ayudará a cumplir los
objetivos para reducir el impacto. Aquellas empresas o compañías que han adoptado este sistema de gestión
ambiental evalúan su eficacia con las auditorías ambientales.
Para llevar a cabo una auditoría ambiental, la empresa designará un responsable o recurrirá a una firma ex-
terna, como las consultoras medioambientales, para que evalúe la efectividad de las medidas adoptadas en la
preservación del medio ambiente. Independientemente del auditor, éste deberá contar con los conocimientos
necesarios para llevarla a cabo. Se espera de él imparcialidad y objetividad para una evaluación fiel y real de
la situación ambiental, de modo que se apliquen medidas correctivas.
Para obtener la certificación ISO 14001, la empresa definirá el alcance de la auditoría ambiental y los perio-
dos de tiempo entre ellas, aspecto que guarda relación con los objetivos fijados.

1.7. Normas de auditoría

La norma NAGA concentra los principios fundamentales de auditoría que regulan el desempeño los audi-
tores durante el proceso de la auditoría. El cumplimiento de estas normas garantiza la calidad del trabajo
profesional del auditor.
NAGA está constituida por 10 normas adoptadas por el American Instituto Of Certified Public Accountants
(AICPA), las cuales se dividen en tres grupos:

1.- Generales.

Entrenamiento y capacidad profesional.

Independencia.
Cuidado o esmero profesional.
• La auditoría es realizada por un profesional, o grupo de ellos, con formación técnica y com-
petencia como auditor(es).
 • En todos los asuntos concernientes a ella, el auditor o los auditores mantendrán la indepen-
dencia de actitud mental.
• Debe ejercer el debido cuidado profesional al planear y efectuar la auditoría; así como al
preparar el informe.

2.- Ejecución del Trabajo.

Planeamiento y supervisión.
Estudio y evaluación del control interno.
Evidencia y competencia.
• El trabajo se planea adecuadamente y los asistentes, si los hay, serán supervisados rigurosa-
mente.
• Se obtiene un conocimiento suficiente del control interno, a fin de planear la auditoría y de-
terminar la naturaleza, alcance y extensión de otros procedimientos de la auditoría.
• Se obtiene evidencia suficiente y competente mediante la inspección, observación y confir-
mación, con el objetivo de tener una base razonable para emitir una opinión respecto a los
estados de los procedimientos.

3.- Información o preparación del informe.

Aplicación de los principios de administración generalmente aceptados.

Consistencia. Revelación Suficiente.
Opinión del Auditor.
• El informe indicará si los procedimientos están conforme a los principios de administración
generalmente aceptados.
• El informe especificará las circunstancias que no se observaron consistentemente en los prin-
cipios en el periodo actual respecto al anterior.
• Las revelaciones informativas de los procedimientos se considerarán razonablemente adecua-
das, salvo que el informe especifique lo contrario.
• El informe contendrá una expresión de opinión referente a los procedimientos tomados en
conjunto o una aclaración si no puede expresarse en una opinión. En este último caso, se
indicarán los motivos respectivos. En los casos en que el nombre de auditor se relacione con
los procedimientos, el informe incluirá una indicación clara del tipo de trabajo y del grado de
responsabilidad a asumir.

Estas 10 normas AICPA incluyen términos subjetivos de medición como: planeación adecuada, suficiente
conocimiento del control interno, evidencia y competencia, y revelación adecuada.
Para decidir en cada trabajo de auditoría qué es adecuado, suficiente y competente es necesario ejercer el
juicio profesional.
La auditoría no es un ejercicio de aprendizaje memorístico o mecánico, el auditor aplicará su juicio pro-
fesional en muchos momentos de cada proyecto. La formulación y publicación de normas rigurosamente
redactadas contribuyen a elevar la calidad de la auditoría, a pesar que su aplicación exija juicio profesional.
1.8. Clasificación y objetivos de auditoría
La verificación de los procedimientos es realizada por un profesional mediante la aplicación de procedimien-
tos de auditoría, y generará un documento llamado informe de auditoría, como resultado de las operaciones,
que mostrará la situación real de la organización, según los principios aceptados.
La organización es algo más que administración, en ella se toman decisiones no documentadas, que pueden
afectar a la organización.
La clasificación de la auditoría se puede clasificar de la siguiente manera:

1. Auditoría Externa: Es realizada por organismos independientes a la organización con la finalidad de

expresar una opinión de alguna actividad global o específica.

2. Auditoría Interna: Es realizada por miembros de la organización auditada, es una actividad de evalua-
ción establecida dentro de una entidad como un servicio a la misma. Las funciones incluyen, entre
otras, examinar, evaluar y supervisar la idoneidad y efectividad de los sistemas.

Los objetivos son:

Proporcionar a la dirección los procedimientos certificados por una organización independiente y ase-
soramiento en materia de los sistemas.

Suministrar información objetiva que sirva de base a las entidades de información y clasificación
crediticia.

Servir de punto de partida en las negociaciones para la compra/venta de acciones de una organización,
pues la información auditada, garantiza confiabilidad.

Reducir y controlar riesgos accidentales, fraudes y otras actuaciones anormales.

Sirve de base objetiva para determinar el gravamen fiscal.

1.9. Resultados esperados de la auditoría

Los resultados esperados de la auditoría son:

Establecer las normas relevantes a la organización.

Obtener un diagnóstico de la situación de la organización en materias de calidad y seguridad y salud

en el trabajo.

Evaluar las prácticas de gestión de la organización.

Proponer un conjunto básico de objetivos y metas para mejorar la gestión de la organización.

Definir la estructura apropiada a la realidad de la organización.

Definir las funciones dentro de la organización.

Proponer responsabilidades y mecanismos de comunicación.

Identificar los requerimientos de personal.

 Establecer los requerimientos de entrenamiento.
Proponer mecanismos de comunicación con las partes interesadas externas (clientes, instituciones pú-
blicas y privadas).
Identificar las unidades de proceso críticas desde el punto de vista de seguridad y salud en el trabajo.
Identificar las unidades de proceso críticas desde el punto de vista ambiental.
Identificar las unidades de proceso críticas desde el punto de vista de calidad del producto.
Identificar las unidades de proceso y/o equipos críticos que afectan la eficiencia operacional y que
deben ser reemplazadas o reparadas.
Identificar las opciones para reducir pérdidas de materiales y energía. Medidas concretas para la mini-
mización de residuos (como merma, reusó, reutilización, tratamiento y reproceso).
Identificar las opciones para mejorar la capacidad de supervisión y control de proceso, de registro y
evaluación de la información obtenida.
Recomendar la elaboración de procedimientos en aquellas actividades críticas en materia de calidad,
medio ambiente, seguridad y salud en el trabajo.
Recomendar indicadores de gestión apropiados para cantidad de insumos, residuos, materia prima y
horas-hombre por tonelada de producto, etc.
Identificar los criterios para mantenimiento preventivo y correctivo, prioridades y responsabilidades.

1.10. El Auditor
Es el profesional encargado de realizar la evaluación y recibe el nombre de auditor. Su trabajo consiste
en analizar atentamente las acciones de la organización y los documentos donde han sido registradas y
determinar si las medidas tomadas en los diferentes casos son adecuadas y han beneficiado a la organización.
El auditor puede ser una persona física o una jurídica. En este último caso, es una organización certificada
para la auditoría.
Un auditor puede ser externo (no pertenece a la organización) o interno (pertenece a ella). Ambos realizan
informes de auditoría, pero los válidos son realizados por la auditoría externa. Los internos son un mecanismo
de control en la propia organización.

1.11. Informe de auditoría

El informe de auditoría externa expresa una opinión no vinculante sobre las cuentas anuales o procedimientos
que presenta una organización.
Hay varios factores para entender los informes de auditoría:
Expresa una opinión del auditor. Es su percepción acerca de los procedimientos de la organización; no
es una verdad absoluta, y por tanto no es vinculante. Sin embargo, en muchas ocasiones estos informes
se tienen en cuenta como algo más que una opinión.
Trata sobre las cuentas o procedimientos anuales. Los estados que se auditan son el balance, la cuenta
de resultados, el estado de cambios en el patrimonio neto y el estado de flujos de efectivo.
1.11.1. La opinión del auditor
Hay diversas opiniones, todas en función de si, o no, son un reflejo de la organización:

Opinión limpia o sin salvedades: Las cuentas anuales auditadas son reflejo de la organización de
acuerdo al marco normativo de referencia.

Opinión con salvedades. El auditor encontró ciertas desviaciones en las cuentas anuales con respecto
al marco normativo de referencia y éstas, salvo por esa salvedad, son reflejo de la organización.

Opinión adversa o negativa. Existen desviaciones relevantes en la elaboración de los procedimientos

en relación con la norma de referencia.

Abstención u opinión denegada. Existe limitación del alcance del trabajo del auditor y no ha obtenido
evidencia suficiente para emitir un juicio que refleje la imagen fiel de la organización.

1.11.2. Importancia de los informes auditorías

A pesar que el informe de auditoría es una simple opinión no vinculante, lo cierto es que su importancia en
el marco organizacional es muy alta. Y se refleja en función de:

Obligatoriedad de elaborar informe de auditoría. En ocasiones, la ley establece que ciertas organiza-
ciones tienen la obligación de ser auditadas. Suele ocurrir con las organizaciones cotizadas. En este
caso, lógicamente el informe de auditoría alcanza relevancia, ya que es la información que tienen las
personas ajenas a la organización para comprobar si los procedimientos son fiables o no lo son.

No obligatoriedad de elaborar informe de auditoría. La mayoría de organizaciones no tienen el re-

quisito legal de ser auditadas. Sin embargo, muchas de ellas lo son, ya que terceros tienen una mayor
confianza en la organización si existe un informe de auditoría favorable. Un informe de auditoría puede
beneficiar a la organización: Al solicitar un préstamo bancario, al intentar captar nuevos accionistas,
etc.
 Metodología
2
La metodología es el procedimiento que establece, de forma ordenada y planificada, las etapas para alcan-
zar los objetivos establecidos por una auditaría en una organización y, por ello, es importante conocer su
desempeño cada ciertos períodos de tiempo, por lo general, años. Por medio de la metodología, se obtiene
la información exacta de los hechos que interesa conocer, avalando así la confiabilidad y veracidad de la
misma.
Durante el procedimiento metodológico se realiza un diagnóstico de desempeño, cuyo propósito es determi-
nar el estado actual de la organización, verificar las circunstancias en las que se encuentra y cómo llego a
ellas; además de tener una visión global de la problemática existente; por lo que a partir de esta realidad, se
sugiere un plan de acción de acuerdo con los resultados obtenidos.
En la fase de diagnóstico, se emplea la observación directa como técnica de la auditoría, para obtener datos
relevantes del desempeño de la organización. La modalidad de la observación es estructurada o sistemática,
ya que se establecen guías estructuradas para el levantamiento de información.
Se utiliza la entrevista como una técnica eficaz para obtener datos relevantes y significativos. Se opta por la
modalidad de entrevista estructurada, con el propósito de que los especialistas (contadores, administradores,
informáticos, ingenieros, arquitectos, entre otros) tengan la libertad de dar su opinión, proporcionen la infor-
mación requerida y porque su aporte es valioso en los resultados.
En cuanto al cuestionario, es estructurado y precodificado, donde las preguntas son formuladas para un fácil
llenado y cuidando no obviar ni olvidar preguntas, algunas respuesta son de selección para un rápido proce-
samiento y graficación para su interpretación, con el objetivo de recopilar los datos de forma estructurada,
para medir la percepción que tienen los empleados del desempeño de la organización.
Este capítulo es una descripción de la metodología empleada para el desarrollo de una auditoría, se describen
cada uno de los elementos utilizados, tales como: su tipo, las etapas para su cumplimiento y los instrumentos
para la recolección de los datos.
Describir el diseño de la auditoría, explica cómo se llevó a cabo la misma.

Resumir el tratamiento estadístico de los datos levantados, procesados. Validez, significancia.

Proporcionar información suficiente para que un lector competente repita la auditoría.

Presentar la información pertinente a los objetivos de la auditoría.

Presentar los hallazgos en una secuencia lógica.

11
 Mencionar todos los hallazgos relevantes, incluso aquellos contrarios a la hipótesis.

2.1. Control
Hoy, entre las diversas definiciones de auditoría, el concepto más generalizado parece ser de Arens y Loeb-
becke, [14], quienes la consideran ”...un proceso de acumular y evaluar evidencias, realizado por una persona
independiente y competente acerca de la información cuantificable de una entidad económica específica, con
el propósito de determinar e informar sobre el grado de correspondencia existente entre la información cuan-
tificable y los criterios establecidos,...” [11].
Por tanto, una 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 descubre fallas en las estructuras y/o vulnerabilidades en la or-
ganización. A pesar de los años y el desarrollo alcanzado por la profesión de auditor, el objetivo con que fue
creada la auditoría, consistente en la detección de los fraudes, malversación, mal desempeño, desvío y/o mal
uso de recursos de todo tipo, marcó la imagen negativa del auditor, aspecto que, lamentablemente, hasta hoy
no se ha superado.

2.2. Auditoría interna

La auditoría interna constituye una herramienta de apoyo a la dirección de las organizaciones, las que, gene-
ralmente, poseen un departamento especial dedicado a ello.
Este tipo de auditoría, denominado también auditoría de gestión u operativa, pone el énfasis en la evaluación
de políticas, procedimientos, métodos y el análisis de tareas.
Las características de la auditoría interna, presentada por Soy [12], parece ser la más convincente. Soy plan-
tea que esta debe:
Ser un órgano asesor de la Dirección.

Ser independiente dentro de la organización.

estar subordinado solamente a la Dirección,

Ser un control de controles.

Contribuir a la mejoría de la eficacia de la gestión mediante el perfeccionamiento de los procedimientos

y sistemas de información y gestión.
En cuanto a los objetivos de la auditoría interna, Soy establece que deben:
Mejorar la eficacia de la gestión por medio del perfeccionamiento de los procedimientos y sistemas,
de la información y control de los resultados de las decisiones adoptadas.

Proporcionar análisis, valoraciones y recomendaciones; aconsejar e informar en relación con las acti-
vidades realizadas.
De acuerdo con el IIA: ”...La auditoría interna es una actividad independiente y objetiva de aseguramiento
y consultoría diseñada para agregar valor y mejorar las operaciones de una organización; le ayuda a lograr
sus objetivos al presentar un enfoque sistemático y disciplinado para evaluar y mejorar la efectividad de la
gestión, el control y la gobernabilidad...”. Este enfoque sistemático y disciplinado se denomina metodología
de auditoría.
 Figura 2.1: Estructura sugerida para la auditoría interna.

Para facilitar su comprensión, la metodología se divide en dos fases:

1. Preparación de la auditoría anual. Debe aplicarse en un enfoque basado en el riesgo. Se tiene en cuenta
el riesgo corporativo, considerando ciclos de negocios, procesos operativos, programas, proyectos o
transacciones que se realizarán. La evaluación tiene como centro de atención aquellas situaciones
que aumentan el riesgo para la empresa, de no alcanzar sus objetivos estratégicos, toda vez que hay
limitaciones de horario y presupuesto.

2. Una vez definido el plan, se aborda una segunda fase. Ésta, se divide en tres etapas:

Planificación del trabajo.

Podría subdividirse en tres:
• Elaboración del memorando de planificación, donde se define el alcance de la auditoría, se
determina el equipo y, si es el caso, la necesidad de especialistas, se presupuestan los costos
del trabajo y se prepara un cronograma de auditoría. En este momento, se busca y recopila
información sobre el entorno corporativo, tal como políticas y procedimientos, matriz de
riesgos, organigramas, aplicaciones de sistemas de TI, etc.
• Comprensión detallada del objeto bajo evaluación. Entrevistas con quien toma la decisiones,
quienes las ejecutan, los tipos de transacciones. La idea es una imagen completa del proceso
bajo revisión, transacción por transacción. La formalización de la comprensión puede ser por
narrativa o por la forma gráfica utilizando un diagrama de flujo. En este paso, se preparan
la matriz de potenciales riesgos (inherentes, TI, fraude, etc.) y la matriz de control (que
identifica todos los controles existentes).
• Preparación de los procedimientos de auditoría y las técnicas: Aquellas que se aplicarán a
la evidencia de la efectividad del control del proceso auditado. Se cuenta con los siguientes
documentos de trabajo: memorando de auditoría, diagrama de flujo o narrativa del objeto
evaluado, matriz de riesgo, matriz de control y programa de auditoría.
Estas etapas se aplican a todos los tipos de trabajos de auditoría: cumplimiento, financieros u
operativos.
Ejecución y recolección de evidencias.
La siguiente etapa es la ejecución de la auditoría, también conocida como trabajo de campo. Es
 la aplicación de los procedimientos y técnicas necesarias para recopilar y formalizar la eviden-
cia, basada en los objetivos de auditoría predefinidos. Es necesario que todos los hallazgos de
la auditoría se relacionen en la matriz de hallazgos. Ésta, es el soporte para la preparación de
recomendaciones de auditoría.
Comunicación de resultados.
La sugerencia es dividir el reporte en tres documentos:
• opinión de auditoría,
• resumen ejecutivo y
• recomendaciones de auditoría. (Con un plan de acción, alineado con la gerencia)

Luego de la presentación del informe final, se debe verificar la implementación del plan de acción.
Toda la documentación obtenida durante una auditoría, en las diversas etapas, se considera un documento
de trabajo; por tal razón, debe ser revisada de manera apropiada por el auditor, para luego ser referenciada y
organizada en carpetas, bien en formato electrónico o físico.
Por supuesto, el trabajo de planeación es muy importante, ya que cuanto mejor se planifica el trabajo1 , la
ejecución es más eficiente y será de mejor calidad la opinión del auditor y en consecuencia los resultados de
la auditoría, cumpliendo su misión de agregar valor a la empresa.
No olvidar que un trabajo de auditoría finalizará cuando se implementen apropiadamente las recomendacio-
nes.

2.3. Auditoría externa

Como cualquier actividad social, la auditoría externa tiene sus propios objetivos y funciones, que son los
siguientes:

Obtención de elementos de juicio fundamentados en la naturaleza de los hechos examinados.

Medición de la magnitud de un error ya conocido, detección de errores supuestos o confirmación de

su ausencia.

Propuesta de sugerencias, en tono constructivo, para apoyar a la gerencia.

Detección de los hechos importantes ocurridos tras el cierre del ejercicio.

Control de las actividades de investigación y desarrollo.

Referente a este contexto, Slosse [13], plantea que ”...Una de las funciones más comunes de la auditoría
externa es brindar una opinión sobre las manifestaciones de la administración incluidas en la información
contable emitida por el ente...”.
La auditoría externa consiste en que una empresa ajena supervise que los estados financieros de una organi-
zación cumplen con la normativa específica.
La auditoría externa realiza un análisis y control exhaustivos, a través de un auditor, el cual es totalmente
ajeno a la actividad de la empresa, con el objetivo de emitir una opinión imparcial e independiente sobre el
sistema de operación de la empresa y su control interno. Además, la auditoría externa, formula sugerencias
de mejora en la organización.
1A veces una mini auditoría sorpresa es excelente.
La auditoría externa examina los sistemas de una empresa y emite una opinión independiente e imparcial de
los mismos.
El dictamen manifestado como resultado de la auditoría externa tiene plena validez y trascendencia frente
a terceros, ya que es un documento que se da bajo la figura de la fe pública, teniendo total credibilidad y
estando verificada toda la información en él reflejada.
La finalidad de la auditoría externa es dotar de razonabilidad y autenticidad los sistemas administrativos,
contables, de proceso y de información de una empresa en concreto. De esta manera, los usuarios de dicha
información (una entidad crediticia) puedan tomar decisiones confiando en las declaraciones plasmadas en
el informe de la auditoría externa. Consulta este listado las mejores empresas de auditoría externa.

2.3.1. Tipos de auditorías externas

La auditoría externa se ejecuta a requerimiento de organismos oficiales, clientes u organismos de certificación
(organizaciones privadas que certifican el cumplimiento de una norma de referencia).
Esta auditoría externa puede subdividirse del siguiente modo:

Auditorías de segunda parte. Solicitadas por un cliente de la empresa auditada, que le sirva de infor-
mación previa a la realización de una compra o contratación para corroborar que realmente la empresa
cumple con los requisitos legales.

Auditorías de tercera parte. Ejecutadas por una tercera parte independiente de la empresa auditada.
Como las auditorías de cuentas, reguladas en la Ley de Prevención de Riesgos Laborales o la de
certificación de los sistemas de gestión ISO 9001.

2.3.2. Auditorías externas de calidad

La auditoría externa de calidad se realiza por una empresa externa, independiente y autorizada con la finali-
dad de que la empresa auditada obtenga un certificado de sistema de gestión de calidad.
Cada vez son más las empresas que recurren a estas certificaciones que aumenta la confianza que dan a
clientes reales y potenciales. Además, estos certificados de calidad pueden ser requisito indispensable para
ciertos servicios que quiera ofrecer la compañía.
Las normas que hay que cumplir para tener un sistema de gestión de calidad certificado son las de la familia
ISO. En concreto la norma ISO 9001 es la que define lo que tiene que ser una auditoría externa de calidad.
Por tanto, la norma ISO 9001 dice que una autoría de calidad es un proceso sistemático, independiente y
documentado que tiene como objetivo comprobar que la empresa auditada cumple los requisitos necesario
para obtener un certificado de calidad.
Cuando una empresa requiere dichos certificados tiene que cumplir una serie de requisitos que previamente
conoce. Una vez preparada la empresa, llama a la auditora externa para que compruebe y otorgue o no el
certificado. Muchas veces, una empresa con una certificación de calidad tiene que renovarla y por eso las au-
ditorías externas suelen ser anuales. La ISO 19011:2011 trata sobre las directrices de los sistemas de gestión
de calidad y se publicó para facilitar las auditorías.

2.3.3. Funciones de la auditoría externa

La auditoría externa tiene como finalidad obtener la mayor cantidad de información posible de una organi-
zación, no sólo sobre los sistemas de gestión de información, sino sobre su estado financiero y comercial.
De esta manera, realiza un análisis y control exhaustivo sobre el desempeño de la empresa, así como la rea-
lización de un informe de auditoría fidedigno y veraz que entregará a terceras partes interesadas (ya sea un
inversor, comprador de un producto o una entidad crediticia).

2.3.4. El papel del auditor externo

Un auditor externo no tiene relación con la empresa que está auditando y por lo tanto proporciona una
evaluación independiente e imparcial de los procedimientos de la misma. También, revisa los sistemas de
información y la tecnología de la empresa para evaluar sus procesos internos en general.
Asimismo, el auditor examinará todas las interrogantes planteadas por las autoridades reguladoras.
Si el auditor externo tiene alguna relación con la empresa o sus empleados, revelará esta situación en su
informe final.
Los auditores externos profundizan en los procedimientos de la organización en busca de errores en los
cálculos y problemas o gastos superfluos. En muchos casos, es el auditor externo quien encuentra alguna
malversación de gastos y recursos de una empresa. También es posible que puedan encontrar situaciones
anómalas como robos o desfalcos a la compañía.
Las auditorías externas se realizan anualmente para garantizar el cumplimiento de las leyes y compromisos
con las leyes locales, regionales y/o nacionales. La auditoría observa las finanzas de la empresa y sus resul-
tados pueden ser utilizados por otras instituciones, tales como entidades financieras, las fiscalizadoras del
gobierno y los accionistas de la empresa en su asamblea anual.
El documento final del informe del auditor externo, examina la estabilidad financiera global de la empresa,
los gastos, las cuentas por cobrar, las cuentas por pagar y el uso de la tecnología en los procesos de la empre-
sa, para dar una visión global de la posición de la compañía en el mercado. Otro de los objetivos que se busca
al realizar las auditorías externas es verificar la legalidad de los estados financieros, los reportes económicos
de la compañía y su crecimiento o decrecimiento económico y financiero.

2.4. Diferencias entre auditoría externa e interna

A priori, son dos términos que pueden llevar a confusión, pero existen importantes diferencias entre ellas:

En la auditoría interna existe un vínculo laboral entre el auditor y la empresa; en la auditoría externa
la relación es de tipo civil.

En la auditoría interna, el resultado otorgado por el auditor es para la propia organización, para su uso
interno; en la auditoría externa, el dictamen se destina a terceros interesados en dicha información.

La auditoría interna está inhabilitada para dar fe pública, todo lo contrario con la auditoría externa.

Las auditorías externas se realizan después de que la auditoría interna de fin de año se ha llevado a cabo por
los auditores internos, como entes de control, de la propia compañía. Las diferencias entre los resultados de
la auditoría interna y externa deben ser igual a cero, a menos que se hubiesen producido cambios. Si han
ocurrido, la empresa debe revelar por qué se hicieron los cambios y por quién fueron realizados, y además
proporcionar una prueba válida del motivo de la modificación. En caso de que la empresa no pueda justificar
alguna diferencia entre los resultados de la auditoría interna y la externa, el auditor externo deberá alertar
sobre dichas diferencias.
2.5. Metodología para una auditoría administrativa
Tiene el propósito de servir como marco de actuación para que las acciones en sus diferentes fases de eje-
cución se conduzcan en forma programada y sistemática, unifiquen criterios y se delimite el alcance y pro-
fundidad con que se revisarán y aplicarán los enfoques de análisis administrativo para garantizar el manejo
oportuno y objetivo de los resultados.
La auditoría administrativa evalúa la forma en que la administración cumple sus objetivos y cómo desempeña
las funciones gerenciales de planeación, organización, dirección y control; logrando así decisiones efectivas
en el cumplimiento de los objetivos trazados por la organización.
También, facilita al auditor la identificación y ordenamiento de la información correspondiente al registro
de hechos, hallazgos, evidencias, transacciones, situaciones, argumentos y observaciones para su posterior
examen, informe y seguimiento.
Para utilizarla de manera lógica y accesible, la auditoría administrativa se ha dividido en etapas, cada una de
las cuales ofrecen criterios y lineamientos a observarse para que las iniciativas guarden correspondencia con
los planes.
Las etapas que integran esta metodología son:

1. Planeación.

2. Instrumentación.

3. Examen.

4. Informe.

5. Seguimiento.

2.6. Planeación
Se refiere a los lineamientos de carácter general que regulan la aplicación de la auditoría administrativa para
garantizar la cobertura de los factores prioritarios.
¿Qué cubre la planeación?

1. Objetivo.
Esta etapa define el propósito de la auditoría. Establece las acciones a desarrollar para instrumentarla
en forma secuencial y ordenada tomando en cuenta las variables de tiempo y forma.

2. Factores a revisar.
La primera medida es determinar los factores que se consideran fundamentales para la organización
en función de dos puntos:

El proceso administrativo.
Incorpora las etapas de su proceso y define los componentes que lo fundamentan, para realizar
un análisis lógico de la organización.
En este orden se apega a propósitos estratégicos que concentran en forma objetiva la esencia o ”
razón de ser” de cada fase.
 Los elementos específicos que forman parte de su funcionamiento.
Estos complementan el proceso administrativo. Estos elementos específicos se asocian con atri-
butos fundamentales que enmarcan su fin y función.

3. Fuentes de información.
El siguiente paso es realizar un ” reconocimiento” preliminar para determinar la situación de la orga-
nización.
Esta etapa implica revisar la literatura administrativa, técnica, legal y toda clase de documentos rela-
cionados y de interés.
Este procedimiento puede reformular objetivos, estrategias, acciones o tiempos de ejecución.
Para realizar esta tarea en forma adecuada debe:

Determinar las necesidades específicas.

Identificar los factores que requieren atención.
Definir estrategias de acción.
Jerarquizar prioridades en función del fin que se persigue
Describir la ubicación, la naturaleza y extensión de los factores.
Especificar el perfil del auditor.
Estimar el tiempo y recursos necesarios para cumplir con el objetivo definido.

Preparación del Proyecto

Con base en la información preliminar se prepara la información necesaria para instrumentar la audi-
toría, incluye dos apartados:

a) Propuesta Técnica:
Tipo: tipo de auditoría que se pretende realizar.
Alcance: Áreas de aplicación.
Antecedentes: Recuento de auditorías administrativas y estudios de mejoramientos previos.
Objetivos: Logros que se pretenden alcanzar con la aplicación de la auditoría administrativa.
Estrategia: Ruta fundamental para orientar el curso de acción y asignación de recursos.
Justificación: Demostración de la necesidad de instrumentarla.
Acciones: Iniciativas o actividades necesarias para su ejecución.
Recursos: Requerimientos humanos, materiales y tecnológicos.
Costo: Estimación global y específica de recursos financieros necesarios.
Resultados: Beneficios que se espera lograr.
Información complementaria: Material e investigaciones que sirven como elementos de
apoyo.
b) Programa de Trabajo:
Identificación: Nombre de la auditoría.
Responsable(s): Auditor a cargo de su implementación.
Área(s): Universo bajo estudio.
Clave: Número progresivo de las actividades estimadas.
 Actividad(es): Pasos específicos para captar y examinar la información.
Fases: Definición del orden secuencial para realizar las actividades.
Calendario: Fechas asignadas para el inicio y término de cada fase.
Representación gráfica: Descripción de las acciones en cuadros e imágenes.
Formato: Presentación y resguardo de avances,
Reportes de avance: Seguimiento de las acciones.
Periodicidad: Tiempo dispuesto para informar avances.

4. Investigación preliminar.

5. Preparación del proyecto de auditoría.

6. Diagnóstico preliminar.

2.7. Asignación de la responsabilidad

Para iniciar formalmente la auditoría, la organización designará al auditor o auditores que estime convenien-
te, atendiendo la magnitud o grado de complejidad de la misma.
La designación como responsable puede recaer en el titular del órgano de control interno, en el encargado de
alguna unidad de apoyo técnico o en un directivo de las áreas de la organización, partiendo de la base que
tenga los conocimientos y experiencia necesarios en la realización de la auditoría administrativa.

2.8. Capacitación
Un vez definida la responsabilidad, se capacitará a las personas o equipo designado, no sólo en lo que res-
pecta al manejo de los medios de levantamiento de información, sino en todo el proceso para la aplicación e
instrumentación de la auditoría.
Por lo anterior, debe dar a conocer a este personal el objetivo buscado, las áreas involucradas, la calenda-
rización de actividades, los documentos de soporte, el inventario estimado de la información a captar, la
distribución de cargas de trabajo, el registro de la información, la forma de reportar, y los mecanismo de
coordinación y de reporte establecidos.

2.9. Actitud
La labor de investigación tiene que ejecutarse sin perjuicios u opiniones preconcebidas por parte del auditor.
Es recomendable que los auditores adopten una conducta diplomática, amable y discreta, a fin de procurar
una imagen positiva; lo que facilitará su tarea y estimulará la participación activa del personal de la organi-
zación.
Con el propósito de evitar crear falsas expectativas, es importante que el equipo de auditores se abstenga de
hacer comentarios sin sustento, o de hacer promesas que no puedan cumplir, apegándose en todo momento
a las directrices de la auditoría en forma objetiva.
2.10. Diagnóstico preliminar
Esta fase se fundamenta en la percepción que el auditor tiene sobre la organización como producto de su
visión.
Si bien no existen elementos de juicio documentados, existe un acercamiento a la realidad y a la cultura
organizacional.
En base a este conocimiento se prepara un marco referencial que fundamente la razón para realizar una
auditoría.
Considere los siguientes elementos:

Origen de la organización:

• Creación.
• Cambios en su forma jurídica.
• Conversión del objeto en estrategias.
• Manejo de la delegación de facultades.

Infraestructura:

• Esquema de operación (procesos/funciones)

• Modificaciones a la estructura organizacional.
• Programación institucional.
• Nivel de desarrollo tecnológico.

Forma de operación:

• Desempeño registrado.
• Logros alcanzados.

2.10.1. Instrumentación
Concluida la parte preparatoria se procede a la instrumentación de la auditoría, etapa en la que seleccionan
y aplican las técnicas de recolección que se estimen más viables; de acuerdo con las circunstancias propias
de la auditoría, la medición que se empleará el manejo de los papeles de trabajo y la evidencia, así como la
supervisión necesaria para mantener una coordinación efectiva.

2.10.2. Recopilación de información

Esta tarea debe enfocarse al registro de todo tipo de hallazgos y evidencias que haga posible su examen obje-
tivo; de otra manera, puede incurrir en errores de interpretación que causen retrasos u obliguen a recapturar
la información, reprogramar la auditoría o, en su caso, a suspenderla.
Asimismo, es conveniente aplicar un criterio de discriminación, teniendo siempre presente el objetivo del
estudio, y proceder continuamente a su revisión y evaluación, para mantener una línea de acción uniforme.
2.10.3. Técnicas de recolección
Para recabar la información requerida en forma expedita y ordenada, puede emplear alguna, o una combina-
ción, de las siguientes técnicas.

1. Investigación documental
Consiste en la localización, selección y estudio de la documentación que puede aportar elementos de
juicio a la auditoría. A las fuentes documentales básicas a las que se pueden acudir son:
Normativa

a) Acta constitutiva.
b) Ley que ordena la creación de la organización.
c) Reglamento interno.
d) Reglamentación especifica.
e) Tratados y convenios.
f ) Decretos y acuerdos.

Administrativos

a) Organigramas.
b) Manuales de normas y procedimientos.
c) Sistemas de Información.
d) Sistemas de normalización y certificación.
e) Cuadros de distribución de trabajo.
f ) Plantillas de personal.
g) Inventarios de mobiliario y equipo.
h) Auditorías administrativas previas.

Mercado

a) Productos y servicios.
b) Áreas (población ingresos factores limitantes).
c) Comportamiento de la demanda (situación actual, situación futura proyectada, característica).
d) Comportamiento de la oferta situación actual, situación futura (previsible), análisis del régimen
de mercado.
e) Determinación de precios.

Ubicación geográfica

a) Localización.
b) Ubicación espacial interna.
c) Características.
d) Del terreno.
e) Distancias y costo de trasporte.
 f ) Justificación en relación con el tamaño y los procesos.

Estudios financieros

a) Recursos financieros para inversión.

b) Análisis y proyecciones financieras.
c) Programas de financiamiento.
d) Evaluación financiera.

Situación económica

a) Sistema económico.
b) Naturaleza y ritmo de la del desarrollo de le economía.
c) Aspectos sociales.
d) Variables demográficas.
e) Relaciones con el exterior.

2. Observación directa.
Es el acercamiento y revisión del área física donde se desarrolla el trabajo de la organización, para
conocer las condiciones de trabajo y el clima organizacional imperante. Es recomendable que el auditor
responsable presida la observación directa, comente y discuta su percepción con su equipo de trabajo;
de esta manera, asegurará que exista un consenso en torno a las condiciones de funcionamiento del
área y definirá los criterios a los que deberá sujetarse la auditoría en todo momento.

3. Acceso a redes de información.

4. Entrevistas.
Consiste en reunirse con una o varias personas y cuestionarlas para obtener información. Este medio,
es posiblemente, el más empleado y uno de los que puede brindar información más completa y precisa,
puesto que el entrevistador, al tener contacto con el entrevistado, además de obtener respuestas, puede
percibir actitudes y recibir comentarios.

5. Cuestionarios.
Se emplean para obtener la información deseada en forma homogénea. Están constituidos por una
serie de preguntas escritas, predefinidas, secuenciales y separadas por capitulo o temáticas específicas.
La calidad de la información que obtenga, dependerá de su estructura y forma de presentación.

6. Cédulas.
Se utilizan para captar la información requerida de acuerdo con el propósito de la auditoría. Están
conformadas por formularios cuyo diseño incorpora casillas, bloques y columnas que facilitan la agru-
pación y división de su contenido para su remisión y análisis, también abren la posibilidad de ampliar
el rango de respuestas.

7. Medición.
Para consolidar la instrumentación, es necesario que los hechos se puedan evaluar relacionándolos con
una medida, la cual parte de los indicadores establecidos para el proceso administrativo y de los ele-
mentos específicos; así como del propósito estratégico y atributos fundamentales asociados con uno y
 con otro. La escalas que se empleen con este fin, cumplen con la función de garantizar la confiabilidad
y validez de la información que se registra en los papeles de trabajo, y que, posteriormente, servirán
para comprobar la veracidad de las observaciones, conclusiones y recomendaciones contenidas en el
informe de la auditoría.

8. Papeles de trabajo.
Para ordenar, agilizar e dar coherencia a su trabajo, el auditor utiliza lo que se denomina papeles de
trabajo; son los registros que describen las técnicas y procedimientos aplicados, las pruebas realizadas,
la información obtenida y las conclusiones alcanzadas.
Estos papeles son el soporte principal que, en su momento, el auditor incorporará en su informe,
ya que incluyen observaciones, hechos argumentos para respaldarlos; además, apoyan la ejecución y
supervisión del trabajo. Deben de formularse con claridad y exactitud, considerando los datos referen-
tes al análisis, comprobación, opinión y conclusiones sobre los hechos, transacciones, o situaciones
detectadas. También se indicaran las desviaciones que presentan respecto de los criterios, normas o
previsiones de presupuesto, en la medida que esta información soporte la evidencia; la cual valida las
observaciones, conclusiones y recomendaciones contenidas en el informe de auditoría.
El auditor preparará y conservará los papeles de trabajo cuya forma y contenido dependen de las con-
diciones de aplicación de la auditoría, ya que son el testimonio del trabajo efectuado y el respaldo de
sus juicios y conclusiones.
Los papeles de trabajo tienen que elaborarse sin perder de vista que su contenido debe incluir:

9. Identificación de la auditoría.

a) El proyecto de auditoría
b) Índices, cuestionarios, cédulas y resúmenes del trabajo realizado.
c) Indicaciones de las observaciones recibidas durante la aplicación de la auditoría.
d) Observación acerca del desarrollo de su trabajo.
e) Anotaciones sobre información relevante.
f ) Ajustes realizados durante su ejecución.
g) Reporte de posibles Irregularidades.
h) Lineamientos recibidos por área o fase de la aplicación.

Para homogenizar su presentación e información, y facilitar el acceso a su consulta, los papeles de

trabajo no deben sobrecargarse con referencias operativas sino consignar los tópicos relevantes, estar
redactados en forma clara y ordenada, y lo suficientemente sólidos en sus argumentos para que cual-
quier persona, o revisor, siga la secuencia del trabajo. Asimismo, son un elemento probatorio de que la
evidencia obtenida y si los procedimientos y técnicas empleados son suficientes y competentes. Aun-
que los papeles de trabajo que prepara el auditor son confidenciales, podrá proporcionarlos cuando
reciba una orden o citatorio para presentarlos, por lo que debe resguardarlos por un periodo de tiempo
determinado por la ley, para cualquier aclaración o investigación que pudiera emprenderse y, tomando
en cuenta su utilidad, para auditorías subsecuentes.

10. Evidencia.
Es la comprobación fehaciente de los hallazgos durante el ejercicio de la auditoría, por lo que consti-
tuye un elemento relevante para fundamentar los juicios y conclusiones que formula el auditor. Por tal
 motivo, al reunirla se debe prever el nivel de riesgo, incertidumbre y conflicto que pueda traer consigo,
así como el grado de confiabilidad, calidad y utilidad real que debe tener; en consecuencia, es indis-
pensable que el auditor se apegue en todo momento a la línea de trabajo acordada, a las normas en la
materia y a los criterios que durante el proceso de ejecución vayan surgiendo.
La evidencia se clasifica en:
Física: Se obtiene mediante inspección u observación directa de las actividades, bienes o sucesos,
y se presenta a través de notas, fotografías, cuadros, mapas o muestras materiales.
Documental: Se obtiene por medio del análisis de documentos y está contenida en cartas, con-
tratos, actas, minutas, facturas, recibos y toda clase de comunicación producto del trabajo.
Testimonial: Se consigue de toda persona que realice declaraciones durante la aplicación de la
auditoría.
Analítica: Comprende cálculos, comparaciones, razonamientos y desagregación de la informa-
ción por áreas, apartados o componentes.
Para que la evidencia sea útil y valida debe ser:
a) Suficiente: es la necesaria para sustentar los hallazgos, conclusiones y recomendaciones del au-
ditor.
b) Competente: cumple con ser consistente, convincente, confiable, y ha sido validada.
c) Relevante: aporta elementos de juicio para demostrar o refutar un hecho de forma lógica y clara.
d) Pertinente: existe congruencia entre las observaciones, conclusiones y recomendaciones de la
auditoría.
Es fundamental que el auditor documente y reporte al responsable de la unidad de control interno, al
titular de la organización y/o al líder del proyecto las siguientes situaciones:
a) Problemas para obtener una evidencia suficiente, producto de los registros incorrectos, operacio-
nes no registradas., archivos incompletos y documentación inadecuada o alterada:
b) Transacciones realizadas fuera del curso normal
c) Limitaciones para acceder a los sistemas de información.
d) Registros incongruente con las operaciones realizadas
e) Condicionamiento de las áreas para suministrar evidencias
En todas las oportunidades, el auditor procederá con prudencia, preservando su integridad profesional
y conservando los registros de su trabajo, incluyendo los elementos comprobatorios de las inconsis-
tencias detectadas.
11. Supervisión del trabajo.
Para tener la seguridad de que se sigue y respeta el programa aprobado, es necesario ejercer una
estrecha supervisión sobre el trabajo que realizan los auditores, delegando la auditoría sobre quien
posea experiencia, conocimiento y capacidad.
De esta manera, a medida que se descienda el nivel de responsabilidad, el auditor que encabece una
tarea, tendrá siempre la certeza de dominar el campo de trabajo y los elementos de decisión para vigilar
que las acciones obedezcan a una lógica en función de los objetivos de auditoría.
La supervisión, en las diferentes fases de ejecución de la auditoría, comprende:
 a) Revisión del programa de trabajo.
b) Vigilancia constante y cercana al trabajo de los auditores.
c) Aclaración oportuna de dudas.
d) Control del tiempo invertido en función del estimado.
e) Revisión oportuna y minuciosa de los papeles de trabajo.
f ) Revisión final del contenido de los papeles de trabajo para cerciorarse de que están completos y
cumplen con su propósito.

Para llevar a cabo la supervisión en forma consistente y homogénea es conveniente observar los si-
guientes criterios.

a) Asegurarse de que existe coincidencia en las líneas fundamentales de investigación en todo el

equipo de auditores
b) Supervisar constantemente el trabajo de los auditores para atender cualquier duda.
c) Revisar el trabajo realizado y efectuar las observaciones y ajustes pertinentes.
d) Efectuar cambios en el equipo de auditores cuando prevalezcan actitudes negativas o no se apli-
quen las líneas de investigación definidas.
e) Celebrar reuniones periódicamente para mantener actualizado a los auditores e instruirlos para
mejorar su desempeño.

Así mismo, es importante que la supervisión del trabajo contemple, que:

a) los reportes de hallazgos deben contar con un espacio para la firma de revisión del auditor res-
ponsable.
b) aquellos documentos que no cuenten con esta firma sean sometidos a revisión y no se aprueben
en tanto no lo autorice el auditor responsable.
c) los papeles de trabajo incluyan las anotaciones del auditor responsable para garantizar las con-
clusiones.
d) Lleve una bitácora que describa el comportamiento de los auditores.
e) Prepare un informe con los logros y obstáculos durante la auditoría.
f ) Elabore una propuesta general que destaque las contribuciones esenciales detectadas y el camino
para instrumentarlas.

En resumen, la instrumentación determina cómo recopilar la información a través de las técnicas de re-
colección como la investigación documental, la observación directa, el acceso a redes de información,
entrevistas, cuestionarios, y cédulas, y toma en cuenta los aspectos de medición como indicadores y
escalas, los papeles de trabajo del auditor, la evidencia que sustenta los hallazgos y la supervisión del
trabajo en sus diferentes modalidades.

12. Examen.
Establece el propósito, procedimiento y las variables cuantitativas seleccionadas para revisar la infor-
mación captada y la formulación del diagnóstico administrativo, en el cual se incorporan los aspectos
para evaluar los hechos, las tendencias y situaciones para consolidar un modelo analítico de la organi-
zación.
 El examen de los factores de la auditoría consiste en dividir o separar sus elementos/componentes
para conocer la naturaleza, las características y el origen de su comportamiento, sin perder de vista la
relación, interdependencia e interacción de las partes entre sí y con el todo, y con su contexto.

13. Propósito.
Aplicar las técnicas de análisis procedentes para lograr los objetivos propuestos en la oportunidad,
extensión y profundidad que requiere la empresa; así como las circunstancias específicas del trabajo,
a fin de reunir los elementos de decisión óptimos.

14. Procedimiento
El examen provee de una clasificación e interpretación de hechos, diagnóstico de problemas, así como
los elementos para evaluar y racionalizar los efectos de un cambio.
El procedimiento de examen consta de los siguientes pasos:

a) Conocer el hecho que se analiza.

b) Describir ese hecho.
c) Descomponerlo para percibir todos sus componentes y detalles.
d) Revisar cada componente, críticamente, para comprenderlo mejor.
e) Ordenar según el criterio de clasificación, seleccionado, haciendo comparaciones y buscando
analogías y discrepancias de cada componente.
f ) Definir las relaciones individuales, y en conjunto, de los componentes.
g) Identificar y explicar su comportamiento para entender las causas que lo originaron y como
atenderlo.

El enfoque para consolidar el examen consiste en adoptar una actitud interrogativa y formular de
manera sistemática seis preguntas:

a) ¿Qué trabajo se hace? Naturaleza o tipo de labores que realizan.

b) ¿Por qué se hace? propósitos que se pretende alcanzar.
c) ¿Quién lo hace? Personal que interviene.
d) ¿Cómo se hace? Métodos y técnicas que se aplican.
e) ¿Con qué se hace? Equipos e instrumentos que se utilizan
f ) ¿Cuándo se hace? Estacionalidad, secuencia y tiempos requeridos.

Después de obtener respuestas claras y precisas para esas preguntas. Se plantea un nuevo interrogatorio
con la pregunta ¿Por qué? en varias ocasiones, de manera consecutiva. Con lo que el examen se vuelve
más crítico, donde las nuevas respuestas abre una perspectiva cada vez mas profunda en cuanto a las
alternativas para respaldar las conclusiones y juicios del auditor. (Franklin 2003 pp.73).

15. Técnicas de análisis administrativos.

Son los instrumentos de apoyo del auditor para complementar sus observaciones, y le posibilitan:

a) Comprobar cómo se están ejecutando las etapas del proceso administrativo.

b) Evaluar cualitativa y cuantitativamente los indicadores establecidos.
c) Examinar los resultados que está obteniendo la organización.
 d) Revisar las circunstancias que inciden en los resultados.
e) Verificar los niveles de efectividad.
f ) Conocer el uso de los recursos.
g) Determinar la medida de consistencia en procesos específicos.

Entre las técnicas que se utilizan para realizar el análisis están las siguientes:

a) Organizacionales:
1) Administración por objetivos
2) Análisis de sistemas
3) Análisis de costo beneficio
4) Análisis de estructura
5) Árbol de decisiones
6) Autoevaluación
7) Control total de la calidad
8) Diagrama de causa y efecto
9) Control de calidad
10) Diagrama de pareto
11) Benchmarking
12) Empowerment
13) Estudio de factibilidad
14) Estudio de viabilidad
15) Inteligencia emocional
16) Reingeniería organizacional
17) Reorganización
b) Cuantitativas:
1) Análisis de serie de tiempos
2) Cadena de eventos
3) Modelo de inventarios
4) Modelos integrados de producción
5) Muestreo
6) Programación dinámica
7) Programación lineal
8) Teoría de las colas o de líneas de espera
9) Teoría de las decisiones. .(Franklin 2003 pp.74).

16. Formulación del diagnóstico administrativo.

Es parte esencial de la auditoría administrativa, es un recurso que traduce los hechos y circunstancias
en información concreta, susceptible de cuantificarse y calificarse. También, es una oportunidad para
diseñar un marco legal de análisis; sistematizar la información de la realidad de una organización,
establecer la naturaleza y magnitud de sus necesidades; identificar los factores más relevantes de su
 funcionamiento; determinar los recursos disponibles en la resolución de problemas; y, sobre todo, sir-
ven a las acciones necesarias que ofrezcan su atención efectiva.
El diagnóstico es un mecanismo de estudio y aprendizaje, toda vez que fundamenta y transforma las
experiencias y los hechos en conocimiento administrativo, a la vez que evalúa tendencias y situa-
ciones para formular una propuesta interpretativa, o modelo analítico, de la realidad de la organiza-
ción.(Franklin 2003 pp.79).

17. Informe
Al finalizar el examen de la organización, el auditor preparará un informe, en el cual se consignen los
resultados de la auditoría; identificando el área, sistema, programa, proyecto, el objeto de la revisión,
la duración, alcance, recursos y métodos empleados.
Este documento señalará los hallazgos, las conclusiones y recomendaciones de la auditoría, por lo
que es indispensable que ofrezca información suficiente respecto a la magnitud y frecuencia de los
hallazgos que se presentan, dependiendo del número de casos o transacciones revisadas en función de
las operaciones que realiza la organización. Así mismo, es importante que tanto los hallazgos como las
recomendaciones estén sustentados por evidencia relevante, debidamente documentada en los papeles
de trabajo del auditor.
Los resultados, las conclusiones y recomendaciones deberán concentrar:

a) Objetividad: visión imparcial de los hechos.

b) Oportunidad. disponibilidad en tiempo y lugar de la información.
c) Claridad: fácil comprensión del contenido.
d) Utilidad: provecho que puede obtenerse de la información.
e) Calidad: apego a las normas de calidad y a los elementos del sistema de calidad en materia de
servicios.
f ) Lógica: Secuencia acorde con el objeto y prioridades establecidas.

El informe constituye un factor invaluable porque posibilita conocer si los instrumentos y criterios con-
templados fueron acordes con los objetivos propuestos, y deja abierta la alternativa de su presentación
previa a la dirección de la organización para conocer los resultados obtenidos, particularmente cuando
se requieren elementos probatorios, o de juicio, que no fueron captados en la aplicación de la auditoría.
Así mismo, establece las condiciones necesarias para su presentación e instrumentación. En caso de
una modificación significativa, derivada de evidencia relevante, el informe tendrá que ajustarse.

18. Aspectos operativos

Antes de presentar la versión definitiva del informe, es necesario revisarlo en términos prácticos, par-
tiendo de las premisas acordadas para orientar las acciones que se llevaron a cabo en forma operativa.
Para este aspecto, es aconsejable ajustarse al siguiente orden:

a) Introducción: Criterios que se contemplaron para comprender e interpretar la auditoría.

b) Antecedentes: Información que enmarca la génesis y situación actual de la organización.
c) Justificación: Elementos que hicieron necesaria su aplicación.
d) Objetivos de la auditoría: Razones por las que se efectuó la auditoría y fines que se persiguen
con el informe.
 e) Estrategia: Curso de acciones seguidas y recursos ejercidos en cada uno de ellos.
f ) Recursos: Medios humanos, materiales y tecnológicos empleados.
g) Costos: Recursos financieros usados en el desarrollo.
h) Alcance: Ámbito, profundidad y cobertura del trabajo.
i) Acciones: Pasos o actividades realizados en cada etapa.
j) Metodología: Marco de trabajo, técnicas e indicadores en el que se sustentó la auditoría.
k) Resultados. Hallazgos significativos y evidencia suficiente que los sustenta.
l) Conclusiones: Inferencias basadas en las pruebas obtenidas.
m) Recomendaciones: Señalamientos para mejorar la operación y el desempeño.
n) Alternativas de implantación: programas y método viables.
ñ) Desviaciones significativas: Grado de cumplimiento de las normas aceptadas para la auditoría.
o) Opiniones de los responsables de las áreas auditadas: Puntos de vistas externos acerca de los
hallazgos, conclusiones y recomendaciones.
p) Asuntos especiales: aspectos que se requieren de un estudio profundo. ( Franklin 2003 pp. 82).
19. Lineamientos generales para su preparación.
a) No perder de vista el objeto de la auditoría cuando se llegue a las conclusiones y recomendaciones
finales.
b) Ponderar las soluciones que propongan para hacerlas prácticas y viables.
c) Explorar las diferentes alternativas para inferir las causas y efectos inherentes a los hallazgos, y
traducirlas en recomendaciones preventivas o correctivas, según sea el caso.
d) Homogenizar las integración y presentación de los resultados para que exista coherencia entre
los hallazgos y los criterios para su creación.
e) Aprovechar todo el apoyo posible para fundamentar sólidamente los resultados.
f ) Ofrecer a los niveles de detención los elementos idóneos para una toma de decisiones objetiva y
consistente.
g) Sentar las bases para la constitución de un mecanismo de información permanente.
h) Crear conciencia en los niveles de decisión de la importancia que reviste el no cumplir, o hacerlo
extemporáneamente, con las medidas recomendadas.
i) Establecer la forma y contenido que deberán observar los reportes y seguimientos de las acciones.
j) Tomar en cuenta los resultados de auditorías realizadas con anterioridad, para evaluar el trata-
miento y cursos de acción tomados en la obtención de resultados.
Es conveniente que antes de emitir el informe, una persona independientemente a la aplicación de la
auditoría, revise los borradores y los papeles de trabajo, a fin de verificar que han cumplido con todas
las normas de auditoría.
20. Presentación del informe
Un vez que el informe ha quedado estructurado, el responsable de auditoría convocará al grupo auditor
para efectuar la revisión de su contenido; en caso de detectar algún aspecto susceptible de enriquecer
o aclarar, realizará los ajustes necesarios para depurarlos. Cuando ya se cuente con el informe final, se
procederá a su entrega y presentación a:
 a) Titular de la organización.
b) Órgano de gobierno.
c) Niveles directivos.
d) Mandos medios y nivel operativo.
e) Grupos de filiación, corporativos o sectoriales.

La presentación del informe puede realizarse con el apoyo de equipos de computación, láminas o
material audiovisual.
En el informe se registran los resultados de la auditoría, los aspectos operativos acordados para orientar
su ejecución y los lineamientos generales para su preparación.

2.11. Seguimiento y supervisión

El seguimiento consiste en elaborar un plan de trabajo conjuntamente con los directivos de la empresa, donde
se refleje los lineamientos generales para desarrollar una implementación de mejoras orientadas corregir las
debilidades encontradas para evitar su recurrencia e incumplimiento. En este plan de trabajo se determinarán
las acciones específicas a implementarse, objetivos, alcance y plazos para el cumplimiento oportuno de las
recomendaciones proporcionadas en el informe de auditoría. Se deberá incluir programas de información
sobre la naturaleza, propósito de las recomendaciones a implementarse con el fin de eliminar obstáculos y
evitar las resistencias al cambio por parte del personal. La estrategia utilizada para el supervisión de reco-
mendaciones se puede enfocar en tres tipos de criterios:

1. supervisión Corporativa.- Cuando las recomendaciones comprometen a los directivos para su respec-
tiva actuación.

2. supervisión Funcional.- Cuando las recomendaciones involucran a los jefes de los departamentos de
una empresa, para realizar un control de las acciones correctivas.

3. supervisión Operativa.- Cuando las recomendaciones involucran al personal operativo debido a su

relación y vinculación con las operaciones empresariales.
 Auditoría en informática
3
3.1. Concepto
Los orígenes de la palabra informática provienen del idioma francés, informatique que se refiere a la infor-
mación automática, el término fue adoptado entre 1966 y 1967 por la Academia Francesa, quien la elevó al
grado de ciencia de la siguiente forma: ”Ciencia del tratamiento sistemático y eficaz, realizado especialmente
mediante máquinas automáticas de la información”.
Existen diferentes conceptos de informática, pero todos convergen en el tratamiento sistemático de la infor-
mación a través de diferentes recursos tecnológicos.
El concepto de auditoría en informática de Aguirre Bautista [16] es el siguiente:
La Auditoría en Informática se refiere a la revisión práctica que se realiza sobre los recursos in-
formáticos con que cuenta una entidad, con el fin de emitir un informe y/o dictamen profesional
sobre la situación en que se desarrollan y se utilizan dichos recursos.
La revisión que se lleva acabo sirve para comprobar el aprovechamiento de los recursos informáticos que
abarcan los siguientes elementos: información, aplicaciones (software), infraestructura (hardware, telecomu-
nicaciones, etc.) y recursos humanos.
Dicha revisión sirve para describir las circunstancias en que se encuentran los recursos informáticos y cómo
se utilizan; a esta descripción se le conoce como Informe de auditoría, posteriormente el auditor tiene que
emitir una opinión profesional acerca de dicho Informe, la cual se conoce como dictamen, que resume los
hallazgos encontrados durante la auditoría y el juicio del auditor que puede o no ser favorable a la entidad,
empresa u organización.
Aunque en la actualidad se realizan diversos tipos de auditoría, no todas emiten una opinión sobre algún
registro, sistema, operación o actividad en particular o con fines específicos. Para lo cual es necesario revisar
la diferencia entre auditoría informática y las auditorías administrativas y contables.
Normalmente la ASI se aplica de 2 formas distintas: se auditan las principales áreas del departamento de
informática y por otro se auditan las aplicaciones.

3.2. Diferencias
Para establecer las diferencias básicas de las auditorías según su área de aplicación revise los conceptos de
auditoría administrativa, contable, ambiental e informática. Ver tabla 3.1.

31
 Tabla 3.1: Diferencias entre algunas auditoría.
auditoría administrativa
Auditoría contable
”Revisión sistemática y exhaustiva que se realiza a la actividad
administrativa de una empresa, en cuanto a su organización,
las relaciones entre sus integrantes y el cumplimiento de las
funciones y actividades que regulan sus operaciones” (Muñoz,
[18]).
”Examen de los estados financieros de una entidad, con objeto
de que el contador público independiente emita una opinión
profesional respecto a si dichos estados presentan la situación
financiera, los resultados de las operaciones, las variaciones en
el capital contable y los cambios en la situación financiera de
la empresa, de acuerdo con los principios de contabilidad ge-
neralmente aceptados” (Comisión de Normas y Procedimien-
tos, en Téllez, [19]).

La auditoría administrativa evalúa la administración en todas las etapas del proceso administrativo: planea-
ción, organización, dirección, integración y control; mientras que la auditoría contable evalúa la situación
financiera de ambas áreas (administrativa y contable); se complementan con la auditoría en informática ya
que los recursos informáticos como soporte a las funciones de la administración y la contaduría.
La siguiente tabla contrapone las tres auditorías para hacer una comparación de diferencias y similitudes
según sus propiedades. Ver tabla 3.2.
 Tabla 3.2: Algunas de la auditorías actuales
PROPIEDADES Auditoría adminis- Auditoría contable Auditoría ambien- Auditoría informá-
trativa tal tica
NATURALEZA Técnica de control Técnica de control Técnica de control Técnica de control
administrativo administrativo
PROPÓSITO / OB- Evaluar y mejorar Dictamen a los es- Determinar las re- Evaluar los recur-
JETIVO la administración tados financieros gulaciones legales sos informáticos
en protección y
preservación del
medio ambiente.
ALCANCE La eficiencia y pro- El sistema contable La evaluación Todas las activida-
ductividad de los de la gestión de des informáticas
procesos adminis- protección del
trativos medio ambiente y
cumplimiento de
las disposiciones
reglamentarias en
vigencia.
FUNDAMENTO La ciencia adminis- Principios de con- Regular el uso Normatividad ins-
trativa y la normati- tabilidad y normas y tratamiento titucional y legal,
vidad de la empresa de auditoría adecuado del me- estándares interna-
dio ambiente y cionales
la protección de
la ecología del
planeta.
METODOLOGÍA Sustentado en los Sustentado en los Técnicas y proce-
métodos científicos métodos científi- dimientos predeter-
cos. minados
APLICACIÓN A la empresa y sus A los estados finan- A todas las áreas, A todas las áreas de
funciones básicas cieros internas y externas, la empresa
de la empresa
PROYECCIÓN Al futuro Al pasado Al pasado y futuro Al pasado y futuro
INFORME Amplio Preciso Amplio y preciso Amplio y preciso

Método científico1

3.3. Importancia
Siempre ha existido la preocupación en las organizaciones de optimizar todos los recursos con los que cuen-
ta; sin embargo, en lo que respecta a la tecnología de informática, es decir, software, hardware, sistemas de
información, investigación tecnológica, redes locales, bases de datos, ingeniería de software, telecomunica-
ciones, etc., como una herramienta estratégica que significa rentabilidad y ventaja competitiva frente a sus
similares en el mercado, en el ámbito de los sistemas de información y tecnología un alto porcentaje de las
1 Técnicas y procedimientos predeterminados, Investigación, la interrogación, el cálculo, la verificación, el análisis, la compara-
ción
empresas tiene problemas en el manejo y control, tanto los datos como los elementos que almacena, procesa
y distribuye son privados.
El propósito de la revisión de la auditoría en informática es verificar que los recursos, es decir, información,
aplicaciones, infraestructura, recursos humanos y presupuestos, sean adecuadamente coordinados y vigila-
dos por la gerencia o por quien ellos designen.
Durante años se ha detectado el despilfarro de los recursos o uso inadecuado de los mismos, especialmente
en informática, porque se ha mostrado interés por llegar a la meta sin importar el costo y los problemas de
productividad.

3.4. Antecedentes
La actividad de auditoría tiene sus orígenes con los intercambios comerciales que se hacían en la antigüedad,
al surgir el registro en papel de todos los movimientos comerciales, también surge la necesidad de verificar
dicha acción.
En las colonias americanas, son los ”oidores” de la corona española, que con el paso del tiempo se transfor-
marían en auditores, vigilaban el pago de quinto real a los reyes de España, ellos cumplían con verificar el
pago de este impuesto.
De manera formal la auditoría en informática tiene como antecedente más cercano a los Estados Unidos de
América. En los años cuarenta se empezaron a dar resultados relevantes en el campo de la computación, con
sistemas de apoyos para estrategias militares, sin embargo, la seguridad y el control sólo se limitaba a dar
custodia física a los equipos y a permitir el uso de los mismos sólo a personal altamente calificado.
Fue en el año de 1978 cuando la Asociación de Auditoría y Control de Sistemas de Información por sus si-
glas en ingles ISACA (Information Systems Audit and Control Association) estableció la certificación CISA
(Certified Information Systems Auditor) para Auditores en Sistemas de Información.
En 1988, el maestro José Antonio Echenique García publicó su libro Auditoría de Sistemas, donde establece
las bases para el desarrollo de una auditoría de sistemas computacionales, dando un enfoque teórico-práctico.
Cabe mencionar que en otros países también se han hecho esfuerzos académicos como el realizado por Mario
G. Piattini y Emilio Peso, [20], en España en el año de 1998 cuando publicaron su obra auditoría informática
un enfoque práctico, donde mencionan diversos enfoques y aplicaciones de la disciplina.
Estos hechos han impulsado a la Auditoría en Informática, misma que se consolida como una actividad
estratégica para las empresas.

3.5. Áreas a auditar

Las áreas en donde realizar la auditoría en informática pueden ser:

Figura 3.1: Áreas de la empresa para aplicar la auditoría informática.

 Sistemas Evalúa los procedimientos, metodologías, ciclo de vida y el uso
de controles en el desarrollo de Sistemas de Información.
Administración de Revisa la aplicación del proceso administrativo en la informática
la función de infor- desde la planeación y control de actividades, la gestión de los
mática presupuestos, costos y adquisiciones, la capacitación del personal
y la administración de estándares de operación.
Auditoría a redes Evalúa el cumplimiento de estándares en la implementación de
redes de video, voz y datos, sus topologías, protocolos y funcio-
namiento así como a su administración, configuración, políticas
de acceso y aprovechamiento.
Centros de cómpu- Revisión de todas las actividades de administración, políticas de
to mantenimiento, políticas de resguardo y respaldo, políticas de ac-
ceso a un centro de cómputo a fin de evaluar el uso de los recursos
informáticos.
Seguridad Evaluación de las protecciones a la Información, Aplicaciones e
Infraestructura así como a las actividades preventivas y correcti-
vas. Se puede llevar acabo de manera física y/o lógica.

3.6. Beneficios y limitaciones

El realizar auditorías en informática de una forma periódica y programada nos puede beneficiar de la si-
guiente forma:

Evaluar el cumplimiento de planes, programas, políticas, normas y lineamientos.

Identificar problemas operacionales.

Proveer oportunidad de mejoras.

Proveer realimentación para acciones preventivas y correctivas.

Dictaminar sobre los resultados obtenidos por una empresa, así como sobre el desarrollo de sus fun-
ciones y el cumplimiento de sus objetivos.

Generar confianza internamente a nivel dirección y en los usuarios sobre la seguridad y control de los
servicios de TI.

Generar confianza externamente (clientes y opinión pública).

Por otra parte existen limitaciones como:

Tiempo. No contar con el tiempo suficiente para ejecutar la auditoría.

Presupuesto. Tener poco presupuesto asignado para este fin, por lo que se tendrá que recurrir a una
auditoría interna.

Personal. No contar con el personal adecuado y la disponibilidad del mismo es baja.

Lugar. Dada las dimensiones de área puede sobrepasar en tamaño nuestras capacidades y superar el
uso de recursos inicialmente asignados.
Lejos de considerarse una moda entre las entidades, empresas u organizaciones la Auditoría en Informática
está justificada por la misma importancia que tiene la información como un factor de ventaja competitiva,
el tener el control adecuado sobre los recursos informáticos que sustentan la toma de decisiones, lo que
proporciona confianza y asegura el cumplimiento de nuestros objetivos.
Como resumen, la auditoría informática se divide en tres grandes áreas:

1. Alrededor del computador.

2. Dentro del computador.

3. Con el computador.

3.7. Técnicas y Herramientas usadas por la auditoría informática

El INEI en su página Web: ¿Qué es la auditoría informática?. Ref. URL [1]. Hace referencia a:

3.7.1. Cuestionarios
La información recopilada es muy importante, y se consigue con el levantamiento de información y docu-
mentación de todo tipo. Los resultados que genere la auditoría se ven reflejados en los informes finales que
emiten y su capacidad para el análisis de situaciones de debilidades o de fortalezas que se dan en los diversos
ambientes. El denominado trabajo de campo consiste en que el auditor busca por medio de cuestionarios la
información necesaria para ser discernida y emitir finalmente un juicio global objetivo, los que deben ser
sustentados por hechos demostrables, llamados evidencias.
Esto se consigue, solicitando el cumplimiento del desarrollo de formularios o cuestionarios lo que son preim-
presos, los cuales son dirigidas a las personas que el auditor considera más indicadas, no existe la obligación
de que estas personas sean las responsables de dichas áreas a auditar. Cada cuestionario es diferente y muy
específico para cada área, además deben ser elaborados con mucho cuidado tomando en cuenta el fondo y
la forma. De la información que ha sido analizada cuidadosamente, se elaborará otro formulario el cual será
emitido por el propio auditor. Estas las respuestas serán cruzadas, lo que vine a ser uno de los pilares de la
auditoría.
Muchas veces, el auditor recopilará la información por otros medios, y que estos preimpresos podían haber
proporcionado, cuando se da este caso, se puede omitir esta primera fase de la auditoría.

3.7.2. Entrevistas
Existen tres formas para que el auditor se relacione con el personal auditado.

1.- La solicitud de la información requerida, debe ser concreta y responsabilidad exclusiva del auditado.

2.- La entrevista sigue un plan predeterminado, pero no es un método de sometimiento a un auditado.

3.- La entrevista es un medio que el auditor usará con una metodología previamente establecida para recabar
información concreta.
La importancia que la entrevista tiene en la auditoría se debe a que, la información que recolecta es abundan-
te, concreta y mejor elaborada que la que proporcionan los medios técnicos, o los cuestionarios. La entrevista
personal entre el auditor y el auditado, es basada en una serie de preguntas específicas en las que el auditado
responde directamente.
El sistema, fecha y horario de interrogación se establece previamente y el auditor tendrá mucho cuidado con
su puntualidad, la entrevista debe ser de forma muy cordial y bajo los parámetros de lo correcto, esto se hace
con la finalidad de que sea lo menos tensa posible, y que el auditado conteste de forma natural, con sencillez.
Sólo que la sencillez con la que se elaboran las preguntas deberán tener un profundo fondo, el cual es distinto
en cada caso.
El auditor experto y con experiencia en la materia, realiza un trabajo de elaboración de sus cuestionarios de
acuerdo a la situación y al escenario auditado.
El auditor sabe que lo que busca, debido a que tiene claro lo que necesita, y por qué lo necesita. Su trabajo es
el basamento fundamental para el análisis, cruce y elaboración posterior del informe final, pero esto no indi-
ca que el auditado tenga que ser sometido a un interrogatorio automatizado o cual no ofrece ningún camino.
Por el contrario el auditor realizara la entrevista de tal forma que el auditado pueda responder a las preguntas
formuladas de manera normal, lo que servirá para llegar al cumplimiento de los cuestionarios de sus Check
Lists.

3.8. Auditoría de sistemas de información

Según Tamayo Álzate en su Libro ”Auditoría de Sistemas – Una visión práctica”. [37] ”... es la parte de la au-
ditoría interna que se encarga de llevar a cabo la evaluación de normas, controles, técnicas y procedimientos
que se tienen establecidos en una empresa para lograr confiabilidad, oportunidad, seguridad y confidencia-
lidad de la información que se procesa a través de computadores; es decir, en estas evaluaciones se está
involucrado tanto los elementos técnicos como humanos que intervienen en el proceso de información...”.

Figura 3.2: Definición de Auditoría de Sistemas.

Las preocupaciones fundamentales con respecto a la tecnología siguen siendo la mismas o se han incre-
mentado con la evolución tecnológica. Estas inquietudes tanto de la Dirección de una entidad, como de sus
accionistas o de la sociedad en general, se concretan en:
La veracidad de la información, en cuanto a su totalidad y exactitud, procesada por los sistemas de
tecnología.
La utilización racional y ajustada a las necesidades reales de los recursos tecnológicos.
 El ”mantenimiento” o ”sostenibilidad” de la estructura tecnológica y su crecimiento no debe ser trau-
mático en el soporte de nuevas actividades.

La confidencialidad de la información

La protección de sus activos, especialmente el software y la información.

3.9. Seguridad general

Con el incremento de ataques a instalaciones informáticas en los últimos años, se han originado acciones
para mejorar la seguridad informática a nivel físico. Los accesos y conexiones indebidos a través de las redes
informáticas y de comunicaciones han acelerado el desarrollo de productos de seguridad lógica, así como la
utilización de sofisticados medios criptográficos.
El sistema integral de seguridad comprende:

Elementos administrativos.

Definición de una política de seguridad.

Organización y división de responsabilidades.

Seguridad física y contra catástrofes (incendio, terremotos, etc.).

Prácticas de seguridad del personal.

Elementos técnicos y procedimientos.

Sistemas de seguridad (de equipos y de sistemas, incluyendo todos los elementos, tanto redes como
terminales.

Aplicación de los sistemas de seguridad, incluyendo datos y archivos.

El papel de los auditores, tanto internos como externos.

Planeación de programas de desastre y su prueba.

La decisión de abordar una auditoría informática de seguridad general en una empresa, se fundamenta en el
estudio cuidadoso de los riesgos potenciales a los que está sometida. Se elaboran ”matrices de riesgo”, en
donde se consideran los factores de las ”amenazas” potenciales a la instalación y los ”impactos” que puedan
causar cuando se presentan. Las matrices de riesgo son cuadros de doble entrada, en donde se evalúan las
probabilidades de ocurrencia de los elementos de la matriz.
El cuadro muestra que si por error se codifica un parámetro que ordene el borrado de un archivo, se tendrá
la certeza que éste se borrará.

3.10. Objetivos de la Auditoria de Sistemas

A continuación se exponen los objetivos que persigue la auditoría de sistemas, los cuales se presentan agru-
pados en objetivos generales y objetivos específicos, de la siguiente forma:
 Figura 3.3: Objetivos de Auditoría de Sistemas.

Objetivos Generales

Evaluar las políticas generales sobre la planeación, ambiente laboral, entrenamiento y capacitación,
desempeño, supervisión, motivación y remuneración del talento humano.

Evaluar políticas generales de orden técnico con respecto al software, hardware, desarrollo, implanta-
ción, operación y mantenimiento de sistemas de información.

Evaluar políticas generales sobre seguridad física con respecto a instalaciones, personal, equipos, do-
cumentación, respaldos2 , pólizas y planes de contingencias.

Evaluar los recursos informáticos de la empresa con énfasis en su nivel tecnológico, producción de
software y aplicaciones más comúnmente utilizadas.

Asesorar a la gerencia y directivos de la empresa en lo relacionado con los sistemas de información,

de tal forma que el proceso de toma de decisiones se efectúe lo más acertadamente posible.

Conocer las políticas generales y actitudes de los directivos frente a la auditoría y seguridad de los
sistemas de información y proceder a hacer las recomendaciones pertinentes.

2 back-ups
 Auditoría Física
4
Los centros de procesamiento de datos son vulnerables a desastres ambientales, accidentes y sabotaje; así
como una mala gestión. La seguridad es la protección de los recursos de CDP de los riesgos naturales y/o
artificiales. Estos recursos incluyen personas, plantas físicas, equipos, programas y datos.
Las personas, programas y datos dentro de CPD pueden ser irreparables y/o irrecuperables.
La auditaría física contempla las instalaciones físicas, vigilancia, alcabalas, boyas, puertas y ventanas de
accesos a edificios, cámaras de vigilancia, sala de servidores y computadoras, instalaciones eléctricas, equi-
pos y dispositivos contra incendios, cajas fuertes, antenas, redes internas, internet, Wifi, lugar geográfico de
las plantas físicas, riesgos sísmicos, inundaciones, incendios, vandalismo, disturbios sociales; así como la
entrada de datos y la salida de información.

4.1. Objetivos
Revisión de las políticas y normas sobre seguridad física.

Verificar la seguridad de personal, datos, hardware, software e instalaciones.

Seguridad, utilidad, confianza, privacidad y disponibilidad en el ambiente informático.

4.2. Alcance
Planta física.

Organización y cualificación del personal de seguridad.

Remodelar el ambiente de trabajo.

Planes y procedimientos.

Sistemas técnicos de seguridad y protección.

40
4.3. Alrededor del computador
La auditoría alrededor del computador se concentra en la planta física, los accesos a sala de servidores
y/o computadores, cámaras de vigilancia, instalaciones eléctricas, equipos y dispositivos contra desastres
naturales y/o artificiales, cajas fuertes. Así como la entrada de datos y salida de información.
Es la parte de la auditoría de sistemas más cómoda para los auditores, por cuanto verifica la efectividad del
sistema de control interno en el ambiente externo de la informática que es tangible.
Naturalmente, se examinan los controles desde el origen de los datos para protegerlos de cualquier tipo de
riesgo que atente contra su integridad, completitud, exactitud y legalidad.
Sin embargo, la auditoría alrededor del computador no es tan simple como aparenta, pues tiene los siguientes
objetivos:

Realizar un inventario de la instalación, equipos y dispositivos informáticos.

Comprobar los controles sobre seguridades físicas y lógicas de la(s) planta(s) física(s).

Verificar la adecuada segregación funcional.

Asegurar la existencia de controles dirigidos a que los accesos de personas estén autorizados.

Comprobar los controles para asegurar que todos los datos enviados sean procesados.

Asegurar que los procesos se hacen con exactitud.

Comprobar que los datos son validados previamente a su proceso.

Verificar el procedimiento utilizado para corregir inconsistencias y la posterior realimentación de los

datos corregidos al proceso.

Examinar los controles de salida de la información evitando los riesgos entre el usuario y los sistemas.

Verificar la satisfacción del usuario, en materia de los informes recibidos.

Comprobar la existencia y efectividad de un plan de contingencias, para asegurar la continuidad de los

procesos y la recuperación de los datos en caso de desastres.

4.4. ¿Qué activos proteger?

La dirección decidirá que activos proteger por su nivel de importancia. Responderá a ¿cuál es el costo de
reposición ellos? y ¿Cuál es la probabilidad de ocurrencia de riesgos y peligro de cada uno de ellos?.
Por cada activo, la dirección decidirá:

No hacer nada.

Minimizar el costo en caso de identificar exposiciones a ocurrir.

Minimizar la probabilidad y posibilidad de exposición.

La auditoría física asegura la integridad de los activos humanos, lógicos y material de un CPD.
No están claros los límites, dominios y responsabilidades de los tres tipos de seguridad que les interesa a los
usuarios: seguridad física, lógica y de las comunicaciones.
Se deben tener medidas para atender los riesgos de fallos, locales o generales.
Medidas:

Antes. obtener y mantener un nivel adecuado de seguridad física sobre los activos

Durante: ejecutar un plan de contingencia adecuado

Después: Los contratos de seguros pueden compensar en mayor o menor medida las pérdidas, gastos
o responsabilidades que se deriven una vez detectado y corregido el fallo.

4.5. Seguridad física

Algunos mecanismos de protección física están diseñados para proteger los programas y datos de la organi-
zación.
El edificio deberá estar en una ubicación segura y ser:

1. contra incendios.

2. paredes no inflamables.

3. alarmas contra incendio, calor y humo.

4. alarmas contra terremotos e inundaciones.

5. extinguidores manuales contra fuego eléctrico.

6. equipos de rocío automático.

7. piso antiestático.

8. UPS.

9. estación de vigilancia y/o alcabala.

10. cámaras de vigilancia.

11. sistemas biométricos de acceso.

12. salidas de seguridad.

13. puertas batientes.

Áreas de la seguridad física a considerar:

A.- Instalaciones, edificación: El auditor informático incluirá un perito que realice la evaluación corres-
pondiente a la estructura física del edificio, de tal manera que emita sus conceptos y certifique las
condiciones generales correspondientes.
Tener en cuenta:
 Ubicación geográfica del edificio.
Ubicación del CPD dentro del edificio.
Elementos de construcción.
Suministro eléctrico.
Sistemas contra incendios.
Inundaciones.
Sismos.

El auditor informático considerará lo siguiente:

B.- Organigrama de la empresa: Con el objetivo de conocer las dependencias orgánicas, funcionales y
jerárquicas, los diferentes cargos. Da la primera visión de conjunto del Centro de Proceso.

C.- Auditoría interna: Deberá solicitarse los documentos de las auditorías anteriores, normas, procedimien-
tos y planes que sobre seguridad física se tengan al departamento de auditoría o en su defecto al encar-
gado de calidad.

D.- Administración de la seguridad: Vista desde una perspectiva que ampare las funciones, dependencias,
cargos y responsabilidades de los diferentes componentes:

Director o responsable de la seguridad integral.

Responsable de la seguridad informática.
Administradores de redes.
Administradores de bases de datos.
Desarrolladores.

E.- CPD (Centro de Procesamiento de Datos) e Instalaciones: Entorno en el que se encuentra incluido el
CPD como elemento físico y la función que debe realizar :
Las instalaciones son elementos que sustentan la actividad informática y proporcionan seguridad a las
personas, a la información y al software entre otras, el auditor inspeccionará:

Sala de servidores.
Sala de impresoras.
Oficinas.
Almacenes.
Sala de acondicionamiento eléctrico.
Aire Acondicionado.
Áreas de descanso, etc.
Rutas de escape.

F.- Equipo y comunicaciones: Son los elementos principales del CPD: servidores, terminales, computado-
res personales, laptops, tabletas, celulares inteligentes, equipos de almacenamiento masivo de datos,
impresoras, medios y sistemas de telecomunicaciones.
Inspeccionar su ubicación dentro del CPD y el control de acceso a los elementos restringidos.
G.- Computadores personales conectados en red: Es preciso revisar la forma en que se llevan a cabo los
respaldos, así como los permisos de acceso al equipo por parte de los usuarios y del equipo a los
datos de la red, se deben examinar los métodos y mecanismos de bloqueo al acceso de información no
autorizada, inspeccionando o verificando dichos accesos.

H.- Seguridad física del personal: accesos, salidas seguras, medios y rutas de evacuación, extinción de
incendios y sistemas de bloqueo de puertas y ventanas, zonas de descanso y servicios, etc.

4.6. Fuentes de información básicas

El siguiente listado indica las fuentes que deben estar accesibles en todo CPD.

Políticas, normas y procedimientos.

Auditorías anteriores.

Contratos de seguros, proveedores y de mantenimiento.

Entrevistas con el personal de seguridad, el informático, de limpieza, etc.

Actas e informes técnicos de peritos, electricistas, fontaneros, especialistas en aire acondicionado y

alarmas, agencias de seguridad, entre otros, que diagnostiquen el estado físico del edificio,

Informes de accesos y visitas.

Políticas de personal: Revisión de antecedentes personales y laborales1 , procedimientos de cancelación

de contratos, rotación de personal en el trabajo, contratado y temporal.

Inventario de archivos: físicos y magnéticos: respaldo, procedimiento de archivo, control de salida y

recuperación de soportes, copias, préstamo y devolución, etc.

4.7. Técnicas y herramientas del auditor

A.- Técnicas.

Observación.
Revisión analítica de la documentación.
Entrevistas con el personal.
Consultores o técnicos y/o peritos.

B.- Herramientas.

Cuaderno y/o grabadora de audio.

Cámara fotográfica y/o grabadora de video.
1 En algunos países, es ilegal solicitar antecedentes penales para contratar personal.
4.8. Los auditores
1. Auditor informático interno:

Revisar los controles relativos a la seguridad física.

Revisar el cumplimiento de los procedimientos.
Evaluar riesgos.
Participar en la selección, adquisición e implantación de equipos y materiales.
Participar en la creación de planes de contingencia.
Revisión del cumplimiento de las políticas y normas de seguridad física.
Efectuar auditorías programadas.
Emitir informes y efectuar el seguimiento de las recomendaciones.

2. Auditor informático externo:

Revisar las funciones del AIE.

Efectuar pruebas a los planes de contingencia.
Mismas del AII.
Emitir informes y recomendaciones

4.9. Desastres naturales

Incendios, inundaciones, descargas eléctricas, derrames de sustancias químicas o gases, explosiones y desas-
tres naturales pueden y destruyen cpd. Siendo el fuego y el agua los casos frecuentes de riesgos con más
efectos colaterales que los temblores, tornados, y disturbios.

4.10. Fallas eléctricas y/o mecánicas

Ningún CPD es inmune a las fallas eléctricas. Ciertos dispositivos de almacenamiento son volatiles: la perdi-
da de energía eléctrica podría significar la pérdida de datos y programas. Los CPD requieren de instalaciones
especiales de aire acondicionado.

4.11. Robo, fraude, malversación

Las posibilidades de robo en un CPD están limitadas a la imaginación de aquellas personas que, directa y/o
indirectamente, están en contacto con él.
 Auditoría de la ofimática
5
Es la revisión del sistema informatizado que genera, procesa, almacena, recupera, comunica y presenta datos
relacionados con el funcionamiento de la oficina. Este tipo de auditoría sirve para evaluar los equipos y
aplicaciones existentes; además del procedimiento de adquisición.

5.1. Objetivos
1. Evaluación del inventario ofimático; refleja con exactitud los equipos y aplicaciones de la oficina
existente en cada una de las áreas.
Aspectos a evaluar:

Examinar el proceso de adquisición de hardware y aplicaciones.

Actividades:
a) Comprobar el establecimiento de políticas y estándares, relacionados con la adquisición, uso
y control de los recursos de hardware y las aplicaciones.
b) Comprobar la existencia de un plan de compras o adquisiciones de recursos informáticos
con base en las necesidades actuales de la empresa.
c) Examinar el proceso de compra de los recursos de hardware y aplicaciones de la empresa.
d) Verificar los antivirus, licencias y caducidad (si procede).
Evaluar la fiabilidad del inventario ofimático de cada una de las áreas de la empresa.
Actividades:
a) Comprobar los mecanismos que garanticen que los equipos y aplicaciones adquiridas están
inventariadas.
b) Elaborar el inventario de los equipos informáticos, aplicaciones y archivos que residen en la
empresa (si procede).
c) Contrastar el inventario levantado con el oficial y adquisiciones de la empresa.
d) Verificar que la jefatura de los departamentos usuarios participen en el proceso de actualiza-
ción del inventario ofimático de la empresa.
e) Comprobar que se evalúan periódicamente los cambios de ubicación de los recursos infor-
máticos.

46
 f) Verificar cada empleado firma su hoja de recepción y/o traslado de recursos informáticos.
Examinar el inventario de licencias de software.
Actividades:
a) Comprobar la existencia de un procedimiento de control para la adquisición y registro de
licencias.
b) Verificar que todo software instalado en la empresa cuenta con licencia actualizada.
c) verificar la caducidad de la licencia de los programas y antivirus.
2. Evaluación de la calidad de las aplicaciones ofimáticas desarrolladas por el personal de la empresa.
Aspectos a evaluar:
3. Comprobar la existencia de un departamento de desarrollo de aplicaciones de la empresa.
Actividades:
a) Verificar la existencia de procedimientos generales de solicitud, autorización, programación y en-
trega de aplicaciones.
b) Constatar la existencia de otros departamentos que desarrollen aplicaciones de uso interno, sin el
control del centro de información.
c) Verificar que las aplicaciones se desarrollan en un laboratorio, evitando operar directamente sobre
los datos reales de explotación.
d) Verificar la existencia de un registro de incidencias de las aplicaciones, así como de los reclamos
de los clientes y usuarios, para detectar aquellas aplicaciones que estarían funcionando de manera
irregular.
4. Evaluar las situaciones de integración y/o incompatibilidad entre las nuevas aplicaciones instaladas y
las existentes.
Actividades:
a) Verificar la existencia de procedimientos formales para la autorización, aprobación, adquisición de
nuevas aplicaciones y cambios de versiones dentro de la empresa.
b) Comprobar que los problemas de integración y las incompatibilidades que presenten las nuevas
aplicaciones previas a su implantación se han analizado y que constan en actas, informes, etc.
c) Comprobar que existe un plan de capacitación de usuarios, con la finalidad que los cambios im-
plementados no impacten negativamente en funcionamiento de la empresa.
d) Verificar que el personal capacitado cuenta con la documentación básica de operatividad de las
aplicaciones, con el propósito de acceder a ella en caso de una ocurrencia.
5. Evaluar si la(s) aplicación(es) existente(n) se ajusta(n) a las necesidades reales de la empresa.
Actividades:
a) Determinar aquellas tareas que necesitan ser automatizados o precisen actualizar los equipos exis-
tentes.
b) Comprobar que los puestos de trabajo, debido a su escasa actividad no se encuentre sobredimen-
sionados.
c) Elaborar una relación, con observaciones, de desincorporación de programas, equipos y dispositi-
vos obsoletos y/o de redistribución y adquisición de nuevos equipos, dispositivos y/o aplicaciones.
5.2. Técnicas y herramientas
5.2.1. Observación
La observación es importante en la auditoría, ya que proporciona argumentos sustanciales a favor de la em-
presa. A través de la observación se verificará y comprobará aspectos como: cumplimiento de las políticas y
normas en el proceso de adquisición, contrastación y fiabilidad del inventario ofimático, el software instalado
en la empresa cuente con licencia, incompatibilidades, entre otros.

5.2.2. Software de apoyo

Software para auditar el uso de los recursos de cómputo de los usuarios (las actividades que ejecutan en cada
equipo), las aplicaciones que ejecuta un usuario en su computador pueden ser rastreadas por esta herramienta;
evaluando de este modo si la actividad que desempeña cada puesto de trabajo se encuentra sobredimensio-
nada.

Guía de cuestionario dirigido a personal administrativo.

Figura 5.1: Cuestionario No. 1

Figura 5.2: Cuestionario No. 2

Figura 5.3: Cuestionario No. 3

 Figura 5.4: Cuestionario No. 4

Guía lista de verificación.

Figura 5.5: Guía de verificación No. 1

Formato para el inventario ofimático de la empresa.

Figura 5.6: Formato para inventario No. 1

Guía para la evaluación al entorno informático.

 Figura 5.7: Formato para evaluación de entorno informático No. 1

Matriz de contraste del inventario ofimático institucional.

Figura 5.8: Matriz de contraste de inventario No. 1

5.3. Software a auditar

Aplicaciones específicas en la gestión de tareas como hojas de cálculo.

Procesadores de texto,

Aplicaciones para la gestión de documentos, como control de expedientes o sistemas de almacena-

miento óptico de información,

Agendas y bases de datos personales;

Sistemas de trabajo en grupo como el correo electrónico o el control de flujo de trabajo;

La evolución tecnológica ha sido tal que hoy en día, que es incuestionable que los productos informáticos
distribuidos ofrecen prestaciones y una relación costo/beneficio muy superior a las soluciones sobre compu-
tadores centralizados.
Este desarrollo de sistemas ofimáticos ha mantenido dos paradigmas fundamentales:

El escritorio virtual.
Un único panel representado por la pantalla del computador, que sustituya el escritorio de trabajo tradi-
cional, y donde se encuentren disponibles las herramientas necesarias para desarrollar las actividades
del oficinista. La interfaz debe ser natural al usuario y fácil de aprender y utilizar.

El trabajo cooperativo.
Considerado como una extensión del concepto de integración de aplicaciones. Es como una multipli-
cidad de actividades coordinadas, desarrolladas por un conjunto de participantes y soportadas por un
sistema informático. Lo anterior implica permitir intercambiar la información necesaria en los diversos
procesos de la organización y/o con otras organizaciones.

5.4. Controles de auditoría

Existen dos características peculiares de los entornos ofimáticos:

La distribución de las aplicaciones por los diferentes departamentos de la organización en lugar de

encontrarse en una única ubicación centralizada; y

El traslado de la responsabilidad sobre ciertos controles de los sistemas de información a usuarios

finales no dedicados profesionalmente a la informática, que pueden, o no, comprender de un modo
adecuado la importancia de los mismos y la forma de realizarlos.

5.4.1. Los controles

Se presentan por grupos y siguiendo criterios relacionados con aspectos de economía, eficacia y eficiencia,
seguridad y condicionantes legales. Estos grupos son los suficientemente generales para servir de base en la
elaboración del guión de trabajo del equipo auditor.

Aspectos financieros.
Determinar si el inventario ofimático refleja con exactitud los equipos y aplicaciones existentes en la
organización, así como los mecanismos para garantizar que los equipos adquiridos están:

• Registrados, según procedencia.

• Inventariados.
• Conciliados.
• Identificados.
• Ha sido determinado y evaluado el procedimiento de adquisiciones de equipos y aplicaciones.

Políticas.

• Revisión de su cumplimiento.
• Consideración de otros mecanismos que optimicen el proceso actual de adquisición.
 • Determinar y evaluar la política de mantenimiento definida en la organización, en cuanto a:
◦ Revisión de contratos y si incluyen a todo el inventario.
◦ Garantías.
◦ Registro de incidencias producidas.
◦ Tiempo de atención de las incidencias y mecanismos.
• Evaluar la calidad de las aplicaciones del entorno ofimático desarrollada por personal de la orga-
nización:
◦ Responsable(s) del desarrollo.
Metodologías y conjunto de pruebas.
• Ambiente adecuado de desarrollo contra explotación.
• Existe una metodología aprobada de desarrollo.
• Reporte de incidencias y seguimiento.
• Evaluar la corrección del procedimiento existente para la realización de los cambios de versiones
y aplicaciones:
◦ Procedimientos y mecanismos formales para la autorización, aprobación, adquisición de
nuevas aplicaciones y cambios de versiones.
◦ Comprobación del cumplimiento de lo instalado para los usuarios.
◦ Compatibilidad e integración en el entorno operativo.
• Determinar que los usuarios cuentan con suficiente formación y la documentación de apoyo
necesaria para ejecutar sus tareas de un modo eficaz y eficiente:
◦ Plan de formación y/o capacitación.
◦ Utilización real de las últimas versiones en los usuarios.
Determinar que el sistema existente se ajusta a las necesidades reales de la organización y:
• Obsolescencia de equipos.
• Uso de equipos y trabajo sobre éstos.
• Detección de nuevas necesidades.
• Seguridad en su cuido y almacenamiento.
• Determinar que existen garantías para proteger los acceso no autorizados a la información reser-
vada de la empresa y la integridad de la misma.
• Determinar si el procedimiento de generación de copias de respaldo es confiable y garantiza la
recuperación de la información en caso de necesidad.
• Determinar que está garantizado el funcionamiento ininterrumpido de aquellas aplicaciones cuya
caída podría suponer pérdidas de integridad de la información y aplicaciones.
• Determinar el grado de exposición ante la intrusión de virus.
• Aspectos legales:
◦ Determinar que en el entorno ofimático se producen situaciones que puedan suponer infrac-
ciones a lo dispuesto por ley de protección de datos de carácter personal.
◦ Determinar que en el entorno ofimático se producen situaciones que puedan suponer infrac-
ciones a lo dispuesto por la ley sobre propiedad intelectual.
5.5. Problemas
Adquisición poco planificada.

Desarrollos ineficaces e ineficientes.

Falta de conciencia de los usuarios acerca de la seguridad de la información.

Utilización de copias ilegales de aplicaciones.

Procedimientos de copias de seguridad deficientes.

Escasa formación del personal.

Ausencia de documentación suficiente.

5.6. Informe auditoría ofimática

1. Identificación del informe.

Auditoría de la ofimática
Elaborado por:
Fecha de elaboración y fecha de entrega:
Número de páginas:

2. Identificación del Cliente.

El área de Informática

3. Objetivos

Verificar que el hardware y software se adquieren siempre y cuando tengan la seguridad de que
los sistemas computarizados proporcionarán mayores beneficios que cualquier otra alternativa.
Verificar que la selección de equipos y sistemas de computación es adecuada.
Verificar la existencia de un plan de actividades previo a la instalación.
Verificar que los procesos de compras TIC están sustentados en políticas, procedimientos, regla-
mentos y normatividad en general, que el proceso se realiza en un marco de legalidad y cumplien-
do con las verdaderas necesidades de la organización para hoy y el futuro, sin caer en omisiones,
excesos o incumplimientos.
Verificar que existen garantías para proteger la integridad de los recursos informáticos.
Verificar que la utilización adecuada de los equipos informáticos es acorde a planes y objetivos.
Plan de contingencia.

4. Alcance de la auditoría:

Comprenderá planta física, instalaciones eléctricas, equipos y dispositivos informáticos, redes

informáticas, seguridad informática y al desempeño de los usuarios de acuerdo a las normas y
demás disposiciones aplicables al efecto.
 Comprenderá con precisión el entorno, objetivos y los límites de la auditoría ofimática.

5. Hallazgos potenciales:

Falta de licencias de software.

Falta de software de aplicaciones actualizados.
No existe un calendario de mantenimiento ofimático.
Faltan material ofimático.
Falta de seguridad en acceso restringido de los equipos ofimáticos y software.
Personal sin conocimientos sobre las aplicaciones que gestiona.
Personal que odia su puesto de trabajo.

6. Conclusiones:

Como resultado se manifestará haber evaluado cada uno de los objetivos contenidos en el pro-
grama de auditoría.
Verificar que CPD np presenta deficiencias sobre el cumplimiento de normas de seguridad.
Manifestar la cantidad de empleados debidamente capacitados.
Destacar que la sistema ofimático pudiera servir de gran apoyo a la organización, el cual no es
explotado en su totalidad por falta de personal capacitado.

7. Recomendaciones:

Verificar que se cuenta con sellos y firmas digitales.

Disponibilidad de un manual de funciones para cada puesto de trabajo dentro del área.
Actualización de datos.
Implantación de equipos de última generación.
Elaborar un calendario de mantenimiento periódico.
Capacitar al personal.
 Auditoría de la dirección
6
Una organización es el reflejo de su dirección, sus características, modos y maneras de actuar. Y que están
influenciadas por la filosofía y personalidad del director.

6.1. Concepto
El proceso de organizar estructura los recursos, flujos de información y controles para alcanzar los objetivos
marcados durante la planificación. Los recursos financieros que la empresa destina a la tecnología de la infor-
mación y su dependencia con los procesos de la organización hacen necesaria una evaluación independiente
de la función que la gestiona o dirige.
Es efectuar un seguimiento permanente de las distintas actividades de la dirección, con el propósito de co-
rregir a tiempo cualquier anomalía o desviación que valla en desacuerdo con lo planificado Siempre en una
organización.
Es un examen que se realiza con carácter objetivo, crítico, sistemático y selectivo con el propósito de evaluar
la eficacia y eficiencia del uso adecuado de los recursos informáticos, de la gestión informática y que ofrecen
el soporte adecuado a los objetivos y metas del negocio.
Es el control de las actividades del proceso de la dirección de los sistemas de información.
Una informática eficiente y eficaz requiere del apoyo de su dirección y que los procesos de gestión sean
óptimos.

Planificar

Organizar y coordinar

Controlar

56
 Figura 6.1: Vista de un organigrama.

Son aplicables a las diversas facetas de la Dirección: consumo de recursos de equipos, desarrollo, operacio-
nes, etc. La organización debe estar estructurada para lograr eficiente y eficazmente los objetivos, y que se
obtengan a través de una adecuada toma de decisiones.
Es conveniente que existan estándares de rendimiento con el cual comparar diversas tareas.

6.2. Acciones de un director

Planificar. Acorde al plan estratégico (conocimiento a evaluar de las acciones a realizar).

• Lectura y análisis de actas, acuerdos, etc.

• Lectura y análisis de informes gerenciales.
• Entrevistas con el director/jefe de la Dirección y con los directores/jefes de otras áreas.

Organizar.

Controlar.

Coordinar.

Los recursos financieros que la empresa dedica a la tecnología de la información y su dependencia con
sus propios procesos como organización hacen necesaria una evaluación independiente de la función que la
gestiona o dirige.
Alcance de la auditoría.

• Organización y calificación de la Dirección de informática.

• Plan estratégico de sistemas de información.
• Análisis de puestos.
• Planes y procedimientos.
 • Normativa.
• Gestión financiera.

Objetivos de la auditoría.
Realizar un informe con el objeto de exponer la adecuación de las medidas aplicadas a las amenazas
definidas, así como el cumplimiento de los requisitos exigidos.

Resultados:
Informe de auditoría detectando riesgos y deficiencias en la Dirección de informática.
Plan de recomendaciones a ser aplicadas en función de:

• Normativa a cumplir

Figura 6.2: Revisión de la estructura orgánica de una empresa.

1. Organigrama
Cuando se realiza la auditoría a la dirección informática el requisito fundamental es conocer la es-
tructura organizacional de dicha Dirección. El auditor conocerá a que otras áreas soporta, a quienes
reportan, de quien dependen y/o sirven; en este caso
El organigrama presenta la siguiente información:

Las jerarquías en la empresa(definición de la autoridad lineal, funcional y de asesoría).

Estructura organizacional.
Funciones.
Objetivos.

2. Revisión de la documentación relacionada con la Dirección

 Cuando se realiza una auditoría a la Dirección informática o a cualquier área, los auditores pretenden
obtener una idea clara sobre las condiciones de trabajo y gerenciales de la dirección que se audita,
lo que incluye las horas de trabajo, salarios y deducciones, así mismo cualquier comprobante que
verifique las acciones que se suscitan en la Dirección.
Los auditores cuando realizan su auditoría van directamente a:

Comprobantes de pago: de ellos se obtiene y comprueba el pago o remuneración, premios y/o

bonificaciones a los empleados.
Políticas y procedimientos: mediante ellos se conocen las normas, políticas, reglas y objetivos
de la empresa, de este modo los auditores conocerán que está trabajando acorde según lo pla-
neado. Estos apartados también contienen los planes de trabajo, los controles, procedimientos y
estándares que gobiernan a la empresa.
Contratos laborales: son muy importantes para la auditoría de la Dirección informática, ya que
comprobará y verificará quienes son empleados fijos, los que están bajo contrato y los asesores
externos. Es importante que la empresa cuente con una organización en sus empleados.

3. Entrevista a directivos
El director/jefe de informática o los miembros de la empresa con cargos directivos llenarán los cues-
tionarios sobre la estructura organizacional, funciones, objetivos y políticas; el auditor realizará las
entrevistas con las siguientes consideraciones:

entrevistar al auditado con el fin de recabar información, de una manera amigable, sin tensión y
con un vocabulario adecuado.
inspirar confianza al auditado.
seleccionar diferentes directivos como: jefes de proyectos, analistas, programadores, etc.
realizar la entrevista acordando la logística (hora, fecha, lugar, etc.).

4. Evaluación
Existen diferentes formas de evaluar a la Dirección informática, entre ellas se encuentran procedimien-
tos (desempeño) y documentos (manual de organización de la empresa), y entre las formas está:

Evaluación de desempeño de las funciones que la alta Dirección debe de realizar.

Organigramas con jerarquías.
Objetivos y políticas.
Manual de normas.
Manual de procedimientos.
Análisis, descripción y evaluación de puestos.
Instructivos de trabajos.
Planeaciones.
Etc.
6.3. Posibles preguntas
Posibles preguntas para una auditoría de la dirección:

1. ¿La dirección de los servicios de información desarrollan regularmente planes a corto, medio y largo
plazo que apoyen el logro de la misión y las metas generales de la organización?

2. ¿Dispone la dirección de un plan estratégico de tecnología de información?

3. ¿Durante el proceso de planificación, se presta adecuada atención al plan estratégico de la empresa?

4. ¿Las tareas y actividades en el plan tiene la correspondiente y adecuada asignación de recursos?

5. ¿Existe un comité de informática/sistemas?

6. ¿Existen estándares de funcionamiento y procedimientos que gobiernen la actividad del área de infor-
mática por un lado y sus relaciones con los directores y/o usuarios por otro?

7. ¿Existen estándares de funcionamiento y procedimientos y descripciones de puestos de trabajo ade-

cuados y actualizados?

8. ¿Los estándares y procedimientos existentes promueven una filosofía adecuada de control?

9. ¿Las descripciones de los puestos de trabajo reflejan las actividades realizadas en la práctica?

10. ¿La selección de personal se basa en criterios objetivos y tiene en cuenta la formación, experiencia y
niveles de responsabilidad?

11. ¿El rendimiento de cada empleado se evalúa regularmente en base a estándares establecidos?

12. ¿Existen procesos para determinar las necesidades de formación de los empleados en base a su expe-
riencia?

13. ¿Existen controles que tienden a asegurar que el cambio de puesto de trabajo y la finalización de los
contratos laborales no afectan a los controles internos y a la seguridad informática?

14. ¿Existe un presupuesto económico? ¿Existe un proceso para elaborarlo?

15. ¿Existen procedimientos para la adquisición de bienes y servicios?

16. ¿Existe un plan operativo anual?

17. ¿Existe un sistema de reparto de costos informáticos justo?

18. ¿La organización cuenta con pólizas de seguros?

19. ¿Existen procedimientos para vigilar y determinar permanentemente la legislación aplicable?

 Auditoría de la explotación
7
7.1. Concepto
Consiste en auditar las áreas que componen la explotación informática y sus interrelaciones, las cuales com-
prenden tres grandes áreas: Planificación, Producción y Soporte Técnico.
La explotación informática produce resultados informáticos como listados impresos, archivos en medios
magnéticos como insumos a otros dispositivos informáticos, órdenes automatizadas para lanzar o modificar
procesos industriales, etc.
Para realizar la explotación informática se dispone de una materia prima, los datos. Los cuales se transfor-
man y someten a controles de integridad y calidad.
La explotación informática se ocupa de producir diversos resultados informáticos como: listados impresos,
archivos digitales, etc.
Para la explotación informática se dispone de una materia prima, los datos, elementos a transformar, y que
se someten a controles de integridad y calidad. Explotación únicamente recibe programas ejecutables que
hayan sido aprobados por Dirección/unidad de desarrollo.
La auditoría de explotación es el control que se realiza sobre las funciones del sistema de información para
asegurar que las mismas se efectúen de forma regular, ordenada y que satisfagan los requisitos empresariales.

7.2. ¿Por qué?

El nivel de competencia que existe, hoy en día, entre las empresas les obliga a tomar decisiones rápidas y
acertadas. Por lo que es necesario el funcionamiento adecuado de los sistemas informáticos, así como la
incorporación de las nuevas tecnologías y la continua actualización de los programas.

7.3. ¿Para qué?

Combinando los nuevos avances tecnológicos con una adecuada organización y una gestión eficiente, las
empresas alcanzarán sus objetivos de manera satisfactoria. La auditoría informática periódica es uno de
los instrumentos mas eficaces con que cuentan las empresas para asegurar su existencia y superar a sus
competidores.
La detección oportuna de las debilidades del sistema son para mejorarlo racionalizando los recursos.

61
7.4. Puntos a considerar
1. La auditoría de la explotación consiste en auditar las secciones que componen la explotación infor-
mática y sus interrelaciones. Ésta se divide en tres grandes áreas: planificación, producción y soporte
técnico.

2. Control de Entrada de Datos. Este proceso analiza la captura de la información en soporte compatible
con los sistemas, el cumplimiento de plazos y calendarios de tratamientos y entrega de datos, es decir,
la correcta transmisión de datos entre entornos diferentes.

3. Planificación y Recepción de Aplicaciones. Se auditarán las normas de entrega de Aplicaciones por

parte de Desarrollo, verificando su cumplimiento y su calidad de interlocutor único. Deberán reali-
zarse muestreos selectivos de la documentación de las aplicaciones explotadas y se inquirirá sobre la
anticipación de contactos con Desarrollo para la planificación a medio y largo plazo.

4. Centro de Control: Seguimiento de Trabajos Aquí se analiza cómo se prepara, se lanza y se sigue la
producción diaria. Para ello, se ejecutan procesos por cadenas o lotes (batch), o en tiempo real. La
diferencia entre batch y tiempo real, es que los procesos batch recogen información durante todo el
día y luego la procesan; en tiempo real, la información se analiza y procesa inmediatamente.

5. Operación. Sala de servidores Se realizan varias operaciones como:

Intentar analizar las relaciones personales y la coherencia de cargos y salarios.

Verificar la existencia de un responsable de sala en cada turno de trabajo.
Analizar el grado de automatización de comandos.
Supervisar la existencia y grado de uso de los manuales de operación.
Verificar la existencia de planes de formación y el cumplimiento de los mismos.
Analizar los montajes diarios y por horas de cintas o cartuchos y las líneas de papel impresas
diarias

6. Centro de Control de Red y Centro de Diagnosis (mesa ayuda) El centro de control de red suele
ubicarse en el área de producción de Explotación. Es utilizado en el ámbito de las Comunicaciones,
estando bastante relacionado con la organización de Software de Comunicaciones de Técnicas de
Sistemas. El Centro de Diagnosis es el ente en donde se atienden las llamadas de los usuarios o clientes
que han sufrido averías o incidencias, tanto de software como de hardware. Debe auditarse desde la
perspectiva de la sensibilidad del usuario sobre el servicio que se le dispone.

7.5. Objetivos
Controlar los manuales de instrucciones y procedimientos de explotación.

Controlar los inicios de los procesos y otra documentación de funcionamiento.

Revisar la agenda de trabajo.

Verificar la continuidad del proceso.

Realizar controles sobre la explotación remota.

 Comprobar que en ningún caso los operadores acceden a documentación de programas que no sea la
exclusiva para su explotación.

Revisar la existencia de procedimientos que impidan la ejecución de programas no activos.

Verificar los procedimientos para incorporar nuevos programas a las librerías de producción.

Examinar los lugares de almacenamiento de cintas y discos, así como su identificación.

Verificar los planes de mantenimiento preventivo de la instalación.

Comprobar que existen normas escritas que regulan lo relativo a copias de seguridad: manejo, autori-
zación de obtención de datos, copiado, destrucción, etc.

7.6. Componentes del sistema de información según COBIT

Datos: En general, se consideran datos tanto a los estructurados como a los no estructurados, las
imágenes y los sonidos.

Aplicaciones: Se incluyen manuales e informáticas.

Tecnología: software y hardware, los sistemas operativos, así como los de gestión de base de datos,
los de red, etc.

Instalaciones: En ellas se ubican y se mantienen los sistemas de información.

Personal: Los conocimientos específicos que éste debe tener de los sistemas de información para su
planificación, organización, administración y gestión.
Estos recursos de los sistemas de información se han de utilizar de forma que:

faciliten la eficacia y la eficiencia de la empresa; que los datos elaborados por su sistema de informa-
ción muestren una imagen fiel de la misma y que la empresa cumpla la legislación vigente.

7.7. Planificación estratégica

Es una revisión global mediante la cual, el auditor conocerá a la empresa, al sistema de información y al
control interno con la intención de hacer una primera evaluación de potenciales riesgos. De acuerdo a los
resultados obtenidos, establecerá los objetivos de la auditoría y determinará su alcance y las pruebas a aplicar,
así como el momento de realizarla.
Para esta tarea es necesario:

Las características de los equipos informáticos.

El sistema o los sistemas operativos.

Características de los archivos o de las base de datos.

La organización de la empresa.

La organización del servicio de explotación.

 Las aplicaciones en explotación a auditar.

El sector o rubro al que pertenece y opera la empresa.

Información comercial.
La instalación de un sistema informático introduce nuevos elementos de control y origina cambios en los
procedimientos tradicionales del procesamiento de datos.
Estos controles son clasificados como:
nuevos para la automatización del procesamiento.

los que sustituyen a aquellos que en los sistemas manuales están basados en el criterio humano y en la
división de tareas.
Se necesitan nuevos controles debido a la automatización. Su objeto es detectar y controlar errores derivados
del uso del equipo informático y de los métodos de procesamiento en el equipo.
Si estos controles no existen, el sistema está expuesto a altos riesgos por error.
En un sistema manual, el control interno depende de factores como la supervisión humana, el cuidado, la
aceptación de responsabilidad y la división de tareas. En vista de que la actividad de procesamiento de infor-
mación está concentrada desaparecen muchos controles basados en el criterio humano y en la mencionada
división.
Los controles en un sistema informático proporcionan una seguridad razonable que el procesamiento opera
correctamente, detecta errores e irregularidades rápidamente y asegura una acción correctiva apropiada.
Los controles necesarios en este tipo pueden dividirse en los relacionados con las actividades de procesa-
miento, en los que previenen y detectan errores, y aquellos relacionados con la organización y administración.
Con respecto a estos dos últimos puntos: la organización y administración:
Se refieren a la asignación de responsabilidad y autoridad para las diversas funciones a realizar en la
organización.

Establecen responsabilidades a través de los trabajos a efectuar por el personal que interviene en el
procesamiento de información. Incluirán los títulos de los cargos y describen claramente las funciones.
También considera a la separación de tareas como elemento de control interno que se aplica en las funciones
básicas del sistema de información.

7.8. Áreas de la auditoría de explotación

Se ha mencionado que la explotación informática comprende tres grandes áreas: planificación, producción y
soporte técnico, a ellas, se agrega el área de los datos.

7.9. Control de entrada de datos

Analiza la captura de los datos en soportes compatibles con los sistemas, el cumplimiento de plazos y ca-
lendarios de tratamientos y entrega de datos; la correcta transmisión de datos entre entornos diferentes.
Verificará que los controles de integridad y calidad de datos se realizan de acuerdo a la norma COBIT.
7.9.1. Procedimiento de control de entrada de datos
Las transacciones de procesamiento electrónico de datos comienzan con procedimientos de entrada de datos.
En generales, cualquiera que sea el ambiente en que se procesan los datos, es necesario efectuar el control
de ingreso para asegurar que cada transacción a ser procesada cumpla con:

1. Recibir y registrar con exactitud e íntegra.

2. Procesar solamente datos válidos y autorizados.

3. Ingresar los datos una vez por cada transacción.

Los controles en el ingreso de datos son preventivos, evitan la producción de errores exigiendo el ajuste de
los datos introducidos a patrones de formato y estructura (fecha valida, dato numérico y/o dentro de un rango
especifico, introducción de dígitos de verificación, etc.).

Las pantallas de captura de datos, o formularios, son diseñadas de manera similar y consistente con los
documentos fuente de los cual se ingresan datos en el sistema. El orden de los campos, en la pantalla
y el documento, deben ser iguales para evitar errores de digitación.

En el ingreso de los datos, la aplicación debe tener mensajes de ayuda adecuados, con el objetivo de
facilitar la captura de estos y advertir sobre algún error cometido, indicando la clase de error y su
posible corrección.

Restringir el acceso de los usuarios a las diferentes opciones de la aplicación, definiendo perfiles de
acceso, de acuerdo a las funciones de cada cargo, para disminuir el riesgo que personas no autorizadas
lean, modifiquen, adicionen, eliminen datos o transacciones.

Identificar en cada pantalla de captura que los campos de los datos importantes sea de obligatoria
digitación.

En toda la aplicación, cada campo debe tener el formato de datos apropiado: numérico, alfabético o
alfanumérico, de fecha y la cantidad adecuada de caracteres.

Para los campos numéricos y de fecha, implantar controles de limite o racionabilidad, para asegurar
que los datos estén dentro de un rango determinado. Como la fecha de vencimiento de un crédito debe
ser posterior a la fecha de apertura del mismo.

La captura o modificación de datos críticos debe dejar una pista de auditoría (log) donde se identifique:
nombre del usuario, fecha y hora de captura, fecha y hora de modificación, ip de la computadora donde
se realizó la transacción.

Verificar que los log de la aplicación sean revisados por los responsables para investigar accesos y
manipulaciones no autorizadas.

Según sean ingresados los datos, el sistema debe compararlos con los registros de los archivos maestros
para determinar la validez de los datos ingresados, en caso de presentarse una inconsistencia, el sistema
avisará inmediatamente al usuario la situación para ser corregida.

De acuerdo con cada aplicación, las pantallas de captura de documentos fuente críticos y que tengan
al menos una columna numérica, incluirán el ingreso de totales de control, con el fin de verificar la
correcta digitación de cantidades. Los totales de control también se aplican en el ingreso de los lotes
 de documentos, ingresando para cada lote, él número de documento a ser procesados, con el fin de
detectar los documentos faltantes por ingresar o ingresados más de una vez.

La aplicación debe imprimir listados de datos ingresados para ser revisados por los usuarios, con el
propósito de verificar la correcta inclusión de los datos.

La aplicación impedirá que los datos de los archivos maestros luego de un movimiento, sean borrados
del sistema.

Los números de documentos fuente o el número del lote, sólo deben ser ingresados para el procesa-
miento una vez.

Es importante tener en cuenta que los anteriores controles se aplican no sólo cuando los datos se
ingresan por primera vez, sino también, cuando ya estos existen en el sistema y lo que se quiere es
modificarlos.

En el ingreso de los datos, puede haber rechazados por el sistema; con lo que la aplicación facilitará el
control sobre dicha transacción, manteniéndola en un archivo para ser analizadas y corregidas por los
usuarios.
En el área de control de entrada de datos se localizan los siguientes puntos de control:
1. Transacciones en línea.
Los objetivos generales de este punto de control se apoyan en el:

a) Disponer de mecanismos de control que minimicen la exposición a riesgos derivados de:

1) ingreso de transacciones que no cumplan con las regulaciones vigentes.
2) ingreso de transacciones erróneas o incompletas.
3) ajustes indebidos a transacciones.
4) deterioros o degradación a la base de datos.
5) carencia de pistas de auditoría.
b) Asegurar la continuidad de las actividades mediante vías alternativas de entrada de datos.
Los objetivos generales mencionados deben traducirse en objetivos específicos. Los mismos se
indican a continuación:
1) Asegurar la exactitud, razonabilidad y legalidad de las transacciones en línea.
2) Asegurar la consistencia de los datos de las transacciones.
3) Verificar los de mecanismos de control de validación de datos de las transacciones, en cuanto
a estructura, integridad, rango, fecha de ocurrencia.
4) Comprobar que sólo transacciones aprobadas sean admitidas en las operaciones en línea.
5) Asegurar que no exista la posibilidad de perder la transmisión de transacciones.
6) Asegurar la eficacia de los mecanismos de detección de errores y de practicas de corrección
de los mismos.
7) Asegurar que los mecanismos de transacciones en línea provean de pistas de auditoría para
pruebas posteriores y que los mismos sirvan como medio de evidencia ante requerimientos
legales o regulatorios.
8) Minimizar el riesgo de que se produzcan interrupciones durante la transmisión de transac-
ciones.
Las técnicas de control aplicables a estos objetivos son:
1) Identificar y registrar los tipos de transacciones aceptadas por el sistema.
2) Identificar y registrar a los operadores autorizados para ingresar las transacciones aprobadas.
3) desplegar en pantalla formatos específicos para orientar al operador acerca de los datos que
debe ingresar en cuanto a dimensión, secuencia, rango o limites dentro de los cuales se
deben mantener los valores a ingresar.
4) Exhibir rangos de validez de los datos, de manera que sirvan de orientación también al
operador.
5) Aplicar diálogos interactivos de control.
6) Controlar la presencia de anomalías estructurales de datos.
7) Evitar el ingreso, como dato, de fechas inexistentes. Por ejemplo, día superior a 31 o mes
13.
8) En el caso de procesamiento en linea, modalidad en lote, puede crearse un archivo de datos
de entrada sin verificarlos en una primera instancia.
9) En el caso de procesamiento en línea, modalidad de tiempo real, la verificación de datos de
entrada que acceden al azar, puede efectuarse por medio de una simulación de procesamiento
en lote.
10) Efectuar previsiones de control en los procedimientos de transacciones trasmitidas en línea,
bajo la modalidad en lote.
Por ejemplo:
Determinar una cantidad fija de transacciones a ser procesadas en lotes y conciliar la suma-
toria de los valores de determinados campos con totales de esos mismos campos obtenidos
por separado y registrados por fuera del sistema.
11) Mantener un conteo de transacciones ingresadas para conciliar el total de la cantidad de
estas con un total obtenido por vía separada. Aplicar un criterio similar para el caso de
procesamiento en línea, en el que se refiere a cantidad de lotes ingresados.
12) Establecer procedimientos específicos para administrar la corrección de errores detectados
en el ingreso de datos y para asegurar su ingreso al proceso. Mantener registros de datos
rechazados que están pendientes de corrección, e informar sobre los mismos a un tercero.
13) Suministrar pistas de auditoría de actividad.
Mantener al final de cada archivo totales de control.
14) Conservar en las terminales logs como pistas de auditoría para la reconstrucción de transac-
ciones desde las estaciones de usuarios.
15) Mantener registros de mensajes enviados y recibidos, identificados por número de serie y
fecha.
16) Prever la formulación de informes gerenciales diarios sobre tipos de transacciones desarro-
lladas, que incluyan totales de importes de determinados campos.
17) Mantener continuidad en el procedimiento en línea mediante la utilización de vías alternati-
vas de procesamiento, de manera que se recurra a otra terminal en caso de in-operatividad de
alguna de ellas, de no ser posible esta solución, prever mecanismos manuales o alternativas
que incluyan el almacenamiento de transacciones durante el procesamiento de emergencia,
la generación de pistas de auditoría respecto de esas transacciones y la consiguiente incor-
poración de las mismas al reiniciarse la transmisión normal a la base de datos.
 18) Verificar que en las transacciones contables los débitos concuerden con los saldos.
19) Prever la efectividad de un entrenamiento por parte de los usuarios y operadores de los
sistemas en línea y en tiempo real, asegurar que los programas de entrenamiento no afecten
los archivos de operación normal.

2. Usuario y operador.
Los objetivos generales de este punto de control se apoyan en:

a) Minimizar la posibilidad los errores humanos durante la transmisión de entrada de datos.

b) Asegurar que las funciones que ejecutan los operadores de datos sobre áreas reservadas se ajustan
a las políticas y prácticas de control de la organización.

Los objetivos específicos:

a) Autorizar el ingresos de datos, consulta y actualización de archivos a personas exclusivamente

autorizadas e identificadas.
b) Desactivar aquellas terminales desde las que se haya intentado accesos no autorizados o erróneos,
o bien, que hayan estado un determinado tiempo inactiva.
c) Mantener registros de los cambios efectuados en las autorizaciones de accesos.
d) Asegurar el mantenimiento confidencial de las claves de encriptación de datos o mensajes; hacer
lo mismo con las contraseñas.

Técnicas de control aplicables a los objetos:

a) Facilitar y simplificar la tarea del operador.

b) Utilizar opciones limitadas de un menú conforme a las autorizaciones otorgadas a cada usuario
por medio de niveles.
c) Introducir en el software rutinas del bloqueo que sólo puedan ser deshabilitadas por contraseñas
autorizadas.
d) Desactivar las terminales después de un intento fallido de ingreso de datos, mantener registros
internos rechazados.
e) Disponer de procedimientos específicos de seguridad en caso de restauración de operaciones
luego de un periodo de inactividad por falla en una terminal.
f ) Efectuar control de duplicación.

3. Terminal o dispositivo de entrada de datos.

Objetivos generales:

a) Asegurar sólo operadores y lugares autorizados.

b) Asegurar la continuidad de los negocios (procesamiento de transacciones), aún en el caso de que
se produzcan fallas en el sistema.
c) Mantener la confidencialidad y privacidad de los datos agrupados y transmitidos para su proce-
samiento dentro de un ambiente protegido.

Objetivos específicos:
 a) Resguardar físicamente el área destinada a terminales.
b) Asegurar que el dispositivo de entrada de datos pueda ser identificado.
c) Asegurar que antes de efectuar una conexión e iniciar una sesión de transmisión de datos, se
verifique que la respectiva terminal sea autentica.
d) Asegurar la autenticidad y legitimidad del operador/usuario.
e) Verificar que los usuarios opere en una terminal que envié y reciba transacciones dentro de los
límites de su autorización.
f ) Asegurar que la terminal, por medio del software de la computadora central, tenga la capacidad
de aceptar o rechazar transacciones en conformidad con las reglas establecidas.
g) Evitar la exposición a códigos de encriptación.
h) Minimizar el riesgo y desconfianza delimitados sobre lo que cada operador hace y observa.
i) Evitar que persona extrañas quieran obtener conocimiento de información confidencial.
Técnicas de control aplicables:
a) utilizar el software establecido.
b) Separar técnicamente las terminales de uso general.
c) Delimitar las opciones de los menues.
d) Evitar personas ajenas al operador autorizado.
e) Registrar los datos a transmitir.
f) Establecer procedimientos alternativos en caso de cualquier anomalía.
g) Establecer límites de tiempo para el mantenimiento.
h) Asignar llaves funcionales especiales a los usuarios.
i) Utilizar cables blindados.
j) Sólo la una persona autorizada cambiará los códigos de encriptación.
k) Verificar que las terminales quedan fuera de servicio, apagadas, al finalizar la jornada laboral.

7.10. Planificación y recepción de aplicaciones

Auditar las normas de entrega de aplicaciones por parte de la gerencia/unidad de desarrollo, verificando su
cumplimiento y su calidad de interlocutor único. Deberán realizarse muestreos selectivos de la documenta-
ción de las aplicaciones explotadas. Se preguntará sobre la anticipación de contactos con desarrollo para la
planificación a medio y largo plazo.

7.11. Centro de control y seguimiento de trabajos

Analizar cómo se prepara, ejecuta y supervisa la producción diaria.
Básicamente, la explotación informática ejecuta procesos por cadenas o lotes sucesivos (Batch), o en tiempo
real (Tiempo Real). Mientras que las aplicaciones de teleproceso siempre están activas y la función de explo-
tación se limita a vigilar y recuperar incidencias, el trabajo Batch absorbe una buena parte de los efectivos
de explotación. Muchos Centros de Proceso de Datos reciben el nombre de Centro de Control de Batch.
El CPD determina el éxito de la explotación, en cuanto que es uno de los factores más importantes en el
mantenimiento de la producción.
 Las aplicaciones Batch cargan muchos datos durante el día y por la noche se ejecuta un proceso que
relaciona la información, calcula u ordena o clasifica y obtiene como salida, uno o más reportes.
Recolecta información durante el día, pero aún no procesa nada. Es un tema de ”Data Entry” que
recolecta información, ejecuta el proceso Batch (por lotes), y calcula lo necesario para iniciar al día
siguiente.

Las aplicaciones en Tiempo Real u Online, son las que, luego de haber ingresado la información co-
rrespondiente, inmediatamente procesan y devuelven un resultado. Sistemas que responden en Tiempo
Real.

7.12. Salas de servidores

Se analizarán las relaciones personales y la coherencia de cargos y salarios, así como la equidad en la asig-
nación de turnos de trabajo. Se verificará la existencia de un responsable de sala en cada turno de trabajo. Se
analizará el grado de automatización de comandos, se verificará la existencia y grado de uso de los Manuales
de Operación.
Se analizará la existencia de planes de formación, su cumplimiento de los mismos y el tiempo transcurrido
para cada operador desde el último curso recibido. Se estudiarán los montajes diarios y por horas de cintas,
dvd, respaldos y/o cartuchos, así como los tiempos transcurridos entre la petición de montaje por parte del
sistema hasta el montaje real. Se verificarán las líneas de papel impresas diarias y por horas, así como la
manipulación de papel utilizado.

7.12.1. Equipos informáticos

En caso de asignación o reutilización de los equipos o dispositivos informáticos de un empleado a otro, de-
be responder a: ¿cuáles son los procedimientos para asegurar de que la información/software del empleado
previo, se borran o destruyen adecuadamente?
Los equipos pueden ser transferidos entre usuarios siempre que sea necesario y para cumplir algún requeri-
miento del proceso de negocios.
Sean caso de esto:

Los equipos preparados para técnicos, pasantes y/o becarios existentes en el departamento.

Personal externo que trabaje en la empresa y requiera de un computador para desempeñar parte de sus
funciones.

Usuarios que requieran de computador debido a que el asignado se daño y espera un nuevo equipo.

Usuarios que hayan sufrido el robo del equipo asignado.

En una solicitud de reposición de un equipo de los casos mencionados, el usuario hace una solicitud di-
recta al departamento/unidad de sistemas informando la falla presentada por el equipo, el personal técnico
comprueba la falla, si es necesario autoriza la adquisición y/o reposición del equipo al usuario; mientras el
usuario tiene uno ”provisional”, hasta que le sea asignado un equipo definitivo.
7.12.2. Centro de control de red y Centro de diagnosis
El Centro de Control de Red (CCR) debe ubicarse en el área de explotación.
Sus funciones se refieren exclusivamente al ámbito de las comunicaciones, internas y externas, estando muy
relacionado con la organización del software de comunicaciones y tecnología de sistemas (CTS). Debe ana-
lizarse la fluidez de esa relación y el grado de coordinación entre ambos. Se verificará la existencia de un
punto focal único, desde el cual sean perceptibles todos las líneas asociadas al Sistema.
El Centro de Diagnosis atienden las llamadas de los usuarios-clientes que han sufrido averías o incidencias,
tanto de software como hardware. El Centro de Diagnosis está especialmente indicado para empresas que
gestionan redes informáticos con usuarios y/o sucursales dispersos en un territorio. Es uno de los elementos
que más contribuyen a configurar la imagen informática de la empresa. Debe ser auditada desde esta pers-
pectiva, desde la sensibilidad del usuario sobre el servicio que se le brinda. No basta comprobar la eficiencia
técnica del Centro, es necesario analizarlo simultáneamente desde el ámbito del usuario.

7.13. Procedimiento de la auditoría

Carta de Encargo
En este documento quedará reflejado, de la forma más clara posible, el alcance del trabajo del auditor.
 Auditoría del desarrollo
8
8.1. Concepto
Como se trata de la auditoría operacional al área de informática, el auditor comprobará la aplicación de los
siguientes parámetros: economía, eficiencia y efectividad, lo que implica una evaluación con visión gerencial,
y tendrá especial interés en comprobar la seguridad del software desarrollado para garantizar que el resultado
de su ejecución sea el esperado y que no interfiere con el resto de aplicaciones de la empresa.
El desarrollo de software es una evolución del llamado ”Análisis y programación de sistemas y aplicaciones”
por lo que está sujeto al control de cada una de sus fases, ya que en caso contrario, además del habitual
aumento de los costos, produciría la insatisfacción del usuario si no cumple con sus objetivos y con la
ergonomía de los interfaces de la misma. A su vez, engloba diversas áreas, tantas como sectores que requieran
ser informatizados en una empresa.

8.2. ¿Por qué y Para qué?

Una auditoría de desarrollo empieza por la observación y el análisis de cuatro puntos fundamentales:
A.- El examen de las metodologías utilizadas: las cuales se analizarán para asegurar la modularidad de las
potenciales ampliaciones de la aplicación y su mantenimiento.
B.- La revisión interna de las aplicaciones: Se controlarán las fases a seguir para el desarrollo:
Estudio de viabilidad. Determinante para cualquier aplicación informática, tiempos y costos.
Definición lógica. Comprobación de haber completado los propósitos lógicos de actuación, en
función de la metodología elegida y la finalidad del proyecto.
Desarrollo técnico. Se verificará que sea ordenado y correcto. Las herramientas técnicas utilizadas
en los diversos programas serán compatibles entre sí y, a ser posible, con las ya existentes en el
sistema de la empresa.
Diseño de algoritmos. Serán sencillos, modulares y económicos en recursos.
Metodología de ensayos. Se realizarán de acuerdo a las normas de la instalación. Se dispondrán
de ensayo de datos, sin el uso de datos reales.
Documentación. Cumplirá la normativa establecida en la instalación, tanto en desarrollo como en
explotación.

72
 Recursos Humanos Utilizados. Deberán fijarse las tareas de análisis, de programación y las inter-
medias para cada elemento que constituye el grupo de desarrollo. En aplicaciones complejas se
recomienda variaciones en la composición del mismo, pero previstos en la planificación inicial.

C.- Satisfacción de usuarios: Una aplicación técnicamente eficiente y bien desarrollada, cumplirá con los
intereses del usuario solicitante, cuya aprobación proporciona grandes ventajas ya que evitará reprogra-
maciones y disminuirá el mantenimiento posterior de la aplicación.

D.- Control de procesos y ejecuciones críticas: El auditor no descartará la posibilidad de que se esté ejecu-
tando un módulo que no se corresponde con el programa fuente desarrollado, codificado y probado por
el grupo de desarrollo de la aplicación. Comprobará la correspondencia biunívoca y exclusiva entre el
programa codificado y su compilación. Si los programas fuente y los módulo no coincidieran se podría
provocar, desde errores1 que producirían graves fallos y altos costos de mantenimiento, hasta fraudes,
pasando por acciones de sabotaje, espionaje industrial/informativo, etc. Por lo que existen normas espe-
cíficas en cuanto a las librerías de programas; las que hayan sido aprobadas por la unidad de desarrollo,
son entregados a explotación con el propósito de:

1.- Copiar el programa fuente en la librería de fuentes de explotación, sólo el administrador tiene
acceso.
2.- Compilar y depositarlo el programa en la librería de módulos de explotación, sólo el administrador
tiene acceso.
3.- Copiar los programas fuente solicitados para su modificación, arreglo, etc. en el lugar que se le
indique.
4.- Cualquier cambio exigirá pasar de nuevo por el punto 1.

8.3. Objetivo
La política para auditar e ingresar un nuevo desarrollo es ardua y compleja, por ello muchas empresas se
apoyan en profesionales y en la auditoría externa como método para la confirmación que el desarrollo cumple
con las expectativas y fases expuestas.

8.4. Etapas
8.4.1. Participación de la gerencia
El auditor verificará:

la participación efectiva de la gerencia solicitante en el desarrollo de sistemas, mediante el examen de

los potenciales escenarios según el comité de planeación de sistemas.

la activa participación del departamento usuario en el desarrollo de sistemas.

el presupuesto del departamento de usuario asignado al desarrollo de sistemas de información.

1 Bug en Inglés
8.4.2. Definición del proyecto
Comprobará que la solicitud del proyecto se hizo por escrito y contiene los siguientes elementos:

Justificación.

Ambiente de la aplicación.

Alcance del proyecto.

Restricciones o limitaciones.

Beneficios del proyecto.

Verificará que el proyecto en revisión coincide con el aprobado por el comité de planeación del sistema.
Comprobará que la documentación relacionada con la definición del proyecto está conforme a los estándares
establecidos para tales efectos.

8.4.3. Controles de desarrollo, adquisición y mantenimiento

Son para alcanzar la eficacia del sistema, economía y eficiencia, integridad de los datos, protección de los
recursos y cumplimiento con las leyes y regulaciones:

1. Metodología del ciclo de vida del desarrollo de sistemas: su empleo garantizará que se cumplirán los
objetivos definidos para el sistema. Estos son algunos controles de la metodología:

La Unidad de sistemas publicará una normativa sobre el uso de la metodología de ciclo de vida
del desarrollo de sistemas y la revisará periódicamente.
La metodología establecerá los papeles y responsabilidades de las distintas aéreas de la Unidad de
sistemas y de los usuarios, así como la composición y responsabilidades del equipo del proyecto.
Las especificaciones del nuevo sistema deberán ser definidas por los usuarios y escritas y apro-
badas antes que comience el proceso de desarrollo.
Establecer un estudio de viabilidad del proyecto, en el cual se formulen formas alternativas para
alcanzar los objetivos del proyecto acompañadas de un análisis costo-beneficio para cada alter-
nativa.
Cuando se seleccione una, realizará el plan director del proyecto. En él, existirá una metodología
de control de costos.
Habrá procedimientos para la definición y documentación de especificaciones como: diseño, de
entrada, de salida, de archivos, base de datos, procesos, programas, controles de seguridad, pistas
de auditoría, etc.
Plan de validación, verificación y pruebas.
Estándares de prueba para programas, sistemas, plan de conversión y aceptación final.

2. Explotación y mantenimiento: el establecimiento de controles asegurará que los datos se tratan de for-
ma congruente y exacta y que el contenido de un sistema sólo será modificado mediante la autorización
adecuada. Estos son algunos de los controles a implantar:

Procedimientos de control de explotación.

 Sistema de contabilidad para asignar a usuarios los costos asociados con la explotación de un
sistema de información.
Procedimientos para realizar un seguimiento y control de los cambios de un sistema de informa-
ción.

Entre los principales motivos de una auditoría, están:

1. Aumento del presupuesto del departamento (DPD).

2. Desconocimiento de la situación informática de la empresa.

3. Falta total o parcial de seguridad lógica y física que garanticen la integridad del personal, equipos e
información.

4. Descubrimientos de fraudes efectuados con el uso del computador.

5. Falta de una planificación y/o de visión informática.

6. La empresa no funciona correctamente, debido a falta de políticas, objetivos, normas, metodología,

estándares, delegación de autoridad, asignación de tareas y adecuada administración de sus recursos.

7. Descontento general de los usuarios, debido a incumplimiento de plazos y mala calidad de resultados.

8. Falta de documentación de los sistemas.

Los motivos para efectuar una auditoría son sustentados cuando existen síntomas de debilidad en la empresa,
tal que acude a la auditoría externa para determinar en donde están las falencias. Estos síntomas se agrupan
en:

1. Desorganización y descoordinación:

Los tiempos conseguidos no se ajustan con los estimados, porque los parámetros de productivi-
dad no son respetados y sufren un desvío.
Los objetivos que la empresa persigue, no coinciden con los obtenidos.
Esto puede darse por un cambio masivo de personal, o porque un área tuvo una mala reestructu-
ración, o debido a que una norma importante que haya sido modificada.

2. Insatisfacción del usuario y una mala imagen, cuando:

no hay capacidad de satisfacer sus requerimientos.

las fallas en hardware no son reparadas, ni se resuelven las incidencias en los plazos establecidos
y razonables, ocasionando un descontento por sentirse no atendido.
los resultados no son entregados en los plazos establecidos.

Las pequeñas imprecisiones pueden ocasionar que la información generada no refleje lo real y que la
actividad del usuario se vea afectada por este motivo.

3. Debilidades económico-financieras:

Elevación de costos de forma repentina y desmesurada.

Por la necesidad de justificar las inversiones informáticas.
 Cuando se dan otras prioridades en el aspecto presupuestario.
Debido a costos y plazos de nuevos proyectos.

4. Existe inseguridad:
Se da una evaluación de nivel de riesgos, la que contempla los puntos siguientes:

a) Seguridad Lógica.
b) Seguridad Física.
c) Aspectos de confidencialidad.

La continuidad en el servicio es importante. En ocasiones se considera más importante que los

aspectos de seguridad.
Existen problemas en los que el (CPD) se encuentra fuera de control, una auditoría no tendría
sentido por considerarse inútil, por eso deben tomarse en cuenta los más mínimos indicios para
su aplicación.

Los principales objetivos son los siguientes:

Controlar que las actividades se realizarán cumpliendo los procedimientos y normas fijados, evaluará
su bondad y asegura el cumplimiento de las normas legales.

Asesorar sobre el conocimiento de las normas.

Colaborar y apoyar el trabajo de auditoría informática, así como de las auditorías externas al Grupo.

Definir, implantar y ejecutar mecanismos y controles para comprobar los grados de aceptación del
servicio informático, lo cual no debe considerarse que la implantación de los mecanismos de medida
y la responsabilidad del logro de esos niveles se ubique en la función de control interno, sino que cada
responsable de objetivos y recursos asuma su responsabilidad es esos grados, así como la implantación
de los medios de medida adecuados.

Los sistemas de información no escapan a la nueva economía, la cual ha obligado a las empresas a realizar
cambios. Algunos de éstos, se resumen en:

Reestructuración de los procesos empresariales (BPR: Business Process Re-engineering)

Gestión de la calidad (TQM)2 es una estrategia orientada a crear conciencia de calidad en los procesos
organizacionales. TQM ha sido ampliamente utilizada en fabricación, educación, gobierno e industrias
de servicio, en los procesos que se realicen en cualquier tipo de organización.
TQM pretende no ser responsabilidad de un departamento concreto de la empresa, sino que es respon-
sabilidad de todos sus integrantes.
Por tanto, cuando se habla de TQM, no se trata solamente de la calidad del producto o del servicio
ofrecido por la organización, sino que más allá, al referirse a la calidad integral de los procesos y sis-
temas. Es decir, para lograr un producto o servicio final de calidad, también los procesos y sistemas
empleados en la ejecución de los mismos, deben ser de calidad.
Se afirma que TQM es la implantación de la calidad en los niveles de la organización, hasta conseguir
2 La Gestión de Calidad Total
 que todos los integrantes de la empresa, se empeñen en el logro colectivo y global de la máxima cali-
dad.
Además, supone un cambio profundo en la cultura de la empresa, ya que pone el énfasis en las perso-
nas, a diferencia de otras etapas del desarrollo de la calidad, en las que se ponía en otros elementos.
Se resume la filosofía de TQM, en los siguientes conceptos:

• Orientación al usuario, tanto externo como interno, ya que es la razón de ser de la empresa y sin
su presencia y fidelidad, su sostenibilidad a largo plazo es imposible.
• La Participación activa del personal. Tendrá la habilidad y posibilidad, de proponer y realizar
cambios en los procesos y aportar soluciones a los problemas que surjan. Esto se consigue a
través de la formación y mejora de sus conocimientos y competencias.
• La Toma de decisiones basada en hechos. En muchas ocasiones, las empresas toman decisiones
basadas en intuiciones que pueden llegar a ser problemáticas. En cambio, con la toma de decisio-
nes basada en hechos y las herramientas adecuadas, es posible medir los resultados de procesos
y evaluar el grado de cumplimiento de los mismos.
• La Mejora de Procesos Permanente. Éstos, son el motor de la organización y en constante cam-
bio, lo que es necesario aplicar una metodología de mejora continua de los mismos, tal que
se proporcionen respuestas eficientes, a los requerimientos de calidad de los usuarios, en cada
momento.

La Gestión de la Calidad Total, es una filosofía de estilo de dirección, orientada a la mejora continua
de los procesos y sistemas, contando con la participación activa de los integrantes de la organización.

Dimensionamiento por reducción o crecimiento hasta el nivel correcto.

Consultoria3 .

Descentralización.

Los cambios mencionados se deben a fuerzas externas que presionan a la empresa (ver Figura 8.1). Ante esta
situación, las empresas evaluarán sus sistemas de control interno de manera permanente.
Para gestionar estas fuerzas, es necesaria la adopción de la tecnología disponible.
Los sistemas de información constituyen un soporte fundamental para iniciar las estrategias planteadas por
la dirección. También, origina un aumento de los requerimientos de control y auditoría.
En este escenario aparecen 2 conceptos fundamentales: El control interno y la auditoría informática.
3 Outsourcing
 Figura 8.1: Atributos de calidad de la información

El control interno informático y la auditoría informática, tienen similitudes en sus objetivos profesionales.
Son campos análogos que propician una transición natural entre ambas disciplinas. Sin embargo, existen
diferencias que conviene resaltar.

Tabla 8.1: Tabla de similitudes y diferencias

Control interno informático Auditoría de sistemas
Similitudes
Conocimientos especializados en Tecnologías de la infor-
mación.

Verificación del cumplimiento de los controles internos,

normativas y procedimientos establecidos por la Dirección
de informática.

Diferencias
Análisis de los controles Análisis de un momento
diario. informático determinado.

Informa a la Dirección de Informa a la Dirección

informática. General.

Sólo personal interno. Personal interno y ex-

terno.
Sus funciones son única-
mente para la Dirección Cubre todos los compo-
de informática. nentes de los sistema de
información.
8.4.4. Auditoría de la calidad del software
El software puede ser desarrollado en casa (por la empresa) o por especializada en desarrollo de software, en
ambos casos, la empresa debe atender que el objetivo principal es reducir el costo, elevar la productividad
y eficiencia bien sea en la empresa usuaria como en la desarrolladora de software y mejorar la calidad para
lograr un producto competitivo que se ajuste a los requerimientos de calidad establecidos por ambas.
Producir ”calidad” es indispensable no sólo para lograr y conservar un segmento de mercado, contra una
competencia cada vez mas aguerrida, sino por que es pasar de un mercado nacional a uno internacional o
global. La utilización de métodos y técnicas para incrementar la calidad de los productos de software amplia
los propios horizontes comerciales.
El aseguramiento de la calidad desempeña un rol determinante para la competitividad de la empresa.
Una auditoría de calidad tiene como objetivo mostrar la situación real para aportar confianza y destacar las
áreas que la pueden afectar. Otro objetivo consiste en suministrar una evaluación objetiva de los productos y
procesos para corroborar la conformidad con los estándares, las normas, las especificaciones y los procedi-
mientos.
Para realizar la evaluación de la calidad del software se considera la Norma ISO 9126-1:2001. La cual define
las características de calidad como un conjunto de atributos del producto de software a través de las cuales
la calidad es descrita y evaluada.
Estas características de calidad del software pueden ser precisadas a través de múltiples niveles de caracte-
rísticas.
Esta norma tiene 4 partes: (a) Modelo de calidad – ISO 9126-1:2001 (b) Métricas externas, las cuales mi-
den el software en sí mismo (Calidad externa) – ISO 9126-2:2003 (c) Métricas internas, las cuales miden el
comportamiento del sistema (Calidad interna) – ISO 9126-3: 2003 (d) Calidad en uso, el cual mide el efecto
de usar el software en un contexto específico – ISO 9126-4:2004.
ISO 9126-1:2001 plantea las siguientes características de calidad:

Funcionalidad.
Es el conjunto de atributos que se refieren a la existencia de un conjunto de funciones y sus propieda-
des específicas. Las funciones cumplen unos requerimientos o satisfacen unas necesidades implícitas.
Cuyas características de la funcionalidad son: aptitud, precisión, interoperatividad, conformidad, se-
guridad y trazabilidad.

Confiabilidad.
Es el conjunto de atributos que se refieren a la capacidad del software de mantener su nivel de ren-
dimiento bajo unas condiciones especificadas durante un período definido. Las características de la
Confiabilidad son: Madurez, Tolerancia a fallas, Facilidad de Recuperación, Disponibilidad y Degra-
dabilidad.

Facilidad de Uso.
Es el conjunto de atributos que se refieren al esfuerzo necesario para usarlo, y sobre la valoración indi-
vidual de tal uso, por un conjunto de usuarios definidos e implícitos. Las características de la Facilidad
de Uso son: Comprensibilidad, Facilidad de aprendizaje, Operatividad, Explicitud, Adaptabilidad al
usuario, Atractivo, Claridad, Facilidad de ayudas y Amistoso al usuario.

Eficiencia.
Es el conjunto de atributos que se refieren a las relaciones entre el nivel de rendimiento del software y la
 cantidad de recursos utilizados bajo unas condiciones predefinidas. Las características de la Eficiencia
son: Respecto al tiempo y Respecto a los recursos.

Facilidad de Mantenimiento.
Es el conjunto de atributos que se refieren al esfuerzo necesario para hacer modificaciones especifi-
cadas. .Las características de la Facilidad de Mantenimiento son: Facilidad de análisis, Facilidad de
cambio, Estabilidad y Facilidad de prueba.

Portabilidad. Es el conjunto de atributos que se refieren a la habilidad del software para ser transfe-
rido desde un entorno a otro. Las características de la Portabilidad son: Adaptabilidad, Facilidad de
instalación, Conformidad y Facilidad de Reemplazo.

La valoración de estas características es útil para que el usuario defina los requerimientos del producto
utilizando solamente las características que emplee en la práctica. Para algunos tipos de productos de soft-
ware, hay determinadas características que no son significativas y las restantes no garantizan que con ellas
comprendan todos los requerimientos de los productos de software, por lo que en cada caso habrá que com-
pletarlas con otras definiciones más específicas para esos productos o situaciones. No obstante el modelo
tiene el nivel de abstracción suficiente como para que sea adaptable en la mayoría de las situaciones, siendo
además, independiente de la tecnología. Los pasos para la realización de una Auditoria de la Calidad del
Software son:

1. Identificación del Producto de software que se pretende auditar,

2. Determinar los Requisitos aplicables,

3. Relevar la información necesaria para el cálculo de las métricas de los requisitos aplicables,

4. Evaluar la Calidad del Software usando las métricas respecto de los requisitos establecidos en el paso
2 y determinar su cumplimiento,

5. Establecer las acciones correctivas respecto de los requisitos evaluados y

6. Elaborar un Informe Final.

El informe de auditoría de la calidad es un medio formal para comunicar los objetivos propuestos, el cuerpo
de las normas, el alcance, y los hallazgos y conclusiones. Es un documento que refleja los objetivos, alcan-
ces, observaciones, recomendaciones y conclusiones del proceso de evaluación relacionados con las áreas de
informática. El informe debe incluir suficiente información para que sea comprendido por los destinatarios
esperados y facilitar las acciones correctivas.
Existen esquemas recomendados respecto de los informes de auditoría con los requisitos mínimos aconseja-
bles respecto a estructura y contenido. Los puntos esenciales son:

1. Identificación del Informe,

2. Identificación del Cliente,

3. Identificación de la empresa auditada,

4. Objetivos de la Auditoría Informática,

5. Normativa aplicativa y excepciones,

 6. Alcance de la Auditoría,

7. Conclusiones: Informe corto de opinión ,

8. Resultado: Informe largo y otros informes,

9. Informe previo,

10. Fecha del Informe,

11. Identificación y firma del Auditor,

12. Distribución del Informe y

13. Conclusiones.

Por último, se dice que la auditoría de la calidad del software trae aparejado la certificación del software, lo
cual mejora el nivel de competitividad de la empresa con sus respectivas consecuencias.

8.4.5. Procedimientos efectivos y documentados

En el concepto de control total de calidad, la supervisión operativa exigirá que todo empleado sea consciente
de su responsabilidad laboral y en todas las especificaciones técnicas de su actividad, para asegurar resultados
completos, precisos y oportunos.
Con las siguientes pruebas, el auditor detectará el grado de información que posee el empleado en cuanto a
su responsabilidad en la ejecución del trabajo y su protección ante los distintos riesgos que puedan afectarlo:

1. Comprobará que los procedimientos implementados por el área de desarrollo de sistemas son efectivos
y debidamente documentados.

2. Verificará que el personal conoce, entiende y utiliza los manuales de procedimientos operativos.

3. Evaluará la metodología utilizada para el desarrollo de sistemas computarizados.

4. Verificará que cada fase del desarrollo del sistema genera un producto técnicamente valido, en materia
funcional y de control.

5. Verificará que el comité de planeación, los usuarios, el equipo del proyecto y el grupo de control de
calidad pueden tomar decisiones en cada fase ya sea para continuar, modificar o suspender el proyecto.

6. Verificará que existen, por escrito, la funciones y responsabilidades de:

La gerencia general.
El comité de planeación.
El equipo del proyecto.
El grupo de control de calidad.
La auditoría interna.

El equipo del proyecto estará integrado, por lo menos, por las siguientes personas:

Analistas de sistemas.
 Diseñadores de sistemas.
Programadores.
Diseñadores gráficos.
Administradores de base de datos.
Expertos en control informático.
Usuarios del sistema.

7. Verificará que las interfaces están bien definidas entre el comité de planeación, la gerencia solicitante,
el equipo del proyecto, el grupo de control de calidad y la función de auditoría interna.

8. Verificará la forma de selección y asignación de responsabilidades a los integrantes del equipo del
proyecto.

9. Verificará que la metodología utilizada para el desarrollo de sistemas pasa revisión periódicamente.

10. Verificará la metodología de desarrollo de sistemas para saber si están empleando las técnicas y los
procedimientos adecuados.

11. Verificará que se lleva un control de actualización de la metodología de desarrollo de sistemas.

12. Verificará que las decisiones tomadas por el personal de sistemas y los usuarios establecen una meto-
dología para el desarrollo de sistemas valida.

A continuación, el auditor identificará los puntos de control a ser evaluados en cada fase del proyecto:

8.5. Estudio preliminar

8.5.1. Equipo de trabajo
El auditor verificará que para el desarrollo del proyecto, la conformación del equipo de trabajo sea coherente
con la metodología para el desarrollo del sistema.
Analizará las responsabilidades de los integrantes del equipo de desarrollo de sistemas.
Evaluará los antecedentes y capacidades, en general, de los miembros del equipo del proyecto.
Investigará que el personal de sistemas y el usuario se identifican con los objetivos y alcance el proyecto.

8.5.2. Requerimiento de información

El auditor comprobará que la descripción del sistema vigente es suficiente amplia para tomarla como base
para los requerimientos del nuevo sistema, y si se han identificado claramente las áreas problemas.
El auditor verificará que se evalúan los requerimientos del sistema, para asegurar la integridad, consistencia
y la factibilidad del proyecto y que concuerdan con los estándares correspondientes.
8.5.3. Aprobación del proyecto
El auditor comprobará que la gerencia recibió oportunamente el estudio de factibilidad para la correspon-
diente revisión y aprobación o desaprobación.
Verificará que la gerencia tomo la decisión de continuar el proyecto con base en el estudio de factibilidad y
que el calendario autorizado para el proyecto se hizo por escrito.
Comprobará que el equipo de trabajo prepara el informe final cumpliendo con los lineamientos aprobados
para este caso y que el informe del equipo de trabajo es revisado y aprobado por la gerencia, antes de pasar
a la siguiente fase.

8.5.4. Factibilidad
El auditor evaluará las alternativas de acción sugeridas por el equipo de trabajo y la potencial factibilidad de
cada uno de ellas.
Evaluará que la acción recomendada se sustenta adecuadamente y factible.

8.5.5. Factibilidad tecnológica

Analizará la factibilidad tecnológica y que se han cumplido los siguientes aspectos:
Requerimientos y disponibilidad de hardware y software.

Restricciones que puedan presentarse y la manera de abordarlas.

8.5.6. Factibilidad operacional

Analizará la factibilidad operacional con relación a:
Los recursos de hardware, software, redes informáticas y de comunicaciones.

8.5.7. Factibilidad legal

Examinará los siguientes componentes legales:
Transferencia de tecnología informática.

Restricciones al uso de la tecnología informática.

8.5.8. Factibilidad económica

Examinará el estudio de costos para cada alternativa de acción y que incluyen los costos, tanto de lado del
usuario y de sistemas, cubren todas las fases del ciclo de desarrollo de sistemas. El estudio de costos incluye:
Hardware.

Software.

Entrenamiento.

Preparación y entrada de datos.

Conversión de archivos y base de datos.

 Pruebas.

Operación en paralelo.

El auditor comprobará que haya consenso, entre los usuarios finales de los sistemas, diseñadores, progra-
madores y quienes implantan el sistema, acerca de los costos, beneficios y requerimientos contractuales del
sistema.

8.5.9. Plan maestro

El auditor comprobará la existencia y efectividad de los estándares de aceptación para cada punto de control
identificado y su utilización en el ciclo de desarrollo del proyecto.
Verifique.
Examinará los registros de control del proyecto para conocer la forma como se han llevado a cabo.
Comprobará que los informes del personal que controla el proyecto se entrega oportunamente a la gerencia.

8.5.10. Control de costos

Analizará los informes de costos en función de tiempo de máquina, nomina y provisiones, resúmenes de
tiempos de dispositivos informáticos y de los empleados.
El auditor comprobará que los informes de costos se preparan y distribuyen oportunamente, observando los
registros que llevan los usuarios, en cuanto a la fecha de recepción, revisión y aprobación respectivas.

8.6. Diseño detallado del sistema

8.6.1. Especificaciones de salida
Examinará la documentación de las especificaciones de salidas del sistema y que contempla los siguientes
elementos:

Formato y contenido de los informes.

Condiciones de entrega de los informes a los usuarios.

Periodos de retención de los informes.

Pistas de auditoría.

Periodo de retención de los archivos.

El auditor verificará de que las especificaciones de salida garanticen al usuario la integridad, exactitud y
autorización de la información recibida.
Además, comprobará que las especificaciones de salida están conforme a los estándares de desarrollo de
sistemas.
8.6.2. Especificaciones de entrada
El auditor examinará la documentación de las especificaciones de entrada y que contiene:

Especificaciones de validación.

Controles de privacidad.

Autorizaciones de entradas y de actualizaciones.

Verificará que la gerencia del departamento usuario ha revisado y aprobado por escrito, las especificaciones
de entrada y están documentadas con base en los estándares de desarrollo de sistemas.

8.6.3. Especificaciones de los archivos y base de datos

El auditor comprobará que se han definido los archivos, base de datos y los métodos de organización ade-
cuados.
En caso de trabajar con bases de datos, verificará que se definen las relaciones estructurales.
Examinará la documentación de los requerimientos del usuario y los tipos de archivos y base de datos para
detectar si la gerencia solicitante las revisó y aprobó, por escrito.
El auditor verificará que el administrador de la base de datos participó en la definición, documentación y
organización correspondiente.
Comprobará que la seguridad ha sido considerada en el proceso de la definición de los archivos y base de
datos y que los periodos de retención de ellos han sido incluidos en sus definiciones.
Establecerá que la documentación relacionada con las especificaciones de los archivos y base de datos se
ajusta a los estándares de desarrollo de los sistemas.

8.6.4. Especificaciones de procesamiento

Examinará que las especificaciones de procesamiento están preparadas de acuerdo con las políticas de la
empresa, que la gerencia solicitante ha revisado y aprobado por escrito las especificaciones de procesamiento
y que la documentación de las especificaciones de procesamiento está de acuerdo con los estándares de
desarrollo de sistemas.

8.6.5. Documentos fuente

El auditor observará las formas de los documentos fuente utilizados para recolectar datos con el objeto de
establecer en su diseño responde a los requerimientos del usuario.
Examine las formas de los documentos fuentes para determinar si contienen todas las condiciones para
efectos de control, tales como estar foliados y tener la autorización de la transacción.
Analice las formas de los documentos fuente para ver si su diseño facilita la obtención de información para
control y promoción de la exactitud de los procesos.
Examine el formato de pantallas para establecer si facilita la obtención de información, y si tiene rutinas de
edición cuando la entrada de datos se hace en línea.
8.7. Diseño de controles
El auditor analizará que se cumple con:

las especificaciones del diseño detallado.

los controles programados.

los controles en mantenimientos preventivos y correctivos en cada punto de control.

el análisis de costo-beneficio para definir los controles programados.

8.7.1. Pistas de auditoría

El auditor analizará que:

las especificaciones del diseño detallado, la documentación intermedia y los listados previstos en el
diseño.

la exactitud de los documentos intermedios y, en general, de los listados validos como pistas de audi-
torías.

la seguridad e integridad de todos los elementos son considerados pistas de auditoría.

8.8. Desarrollo e implantación

8.8.1. Objetivo de la programación
El auditor examinará que los objetivos de la programación están adecuadamente interpretados. Observará las
funciones, entradas, salidas, base de datos y los archivos.
Analizará la coherencia entre los objetivos y los estándares de programación.

8.8.2. Descripción de la programación

El auditor analizará que:

las metodologías de la programación corresponden con la definición original del sistema.

la descripción detallada de la lógica, con el objetivo de establecer que está escrita en forma clara y
concisa para que sea fácilmente entendida su función.

los estándares de documentación están un diagrama de flujo del programa y que la documentación lo
contempla actualizado y ajustado a la definición del programa.

las descripciones de los archivos correspondientes a los programas seleccionados con el objetivo de
establecer si se describen con precisión los registros y los campos para los datos, incluyendo las defi-
niciones de los códigos y de los registros.
 que las descripciones de los archivos y base de datos y los registros del administrador de la base de
datos y del diccionario de datos están de acuerdo con los estándares de la documentación. Cuando
sean base de datos, verificará que los elementos utilizados por los programas seleccionados están
debidamente descritos y que no alteran otras definiciones del sistema.

8.8.3. Software estandarizado

El auditor comprobará que el software seleccionado:
cuenta con informes de factibilidad, recomendaciones y alternativas.

tiene contratos de adquisición que corresponden con las políticas de la empresa.

fue revisado y aprobado antes de usarlo y pagarlo.

cuenta con documentación para su adaptación y validez del sistema incorporado.

8.8.4. Programación por contrato

El auditor examinará los términos del contrato para comprobar que:
son adecuados y la intervención del gerente de sistemas en su aprobación.

se cumple con las políticas de la empresa.

los servicios esperados están claramente expresados y definidas las contingencias.

los programadores han instruidos en los estándares de documentación para la programación y sobre
los objetivos definidos por la organización.

el grupo de control de calidad y el de sistemas de información han aprobado los códigos, la documen-
tación y controles en los programas según políticas definidas por la empresa.

la documentación de los programas cumple con los estándares de la organización.

los pagos por servicio de programación están aprobados y de acuerdo con el respectivo contrato.

8.9. Documentación de los programas

El auditor comprobará que la documentación:
cumple con los estándares correspondientes.

ha sido probados por el comité de planeación de sistemas de información.

considera el tipo de equipo, sistema operativo, aplicaciones y lenguajes de programación.

es conocida y practicada por el personal de la empresa.

de los programas, a nivel individual, cumple con los estándares predefinidos.

ha sido revisada por la gerencia de sistemas, y que es adecuada y completa.

8.9.1. Manual de operaciones
El auditor comprobará que estos manuales:

existen.

corresponden a cada programa y/o aplicación.

se ajustan a los estándares de documentación establecidos.

cumple con lo siguiente:

• Función del programa.

• Especificaciones de hardware.
• Relación de los mensajes de consola, y con la respuesta que dará el operador.
• Creación de las salidas y su uso.
• Identificación de las etiquetas de los archivos de salida.
• Punto de reinicio.
• Procedimientos para tratar los errores.

son utilizados en las prueba.

son leídos y utilizados por los operadores.

8.9.2. Manual de usuario

El auditor comprobará que estos manuales:

existan por cada aplicación.

cumplen estándares y en la medida que necesita el usuario en cada aplicación.

ayudan a preparar los datos de entrada.

8.10. Pruebas del software

Las pruebas sólo confirman la existencia de los errores que detectan.
Cuando realiza un batería de pruebas y detecta una serie de errores, nadie asegura que no existan más
errores que la prueba no detecta, sólo conoce que los errores detectados existen.

Es imposible probar todos los casos posibles.

El número de casos posibles a probar en la prueba de un software es un número alto, probablemente
infinito, por lo que debe asumir que no se pueden probar todos los casos.
Además, cualquier corrección que aplique al software para solucionar incidencias detectadas, añadirá
variables nuevas y éstas harán que el número de casos a probar vuelvan a aumentar.
La eficacia en la detección de errores de las mismas pruebas disminuye con el paso del tiempo.
Esto significa que un conjunto de pruebas detectará los errores para los que fue diseñado pero no
encontrará los errores para los cuales no se construyó.
La automatización de la ejecución de las pruebas pierde su valor con el tiempo ya que los errores que
detecta no aparecerán pero no alertará sobre otros que se hayan introducido y para los cuales no había
sido diseñado.

El software se puede probar sin estar terminado.

No olvidar que hay una forma de prueba temprana del software. Recordar los dos tipos de pruebas que
se pueden efectuar:

• Forma dinámica. Ejecutando el software y realizando los casos y ciclos definidos.

• Forma estática. Revisiones del código para encontrar defectos.
Este tipo de revisión será realizada en cualquier fase del ciclo de vida del desarrollo del software
no hay que esperar a que esté construido completamente. Al detectar con antelación el costo de
su corrección es menor.

Los errores se ocultan detrás de otros errores.

Los errores suelen ocultarse detrás de otros errores, ya que se agrupan cuando aparecen. Esto hace que
repetir las pruebas sea una inversión en tiempo importante a ser tomada en cuenta en el presupuesto
del proyecto.
¿Cómo ayudarían en esto las herramientas de prueba estática? Pues como lo hace el corrector orto-
gráfico a la hora de escribir en un procesador de texto, marcando lo que no es del todo correcto y
haciéndonos ganar tiempo.

Las Pruebas dependen del contexto.

Para que las pruebas que se realizan sobre un software sean lo más eficientes y efectivas posibles,
deben tener en cuenta el tipo de proyecto y de producto sobre el cual se realizan.
Como una lista de historias de usuario a ser revisadas de forma estática pero no pueden ser probadas
de forma dinámica, ya que no tienen código que ejecutar.

Un software sin errores es una falacia.

Si una batería de pruebas no genera error, es decir todo ha ido bien, no significa en ningún caso que el
software no tenga errores sino que dichas pruebas no lo han detectado.
 9
Auditoría de la red informática

Con las redes informáticas y el acceso a Internet se consolidó un medio de comunicación que ha impactado
sobre los modos de organización de la sociedad y, por ende, el empresarial.
Interacción que ha generado las comunidades virtuales que están integradas por personas y organizaciones,
ubicadas en diferentes lugares y momentos, que comparten intereses comunes. En la práctica, compartir,
significa información en formato digital que fluye en muchos sentidos a través de la red. Stevenson [24] se
refiere a ella como la ”sociedad de la información compartida”.
En la actualidad, los elementos que conforman una red informática adquieren diferentes responsabilidades
sobre la información y su compartición, involucrándolos en diversos procesos del negocio. Por ello, este
capítulo está enfocado al estudio de la seguridad y administración en los diferentes puntos de acceso a las
redes informáticas de las organizaciones.
Dentro del ámbito informático, las redes informáticas quizás lo que más ha cambiado son las formas, se
habla de intranet1 , internet, Wifi, Bluetooth y la nube. También, el espectro de la auditoría ha cambiado,
ahora existe para redes alámbricas, inalámbricas y, la novedosa auditoría forense.
Son casos especiales las tecnologías computacionales en el sector de e-gobierno, la salud, el bancario y
financiero; situación que han incrementado la necesidad de una gestión eficaz y eficiente en la autorización
de ingreso a los recursos de red desde dentro o fuera de la misma y la necesidad de mantener los datos seguros
y no expuestos; además de tener una red libre de amenazas ante el tráfico de estos datos, manteniendo así
una red segura, disponible y confiable [25].
1 La tipología de red ha saltado del cableado clásico a la fibra óptica, y las microondas.

90
 Figura 9.1: Elementos de seguridad a considerar en instituciones financieras.

Además, se están desarrollando sistemas operativos y aplicaciones pensados para otros dispositivos de me-
nor tamaño, distintos a los supercomputadores, computadores de escritorio, como ”laptops”, ”tablets”, los
”ebooks”, o los teléfonos inteligentes.

9.1. Objetivo
Una auditoría de red informática, es un proceso de revisión de la seguridad de una aplicación web, y más en
concreto, en el área de seguridad y administración de redes y sistemas operativos y cuya finalidad es encon-
trar las vulnerabilidades de seguridad existentes, con el objetivo de solucionarlas antes de que el atacante se
aproveche de las mismas.
Un auditor informático en redes informáticas es una profesional especialista con conocimientos técnicos
profundos en el ámbito de la informática, que es capaz de analizar una aplicación desde el punto de vista de
un atacante anónimo, tanto interno como externo.
El auditor informático atenderá la seguridad como uno de los puntos más preocupantes y complejos en el
diseño de las arquitecturas de red informática y la protección del manejo de la información, como responsa-
bilidad principal de la empresa, y en aquellos sectores especiales, donde la información tiene características
de confidencialidad e integridad únicas.
Además, verificará que la empresa facilite al usuario autenticarse en el sitio Web para iniciar una sesión, y
que una vez iniciada, un tercero no pueda utilizarla o interceptarla.
También, acreditará la realización de revisiones de seguridad, para constatar que los controles aplicados a
la infraestructura de cómputo y telecomunicaciones utilizadas sean los adecuados para las operaciones y
prestación de servicios a través de medios electrónicos.
9.2. Propósito
En los últimos tiempos se han incrementado, en potencia y frecuencia, los problemas ocasionados con los
ataques vía Internet. Muchas empresas ven comprometida su seguridad por las vulnerabilidades en su infra-
estructura tecnológica, lo que obliga a comprobar el sistema interno.
Por este motivo, es necesario conocer los tipos y propósitos de la auditoría a las redes informáticas, como
recurso eficaz para mantener la seguridad informática.
El auditor listará, de manera general, el conjunto de enfoques a ser utilizados para llevar a cabo la auditoría
de una red informática corporativa, donde deberá mencionar que el objetivo es: dar información sobre el
estado de las medidas de seguridad aplicadas, para identificar fallas, evaluarlas y posteriormente corregirlas.
Por último, se resaltará que no debe aplicarse una visión parcial de la auditoría, ya que en la actualidad las
distintas amenazas obligan a tener una perspectiva general de los problemas. De esta manera, es posible con-
siderar los distintos enfoques y sobre todo los elementos involucrados, ya que ningún sistema se encuentra
aislado -desde dispositivos de red, equipos de cómputo, móviles o cualquier otro que pueda conectarse a una
red.
Y esto, sin los análisis pertinentes, podría aumentar el espectro de vulnerabilidades.

9.3. La importancia de una auditoría de seguridad de red

La auditoría de información es enfocada por los estudiosos del área en dependencia de los propósitos trazados
y sus propias experiencias. Así, Cornella2 [28] la define como ”...un proceso de identificación y evaluación
de los recursos de información, con el propósito de garantizar solo el flujo de la información necesaria, la que
permite cumplir los objetivos de la organización...” Un enfoque similar lo aportan Buchanan y Gibb3 [29]
al referirse a este proceso como un método que identifica, evalúa y gerencia los recursos de información,
planteamiento con el que coincide el Information Resources Management Network.4 [30]
Resulta de vital importancia señalar que la existencia de distintos tipos auditoría descansa no sólo en sus
objetivos o en las personas que la realizan, sino también en la información que evalúa. El hecho de que,
independientemente del tipo de auditoría, lo que se examina es la información documentada u obtenida a
partir de diversos instrumentos de recopilación, lo que conduce a la comprensión de su importancia para el
funcionamiento de una organización y al surgimiento de la auditoría de la propia información.

9.3.1. Analizar riesgos

El análisis de riesgos es una tarea importante en la auditoría de redes, pues es la única manera de comprender
cuán vulnerable es el sistema y, con ello, mejorar este aspecto.
Lo que el auditor pretende es conocer el estado de protección de los activos de manera medible y en qué
nivel.
Esto se podría realizar de manera autónoma, sin considerar una auditoría completa aunque es inconveniente,
2 La auditoría de la información es básicamente un proceso de identificación y evaluación de los recursos de información nece-

sarios para cumplir con los objetivos de la empresa. Se trata de un paso previo a la determinación de una estrategia de gestión de la
información. De manera muy simple: el objetivo de la auditoría de la información es asegurar que la información que circulará por
el sistema es la que más conviene a la organización.
3 El papel de la auditoría de información es mantener un método para identificar, evaluar y gerenciar, y recursos de información

gerencial que aprovecha el potencial estratégico de la información.

4 Un análisis sistemático del uso, los recursos y los flujos de información, y una comprobación que establezca tanto en lo que

concierne a la gente como a los documentos existentes hasta qué punto éstos contribuyen a los objetivos de una empresa.
pues no deja de ser sólo una parte del proceso que sirve en determinados casos pero cuyos resultados podrían
ser, incluso, contraproducentes.

9.3.2. Trabajo en el laboratorio

El auditor trabajará sobre un sistema de control desconectado del productor, procurando que sea lo más pa-
recido posible al original para que los datos sean concluyentes. No podrá trabajar sobre los riesgos pero sí
identificará las vulnerabilidades y las medidas a tomar para evitarlas.
El análisis que realizará es activo e intrusivo en los dispositivos y pasará por escaneo de puertos, vulnerabi-
lidades y otros.

9.3.3. Trabajo en el sistema de producción

En este caso, el auditor trabajará sobre el sistema de producción real y en funcionamiento, de manera que la
información recibida es un reflejo del trabajo de este.

9.4. Centro de control de red

El Centro de Control de Red se ubicará en el área de producción o sala de servidores.
Sus funciones se refieren exclusivamente al ámbito de las comunicaciones, estando relacionado con la orga-
nización de software de servidores y técnicas de sistemas. Por lo que el auditor analizará la fluidez de esa
relación, el grado de coordinación entre ambos y verificará la existencia de un único punto focal, desde el
cual sean perceptibles todos las líneas asociadas al sistema.
En materia de seguridad para la transmisión de datos, el auditor describirá las medidas para asegurar la
transmisión cifrada punto a punto y los elementos que garantizan la seguridad en cada uno de los nodos
involucrados en el envío y recepción de datos.
Igualmente, verificará que los mecanismos de almacenamiento seguro de los datos que comprometan infor-
mación protegida por los secretos corporativos, de investigación y desarrollo, los mecanismos de cifrado,
incluyendo aquella información resguardada como respaldo o cualquier otra copia que por algún motivo lle-
gará a realizarse son los adecuados.
Además, comprobará que se mantienen copias de la información crítica procesada en una bóveda bancaria,
en la dirección de la empresa, en el centro de computo en su caja fuerte; o si procede, por el prestador de
servicios en las instalaciones de la entidad contratantes ubicadas en territorio nacional.

9.5. Centro de diagnosis

El Centro de Diagnosis atenderá las llamadas de los usuarios-clientes que han sufrido averías o incidencias,
tanto software como hardware. El Centro de Diagnosis está indicado para centros de computo, como bancos,
organismos de e-gobierno y/o empresas de servicios que tiene usuarios dispersos en el territorio local, estatal,
nacional e internacional. Es uno de los elementos que más contribuyen a la imagen corporativa e informá-
tica de la organización. por lo que deberá ser auditada a partir de esta perspectiva, desde la sensibilidad del
usuario sobre el servicio que se le ofrece.
No basta con comprobar la eficiencia técnica del centro, es necesario analizarlo simultáneamente en el ám-
bito del servicio y atención al usuario.
En el caso de auditar a instituciones bancarias y financieras, el auditor verificará que existe un oficial de
seguridad, quien tiene una descripción de sus funciones, las cuales consistirán, entre otras cosas, en admi-
nistrar y autorizar los accesos y claves criptográficas, las cuales deberán almacenarse y resguardarse en las
instalaciones de la entidad bancaria y/o financiera, en territorio nacional, con la finalidad de que la institución
es mantenga enterada del acceso y uso de la información.

Alcance.

• Calificación del personal

• Sistemas técnicos de la red
• Mantenimiento de la Red

Objetivos.

• Realizar un informe de auditoría con el objeto de verificar la adecuación de las medidas aplicadas
a las amenazas definidas, así como el cumplimiento de los requisitos exigidos.

Referencia Legal.-

• Manual de protección de datos aprobado estatal, regional, nacional e internacionalmente,

• Normativa corporativa.

Resultados

• Informe de auditoría detectando deficiencias en el sistema de la red informática.

• Plan de recomendaciones a aplicar en función de:
◦ Normativa(s) a cumplir.
◦ Recomendaciones.

Para el auditor informático, el entramado conceptual que constituyen las redes, sus nodos, líneas, concentra-
dores, multiplexores, redes locales, etc. son el soporte físico-lógico de la auditoría de redes informáticas en
tiempo real.
 Figura 9.2: COBIT–Objetivos de control para la información pública y tecnologías Relacionadas

El auditor enfrentará la dificultad técnica del entorno, pues analizará situaciones y hechos alejados entre sí,
y estará condicionado a la participación del servicio telefónico que presta el soporte.
Como en otros casos, la auditoría de esta área requiere un equipo de especialistas, expertos en seguridad
informática, comunicaciones y en redes locales (no olvidar que en entornos geográficos reducidos, algunas
empresas optan por el uso interno de redes Locales, diseñadas y cableadas con recursos propios).
El auditor de informático investigará sobre los índices de utilización de las líneas contratadas con informa-
ción abundante sobre tiempos de desuso. Deberá proveerse de la topología de la red informática, la cual debe
estar actualizada, de no estarlo significaría una debilidad.
La falta de identificación de puntos, conocida como tabla o listado de asignaciones, que determina núme-
ro de líneas existen, qué puntos unen, cómo son y donde están instaladas, no saberlo supondría una grave
inoperatividad informática.
Estas son algunas de las debilidades más frecuentes o importantes que se encuentran en las redes informáti-
cas. La contratación, instalación y certificación de líneas va asociada a puestos de trabajo correspondientes
(pantallas, servidores de redes locales, computadoras con tarjetas de comunicaciones, impresoras, etc.), ac-
tividades que deberán estar coordinadas y de ser posible, dependientes de una única organización.

9.6. Metodología
Entre otras metodologías para la auditoría de redes informáticas, se propone utilizar una basada en OWASP,
OSSTMM.
La fundación OWASP5 es una organización sin ánimo de lucro fundada en USA.
Su proyecto reconocido es ”OWASP Testing Project”, que es una serie de pruebas para verificar la seguridad
de las aplicaciones web. En general, se utiliza el término OWASP para el testeo de aplicaciones web, pero
5 www.owasp.org
que tiene un amplio espectro de proyectos.
Este libro sugiere utilizar la metodología de pruebas de OWASP.
El manual OSSTMM6 describe la realización de las pruebas de seguridad y las métricas a emplear por el
auditor que realiza la auditoría de seguridad.
La fundación ISECOM publica y actualiza el manual.
OSSTMM es un estándar de facto (fue el primero en aparecer). El manual describe los casos de prueba de
los elementos a probados y como medir los resultados. Es más general que la metodología OWASP, porque
describe todo tipo de auditoría, no sólo la de aplicaciones web, y se toma como referencia para este texto.

9.7. Auditoría de la red corporativa

la auditoría de las redes informáticas dará a conocer el estado en que se encuentra la protección de la infor-
mación dentro de la empresa. Tratará de realizar una evaluación y análisis de las debilidades existentes en las
medidas de seguridad que la empresa utiliza y los componentes que se dedican a esta función. Involucra la
identificación, análisis y evaluación de debilidades de las medidas de seguridad aplicadas y de los elementos
tecnológicos de la empresa.
Además, puede tener distintos objetivos, por lo tanto las revisiones de seguridad varían de acuerdo al alcance,
los criterios a utilizar como parámetros de comparación, las personas involucradas, los objetivos a alcanzar,
entre otros elementos que determinarán el tipo de revisión.
En el caso específico de las redes informáticas, la auditoría está relacionada con un método o un conjunto
de ellos para verificar el cumplimiento de los requisitos de seguridad, necesarios dentro de una colección de
dispositivos interconectados -como routers7 , switches8 , hubs9 , computadoras y dispositivos móviles, niveles
de acceso, entre otros. Ver fig. 9.3.
6 http://www.isecom.org/research/osstmm.html
7 Es un dispositivo que interconecta computadoras que funcionan en el marco de una red. Su función: establecer la ruta que
destinará a cada paquete de datos dentro de una red informática.
8 Es un dispositivo de interconexión utilizado para conectar equipos en red formando lo que se conoce como una red de área local

(LAN) y cuyas especificaciones técnicas siguen el estándar Ethernet (o técnicamente IEEE 802.3)
9 En la actualidad, los hubs se consideran obsoletos. Ya que los switches tienen prestaciones muy superiores, por lo que si alguna

red lo utiliza es recomendable sustituirlo por un switch.

 Figura 9.3: Esquema de una red informática corporativa.

Existen diferentes clasificaciones con las que se verificará que se cumplen los requisitos de seguridad nece-
sarios dentro de los dispositivos que estén interconectados en la empresa.
Algunos de los puntos que certificará el auditor serán:

1. Programa sobre planes de contingencia, seguridad física, entre otros.

2. Programas específicos sobre sistemas de información determinada.

3. Revisión y evaluación de controles y seguridades.

4. Examen detallado de áreas críticas.

 Figura 9.4: Topología en estrella de las redes locales en la actualidad

9.7.1. ¿Qué considerar en la auditoría de redes?

Aquí surge la pregunta ¿Física o lógica?
Cuando se considera la protección de la información y de los dispositivos de red, la auditoría se clasifica en
revisiones de seguridad física y lógica. Por un lado, la revisión de seguridad física está orientada en conocer
y evaluar los mecanismos de protección del hardware y del cableado, mientras que las revisiones lógicas
tienen como propósito verificar y evaluar las medidas de protección sobre la información y los procesos.
En este sentido, la auditoría de seguridad física en redes considera la revisión de las conexiones y las estric-
tas normas de cableado estructurado establecidas por organismos como ANSI o ISO, así como medidas que
protegen tanto el cableado como los dispositivos de red, incluso controles aplicados sobre las salas de servi-
dores. En tanto, las evaluaciones lógicas consideran mecanismos de control de acceso a la red, privilegios de
cuentas con autorización para conexiones o los protocolos utilizados, por mencionar algunos.

9.7.2. ¿Auditoría física y/o lógica?

La revisión física está orientada a conocer los mecanismos de protección del cableado a nivel de hardware.
Se puede decir que lo que se hace en comprobar las normas ISO o ANSI del cableado y la revisión de las
conexiones.
A nivel lógico, la auditoría verificará y evaluará las medidas de protección de los procesos y de la informa-
ción. Además, comprobará los mecanismos de control de acceso a la red, los privilegios de las cuentas con
autorización y los protocolos usados.
También, con base en la configuración de la red, la auditoría considerará revisiones de red interna y externa.
Las externas son aquéllas que se llevan a cabo desde fuera del perímetro y pueden incluir la evaluación de
configuraciones, revisión de reglas en cortafuegos (firewall), configuración de IDS/IPS y listas de control de
acceso en routers, entre otras actividades.
 Figura 9.5: Topología de red informático en árbol.

La red interna, en cambio, considerará la revisión de la configuración de segmentos de red, protocolos utili-
zados, servicios desactualizados y/o topologías empleadas.
La computadora es un instrumento que estructura gran cantidad de información, la cual puede ser confiden-
cial para individuos, empresas o instituciones, y puede ser cambiada, mal utilizada o divulgada a personas,
organizaciones e, incluso, países que hagan mal uso de ésta.
También puede ocurrir robos, fraudes o sabotajes que provoquen la destrucción total o parcial de la actividad
computacional. Esta información es de suma importancia, y el no tenerla en el momento, en la calidad e
integridad precisa provocaría retrasos costosos en tiempo, dinero y prestigio.
En la actualidad y principalmente en los distintos equipos informáticos, personales y/o corporativos, se ha
dado otro factor a considerar: los llamados ”virus” de las computadoras, los cuales, aunque tienen diferentes
intenciones, se encuentra principalmente en paquetes y programas en la red que son copiados sin autoriza-
ción (”piratas”), programas que sabotean toda la información que se tiene en un disco. Al auditar los sistemas
se tendrá cuidado que no se tengan copias ”no autorizadas” o bien que, al conectarse en red con otras compu-
tadoras, no exista la posibilidad de transmisión del virus.
El auditor informático gestionará herramientas como: cortafuegos (firewalls), los sistemas de detección de
intrusiones (IDSs), o los sistemas de gestión de eventos e información de seguridad (SIEM).
El uso inadecuado de la computadora comienza desde la utilización de tiempo de máquina para usos ajenos
de la organización, el acceso a sitios web prohibidos, la copia de programas para fines de comercialización
sin reportar los derechos de autor hasta el acceso por vía telefónica a bases de datos a fin de modificar la
información con propósitos fraudulentos.
La seguridad informática abarca los conceptos de seguridad física y lógica.

9.7.3. La seguridad física

Se refiere a la protección del Hardware y de los soportes de datos, así como a la de los edificios e instalaciones
que los albergan. Contempla las situaciones de incendios, sabotajes, robos, catástrofes naturales, etc.
Aquí entra todo lo concerniente a la seguridad material, o física, del entorno. Y que haya relación personal y
profesional entre el auditor y el objeto material que se pretende atacar. El objetivo de este grupo de pruebas es
comprobar que las defensas y barreras, lógicas o físicas, que protegen los activos, funcionan correctamente,
e impiden todo acceso ilegítimo. Además se debe verificar que hay servicios de protección contra incendios,
tales como extintores y detectores de humo. Un ejemplo sería comprobar que el auditor no puede ganar
acceso al CPD de la empresa auditada, con intención de desconectar los servidores, borrarlos o romperlos,
sin disponer de la llave de la puerta, la clave, tarjeta, o el permiso oportuno para traspasar la barrera de
entrada. Otro ejemplo podría ser apagar el aire del CPD para ver si lo detecta el sistema de monitorización.
La utilidad de estas pruebas también está en detectar algún vacío o brecha en el cumplimiento de las normas
de seguridad indicadas en la política de la empresa, o en las regulaciones o legislación pertinente. Este grupo
tampoco suele aplicarse en el caso concreto de la auditoría web.

9.7.4. La seguridad lógica

Se refiere a la seguridad de uso del software, a la protección de los datos, procesos y programas, así como el
ordenado y autorizado acceso de los usuarios a la información.
Un método eficaz para proteger sistemas de computación es el software de control de acceso. Dicho sim-
plemente, los paquetes de control de acceso protegen contra el acceso no autorizado, pues piden del usuario
una contraseña antes de permitirle el acceso a información confidencial. Dichos paquetes han sido populares
desde hace muchos años en el mundo de las computadoras grandes, y los principales proveedores ponen a
disposición de clientes algunos de estos paquetes.
Existe una Aplicación de Seguridad que se llama SEOS, para Unix, que audita el nivel de Seguridad en los
servidores, como: accesos a archivos, a directorios, qué usuario lo hizo, si tenía o no permiso, si lo no tenía
porque falló, qué hace cuando hay entrada de usuarios a los servidores, fecha y hora, accesos con clave equi-
vocada o cambios en ella, su robustez y complejidad, etc. La Aplicación puede gráficar y hacer reportes, etc.
La seguridad informática se puede clasificar en: a) área general y b) área especifica (ver seguridad de explo-
tación, ver Capítulo 7). Así, se efectuará una auditoría de la seguridad global de una instalación informática
– seguridad general- y auditoría de la seguridad de un área informática determinada –
9.8. Tipo de evaluación de las redes que existen
9.8.1. Nivel interno o externo
Las revisiones externas son aquellas que se realizan fuera del perímetro de la red, incluyendo revisión de las
reglas de Firewall, configuración de IPS, control de acceso a los routers, entre otros.

9.8.2. Sistemas de seguridad para empresas

Por el contrario, las revisiones dentro de la red a nivel interno revisan los protocolos usados, los servicios
desactualizados y la configuración de los segmentos de la red.

9.9. ¿Red cableada o inalámbrica?

Además, la revisión se clasifican en función del tipo de red a evaluar, como en una red cableada o una inalám-
brica, éstas, se clasifican en red Wifi y Bluetooth. En las redes inalámbricas, se evaluará la conveniencia de
los protocolos de cifrado utilizados para las comunicaciones entre los puntos de acceso y los dispositivos que
se conectan a la red, así como el uso de claves de cifrado extensas y complejas, que reduzcan la probabilidad
de éxito de ataques de fuerza bruta o de diccionario.
En este sentido, es importante comprobar la vulnerabilidad de los dispositivos informáticos relacionada con
ataques comunes a las redes inalámbricas, sobresalen la suplantación de puntos de acceso o denegación de
servicio (DoS). Es un punto muy importante, al considerar el peligro de la mala gestión del Wifi en empresas.
Si la auditoría se realiza sobre redes inalámbricas, se evaluará los protocolos de cifrado entre los puntos de
acceso y los dispositivos que se conectan a la red y las claves de cifrado.
Si, por el contrario, se trata de una red cableada, comprobará la vulnerabilidad de los dispositivos físicos o
la suplantación de los puntos de acceso.

9.9.1. Auditoría LAN

Esta red utiliza el cable par trenzado, el coaxial o la fibra óptica como elementos utilizados en las redes LAN
convencionales. También, se determinará la velocidad de transmisión que se sitúa entre los 10 y hasta los
1000 Mbps.
Con las listas de verificación, el auditor realizará un análisis y diagnóstico de la red, para determinar con
exactitud la situación actual de las redes de la empresa auditada, tomando el modelo de referencia OSI,
estándares como el TIA-942, Tire, norma de cableado estructurado ANSI/TIA/EIA-568-B, ANSI/TIA/EIA-
569-A.
 Figura 9.6: Topología de una red informática.

Inicialmente, el auditor evaluará la parte física de la red, las condiciones del cableado estructurado, la sala
de servidores, el centros de datos, etiquetado de los cables, orden, limpieza y fichas técnicas; así como la
bitácora de mantenimiento de los equipos de red. Luego, realizará el levantamiento de información, análisis y
diagnóstico de la configuración lógica de la red: plan-ip, tabla y diagrama de vlan y topológico, ver figura 9.6,
situación del spaning-tree, configuración de los equipos de red, etc. Con la información obtenida realizará el
informe pertinente según situaciones y hallazgos registrados.

9.9.2. Auditoría Wifi

Las redes inalámbricas envían datos por microondas. Éstas, viajan por el aire, por lo que es más fácil ganar
acceso a ellas que a las redes cableadas. El auditor verificará la seguridad de los enrutadores Wifi que comu-
nican los dispositivos informáticos y las medidas adoptadas para evitar los accesos no autorizados a la red;
como protegen las comunicaciones y evitan la denegación de servicio; y por último, verificará la prevención
de transmisiones desde la máquina conectada, cuya información podría ser interceptada durante su procesa-
miento, sin conocimiento del usuario.
El auditor analizará el tráfico de la red para determinar qué algoritmos de cifrado se están empleando, o si la
red funciona abierta y analizará el esquema de autenticación de la red.
Una tarea común es capturar el tráfico de la red Wifi, e intentar obtener la clave secreta de acceso a la red. Si
logra conectarse y hacer uso de ella, se considera que las pruebas han tenido éxito.
Con una auditoría Wifi, el auditor analizará y comprobará este tipo de redes en la empresa, detectando los
problemas de seguridad.
Una red inalámbrica, ver figura 9.5 ofrece:

a) Movilidad.

b) Simplicidad y rapidez en la instalación.

c) Flexibilidad en la instalación.

d) Costo de propiedad reducido.

e) Escalabilidad.

Figura 9.7: Topología de una red WiFi

Las pruebas a realizar son:

Inventario de los dispositivos inalámbricos activos.

Comprobación de uso de claves por defecto.

Auditoría física: Tipos de dispositivos, antenas, localizaciones. . .

Estudio del diseño de la red y la interconexión con la red corporativa.

Análisis del diseño de la política de control de acceso.

Detección de intrusiones.

Análisis y evaluación del sistema de supervisión de la red y de notificación de incidencias.

Comprobación de la red frente a ataques.

Evaluación de mecanismos de detección implementados.

9.9.3. Auditoría Bluetooth
La tecnología BLE (Bluetooth Low-Energy) se encuentra cada vez más distribuida, se usa en el hogar, en la
oficina y en la calle. Y algunos problemas de conectividad son resueltos con Bluetooth de forma eficiente.
El ahorro de energía puede enfrentarse con la seguridad, donde la falta de estándares y omisiones de ellos
por parte de los usuarios originan debilidades y ataques que pueden ser utilizados para obtener información
de un dispositivo conectado vía Bluetooth, o manipularlo o realizar acciones para las que no fue diseñado o
autorizado.
Un sistema con alto nivel de seguridad, podría ser vulnerable gracias a un ratón o un teclado inalámbrico
Bluetooth.
La auditoría a dispositivos BLE consistirá en una serie de pruebas para identificar el nivel de seguridad de
los dispositivos que utilizan esta tecnología. El auditor tratará de ”sniffar”10 el tráfico BLE desde dos puntos
de vista: desde un dispositivo BLE o ”escuchando” el aire con placas Micro:Bit y la herramienta BTLEJack.
Por lo que el auditor manejará conceptos técnicos avanzados y la teoría necesaria para entender Bluetooth
como, los canales BLE, channel map, address access, el intervalo e incremento de salto, el algoritmo de
salto, los roles de los dispositivos, entre otros.
En ocasiones, el problema radicará en las posibilidades de suplantación en el ámbito Bluetooth y las medidas
a tomar para fortalecer entornos BLE desde el diseño de la aplicación o dispositivo.

9.10. El acceso remoto a la red informática

Con cualquiera de los tres tipos de red mencionadas, la empresa asumirá la protección de sus redes, estánda-
res de seguridad y los requisitos a cumplir.
Las empresas no siempre conocen hasta donde llegan sus debilidades en redes y cómo pueden gestionarlas.
De ahí, la finalidad de que existan diferentes tipos y propósitos de la auditoría de redes informáticas, pues
hay muchas maneras de atacar un sistema, y una de ellas, es el hombre, como el eslabón más débil, quien
omite la clave, la comparte, la olvida y por ello la escribe en una papel que pega debajo del teclado, o la
conocida: 12345678. Ahora ya sólo queda la mentalización e implicación de los organismos más altos para
evitar que los ataques empapen negativamente sus negocios y sus empleados cumplan cabalmente con las
disposiciones de la dirección.

9.10.1. Pruebas de seguridad humana

En una auditoría de redes informática, los trabajadores son importantes y al entrevistarlos se obtendrá infor-
mación que, de otra manera, no podría conocer hasta el punto de ser una más de las tareas a realizar en una
auditoría de redes.
Así, entre otras cosas, el auditor descubrirá si hacen un buen uso de los recursos que tienen a su alcance e
incluso si pueden ser ellos mismos una brecha en la seguridad del sistema, algo, por otro lado, muy habitual.
También, conocerá, de primera mano, cómo se trabaja y cómo funciona el sistema.
El auditor podrá disponer de un conjunto de pruebas psicológicas dirigido al personal que guarda, protege o
vigila los bienes o activos informáticos de la empresa a auditar, y en general, a todo el que esté directamente
involucrado con el objetivo del ataque. Requiere de cierto trato o interacción con estas personas, que conocen
los datos o tienen acceso a ellos, con el propósito de engañarlas para que revelen información, o la forma
10 En informática, un Sniffer (analizador de protocolos) es un programa de captura de las tramas de una red de computadoras.
de acceder a la misma. Se basa, por tanto, en encontrar las vulnerabilidades de las personas, en lugar de las
máquinas. Esto se conoce como ”ingeniería social”.
La utilidad de este grupo de pruebas es comprobar el grado de conciencia, responsabilidad y ética del perso-
nal respecto de la seguridad, y verificar que cumplen con la política de la empresa.
Una norma sería cambiar la contraseña del usuario cada tres meses, y no apuntarla en un “post-it” a la vista,
por lo que el auditor comprobaría si los empleados siguen la recomendación. También, comprobará si hay
algún vacío o falta en las normas de seguridad que pueda ser aprovechado por personas externas a la empre-
sa.
El auditor tendrá en cuenta que el personal de la empresa deberá ser capacitado, concienciado, e informado
sobre las responsabilidades asociadas a su puesto respecto a la privacidad de los datos que maneja y que son
propiedad de la empresa. Según el grado de privilegios al que puede acceder por su puesto de trabajo, la
exigencia será distinta.
Además, las pruebas deben hacerse y aplicarse con/sin el conocimiento del personal objetivo.
Lógicamente, si saben que serán puestos a prueba, estarán más alerta que de costumbre a la espera de cual-
quier suceso ”extraño”, y su comportamiento no será el de un día normal. En el caso de la auditoría de
aplicaciones web, estas pruebas estarán incluidas.

9.11. Auditoría técnica o de cumplimiento

Las revisiones técnicas incluyen información acerca de los dispositivos y protocolos utilizados para identifi-
car y corregir debilidades. Esto se hace simulando ataques en ambientes controlados.

9.12. Revisar la documentación técnica

El auditor comprobará la existencia de estos documentos. Ellos servirán, a lo largo de la auditoría para
proponer mejoras para los procesos, según requerimientos de la empresa.
Algunos de los archivos a revisar serán los diagramas de arquitectura y de procesos, los documentos de
procedimientos, el inventarios de activos, entre otros.

9.13. Revisar configuración y funcionalidad

El auditor validará el sistema de control, buscando entender sus requisitos y características. Además, identi-
ficará las áreas donde centrar su actuación, tras el descubrimiento de algunas vulnerabilidades.
El resultado es la mejora de la seguridad sin que el sistema en cuestión deje de funcionar.

9.14. Etapas de la auditoría

La metodología propuesta se estructura en cuatro fases: reconocimiento, mapeado, descubrimiento, y explo-
tación. No todas se desarrollarán en orden estrictamente secuencial. Algunas, están fuertemente vinculadas
que se desarrollan en paralelo o se traslapan en un sólo paso. A continuación, las etapas:
1. Reconocimiento.
Se centra en la búsqueda de un objetivo susceptible de ser atacado. El reconocimiento puede ser de
dos tipos: activo o pasivo.
 En el pasivo, el atacante recolecta información sobre un objetivo fijo o potencial con acciones
sencillas y de bajo riesgo.
En el activo, el atacante busca por la red un blanco, no prefijado, de forma más arriesgada.
Dedicará tiempo a navegar en busca de una víctima propicia aleatoria.

En ambos casos, implica la recopilación de información útil.

En el caso de un auditor, el objetivo es fijo ya que actúa por el requerimiento específico de una empresa
para auditar su red informática.
Actividades frecuentes:

Definición del alcance: servidores, URL, máquinas a auditar, dominios, etc.

Búsquedas en registros de Internet: whois, DNS, transferencia de zona, etc.
Consultas en páginas públicas: listas de correos, grupos de noticias, páginas de ofertas de empleo,
redes sociales, etc. En ellas se revelan las tecnologías que utiliza la empresa o los campos donde
tiene carencias.
Consultas con motores de búsqueda: Google, Yahoo, Yandex, etc. Búsqueda de información
asociada a los dominios que se requieren auditar.
Búsqueda de sub-dominios: para encontrar más máquinas dentro de la misma red.
Elaboración de diccionarios: creación de listados de las palabras que componen la web, para su
posterior utilización en otros tipos de ataques.

2. Mapeado.
La información recolectada en la etapa anterior se utiliza para entender su funcionamiento, determinar
si la web es dinámica o estática, el flujo de navegación entre páginas, cómo se mantiene el estado de las
sesiones, si tiene parte autenticada o no, etc. Identifica las partes que componen la aplicación objetivo,
descubre cómo se relacionan estas partes entre sí, y cuál es el comportamiento lógico esperado del
usuario, para empezar a pensar, finalmente, dónde y cómo se puede evitar el flujo lógico, debido a un
comportamiento inesperado, que los desarrolladores del software no hayan considerado.
Actividades frecuentes:

Escaneo de puertos.
Versión del sistema operativo y otras aplicaciones.
Análisis SSL.
Análisis de balanceo de carga y firewalls de aplicaciones web.
Análisis de la configuración del software.
Spidering. Análisis de los resultados.

3. Descubrimiento.
De lo recolectado anteriormente, pretende descubrir las incidencias. Si el atacante tiene que crear algún
script, ver la pág. 108, lo hace en esta etapa y/o en la de explotación. Explora la aplicación con tráfico
malicioso dirigido a los puntos que cree vulnerables y planea los ataques contra la aplicación o contra
la configuración específica que presenta. En ocasiones, realiza algo de mapeo.
 Entran en juego las herramientas propias de ataque y los diccionarios de fuzzing11 para el testeo de
parámetros.
Actividades frecuentes:

Uso de escáneres automáticos web.

Fuzzing de los parámetros de la aplicación.

4. Explotación.
En la última etapa, el atacante tiene todo preparado para los ataques. Un único defecto encontrado en
la aplicación puede dar acceso a otras partes de la misma, o incluso a otras máquinas, que previamente
no eran vulnerables. Es una etapa cíclica, ya que en cada intento, pueden descubrirse más puntos donde
repetir el ataque con éxito. Un hacker o auditor inexperto suele saltarse las etapas anteriores y empezar
por esta directamente.

9.15. En cuanto a ataques a las redes de comunicación

El mundo está viviendo una auténtica revolución tecnológica. Todos los sectores están siendo digitalizados,
desde la agricultura o la ganadería hasta la industria, el comercio, el turismo, etc. Este aumento en el uso de
tecnología también ha provocado un incremento en la cantidad de ciberataques.
Hace unos años, los objetivos principales de los atacantes eran las personas particulares. En la actualidad,
la mayoría de ataques informáticos son dirigidos a empresas, y así lo demuestran los datos de los ataques
informáticos en los últimos años.
Estos ataques provocan cuantiosas pérdidas en las empresas.

Figura 9.8: Pérdidas medias causadas por los incidentes de seguridad más comunes en las pymes.

La mejor manera de evitar estos tipos de ataque es conocerlos y entender cómo funcionan.
11 Técnica de pruebas de software, automatizado o semiautomatizado, que implica proporcionar datos no válidos, inesperados o
aleatorios a las entradas de un programa de computador.
9.15.1. Tipos de ataques informáticos
Existen numerosos tipos de ciberataques, cada uno con unas características u objetivos diferentes.
Debido a la complejidad de sus nombres, la mayoría de ellos en inglés, es complicado saber de qué se tratan.
Por ello, se describen los principales ataques informáticos para el auditor:

9.15.1.1. Malware
También llamado software malicioso, por su traducción del inglés (malicious software). Su función principal
es introducirse en un equipo y dañarlo de diversas formas.
Las más comunes son las siguientes:

1.- Virus. Permanece inactivo hasta que un usuario lo ejecuta. En ese momento, el virus comienza a infectar
los archivos extendiéndose por todo el equipo o red informática.

2.- Worms (gusanos). Infectan los archivos del equipo para difundirlos. Tienen la capacidad de extenderse
a otros equipos sin necesidad de que un usuario los ejecute.

3.- Troyanos. Muestran la apariencia de un programa fiable, pero esconden otro tipo de malware que es
instalado automáticamente para tomar el control del equipo.

4.- Keyloggers. Registran las pulsaciones del teclado. Esta información es utilizada para conseguir contra-
señas y datos del equipos y/o usuario.

5.- Spyware. El objetivo principal de este malware es el robo de información.

6.- Adware. Se encarga de mostrar publicidad al usuario a través de banners, pop-ups, nuevas ventanas en
el explorador. El objetivo secundario es obtener información sobre la actividad del usuario en la red.

7.- Ransomware. Es el tipo de ataque más común en la actualidad. Se basa en el cifrado de los datos,
restringiendo el acceso a los archivos del equipo para solicitar el rescate de los mismos. En la mayoría
de los casos, pagos en bitcoins.

9.15.1.2. Denegación de servicio distribuido (DDoS)

Este tipo de ataque informático consiste en generar tráfico desde múltiples dispositivos a un sitio web. Debido
a este drástico aumento del tráfico, el rendimiento de la red disminuye hasta el punto de que dicha red se
satura e interrumpe su funcionamiento normal.
Los ataques DDoS son difíciles de evitar debido a la complejidad que han adquirido durante estos últimos
años y la importancia de las transacciones a través de Internet.

9.15.1.3. Ingeniería social

En la mayoría de los casos, los problemas informáticos son provocados por errores de los propios empleados,
por ello es importante capacitar a los usuarios.
Estos ataques informáticos son a través del llamado phishing. Este tipo de ataques se basa en una suplantación
de identidad.
El caso más común es el envío de un correo electrónico aparentemente de una entidad conocida (bancos,
netflix, facebook, etc.) tal que de algún modo conduce a una persona a un enlace malicioso donde introduce
su usuario y contraseña.
Por ejemplo, el ataque de phishing sufrido este año suplantando la identidad de Caja Rural tuvo el siguiente
procedimiento. El usuario recibía un email, aparentemente de Caja Rural, el cual decía que, debido a una
nueva política de seguridad, su cuenta había sido suspendida y que, para restaurar el acceso, debía hacer clic
en un enlace donde introducir sus credenciales.
El auditor comprobará, que existe una enorme variedad de ataques informáticos, cada uno con una función
o un objetivo concreto.
Conociendo en qué consisten y cómo funcionan, la organización estará alerta y conocerá cómo detectar
cuándo la empresa está siendo víctima de los ciberdelincuentes.

9.15.2. Penetración extremo a extremo

Tendrá por objetivo conocer cuán destructivo o profundo podría ser un ataque. Se puede realizar una pene-
tración desde el exterior o desde el interior, siempre a conveniencia.

9.16. Trabajo en componentes

En esta ocasión, el auditor se centrará en la seguridad de los productos, probándolos de manera aislada, sin
que se estén conectados al sistema.

9.17. Potenciales amenazas

En los últimos años, ha habido una evolución y sofisticación de las amenazas que afectan a usuarios y em-
presas que utilizan servicios de Internet y de otras redes. Esto ha convirtiendo en una necesidad el uso de
medidas proactivas y ofensivas para identificar vulnerabilidades, antes de ser aprovechadas por un atacante.
Este enfoque busca conocer las motivaciones de los atacantes, así como las herramientas, métodos o vectores
de ataque que utilizan para vulnerar las redes y sistemas informáticos, de manera que se puedan identificar las
debilidades en la infraestructura tecnológica antes de que alguien ajeno a los recursos también pueda hacerlo.

9.18. ¿Revisiones técnicas o de cumplimiento?

Otro tipo de auditorías están relacionadas con las personas que llevan a cabo las revisiones y su especializa-
ción en el tema, por lo tanto se pueden realizar revisiones técnicas y de cumplimiento.
Las revisiones técnicas comprenden conocimientos de los protocolos y dispositivos utilizados, de manera
que las debilidades sean identificadas y posteriormente corregidas. Para esto, es importante aplicar la pers-
pectiva ofensiva, en la cual se simulan ataques, claro está, siempre con la autorización debida y en ambientes
controlados (incluyen evaluaciones de vulnerabilidades o pruebas de penetración).
Las revisiones de cumplimiento o gestión permiten conocer el estado de apego en las prácticas que se llevan
a cabo en las organizaciones relacionadas con la protección de las redes, en comparación con lo que esta-
blecen documentos especializados, como los estándares de seguridad, marcos de referencia o requisitos que
deban ser cumplidos.
9.19. Posibles preguntas
1. ¿La gerencia de redes tiene una política definida de planeamiento de tecnología de red?

2. Esta política es acorde con el plan de calidad de la organización

3. La gerencia de redes tiene un plan que permite modificar en forma oportuna el plan a largo plazo de
tecnología de redes , teniendo en cuenta los posibles cambios tecnológicos o en la organización?

4. ¿Existe un inventario de equipos y software asociados a la redes de datos?

5. ¿Existe un plan de infraestructura de redes?

6. ¿El plan de compras de hardware y software para el sector redes está de acuerdo con el plan de
infraestructura de redes?

7. ¿La responsabilidad operativa de las redes esta separada de las de operaciones del computador?

8. ¿Están establecidos controles especiales para salvaguardar la confidencialidad e integridad del proce-
samiento de los datos que pasan a través de redes públicas, y para proteger los sistemas conectados

9. ¿Existen controles especiales para mantener la disponibilidad de los servicios de red y computadoras
conectadas?

10. ¿Existen controles y procedimientos de gestión para proteger el acceso a las conexiones y servicios de
red.?

11. ¿Existen protocolos de comunicaron establecida

12. ¿Existe una topología estandarizada en toda la organización

13. ¿Existen normas que detallan que estándares que deben cumplir el hardware y el software de tecnología
de redes?

14. ¿La transmisión de la información en las redes es segura?

15. ¿El acceso a la red tiene clave?

 Auditoría de bases de datos
10
La auditoría de bases de datos es un proceso de supervisión continuo y riguroso de los controles que la ad-
ministración ha establecido dentro de los sistemas gestores de bases de datos y sus componentes para una
seguridad razonable de la utilización adecuada de los datos que son almacenados por los usuarios mediante
los sistemas de información.
La supervisión y pruebas a los controles comprueban su pertinencia y suficiencia, para ajustar, eliminar y/o
implementar nuevos controles para su buen desempeño y utilización.
Los controles de las bases de datos minimizan el riesgo inherente de este valioso e importante activo que
tiene la empresa, ya que ellas mantienen y producen la información que necesita la empresa para su funcio-
namiento o para su planificación estratégica.
Por esta razón, la gerencia encargada establecerá políticas de seguridad, procedimientos de utilización y los
controles pertinentes, luego las políticas serán divulgadas en la empresa.
Los auditores de la base de datos implementarán un proceso para certificar los accesos a los datos, siguiendo
una metodología basada en un checklist1 con los puntos a comprobar o mediante la evaluación de riesgos
potenciales.
En el caso en que los datos ”convivan” en varios lugares de la empresa, (cada sector o sistema trabaja con
su base propia), se debe ayudar a evitar estas duplicaciones innecesarias y costosas, unificando lo que por
coherencia e integridad debería ser único.
Estos son procesos que miden, aseguran, demuestran, supervisan y registran los accesos a las bases de datos
determinando:

1. Quién accede a los datos.

2. Cuándo se accedió a los datos.

3. Desde qué tipo de dispositivo/aplicación.

4. Desde que ubicación en la Red.

5. Cuál fue la sentencia SQL ejecutada.

6. Cuál fue el efecto del acceso a la base de datos.

1 Formulario con preguntas a ser llenado por el auditor al interrogar a usuarios, clientes y directivos.

111
10.1. Objetivo
”Verificar la responsabilidad para la planificación de planillas y control de los activos de datos de la empresa”
(administrador de datos).
”Verificar la responsabilidad de la administración del entorno de la base de datos” (administrador de la base
de datos).
Proporcionar servicios de apoyo en aspectos de empresa y métodos, mediante la definición, implantación y
actualización de base de datos y/o procedimientos administrativos con la finalidad de contribuir a la eficien-
cia.
Disponer de mecanismos para obtener trazas de auditoría completas y automáticas relacionadas con el acceso
a las bases de datos incluyendo la capacidad de generar alertas con el objetivo de:

1. Mitigar los riesgos asociados con el manejo inadecuado de los datos.

2. Apoyar el cumplimiento regulatorio.

3. Satisfacer los requerimientos de los auditores.

4. Evitar acciones criminales.

5. Evitar multas por incumplimiento.

6. Investigar actividades dudosas sobre la BD.

7. Recopilar información acerca de actividades específicas de la BD.

8. Recopilar estadísticas sobre qué tablas se están actualizando, cuántas E/S lógicas se realizan y cuántos
usuarios se conectan de forma simultánea en las horas de máxima actividad

10.2. Propósito
El propósito de los controles de las bases de datos es minimizar el riesgo inherente que tiene este valioso
recurso. Los datos contenidos en las bases de datos pueden considerarse uno de los activos más importantes
que tiene la organización, ellos finalmente producirán la información que necesita la empresa para su fun-
cionamiento día a día o para su planificación estratégica.
Se debe definir lo que se desea auditar:

1. Usuarios, sentencias u objetos.

2. Ejecuciones correctas, incorrectas o ambas.

Se debe gestionar los registros de la auditoría:

1. Controlar su aumento y/o disminución significativa.

2. Protegerlos de un acceso no autorizado.

10.3. ¿Qué es y para qué sirve?
En concreto, se realiza un examen de los accesos a los datos almacenados en las bases de datos con el objetivo
de medir, supervisar y tener constancia de los accesos a la información almacenada en las mismas. Si bien el
objetivo puede variar en función de la casuística, en todos los casos el propósito último busca, de uno u otro
modo, la seguridad corporativa.
Una auditoría de base de datos, por lo tanto, facilita herramientas eficaces para conocer de forma exacta cuál
es la relación de los usuarios a la hora de acceder a las bases de datos, incluyendo las actuaciones que deriven
en una generación, modificación o eliminación de datos.
En la práctica, responde a muchas preguntas que resultan relevantes a la hora de controlar y auditar. Desde
determinar quién accede a los datos, cuándo se accedió o cuál es su ubicación en la red informática y desde
qué dispositivo o aplicación lo hizo, hasta qué sentencia SQL fue ejecutada, así como el resultado del acceso.
Realizar un seguimiento de estos eventos en la base de datos es un primer paso para la auditoría en las
aplicaciones asociadas a ella. No en vano, el papel primordial que tienen los datos en las organizaciones,
como su activo más valioso, obliga a controlar su acceso, distribución y utilización.
En este sentido, la auditoría de base de datos es un control necesario, cuya dificultad aumenta debido a
la creciente complejidad de las tecnologías de bases de datos. Así mismo, las amenazas de seguridad se
han multiplicado, apareciendo nuevos riesgos e incrementándose los ya existentes, al tiempo que amplía su
alcance a través de la disciplina conocida como Gestión de Recursos de Información.
Estas circunstancias motivan la necesidad de nuevos mecanismos de control y seguridad, al tiempo que
se hace necesario recurrir a personal especializado que, por lo general, es externo. Aún así, la auditoría
representa un desafío, pues los sistemas aumentan su complejidad con mayor rapidez que los procedimientos
y tecnologías diseñadas para su control.

10.4. Los controles

¿Dónde implantarlos? Existen tres opciones, la primera es ubicarlos en el nivel de las aplicaciones, es decir,
directamente en los programas o interfaces del usuario. La segunda, colocarlos en las aplicaciones, y la
tercera, es ubicar el control en la base de datos, lo que se llama control en la fuente.
1. Los controles en las aplicaciones.
Implica que cada sistema, módulo o programa tiene el control; con las consecuentes dificultades en
modificaciones, sustituciones de código y compilaciones de programas. Opción muy vulnerable, ya
que se podría acceder a la base de datos por otros medios.
2. Los controles en la red.
Consiste en ubicar el control entre el usuario y la base de datos. Esta alternativa tiene la ventaja de un
único control, ubicado en una posición estratégica fácil de modificar y de administrar. El control es un
programa espía que captura los mensajes entre los usuarios y la base de datos, funciona 365/24/7. El
único problema es conocer cómo eran los valores de los datos antes y después de cualquier operación
de actualización.
3. Control en la fuente.
Es colocarlo directamente en la base de datos, es un único control, fácil de implementar y administrar.
En este caso, es posible conocer los valores de los datos antes y después de la actualización, utilizando
mecanismos correspondientes de la base de datos.
10.5. Alcance
El auditor debe revisar quién o qué hizo, desde donde, cuándo y cómo.
Además, la auditoría de bases de datos evaluará:

1. Definición de estructuras físicas y lógicas de las bases de datos.

2. Control de carga y mantenimiento de las bases de datos.

3. Integridad de los datos y protección de accesos.

4. Estándares para análisis y programación en el uso de bases de datos.

5. Procedimientos de respaldo y de recuperación de datos.

10.6. ¿Cuál es la importancia de la auditoría en la base de datos?

La auditoría en base de datos mantiene la conformidad regulatoria, entender la actividad de la base de datos y
obtener información sobre discrepancias y anomalías. Esto es esencial para identificar posibles riesgos para
el negocio o sospechas de violaciones de seguridad en los sistemas de la compañía.
La importancia de la auditoría del entorno de bases de datos radica en que es el punto de partida para realizar
la auditoría de las aplicaciones que utiliza esta tecnología.
La Auditoría de BD es importante porque toda la información de la empresa reside en sus bases de datos,
por lo que:

1. Deben existir controles relacionados con el acceso a las mismas.

2. Debe demostrar la integridad de la información almacenada en las bases de datos.

3. Debe mitigar los riesgos asociados a la pérdida de datos y a la fuga de información.

4. Debe asumir la responsabilidad de protección de la información confidencial de los clientes.

5. Debe proteger los procesos de negocios.

6. Debe tomar medidas mucho más allá de asegurar sus datos.

Aspectos Claves:

1. No comprometer el desempeño de las bases de datos

Soportar diferentes esquemas de auditoría.

Tomar en cuenta el tamaño2 de las bases de datos a auditar y los posibles SLA establecidos.

2. Segregación de funciones:

La auditoría de base de datos no debe ser aplicada por los DBA del área de TIC.

3. Proveer valor a la operación del negocio para:

2 Tamaño es igual a número de Gbytes, TeraBytes coupados por la base de datos
 la auditoría y seguridad.
apoyar la toma de decisiones de la empresa.
mejorar el desempeño de la empresa.

4. Auditoría completa y extensiva:

Cubrir el mayor número posible de gestores de bases de datos.

Estandarizar los reportes y reglas de auditoría.

Las bases de datos son componentes esenciales en los sistemas computacionales. Al final, las empresas
confían en ellas para conservar sus datos de forma segura y consistente. Para que estas cualidades sean
garantizadas, es importante que la auditoría en base de datos sea una política de la empresa.
La auditoría detecta y previene fallas en el sistema. En la base de datos, este proceso pasa a controlar y
registrar los eventos que se producen en el sistema. Para ello, define ciertas tablas para almacenar registros
con información sobre el uso de las bases de datos.
Con la auditoría, es posible:

1. categorizar las acciones a ser auditadas;

2. utilizar informes previamente configurados para analizar las operaciones;

3. encontrar acontecimientos sospechosos, inusuales y tendencias.

4. La necesidad de auditoría aumenta según se utiliza la base de datos. Las metodologías usadas en este
proceso pueden ser desarrolladas por la propia empresa. La idea es establecer qué partes deben ser
revisadas, de acuerdo con las necesidades de la compañía, para garantizar la seguridad del sistema.

10.7. Marco legal

10.7.1. Ley de Protección de Datos Personales
Muchos países tienen, adoptan y/o adaptan la denominada Ley de Protección de los Datos Personales. Esta
ley establece las condiciones que sobre seguridad y confidencialidad deben cumplir cualquier registro públi-
co o privado de datos y la prohibición de las que no cumplan.

10.7.2. Sanciones previstas por ley

Además, establecen en la misma ley sanciones penales contempladas en el código Penal de los respectivos
países. Se habla sobre penas de un mes a dos años cuando se viole la confidencialidad y/o seguridad de los
datos.

10.7.3. Marcos jurídicos

Se definen varios marcos jurídicos relacionados con la preservación digital. Estos se enuncian a continuación,
tomado de Unesco [40]:

Depósito legal o legislación sobre gestión de registros.

 Reglas de organización que rigen la información de las empresas.

Obligaciones contractuales de depositar datos.

Condiciones relativas a los subsidios, los premios, la contratación o adhesión de las empresas.

Derechos que una organización hereda de otra.

Acuerdos de licencia negociados o adquiridos.

Derechos que implica la entrega voluntaria de material a un programa de preservación.

Algunos organismos capturan y almacenan materiales disponibles pública y libremente, como los
sitios Web y las redes sociales, sin solicitar previamente autorización. Algunas de ellas aseguran que
harán un ”uso correcto” del material de dominio público; otros invocan la ”cláusula de exclusión” en
virtud de la cual se invita en general a los titulares de derechos a expresar sus objeciones.

10.8. Tipo de auditoría en base de datos

Las pruebas de auditoría son de dos tipos: 1) de cumplimiento y 2) sustantivas. Pruebas que buscan obtener
evidencia que los controles establecidos existen en realidad, se utilizan y ejecutan correctamente.

10.8.1. De actividades de los usuarios

Consiste en controlar las actividades que realizan los usuarios en la base de datos como las tablas, vistas,
disparadores, funciones, permisos y restricciones de integridad que los usuarios crean en la base de datos.
Este proceso de supervisión de las actividades de los usuarios encuentra posibles accesos a objetos no auto-
rizados, conexiones en horas o días fuera de horarios normales. Esta actividad se almacena en una tabla o en
un archivo denominado registro de auditoría. El cual puede tener un crecimiento exponencial, por lo que es
necesario administrarlo adecuadamente, muchas veces este registro llega a ser igual o mayor en tamaño que
la base de datos.

10.8.2. De transacciones

10.9. ¿Cómo hacer el proceso?

El auditor obtendrá información sobre los usuarios, accesos, permisos, autorizaciones y similares para ser
capaz de identificar fallas. Para ello, debe observar las fases del ciclo de vida de la base de datos.
El auditor solicitará y analizará:

1. Políticas y normas del negocio en relación con las actividades apoyadas con el SGBD

2. Información de objetos de la BD (tablas, vistas, procedimientos almacenados, triggers, etc.).

3. Diagrama de sistema y de red del servidor de bases de datos, servidores de replicación y/o de aplica-
ciones. Todas las conexiones clientes a la base de datos incluyendo interfaces de red, direcciones IP,
conexiones LAN y WAN.

4. Listado de usuarios de la BD con sus roles y privilegios.

 5. Documentación de las aplicaciones sobre la BD.

6. Organigrama y descripción de funciones y procedimientos del personal que soporta las bases de datos.

7. Políticas de administración y procedimientos sobre la BD incluyendo aquellos de seguridad, progra-

mas de backup y de restauración.

8. Documentación de pruebas de restauraciones.

9. Documentación de espacio en disco, tablas de espacio y supervisión.

10. Archivos de arranque de bases de datos.

11. Script de utilidades.

12. Archivos de configuración

13. Listados a través del sistema operativo de los directorios de la BD mostrando propietarios y permisos
hasta el nivel de archivos.

14. Listados a través del sistema operativo de los directorios de programas de aplicación que accedan las
BD, mostrando propietarios y permisos hasta el nivel de archivos.

15. Listado de archivos de usuarios y sus grupos.

16. Listado de información de archivos de logs3 .

17. Listado de los servicios habilitados (exposiciones a Internet).

10.10. Estudio y planificación previos

En esta etapa se estudia la viabilidad y el costo-beneficio del sistema. La idea es analizar las alternativas para
lograr los objetivos del proyecto y es referencia para que el auditor verifique si se cumplen los procedimientos
de gestión aprobados.

10.11. Construcción de bases de datos

Toda la información debe documentarse de acuerdo con los estándares definidos por la empresa. Cuando
estas actividades se dejan para después, el costo es mayor.
Para identificar si están compuestos correctamente, el auditor debe conocer los estándares definidos, con
base en los modelos lógico, físico y, si es posible, conceptual.

10.12. Selección del equipo

El equipo administrador de las bases de datos estará capacitado para este trabajo. Es esencial que los profe-
sionales conozcan y sepan operar las herramientas adecuadas para las especificaciones técnicas del SGBD.
3 Archivo creados por el sistema operativo que contiene las excepciones ocurridas durante la operación del sistema y sus compo-

nentes.
10.13. Diagramas y contenido de la base de datos
El auditor analizará la base de datos para determinar que cumple las definiciones de datos, estructuras,
relaciones, restricciones y el almacenamiento. Verificará que todo es tratado y almacenado de la forma espe-
cificada y que los usuarios han actuado en el mantenimiento de la consistencia y la integridad de los datos.

10.14. Mantenimiento
Es aquí donde se confirmará que el diseño de la base de datos es correcto, que el equipo está listo para
construirlo y que los usuarios están preparados para usarlo manera adecuada. Se definen los comportamientos
que cada uno debe tener para mantenerlo íntegro y seguro.

10.15. Revisiones
Después de la implantación de la base de datos, es esencial su revisión para comprobar que se han obtenido
los resultados esperados. Además, se debe evaluar que las necesidades de los usuarios se han cumplido y que
el costo-beneficio coincide con las previsiones.
La auditoría es esencial para determinar cómo mantener la integridad, la seguridad y el control de los datos.
Para ello, se recomienda utilizar software que extrae la información de la base de datos, muestra el camino
de las transacciones, supervisa y optimiza los procesos.
Para que la auditoría en la base de datos sea exitosa, el auditor deberá tener el apoyo de una empresa es-
pecializada, con profesionales experimentados, como soporte a que el proceso ocurra sin contratiempos ni
riesgos.

10.16. Posibles Preguntas

1. Existe equipos o software de SGBD

2. La empresa tiene un sistema de gestión de base de datos (SGBD)

3. Los datos son cargados correctamente en la interfaz gráfica

4. Se verificará que los controles y relaciones de datos se realizan de acuerdo a Normalización libre de
error

5. Existe personal restringido que tenga acceso a la BD

6. El SGBD es dependiente de los servicios que ofrece el Sistema Operativo

7. La interfaz que existe entre el SGBD y el SO es el adecuado

8. ¿Existen procedimientos formales para la operación del SGBD?

9. ¿Están actualizados los procedimientos de SGBD?

10. ¿La periodicidad de la actualización de los procedimientos es Anual ?

11. ¿Son suficientemente claras las operaciones que realiza la BD?

12. ¿Existe un control que asegure la justificación de los procesos en el computador? (Que los procesos
que están autorizados tengan una razón de ser procesados)

13. ¿Se procesa las operaciones dentro del departamento de cómputo?

14. ¿Se verifican con frecuencia la validez de los inventarios de los archivos magnéticos?

15. ¿Existe un control estricto de las copias de estos archivos?

16. ¿Se borran los archivos de los dispositivos de almacenamiento, cuando se desechan estos?

17. ¿Se registran como parte del inventario las nuevas cintas magnéticas que recibe el centro de computo?

18. ¿Se tiene un responsable del SGBD?

19. ¿Se realizan auditorías periódicas a los medios de almacenamiento?

20. ¿Se tiene relación del personal autorizado para manipular la BD?

21. ¿Se lleva control sobre los archivos trasmitidos por el sistema?

22. ¿Existe un programa de mantenimiento preventivo para el dispositivo del SGBD?

23. ¿Existen integridad de los componentes y de seguridad de datos?

24. De acuerdo con los tiempos de utilización de cada dispositivo del sistema de cómputo, ¿existe equipo
capaces que soportar el trabajo?

25. ¿El SGBD tiene capacidad de teleproceso?

26. ¿Se ha investigado si ese tiempo de respuesta satisface a los usuarios?

27. ¿La capacidad de almacenamiento máximo de la BD es suficiente para atender el proceso por lotes y
el proceso remoto?

28. ¿Qué versión o versiones de SQL Server está o están siendo utilizadas actualmente? ¿Tienen todas ellas
licencia de uso activa? ¿Hay alguna versión no actualizada que aún se esté utilizando o soportando?

29. ¿Cuáles son los nombres de los servidores de base de datos SQL actualmente productivos y donde
están ubicados?

30. ¿Qué servidores de desarrollo están utilizando SQL Server y dónde están localizados?

31. ¿Qué dependencia o impacto tienen las aplicaciones que utilizan bases de datos respecto del funciona-
miento de la unidad?

32. ¿Quién es / son el/los administradores de las bases de datos (DBA)? ¿Quién es el backup del DBA?

33. ¿Están ambos (DBA y DBA backup) adecuadamente capacitados?

34. ¿Está disponible la documentación para crear bases de datos estructurales y objetos de bases de datos,
y existe asistencia o ayuda para el diseño eficiente de aplicaciones?
35. ¿Ha existido recientemente algún problema?
Preguntar y revisar la documentación sobre el desarrollo realizado para un incidente recientemente
reportado.

36. ¿Cómo se monitorizan habitualmente las bases de datos? ¿Quién recibe las alertas y en qué formato o
de qué manera?

37. ¿Qué procesos se usan para el chequeo y gestión de base de datos a desarrollar y/o mantener? Copias
de seguridad de las bases de datos y restauración de las mismas.

38. ¿Cuál es el proceso y frecuencia con la que están programados los backups de los datos almacenados
en las bases de datos?

39. ¿Conoce y tiene experiencia el DBA o las personas apropiadas cómo recuperar datos perdidos o co-
rruptos?

40. ¿Qué método usa o usaría para recuperar y reconstruir datos perdidos o corruptos?

41. ¿Cuándo fue la última vez en la que fue necesario hacer una restauración de datos?
Revisar la documentación asociada a dicho problema y el proceso utilizado para su restauración y
solución.

42. ¿Existe un proceso formal de backup y restauración para los datos guardados en los servidores?
Asegurarse de que la reconstrucción de la sección asignada a la parte de datos del SQL Server está
bien documentada,

43. ¿Están los backups almacenados en un lugar apartado? ¿Se puede verificar?

44. ¿Pueden ser conseguidos los backups desde su emplazamiento externo habitual en menos de 24 horas?
¿Están realizados en modalidad 365*24*7?

45. ¿Están los datos salvados en modo de backup normal o son incrementales?
Si los datos están archivados, ¿cuál es la política y el proceso para realizar su archivado? Explicarlo y
verificarlo.

46. ¿Cuándo fue la última vez que se recuperaron datos perdidos o corruptos reales? ¿Qué proceso se
siguió? ¿Cuánto tiempo se invirtió en dicho proceso?
Si no ha habido algún proceso reciente de reconstrucción de datos desde archivos de respaldo o de
backup, ¿cuándo fue la última vez que se desarrolló un proceso de restauración en modo test y cómo
se verificó su correcto funcionamiento? Preguntar para ver la documentación histórica del comentado
proceso de restauración, sea real o en modo test.

47. ¿Qué bases de datos son consideradas críticas?

Para bases de datos críticas, ¿cuánto tiempo puede la unidad o empresa continuar su negocio sin ellas?

48. ¿Existe un procedimiento adecuado Business Continuation Plan (BCP) y computer Disaster Recovery
Plan (cDRP) en el que esté incluido todo lo relativo a las bases de datos SQL?
49. ¿Ha habido allí alguna caída súbita de aplicaciones o alguna falta de disponibilidad de algún aspecto
relativo a SQL? Preguntar para revisar los tickets o peticiones de resolución asociados con dicho
problema para su correcta documentación, escalación, y sobre todo la documentación de las "lessons
learned-lecciones aprendidas".

50. ¿Sigue la adquisición del software SQL la normativa de la Empresa, división o los estándares de la
industria o negocio al que se dedica la Empresa?
Si la versión de SQL no fue adquirida por la vía legal de compra de software marcada por la Empresa,
¿quién fue el vendedor o la fuente a través de la cual fue comprada? ¿Quién y cómo da soporte sobre
ella?

51. ¿A quién se le reportan y quien hace un seguimiento de los problemas derivados de SQL?

52. ¿Existe un nivel identificado para el escalado para el Soporte de problemas (Tier 1, 2, y 3)? ¿Cuáles
son los criterios o pautas que regulan este escalado?

53. ¿Los permisos a las bases de datos para administradores / usuarios están regulados por grupos de
Directorio Activo?

54. ¿Quién administra la entrada y salida de trabajadores de la Empresa (incluyendo consultores o traba-
jadores externos)? ¿Está centralizado este proceso?
Si los permisos de usuario se dan a user id (user identification), ¿está el DBA (data base administrator)
incluido en el proceso de notificaciones de entrada y salida de la empresa? ¿Se desarrolla una revisión
periódica de los usuarios con permisos? Verificar que los “business owner” deben aprobar el acceso y
el correspondiente nivel de acceso o de permiso cuando las peticiones se hagan para solicitar accesos
a tablas o a bases de datos, bien sea directamente a través del SQL server o bien a través de algún apli-
cativo de desarrollo propio. Revisar las normativas o roles para acceso a las carpetas de los Servidores
de SQL para asegurar que los grupos de Directorio Activo se están usando, y verificar que las personas
que lo necesitan sólo tienen los accesos que realmente requieren para su trabajo.

55. ¿Cuál es el proceso de manejo de cambios para los cambios relativos al SQL Server y a las posibles
localizaciones de las bases de datos?

56. ¿Son todos los cambios manejados siguiendo el proceso marcado en el punto anterior? Preguntar
para ver un número representativo de cambios realizados documentando las respuestas y los procesos
realizados en cada caso.

57. ¿Cómo se manejan los requerimientos de cambios? Describir la inicialización de los cambios y el
seguimiento que se hace de ellos.

58. ¿Cómo se priorizan los cambios? ¿Cómo se manejan los cambios de alta prioridad o que tengan ca-
rácter de urgencia?

59. ¿Cómo se notifica al solicitante de cambios en las tablas del SQL Server, del estado de los mismos?

60. ¿Hay procedimientos para notificar al personal de Soporte de los cambios realizados en los sistemas?
¿Y a los usuarios finales a los efectos que cada uno necesite?

61. ¿Hay procedimientos para notificar a los usuarios finales de los cambios realizados en el sistema?
62. ¿Los cambios requeridos son revisados por un personal funcional con el conocimiento suficiente y
aprobados por el correspondiente “business owner”?

63. ¿Son los cambios registrados y seguidos a través de un sistema de manejo de cambios? Preguntar por
la documentación existente al respecto.

64. ¿Hay una aceptación del proceso de test junto con el departamento funcional que las utiliza? ¿Hay test
de resultados que muestren especialmente las diferencias encontradas, que estén grabados y que hayan
sido revisados?

65. ¿Cuál es el proceso documentado a seguir para instalar una nueva versión del software de base de
datos?

66. ¿Se aplicaron los cambios durante periodos relativamente tranquilos cuando el desastre pudo ser así
debidamente minimizado?

67. ¿Hay un proceso de manejo de los cambios específicos que provea un plan de vuelta atrás?
Preguntar por un ejemplo del mismo para verificación.

68. ¿Quién es el encargado de mover los cambios en las bases de datos, del servidor de test al productivo?

69. ¿Hay un entorno de desarrollo diferente, separado del de producción?

70. ¿Quiénes son los administradores principales de estas bases de datos y de sus back- ups?

71. ¿Cuánto tiempo llevan cumpliendo esta función?

72. ¿Qué formación inicial y complementaria tienen para las bases de datos (DBA)? Si el soporte no es
para un DBA local, explicar cómo se realiza el acceso a la red y el mantenimiento de las mismas.

73. ¿Cuáles son los procedimientos documentados de la unidad y las normas para hacer frente a la mani-
pulación y al mantenimiento de programas de aplicaciones financieras y a sus datos?

74. ¿Cómo se comunica a los trabajadores del equipo de informática y analistas funcionales los eventos
realizados o a realizar sobre estas bases de datos?

75. ¿Quién es el responsable de la recuperación de una base de datos perdida o dañada (es decir Mdb, Dbf
y el espacio dedicado a ellas)? Revisar la política, procedimiento, y los registros de datos usados dia-
riamente y la restauración de los mismos (es decir, la recuperación de datos en un momento específico
del tiempo).

76. ¿Cuándo fue necesario hacer la última recuperación?

77. ¿Con qué frecuencia se examina este proceso?

78. ¿Dónde está localizado y cuál es el proceso documentado para adquirir y actualizar las bases de datos?

79. ¿Cuál es el procedimiento con el que se reacciona a los eventos / acontecimientos reportados (es decir,
informe, seguimiento, resolución o escalado de los problemas)?

80. ¿Cómo se realiza la supervisión/monitorización de la política de seguridad informática corporati-

va para bases de datos, administración de aplicaciones y contraseñas (es decir, Oracle dba_audit,
dba_profiles)?
 81. ¿Con qué frecuencia el “business owner” y el jefe del IT revisan los usuarios y los permisos de los
grupos de acceso a las bases de datos? Examen de auditoría del rastro de las aprobaciones de acceso a
las diferentes bases.

82. ¿Cuál es y dónde está guardado el proceso para la concesión / revisión de acceso de base de datos para
los usuarios (es decir, grupo de acceso, ficheros Mdb o las funciones de base de datos de Oracle)? Si
se utilizan grupos RACF o grupos de AD, obtener una lista de ellos y verificar quien tiene acceso a los
mismos.

83. ¿Dónde se guardan y cuáles son los procedimientos para la administración de usuarios, acceso, trans-
ferencia de archivos, etc.? Si no está hecho, pedir al Coordinador de Recursos Humanos una lista de los
usuarios nuevos, de usuarios antiguos y también de los becarios o de los consultores. Asegúrese que
no hay fallos secundarios de seguridad para las bases de datos y que estén todas controladas, sean del
tipo que sea (Access, Oracle, Dbase II, etc.). Asegúrese de que los servidores de bases de datos están
ubicados en una zona de seguridad protegida. Pregunte al administrador del DBA o al Network Admi-
nistrator para que nos muestre las ubicaciones físicas de los servidores . CHECKLIST AUDITORIA
DE BASE DE DATOS:

84. Existe algún archivo de tipo Log donde guarde información referida a las operaciones que realiza la
Base de datos?

85. Se realiza copias de seguridad (diariamente, semanalmente, mensualmente, etc.)?

86. Existe algún usuario que no sea el DBA pero que tenga asignado el rol DBA del servidor?

87. Se encuentra un administrador de sistemas en la empresa que lleve un control de los usuario?

88. Son gestionados los perfiles de estos usuarios por el administrador?

89. Son gestionados los accesos a las instancias de la Base de Datos?

90. Las instancias que contienen el repositorio, tienen acceso restringido?

91. Se renuevan las claves de los usuarios de la Base de Datos?

92. Se obliga el cambio de la contraseña de forma automática?

93. Se encuentran listados de todos aquellos intentos de accesos no satisfactorios o denegados a estructu-
ras, tablas físicas y lógicas del repositorio?

94. Posee la base de datos un diseño físico y lógico?

95. Posee el diccionario de datos un diseño físico y lógico?

96. Existe una instancia con copia del Repositorio para el entorno de desarrollo?

97. Está restringido el acceso al entorno de desarrollo?

98. Los datos utilizados en el entorno de desarrollo, son reales?

99. Se llevan a cabo copias de seguridad del repositorio?

100. Las copias de seguridad se efectúan diariamente?

101. Las copias de seguridad son encriptadas?

102. Se ha probado restaurar alguna vez una copia de seguridad, para probar que las mismas se encuentren
bien hechas?

103. Los dispositivos que tienen las copias de seguridad, son almacenados fuera del edificio de la empresa?

104. En caso que el equipo principal sufra una avería, ¿existen equipos auxiliares?

105. Cuando se necesita restablecer la base de datos, ¿se le comunica al administrador?

106. ¿La comunicación se establece de forma escrita?

107. Una vez efectuada la restauración, se le comunica al interesado?

108. Se lleva a cabo una comprobación, para verificar que los cambios efectuados son los solicitados por el
interesado?

109. Se documentan los cambios efectuados?

110. Hay algún procedimiento para dar de alta a un usuario?

111. Hay algún procedimiento para dar de baja a un usuario?

112. Es eliminada la cuenta del usuario en dicho procedimiento?

113. El motor de Base de Datos soporta herramientas de auditoría?

114. Existe algún tipo de documentación referida a la estructura y contenidos de la Base de Datos?

115. Se cuenta con niveles de seguridad para el acceso a la Base de Datos?

116. Se encuentra la Base de Datos actualizada con el último Set de Parches de Seguridad?

117. Existe algún plan de contingencia ante alguna situación no deseada en la Base de Datos?

118. Existen logs que permitan tener pistas sobre las acciones realizadas sobre los objetos de las base de
datos?

119. Se usan los generados por el DBMS?

120. Se usan los generados por el Sistema Operativo?

121. Se han configurado estos logs para que sólo almacenan la información relevante?

122. Se tiene un sistema de registro de acciones propio, con fines de auditoría?

123. Las instalaciones del centro de cómputo son resistentes a potenciales daños causados por agua?

124. Las instalaciones del centro de cómputo son resistentes a potenciales daños causados por el fuego?

125. La ubicación del centro de cómputo es acorde con las mínimas condiciones de seguridad?

126. Existe y es conocido un plan de actuación para el personal del centro de cómputo, en caso de incidentes
naturales u otros que involucren gravemente la instalación?
127. Existe un control de las entradas y las salidas de la base de datos (A nivel datos)?

128. La información que poseen en la base de datos es real?

129. Existe un contrato de confidencialidad con las terceras partes?

130. Se notifican las acciones realizadas a nivel de mantenimiento de hardware?

 Auditoría de mantenimiento
11
El Mantenimiento de sistemas informáticos consiste en su revisión y evaluación completa, con el objetivo de
establecer políticas de seguridad, empresa, documentación y mejora del rendimiento.
El mantenimiento de los sistemas informáticos debe gestionar el mantenimiento preventivo teniendo como
objetivo minimizar el correctivo.

11.1. Cómo Funciona

El primer paso del ”Mantenimiento de Sistemas” es realizar una ”auditoría del sistema”, tomando datos para
dimensionar dicho sistema informático, así como hacer un posterior análisis del mismo para establecer las
políticas de seguridad, explotación y empresa que favorezcan su uso eficaz y racional.
Para ello, se deberá auditar:

1. La estructura general del sistema informático.

2. Los recursos materiales, tales como equipos y sus características, el software instalado, así como los
objetivos a los que están destinados.

3. Realizar diagnósticos de rendimiento a nivel de servidores, redes y comunicaciones.

4. Conocer la seguridad informática.

5. Determinar los posibles riesgos por falta de disponibilidad de algún servicio.

6. Generar un informe ejecutivo con conclusiones, plan de acción y mejoras sugeridas.

Luego de realizada la auditoría y teniendo en cuenta que el sistema informático tiene continuos cambios, el
”mantenimiento de sistema” pretende cubrir tres objetivos:

1. Mantener actualizada la documentación relacionada con dicho sistema informático, recopilada e iden-
tificada en auditorías internas periódicas, simulación de situaciones, revisión documentación, diagnós-
ticos de rendimientos, revisiones de seguridad, etc.

2. Ayudar al responsable de la empresa a resolver aquellas incidencias complejas del día a día, es decir,
ser el soporte de segundo nivel del responsable informático de la empresa.

126
 3. Asesorar sobre nuevas soluciones a desarrollar en el sistema informático o mejoras a implementar.

El auditor tendrá en cuenta para la auditoría:

1. Alcance.

Planes y procedimientos de Mantenimiento.

Normativa.

2. Objetivos.

El informe de auditoría para evaluar el mantenimiento correctivo y preventivo del software.

3. Referencia Legal:

Estándares.
ISO/IEC 12207.
IEEE 1074.
IEEE 1219.
ISO/IEC 14764.

11.2. Plan de recuperación de desastres

Es un proceso de recuperación que cubre los datos, el hardware y el software crítico, para que una empresa
reinicie sus operaciones en caso de un desastre natural o artificial. También, incluirá proyectos para enfrentar
la pérdida inesperada o repentina de personal clave.
Enviará respaldos fuera de sitio diaria, semanal y/o mensualmente para que en el peor de los casos no pierda
más que los últimos datos según política de respaldo.
Incluirá el software así como toda la información de datos, para facilitar su recuperación.
Si es posible, usará una instalación remota de reserva para reducir al mínimo la pérdida de datos y/o tiempo de
poner en producción los sistemas de informáticos, las redes de área de almacenamiento y la nube informática.
Todo como reciente desarrollo que hace que los datos estén disponibles inmediatamente sin la necesidad de
recuperarlos o sincronizarlos.
Dispondrá de protectores de línea para reducir al mínimo el efecto de picos de transición sobre equipos
electrónicos delicados; así como UPS para evitar que el suministro de energía sea ininterrumpido.
La prevención de incendios - alarmas, extintores accesibles para fuego eléctrico y/o químico.
Software antivirus, si procede.
Contratos de seguro en el hardware.
Para asegurar la continuidad del negocio, es recomendable recordar la premisa: "Siempre desear lo mejor
y planear para lo peor". En un buen plan de contingencia existen diferentes factores que hay que tomar en
cuenta. Los más importantes son:

El directorio telefónico: para notificar al personal clave del problema y asignarles tareas enfocadas
hacia el plan de recuperación.
 Reservas de memoria: las cintas, cd, dvd, discos duros externos, unidades sd de reserva que son con-
servadas fuera de la empresa es necesario grabarlas por triplicado. Si usan servicios remotos de reserva
requerirá una conexión de red a la posición remota de reserva (o Internet).

Clientes: tener una notificación preparada para informales sobre el problema, podría reducir al mínimo
el pánico.

Instalaciones: teniendo sitios calientes o fríos para empresas más grandes.

Instalaciones de recuperación móviles que estén disponibles en diversos proveedores.

Trabajadores con conocimiento. Durante un desastre, a los empleados se les requiere trabajar más
horas. Deberá haber un sistema de apoyo para aliviar la tensión.

La información de negocio. Las reservas deben estar almacenadas completamente separadas de la

empresa. La seguridad y la fiabilidad de los datos es clave en estas ocasiones.

11.3. Qué es una auditoría de mantenimiento

Realizar una auditoría de mantenimiento es comprobar cómo se gestionan cada una de las trece áreas de
gestión en las que se divide dicho mantenimiento: personal, plan de mantenimiento programado, gestión del
mantenimiento legal, implantación de técnicas predictivas, contratos de mantenimiento, gestión del mante-
nimiento correctivo, gestión de medios técnicos, gestión de repuestos, implantación y uso de procedimientos
de trabajo, empleo del software de mantenimiento, informes e indicadores, gestión de la prevención y resul-
tados obtenidos.
El objetivo es conocer la gestión en estas áreas en el departamento de mantenimiento de una empresa, iden-
tificar los puntos de mejora y determinar qué acciones son necesarias para lograr un estándar o modelo de
excelencia.
La auditoría de gestión de mantenimiento propuesta se sustenta en el análisis de un total de 118 puntos. Para
cada uno de ellos se plantea una pregunta, con cuatro posibles respuestas. Así, si la respuesta a la pregunta
planteada es favorable, tal que la situación se parece al modelo de excelencia, la respuesta es un ”4”. Si la
situación es aceptable, pero presenta posibilidades de mejora, se le asigna un ”3”. Pero si la situación no es
aceptable, es decir, se aleja del modelo de excelencia, el valor asignado es ”1”. Si la situación es desfavorable
y es necesario un cambio, se asigna un ”0” para considerar la situación de ese punto es un desastre.
Todos aquellos puntos que alcanzan como resultado un ”0” o un ”1” deberán incluirse en un PLAN DE AC-
CIÓN, y transcurrido cierto tiempo, realizar una nueva auditoría para comprobar los puntos desfavorables.
El punto más importante de una auditoría de mantenimiento es el PLAN DE ACCIÓN, en el que se iden-
tifican los problemas que se detectan en la gestión del mantenimiento de la planta, y como se propone
solucionarlos.

11.4. El modelo de excelencia

La auditoría de mantenimiento se sustenta en la comparación de la situación existente en una empresa con
un modelo que pudiera considerarse excelente. Una vez definida dicha situación, comparar esa gestión ideal
con la de la empresa auditada, y determinar si cada uno de los puntos está gestionado de la mejor forma
posible. Aquellos que se aparten de esa gestión excelente serán puntos de mejora.
11.5. El perfil del auditor
El auditor que realiza la auditoría de mantenimiento es siempre un profesional interno o externo pero ajeno
al mantenimiento de la instalación, para garantizar su visión imparcial y no contaminada por el día a día. La
formación y experiencia con la deben contar es la siguiente:

Ser profesionales que conocen bien el entorno de mantenimiento, y preferiblemente ingenieros con
años de experiencia.

Conocer la forma de llevar a cabo una auditoría de mantenimiento.

Ser minuciosos y observadores.

No estar involucrados en el día a día del departamento, garantizando su imparcialidad.

Ser constructivos en sus apreciaciones.

11.6. Las áreas analizadas en una auditoría

Las trece áreas de gestión a ser analizadas en una auditoría de mantenimiento son las siguientes:

Personal y organigrama.

Plan de mantenimiento programado.

Gestión del mantenimiento legal.

Implantación de técnicas predictivas.

Mantenimiento contratado y gestión de contratos.

Gestión del mantenimiento correctivo.

Implantación de procedimientos y empleo de éstos.

Gestión de herramientas y medios técnicos.

Gestión de repuestos.

Utilización del software de mantenimiento.

Información, indicadores e informes.

Gestión de la prevención de riesgos.

Resultados obtenidos en mantenimiento.

El cálculo del índice de conformidad.

No todos los aspectos analizados en la auditoría tendrán el mismo peso. Así, no tiene la misma importancia
ni afectará por igual a los resultados que no haya un plan de mantenimiento en la instalación o que el formato
de orden de trabajo no resulte adecuado.
Basado en la experiencia del autor, en el cuestionario propuesto se ha elegido una escala de 1 a 3, asignando
a los aspectos relevantes un valor de 3 y a los menos significativos un valor de 1.
Multiplicando la valoración obtenida en cada aspecto analizado (de 0 a 4) por la ponderación de ese aspecto,
sumando el resultado obtenido en esa multiplicación en cada uno de los aspectos y dividiendo entre el valor
máximo posible, se obtiene el índice de conformidad, que será un porcentaje del valor máximo posible y por
tanto, una medida del grado de excelencia del departamento de mantenimiento comparado con la situación
ideal que debería presentar:

Junto con el índice de conformidad global, es conveniente medir al menos otros cuatro índices, referi-
dos a cómo se ve afectada la disponibilidad de los sistemas, la fiabilidad, como se afecta la posibilidad
de sufrir una avería de gran alcance, a incrementar los costos, a aumentar la posibilidad de accidentes
y/o a disminuir la vida útil de la planta.

Para calcular cada uno de ellos, basta con tomar únicamente los aspectos que influyen en cada una de esas
consecuencias, y aplicar la fórmula anterior por separado para cada conjunto de aspectos.

11.7. Herramientas informáticas para la auditoría de mantenimiento

La realización de una auditoría no requiere de una herramienta informática. Puede realizarse en papel o con
herramientas ofimáticas sencillas. No obstante, los cálculos pueden resultar tediosos y complejos.
Muchas empresas de tecnología han desarrollado un software a utilizarse para esta auditoría. Muchas de estas
herramientas configuran diferentes tipos de auditoría, adaptarla para cada empresa concreta, plantear una
serie de interrogantes a ser analizadas, recolectar las respuestas a las preguntas planteadas, tanto numéricas
como a nivel de comentarios, y recopilar los resultados en un informe generado de forma automática.

11.8. Cuestionario de la auditoría

Las 132 preguntas cuyo análisis compone la auditoría de gestión de mantenimiento de una empresa son las
siguientes:

1. ¿El organigrama de mantenimiento garantiza la presencia de personal de mantenimiento preparado

cuando se necesite, de la forma más rápida posible?

2. ¿Hay personal considerado ”imprescindible” cuya ausencia afecta a la actividad normal del área de
mantenimiento?

3. ¿El organigrama garantiza que habrá personal disponible para realizar un mantenimiento programado,
incluso en el caso de un aumento del mantenimiento correctivo?

4. ¿El número de horas extraordinarias que se genera en el área de mantenimiento es habitualmente

superior al máximo legal autorizado?

5. ¿La cualificación previa que se exige al personal del área de mantenimiento es la adecuada?
 6. ¿Se realiza una formación inicial efectiva cuando se incorpora un nuevo trabajador al área de mante-
nimiento?

7. ¿Hay un plan de formación para el personal de mantenimiento?

8. ¿Este plan de formación hace que los conocimientos en el mantenimiento de la planta mejoren?

9. ¿El plan de formación hace que los conocimientos en otras áreas de la planta (operaciones, seguridad,
medio-ambiente, administración, etc.) mejoren?

10. ¿El personal de mantenimiento mecánico realiza tareas eléctricas o de instrumentación sencillas?

11. ¿El personal de mantenimiento mecánico realiza tareas eléctricas o de instrumentación especializadas?

12. ¿El personal de mantenimiento eléctrico realiza tareas mecánicas sencillas?

13. ¿El personal de mantenimiento eléctrico realiza tareas mecánicas especializadas?

14. ¿El personal de mantenimiento está capacitado para trabajar en otras áreas (operaciones, seguridad,
control químico, etc.)?

15. ¿Se respeta el horario de entrada y salida?

16. ¿Se respeta la duración de los descansos?

17. ¿La media de tiempos muertos no productivos es la adecuada?

18. ¿Los tiempos de intervención se ajustan a la duración teórica estimable en que podrían realizarse los
trabajos?

19. ¿El personal de mantenimiento es reconocido en su trabajo?

20. ¿El personal de mantenimiento percibe que la empresa se preocupa de sus necesidades para realizar
un buen trabajo?

21. ¿El personal de mantenimiento considera que tiene proyección profesional dentro de la empresa?

22. ¿El personal de mantenimiento se siente satisfecho con su horario?

23. ¿El personal de mantenimiento se considera bien retribuido?

24. ¿El personal de mantenimiento está comprometido con los objetivos de la empresa?

25. ¿El personal de mantenimiento tiene un buen concepto de sus mandos?

26. ¿El personal de mantenimiento considera que el ambiente del departamento de mantenimiento es agra-
dable?

27. ¿El nivel de ausentismo entre el personal de mantenimiento es bajo?

28. ¿El nivel de rotación entre el personal de mantenimiento es bajo?

29. ¿Las instalaciones cuentan con un plan de mantenimiento?

30. ¿El plan de mantenimiento afecta a todas las áreas y equipos significativos de la planta?
31. ¿La estructura del plan de mantenimiento facilita su actualización y control de la ejecución? Para
elaborar el plan, ¿se han tenido en cuenta la importancia de los equipos? Para elaborar el plan, ¿se han
tenido en cuenta la importancia de los fallos?

32. ¿El plan tiene como objetivo principal evitar los fallos críticos de la planta?

33. ¿El Plan de Mantenimiento respeta las instrucciones de los fabricantes?

34. ¿Es posible llevar a cabo este plan de mantenimiento?

35. ¿Se actualiza el plan de acuerdo con los resultados de mantenimiento?

36. ¿Hay una programación de las tareas que incluye el plan de mantenimiento?

37. ¿En la programación se establece quien y cuando se realiza cada tarea?

38. ¿Es fácil realizar el control del cumplimiento de la programación?

39. ¿La programación de las tareas de mantenimiento se cumple?

40. ¿La cantidad de trabajo burocrático que genera es asumible?

41. ¿Los responsables de mantenimiento y de la instalación conocen las obligaciones legales de manteni-
miento?

42. ¿Se tiene un listado actualizado de la normativa que afecta a la instalación?

43. ¿Las tareas de mantenimiento legal están desglosadas convenientemente?

44. ¿Se han suscrito los contratos obligatorios que contemplan las diversas normativas?

45. ¿Se dispone de un registro ordenado de las obligaciones legales de mantenimiento?

46. ¿Dicho registro está actualizado?

47. ¿Todas las obligaciones legales de mantenimiento se han realizado?

48. ¿Todas las tareas habituales de mantenimiento están recolectadas en procedimientos?

49. ¿Los procedimientos son claros y entendibles?

50. ¿Los procedimientos contienen la información que se necesita para realizar cada tarea?

51. ¿El personal de mantenimiento recibe formación en estos procedimientos, especialmente cuando se
producen cambios?

52. ¿El proceso de implantación de un nuevo procedimiento es el adecuado?

53. ¿Cuándo el personal de mantenimiento realiza una tarea utiliza el procedimiento aprobado?

54. ¿Los procedimientos de mantenimiento se actualizan periódicamente?

55. ¿El departamento de mantenimiento dispone de los medios de comunicación interna que se necesitan?
56. ¿El departamento de mantenimiento dispone de los medios de comunicación con el exterior que se
necesitan?

57. ¿Se dispone de los medios de transporte que se necesitan?

58. ¿Se dispone de los medios de elevación que se necesitan (carretillas elevadoras, carretillas manuales,
polipastos, puentes grúa, diferenciales, etc.)

59. ¿Las herramientas mecánicas se corresponden con lo que se necesita?

60. ¿Las herramientas eléctricas se corresponden con lo que se necesita?

61. ¿Las herramientas para el mantenimiento de la instrumentación se corresponden con lo que se necesi-
ta?

62. ¿Las herramientas para el mantenimiento predictivo se corresponden con lo que se necesita?

63. ¿Las herramientas de taller se corresponden con lo que se necesita?

64. ¿Los equipos de medida están calibrados?

65. ¿Existe un inventario de herramientas?

66. ¿Se comprueba periódicamente el inventario de herramientas?

67. ¿El taller está situado en el lugar apropiado?

68. ¿Está limpio y ordenado su interior?

69. ¿La proporción entre horas/hombre dedicadas a mantenimiento programado y correctivo no progra-
mado es la adecuada?

70. ¿El tiempo medio de resolución de una avería es bajo?

71. ¿Hay un sistema claro de asignación de prioridades?

72. ¿Este sistema se utiliza correctamente?

73. ¿El número de averías con el máximo nivel de prioridad es bajo?

74. ¿El número de averías pendientes de reparación es bajo?

75. ¿La razón por la que las averías pendientes están pendientes está justificada?

76. ¿Se realiza un análisis de los fallos que afectan a los resultados de la planta?

77. ¿Las conclusiones de estos análisis se llevan a la práctica?

78. ¿El número de averías repetitivas es bajo?

79. ¿Se ha elaborado una lista de repuesto mínimo que debe permanecer en inventario?

80. ¿Los criterios empleados para elaborar esa lista son válidos?

81. ¿Se comprueba periódicamente que se dispone de ese inventario?

 82. ¿La lista de inventario mínimo se actualiza y mejora periódicamente?

83. ¿Se realizan periódicamente inventarios de repuesto?

84. ¿Los movimientos del almacén se registran en el sistema informático?

85. ¿Coincide el inventario físico con el teórico (según los inventarios y el sistema informático)?

86. ¿El almacén está limpio y ordenado?

87. ¿El almacén está situado en el lugar adecuado?

88. ¿Es fácil localizar cualquier pieza?

89. ¿Las condiciones de almacenamiento son correctas?

90. ¿Se realizan comprobaciones del material cuando se recibe?

91. ¿Todos los trabajos que se realizan se reflejan en una orden de trabajo?

92. ¿El formato de esta orden de trabajo es adecuado?

93. ¿Los técnicos de mantenimiento cumplimentan correctamente estas órdenes?

94. ¿Las órdenes de trabajo se introducen en el sistema informático?

95. ¿El sistema informático de mantenimiento resulta adecuado?

96. ¿El sistema informático supone una carga burocrática excesiva?

97. ¿El sistema informático aporta información útil?

98. ¿El sistema informático aporta información fiable?

99. ¿Los mandos de mantenimiento consultan habitualmente la información contenida en el sistema?

100. ¿Los operarios de mantenimiento consultan habitualmente la información contenida en el sistema?

101. ¿Se emite un informe periódico que analiza la evolución del departamento de mantenimiento?

102. ¿El informe aporta información útil para la toma de decisiones?

103. ¿La disponibilidad media de los equipos significativos es la adecuada?

104. ¿La disponibilidad media de la planta es la adecuada?

105. ¿La evolución de la disponibilidad es positiva (está aumentado la disponibilidad)?

106. ¿La fiabilidad media de los equipos significativos es la adecuada?

107. ¿La fiabilidad media de la planta es la adecuada?

108. ¿La evolución de la fiabilidad es positiva (está aumentado la fiabilidad)

109. ¿El número de O.T. de emergencia está descendiendo?

110. ¿El tiempo medio de reparación en equipos significativos es bajo?

111. ¿El tiempo medio de reparación en equipos significativos está descendiendo?

112. ¿El número de averías repetitivas está descendiendo?

113. ¿El número de horas/hombre invertidas en mantenimiento es el adecuado?

114. ¿El número de horas/hombre invertidas en mantenimiento está descendiendo?

115. ¿El gasto en repuestos es el adecuado?

116. ¿El gasto en repuestos está descendiendo?

117. ¿Existe un contrato de mantenimiento?

118. ¿Existe un programa de mantenimiento preventivo para cada dispositivo del sistema de cómputo?

119. ¿Se lleva a cabo tal programa?

120. ¿Existen tiempos de respuesta y de compostura estipulados en los contratos?

121. Si los tiempos de reparación son superiores a los estipulados en el contrato, ¿Qué acciones correctivas
se toman para ajustarlos a lo convenido?

122. ¿Existe plan de mantenimiento preventivo. ?

123. ¿Este plan es proporcionado por el proveedor?

124. ¿Se notifican las fallas?

125. ¿Se les da seguimiento?

126. ¿Tiene un plan logístico para dar soporte al producto software?

127. ¿Los requerimientos de mantenibilidad se incluyen en la Actividad de Iniciación durante el Proceso

de Adquisición (ISO 12207) y se evalúa durante el Proceso de Desarrollo?

128. ¿Las variaciones en el diseño son supervisadas durante el desarrollo para establecer su impacto sobre
la mantenibilidad?

129. ¿Se realizan varios tipos de medidas para poder estimar la calidad del software?

130. ¿La mantenibilidad se tiene en cuenta antes de empezar a desarrollar?

131. ¿El desarrollador prepara un Plan de Mantenibilidad que establece prácticas específicas de mantenibi-
lidad, así como recursos y secuencias relevantes de actividades?

132. ¿Durante el análisis de requerimientos, los siguientes aspectos que afectan a la mantenibilidad, son
tomados en cuenta?
 Auditoría de la seguridad
12
Una auditoría de seguridad informática se define como la evaluación del nivel de madurez en seguridad de
una empresa, donde se analizan las políticas y procedimientos de seguridad definidos por la misma y se
revisa su grado de cumplimiento. También, las medidas técnicas y organizativas implantadas para garantizar
la seguridad. En este capítulo se presenta en qué consiste una auditoría de seguridad informática y sus
tipologías.

12.1. Objetivos de una auditoría de ciberseguridad

Se pretende detectar debilidades y vulnerabilidades de seguridad que serían explotadas por usuarios malin-
tencionados o atacantes, ocasionando perjuicios importantes para la empresa. Además, la auditoría evitaría
el robo de información y la competencia desleal.
La auditoría de seguridad es básica para una empresa, independientemente de su tamaño y rubro, ya que
detectaría posibles puntos débiles que sirvan de referencia para implementar un plan de mejora.

12.2. Tipos de auditorías de seguridad informática

1. Según quién las realice.
La auditoría de ciberseguridad se diferencian en dos tipos, en función de quién las realice:
Interna: realizada por personal propio de la empresa con o sin apoyo externo.
Externa: realizada por personal externo e independiente a la empresa.
2. Según la metodología empleada.
En función de ella, se podrían diferenciar como:
De cumplimiento: verifica la aplicación de un determinado estándar de seguridad (como ISO
27001) o de las propias políticas y procedimientos internos de seguridad de la empresa.
Técnicas: auditorías o revisiones de seguridad cuyo alcance está acotado a un(os) sistema(s)
informático(s) objeto de la revisión.
3. Según su objetivo.
Algunos de los principales tipos de auditoría de seguridad informática son:

136
 Forense: pretende recopilar la información para determinar qué ha desencadenado el evento in-
formático, las causas que lo han producido, el alcance del mismo (sistemas y/o información
afectada), así como las evidencias digitales del mismo.
Aplicaciones Web: pretende identificar las potenciales vulnerabilidades en este tipo de aplicacio-
nes las que podrían ser explotadas por atacantes. Este tipo de auditoría se diferencia en el análisis
dinámico de la aplicación (DAST – Dynamic Application Security Testing), de una revisión en
tiempo de ejecución de la aplicación sobre la propia web y el análisis estático de la aplicación
(SAST – Static Application Security Testing), buscando posibles vulnerabilidades en el código.
Hacking ético o test de intrusión: auditoría que prueba las medidas de seguridad técnicas de una
empresa (como firewalls, IDS/IPS, etc.) de la misma manera que lo haría un potencial atacante
para identificar debilidades o vulnerabilidades explotables a ser corregidas.
Control de acceso físico: audita las plataformas y medidas de seguridad que componen el sistema
de seguridad perimetral físico de una empresa (cámaras, mecanismos de apertura de puertas,
software de control de acceso, etc.) para verificar su funcionamiento.
Red: revisa todos los dispositivos conectados a la red y verifica la seguridad de los mismos
(actualización de su firmware, firmas de antivirus, reglas de Firewall, control de acceso a la red,
segmentación de la red en VLAN, seguridad de las redes Wifi, etc.)
La auditoría de seguridad elabora un informe detallado conteniendo los siguientes aspectos: alcance de la
auditoría, metodología seguida, resultados de la evaluación de los objetivos de control, hallazgos detectados,
riesgos asociados a los hallazgos y recomendaciones para la definición e implementación de un plan de
acción correctivo.
1. Alcance.
empresa y calificación del personal:
Planes y procedimientos.
Sistemas técnicos de detección y comunicación.
Análisis de puestos.
Mantenimiento.
Normativa.
2. Objetivos:
Realizar un informe de auditoría con el objeto de verificar la adecuación de las medidas aplicadas
a las amenazas definidas, así como el cumplimiento de los requisitos exigidos.
3. Referencia Legal:
Manual de auto protección aprobado por O.M. de 29/11/84, NBE-CPI 96 (RD 2177/96),
Normativa de las Comunidades Autónomas y Ordenanzas Municipales, CEPREVEN.
4. Resultados:
Informe de auditoría detectando riesgos y deficiencias en el sistema de seguridad.
Plan de recomendaciones a aplicar en función de:
• Riesgos.
• Normativa a cumplir.
• Costos estimados de las recomendaciones.
12.3. Lógica
PREGUNTAS

1. ¿Existen medidas, controles, procedimientos, normas y estándares de seguridad?

2. ¿Existe un documento donde este especificado la relación de las funciones y obligaciones del personal?

3. ¿Existen procedimientos de notificación y gestión de incidencias?

4. ¿Existen procedimientos de realización de copias de seguridad y de recuperación de datos?

5. ¿Existe una relación del personal autorizado a conceder, alterar o anular el acceso sobre datos y recur-
sos?

6. ¿Existe una relación de controles periódicos a realizar para verificar el cumplimiento del documento?

7. ¿Existen medidas a adoptar cuando un soporte vaya a ser desechado o reutilizado?

8. ¿Existe una relación del personal autorizado a acceder a los locales donde se encuentren ubicados los
sistemas que tratan datos personales?

9. ¿Existe una relación de personal autorizado a acceder a los soportes de datos?

10. ¿Existe un período máximo de vida de las contraseñas?

11. ¿Existe una relación de usuarios autorizados a acceder a los sistemas y que incluye los tipos de acceso
permitidos?

12. ¿Los derechos de acceso concedidos a los usuarios son los necesarios y suficientes para el ejercicio de
las funciones que tienen encomendadas, las cuales a su vez se encuentran o deben estar- documentadas
en el Documento de Seguridad?

13. ¿Hay dadas de alta en el sistema cuentas de usuario genéricas, es decir, utilizadas por más de una
persona, no permitiendo por tanto la identificación de la persona física que las ha utilizado?

14. ¿En la práctica las personas que tienen atribuciones y privilegios dentro del sistema para conceder
derechos de acceso son las autorizadas e incluidas en el Documento de Seguridad?

15. ¿El sistema de autenticación de usuarios guarda las contraseñas encriptadas?

16. ¿En el sistema están habilitadas para todas las cuentas de usuario las opciones que permiten establecer:

Un número máximo de intentos de conexión.

Un período máximo de vigencia para la contraseña, coevento con el establecido en el Documento
de Seguridad.

17. ¿Existen procedimientos de asignación y distribución de contraseñas?

12.4. Física
PREGUNTAS

1. ¿Existen procedimientos para la realización de las copias de seguridad?

2. ¿Existen procedimientos que aseguran que, de todos los archivos con datos de carácter personal, se
realiza copia al menos una vez cada semana?

3. ¿Hay procedimientos que aseguran la realización de copias de todos aquellos archivos que han expe-
rimentado algún cambio en su contenido?

4. ¿Existen controles para la detección de incidencias en la realización de las pruebas?

5. ¿Existen controles sobre el acceso físico a las copias de seguridad?

6. ¿Sólo las personas con acceso autorizado en el documento de seguridad tienen acceso a los soportes
que contienen las copias de seguridad?

7. ¿Las copias de seguridad de archivos de nivel alto incluyen los archivos cifrados, si estas copias se
transportan fuera de las instalaciones?

8. ¿Las copias de seguridad de los archivos de nivel alto se almacenan en lugar diferente al de los equipos
que las procesan?

9. ¿Existe un inventario de los soportes existentes?

10. ¿Dicho inventario incluye las copias de seguridad?

11. ¿Las copias de seguridad, o cualquier otro soporte, se almacenan fuera de la instalación?

12. ¿Existen procedimientos de actualización de dicho inventario?

13. ¿Existen procedimientos de etiquetado e identificación del contenido de los soportes?

12.5. ¿En qué consiste la auditoría en seguridad informática?

La auditoría de seguridad informática pretende detectar las vulnerabilidades de la implementación de tec-
nología en la estrategia de negocio. También ofrecen soluciones para ganar en eficiencia, rentabilidad y
tranquilidad para los equipos de gestión.
Los especialistas en auditoría informática investigarán el correcto funcionamiento y rendimiento de los equi-
pos y sistemas de una empresa:

La actualización de los diferentes software de gestión.

El estado de las redes de comunicación.

La calidad de los servidores.

El funcionamiento de los dispositivos fijos y móviles.

Los planes de contingencia ante eventualidades que pongan en riesgo el sistema.

 La capacitación del personal en el uso de la tecnología.

El cumplimiento de las normativas vigentes.

Los puntos de vulnerabilidad informática.

Las oportunidades de mejora del rendimiento a través de nuevas herramientas.

Las políticas de protección de datos y resguardo de la información.

Los protocolos de acción ante contingencias, amenazas y ataques delictivos.

12.6. ¿Qué tipos de auditorías de seguridad informática se realizan?

Dependiendo de los fines de nuestra auditoría, es posible contratar profesionales externos con un objetivo
concreto en su análisis informático. Este puede ser:

1. Una auditoría forense:

Se trata de un servicio especializado para actuar ante un evento de seguridad con el objetivo de re-
copilar evidencias digitales que permitan reunir la mayor información posible sobre el ilícito y sus
operaciones.

2. Auditorías de código:
Se trata de pruebas de calidad del código fuente para identificar vulnerabilidades no sólo ante ataques
informáticos sino también ante el propio crecimiento de la demanda que la actividad realizada por el
software.

3. La auditoría web:
Este tipo de análisis está orientado a conocer las propiedades de las aplicaciones digitales y servicios
web utilizados a diario según la estrategia de negocio para prevenir posibles riesgos y optimizar la
seguridad.

4. Actualización de dispositivos:
Se trata de la verificación de la actualización del software y antivirus. Se comprueba el cumplimiento
de las reglas del firewall.

5. Hacking Ético:
Este tipo de auditoría es de la más interesante ya que consiste en probar las medidas de seguridad con
un test de intrusión con técnicas de hacking.

6. Auditoría de redes:
Esta herramienta provee a los directivos de un mapeo de todos los equipos conectados a la red interna,
el estado de las conexiones y la actividad de los dispositivos que articula.

7. Auditoría física:
Es un servicio que se encarga de proteger perimetralmente a una entidad a partir de sistemas como
controles físicos de entrada, alarmas contra incendios, sistemas de videovigilancia, el estado de las
instalaciones de servicios de luz, agua y gas, etc.
12.7. ¿Qué beneficios tiene la auditoría informática?
A través de ella, la empresa accede a un informe detallado sobre cada uno de los aspectos importantes
relacionados con su actividad automatizada.
De esta forma, se mencionan las oportunidades para optimizar el trabajo, tal que con las ventajas inmediatas
de la implementación de mejoras basadas en una auditoría informática la empresa logrará:

Mayor velocidad de gestión

Seguridad en los procesos informatizados

Prevención de delitos

Mantenimiento de las herramientas de trabajo

Mejor rentabilidad de las operaciones

Escalabilidad de la estrategia de negocio

Para que una auditoría informática sea realmente productiva para una empresa, lo fundamental es que sea
parte de una política general de resguardo de la seguridad informática y la optimización de las inversiones y
esfuerzos a través de constantes mejoras en los sistemas informáticos.
Las empresas que han tomado consciencia de la importancia de la seguridad informática, saben que los
beneficios también se presentan en la imagen que la institución ofrece a los clientes y la sustentabilidad del
negocio.

12.8. Protección de un servidor

Proteger un servidor de cualquier tipo de ataque, es fundamental para un proveedor de alojamiento web,
administrador de sistemas, o usuario con un pequeño vps o servidor personal. Si aún no lo ha hecho, es
importante que implemente una política de seguridad solida, de forma que minimice los riesgos y mantenga
los datos seguros.
Podría enumerar cientos (o miles) de consejos y trucos para mejorar la seguridad de su servidor, para man-
tenerlo seguro ante intentos maliciosos de ingreso. En este apartado, vemos las medidas fundamentales y
obligatorias que debe tener presente si no quiere riesgos innecesarios.
Mejorar la seguridad del servidor no es complicado, sólo debe seguir algunas pautas generales y ser cohe-
rente su uso. Los consejos de seguridad aquí presentados son para protección contra algunos de los ataques
comunes y que un auditor debe considerar. Veamos los principales consejos de seguridad.

12.9. Hacker, crackers, lamers, script kiddies y phreakers

¿Qué es un Hacker? Es un individuo con conocimientos avanzados de computación, es la persona que dis-
fruta explorando los detalles de un sistema y cómo ampliar sus capacidades.
¿Qué es un Cracker? El término cracker (del inglés to crack, que significa romper o quebrar) se utiliza para
referirse a las personas que rompen o vulneran algún sistema de seguridad. Los crackers pueden estar moti-
vados por una multitud de razones, incluyendo fines de lucro, protesta, o por el desafío.
Es considerado un ”Criminal”. Este utiliza sus conocimientos para invadir sistemas, descifrar y algoritmos de
encriptación, ya sea para poder correr juegos sin un CD-ROM, o generar una clave de registro falsa para un
determinado programa, robar datos personales, o cometer otros actos ilícitos informáticos. Algunos intentan
ganar dinero vendiendo la información robada, otros sólo lo hacen por fama o diversión.
¿Qué es un Lamer? Este grupo es quizás el que más número de miembros posee y quizás son los que mayor
presencia tienen en la red. Normalmente son individuos con ganas de hacer Hacking, pero que carecen de
cualquier conocimiento.
Habitualmente son individuos que apenas si saben lo que es una computadora, pero el uso de este y las
grandes oportunidades que brinda Internet, convierten al nuevo internauta en un obsesivo ser que rebusca
y relee toda la información que le fascina y que se puede encontrar en Internet. Normalmente la posibili-
dad de entrar en otro sistema remoto o de girar un gráfico en la pantalla de otra computadora, le fascinan
enormemente. Este es quizás el grupo que más peligro acontece en la red ya que ponen en práctica todo el
Software de Hackeo que encuentran en la red. Así es fácil ver como un Lamer prueba a diestro y siniestro
un ”bombardero de correo electrónico” esto es, un programa que bombardea el correo electrónico ajeno con
miles de mensajes repetidos hasta colapsar el sistema y después se autodenomina Hacker.
¿Qué es un Script Kiddies? En la cultura de programación y hacking, un script kiddie o skiddie es un indivi-
duo no calificado que utiliza scripts o programas desarrollados por otros para atacar sistemas informáticos,
redes y defectos de sitios web. Se supone generalmente son niños que carecen de la capacidad de escribir
programas sofisticados o exploits y su objetivo es intentar impresionar a sus amigos o ganar el crédito en las
comunidades de entusiastas de la computadora. Sin embargo, el término no se relaciona con la edad real del
participante.
¿Qué es un Phreakers?
Phreaking es un término acuñado para describir la actividad de una cultura de personas que estudian, ex-
perimentan o exploran sistemas de telecomunicaciones, tales como equipos y sistemas conectados a redes
telefónicas públicas. El término phreak es una ortografía sensacional de la palabra freak con el ph-from telé-
fono, y también puede referirse al uso de varias frecuencias de audio para manipular un sistema telefónico.
Phreak, phreaker, o phreak del teléfono son nombres usados ??para y por los individuos que participan en
phreaking.

12.10. Phishing
El phishing y los piratas informáticos de los medios sociales y el correo electrónico son los delitos ciberné-
ticos que se denuncian con más frecuencia en varios países.
El auditor debe considerar que, aunque una de cada tres empresas de aplicaciones Web está preocupada por
las estafas de phishing. El software de rescate es una preocupación para un tercio de ellas, mientras que una
quinta parte de las empresas se preocupan por el robo de sus datos financieros.
Una de cada cinco empresas encuestadas ha sido víctima de un cibercrimen.
Las personas que han sido víctimas de los ciberdelitos tienen una tasa de estrés (reportada por el 75 %) y an-
siedad (reportada por el 70 %) como los impactos psicológicos más comunes. Otras repercusiones mentales
incluyen miedo (52 %), vergüenza (51 %), ira (48 %) y aislamiento (43 %).
Más de la mitad (57 %) de esas personas no considera útil denunciar el delito cibernético, y sólo el 21 % dice
que el sistema legal hace un buen trabajo al protegerlos del fraude en línea.
Si bien un 55 % de la población siente que su sistema legal hace un buen trabajo al protegerlos del fraude en
línea; sin embargo, el 37 % dice que denunciar el crimen cibernético no es útil.
Los investigadores notaron ciertas diferencias en la actitud hacia la seguridad entre los grupos de edad.
Una falsa sensación de seguridad fue más evidente entre los Gen Z, (18 a 25 años), con el 50 % sintiendo que
no son lo suficientemente importantes o vulnerables como para ser blanco de los piratas informáticos.

12.11. Consejos de seguridad en servidor Linux

1. Autenticarte con clave publica en SSH.
Sin duda alguna, SSH es el protocolo más utilizado para conectarse a un servidor remoto. La mayoría
de los usuarios se conectan y administran sus servidores remotos mediante una contraseña. Como
norma general, el servicio SSH usa el puerto 22, y eso es un peligro pues los clientes lo saben, también
los piratas informáticos o usuarios malintencionados.
Para solucionar este problema tiene dos opciones, cambiar el puerto de acceso ssh por defecto, o usar la
autenticación basada en claves SSH que es más segura. En la segunda opción propuesta, cada usuario
tiene una clave pública y una privada. El usuario conserva la clave privada y la pública se guarda en el
servidor.
La clave SSH contiene más bits que una contraseña normal, por tanto no es fácil descifrarla. El único
requisito es mantener segura su clave privada, no compartirla. Además, tiene la ventaja de no tener
que escribirla password cada vez que se conectas a su servidor.

2. Asegura los sitios web con HTTPS.

HTTPS es la versión segura de HTTP. Este protocolo de comunicación, asegura que el tráfico entre
dos sistemas, tal que la conexión de un usuario con el sitio web es privada e inaccesible para otros
usuarios. Al tener SSL, la información transita de forma cifrada.
Los piratas detectarán el tráfico de información, pero no lo podrán visualizar. HTTPS utiliza el proto-
colo SSL/TLS para el cifrado y la autenticación, cifra las solicitudes y respuestas HTTP para que los
atacantes sólo lean caracteres aleatorios en vez de todos los detalles.

3. Mantener el servidor actualizado.

Mantener los paquetes del servidor siempre actualizados, es una tarea importante. No sólo el sistema
operativo, sino también de todos los servicios instalados.
Es una buena formula para evitar desagradables sorpresas. Puede crear un script bash que haga el
trabajo, pero es recomendable hacer intervenciones y revisiones manuales.

4. Deshabilitar los servicios no utilizados.

Cuando se habla de consejos de seguridad en un servidor Linux, deshabilite y elimine los servicios
que no necesita. De forma predeterminada, la mayoría de los sistemas operativos basados en Linux
vienen con una herramienta para administrar los servicios.
El auditor prestará especial atención a los sitios web creados con WordPress (el cms más común actual-
mente), y sugerirá eliminar complementos y temas no usados. Cuanta menos información proporcione
sobre su infraestructura, menos datos tiene los usuarios maliciosos de su sistema.

NOTA: Es común que los servicios de correo electrónico, estén habilitados por defecto. Si
no lo utiliza es importante que lo anule y/o elimine.

5. Instalar y configurar un firewall.

 A no ser que sea un usuario muy avanzado y maneje iptables o nftables a la perfección, es importante
configurar un firewall para evitar conexiones no autorizadas entrantes o salientes del servidor.
La mayoría de distribuciones Linux vienen con un software firewall integrado o se puede agregar
fácilmente.
Uno de esos completos es CSF, también conocido como ConfigServer Security & Firewall. Es una
herramienta firewall gratuita, basada en la web, y que protege al servidor excelentemente. Se puede
integrar con muchos paneles de control web.

6. Política de contraseña segura.

El auditor comprobará que existe una política de contraseñas para todos usuarios con acceso al servi-
dor. Estas son las principales recomendaciones.

Habilitar la autenticación de dos factores.

Usa contraseñas con un mínimo de 10 caracteres.
Palabras del diccionario no son nada recomendables.
En la contraseña se recomienda incluir números, símbolos y caracteres especiales.
No almacene sus contraseñas en sistemas portátiles, como teléfonos inteligentes o tabletas.
El uso de generadores de contraseñas automáticos, es la mejor opción.
Establezca una fecha de vencimiento de la contraseña.
No utilice la misma contraseña para varias cuentas.

En términos de cifrado hay varios algoritmos hash usados para de cifrado seguro.
Este es un resumen de los más conocidos, dependiendo del primer número entre símbolos $ será una
codificación u otra.

Tabla 12.1: Algortimos HASH más utilizados

1=MD5 (22 caracteres)
2=blowfish
5=SHA-256 (43 Caracteres)
6=SHA-512 (86 Caracteres)

Al poner una contraseña a un usuario, la función hash la cifra con el algoritmo determinado según sea
el cifrado. Toma un bloque arbitrario de datos y devuelve una cadena con una determinada longitud
(valor hash). Los datos para ser codificados son denominados ”el mensaje” y el valor hash se le deno-
mina ”message digest” o simplemente ”digest”.

1 $6$OrqRmooe$2XSkIJNgd3Te/xPUd6S1wdysNgPhFrT7UFHkbhvjECkt/
L9Z3rmqBUbRDBcfLf4sz/Z775X.WgJTaijVG7mhn1

El número destacado 6 indica en qué tipo de hash está la contraseña cifrada, en este caso se trata de
SHA-512, (Secure Hash Algorithm) y por lo tanto tiene 86 caracteres en total.

7. Detectar malware.
También se recomienda escanear al servidor en busca de software malicioso. Si localiza algo extraño,
 debe eliminarlo inmediatamente. Si bien el malware no es común en Linux, si existe.
Los consejos de seguridad están incompletos sin ClamAV; una de las mejores herramientas de escaneo
para los sistemas basados en Linux. El auditor analizará el servidor en busca de software o archivos
maliciosos y los elimina automáticamente (si lo indicas).

8. Evita los servicios Telnet, FTP y Rlogin.

Cualquier usuario que se encuentre en la misma red, puede intentar el acceso mediante comandos FTP,
telnet o rsh (remote shell) a los nombres de usuario y contraseñas con el simple uso de un rastreador de
paquetes. Evite el uso de estos servicios y acostumbre OpenSSH, FTPS y SFTP. Es una buena forma
de evitar comprometer la seguridad de su sistema linux.

Los consejos de seguridad presentados, son básicos y de sentido común si no quiere tener intrusiones ajenas
en su servidor.
 Auditoría forense
13
Este capítulo es una introducción a la auditoría informática, no pretende ser una presentación exhaustiva del
tema, lo que queda fuera del contexto del capítulo y de este texto.
La ciencia forense es sistemática y se basa en hechos premeditados para recabar pruebas y luego analizarlas.
La tecnología, en caso de análisis forense en sistemas informáticos, son aplicaciones que hacen un papel de
suma importancia en recaudar la información y pruebas necesarias. La escena del crimen es el computador
y la red a la cual éste está conectado. Gran cantidad de documentos son elaborados digitalmente en compu-
tadores para ser a continuación impresos.
Ya se han producido algunas experiencias en algunos países de habla hispana, siendo los más destacados
España, México, Venezuela y Colombia; los cuales han solicitado la determinación de la autenticidad e in-
tegridad por ejemplo de mensajes de e-mail pudiéndose relacionar con un remitente, dirección de correo,
computador y hasta con una persona determinada e inclusive la relación entre estos elementos y los datos
anexos (attachments) que se encontraban en el email almacenado previamente en el equipo incurso.
Hay que tener en cuenta que ”Forense” es un proceso legal, así como mecanismos y herramientas técnico-
legales. Según la investigación que sea, el auditor forense informático debe entender y aplicar una amplia
gama de conceptos jurídicos, y tomar en cuenta los precedentes, como la cadena de custodia, el deterioro
de las pruebas, y contar con las pruebas suficientes que sean aceptadas ente los tribunales, esto puede ser
desalentador.
Por esto, la mayoría de las técnicas de análisis forense se centran en la recuperación de la información en
discos duros, para lo cual existen herramientas que realizan duplicaciones exactas del contenido de un disco
duro.
La figura del auditor forense informático se ha creado para conocer los ataques informáticos y realizar inves-
tigaciones informáticas y análisis digitales, recabar datos para ser utilizados como pruebas judiciales y sobre
todo para documentar la comisión de ciberataques en una empresa.

13.1. Agencias forenses

Destaca en este campo el Concurso de Reto Forense que se celebra desde el año 2004, en el que los partici-
pantes deben analizar un sistema informático comprometido como forma de capacitación a futuros auditores
forenses informáticos.
Éste reto está patrocinado por las dos principales empresaes académicas de seguridad informática de España

146
y México, la UNAM a través de la DGSCA y el UNAM-CERT y la organización pública Red.es a través
del Grupo de Seguridad de RedIRIS, con el apoyo de organizaciones y organismos de seguridad informática
iberoamericanos y mundiales.
El Centro de INTERPOL contra la Delincuencia digital, indica ”que los delincuentes se aprovechan de las
nuevas tecnologías, de la facilidad de los desplazamientos internacionales y del anonimato de las actividades
en el mundo virtual..” adiciona ”..en el mundo virtual, casi cualquier persona puede participar en un delito y
borrar el rastro de su actividad de una manera que es prácticamente imposible en el mundo real..” [45]
El autor pretende estimular a los interesados en conocer con alguna profundidad la problemática que acom-
paña a la auditoría forense informática.

13.2. Antecedentes y conceptos

Como bien lo define Kata Y. [41], ”La auditoría forense consiste en una evidencia digital que se obtiene
por el uso de técnicas de investigación criminalística integradas con la contabilidad, conocimientos jurídicos
procesales y con habilidades en finanzas de negocios para recabar y manifestar información y opiniones co-
mo pruebas ante los tribunales, el análisis resultante además de poder usarse en los tribunales puede servir en
disputas de diversa índole”. Se trata de una especialidad relativamente nueva, que demanda alta calificación
en conocimientos de informática, y la doctrina del derecho penal y del civil.
En el plano de los sistemas informáticos y la Ciencia Forense, se habla de Análisis Forense Digital. Esta dis-
ciplina es relativamente nueva y se aplica tanto para la investigación de delitos ”tradicionales”, (homicidios,
fraude financiero, narcotráfico, terrorismo, etc.), como para los relacionados con las TIC, entre los que des-
tacan piratería de software y comunicaciones, distribución de pornografía infantil, intrusiones y ”hacking”
en las empresas, spam, phishing, etc.
De manera formal, se define el Análisis Forense Digital como un conjunto de principios y técnicas que
comprende el proceso de adquisición, conservación, documentación, análisis y presentación de evidencias
digitales y que llegado el caso puedan ser aceptadas legalmente en un proceso judicial. Por evidencia digital
se entiende al conjunto de datos en formato binario, esto es, comprende los ficheros, su contenido o referen-
cias a éstos (metadatos) que se encuentren en los soportes físicos o lógicos del sistema atacado.
Dentro del Análisis Forense Digital (en lo sucesivo AFD), destacan las siguientes fases:

A.- Identificación del incidente.

B.- Recopilación de evidencias.

C.- Preservación de la evidencia.

D.- Análisis de la evidencia.

E.- Documentación y presentación de los resultados.

Otro concepto importante es el Incidente de Seguridad Informática, que ha evolucionado en los últimos años.
En principio, un incidente de este tipo se entendía como cualquier evento anómalo que pudiese afectar a la
seguridad de la información, como podría ser una pérdida de disponibilidad, su integridad o confidencialidad,
etc.
Pero la aparición de nuevos tipos de incidentes ha hecho que este concepto haya ampliado su definición.
Actualmente un Incidente de Seguridad Informática puede considerarse como una violación o intento de
violación de la política de seguridad, del uso adecuado o de las buenas prácticas de utilización de los sistemas
informáticos.
En USA, la informática forense tuvo su punto de quiebre cuando los policías e investigadores militares se
dieron cuenta que los criminales utilizaban cada vez más y más recursos tecnológicos.

13.3. Vulnerabilidades comunes

Ahora cabe una categorización de dichos incidentes como a para su valoración y una visión de cómo afron-
tarlos. Aunque se han propuesto varios tipos de clasificaciones sobre taxonomías de incidentes, no existe
ningún consenso al respecto y ni mucho menos sobre cual de ellas es la más acertada. La que se propone a
continuación tiene la finalidad de ayudar a una mejor comprensión de apartados siguientes del documento:

Incidentes de Denegación de Servicios (DoS): cuya finalidad es obstaculizar, dañar o impedir el acceso
a redes, sistemas o aplicaciones mediante el agotamiento de sus recursos.

Incidentes de código malicioso: Cualquier tipo de código ya sea, virus, gusano, ”caballo de Troya”,
que pueda ejecutarse en un sistema e infectarlo.

Incidentes de acceso no autorizado: Se produce cuando un usuario o aplicación accede, por medio de
hardware o software, sin los permisos adecuados a un sistema, a una red, a una aplicación o los datos.

Incidentes por uso inapropiado: Se dan cuando los usuarios se ”saltan” la política de uso apropiado de
las sistemas (como ejecutando aplicaciones P2P en la red interna de la empresa para la descarga de
música).

Incidente múltiple: Se produce cuando el incidente implica varios de los tipos anteriores.

Los objetos maliciosos más usados detectados en los distintos dispositivos informáticos pueden divi-
dirse en tres grupos principales:

• Módulos de publicidad.
• Exploits (aprovechar vulnerabilidades) para acceder de raíz a los dispositivos.

Otros incidentes a considerar son:

Inadecuado compromiso de la dirección.

Personal inadecuadamente capacitado y concientizado.

Inadecuada asignación de responsabilidades.

Ausencia de políticas/ procedimientos.

Ausencia de controles:

• físicos y/o lógicos.

• disuasivos/preventivos/detectivos/correctivos.

Ausencia de reportes de incidentes y vulnerabilidades.

Inadecuado seguimiento y supervisión de los controles.

13.4. Definiciones
Metadatos: Son datos que se escriben dentro de otros datos. Por ejemplo es posible obtener datos de una
fotografía tomada por un teléfono digital, como la fecha, hora y lugar donde se tomó, etc., según describe
Kata Y. [41].
Evidencia digital: ”. . . cualquier información, que sujeta a una intervención humana u otra semejante, ha sido
extraída de un medio informático” Kata Y. [41].
Siniestro informático: Según Miguel Antonio Cano C. [42] referido por Villacis, V. [43] ”El siniestro infor-
mático implica actividades criminales como robos, hurtos, falsificaciones, estafa, sabotaje, etc. Sin embargo,
debe destacarse que el uso de las técnicas informáticas ha creado nuevas posibilidades del uso indebido de
computadoras lo que ha propiciado a su vez la necesidad de regulación por parte del derecho.”

13.5. Procedimientos
Los capítulos previos1 describen algunas medidas, y quizás alguna más, y aunque no es agradable preparar
actuaciones ante desastres en sus sistemas informáticos, siendo realista, no estaría de más incluir dentro de su
política de seguridad un ”Plan de Respuesta ante Incidentes”. Éste plan dependerá de las características de su
organización, y de su política, pero en base y sin extendernos en ello pues no es objetivo de este documento,
debería contener los siguientes puntos:

Alcance, propósitos y objetivos del plan de acción.

Estructura organizativa del equipo de respuesta a incidentes, responsabilidades, autoridad, departa-

mentos implicados.

Actuaciones para la contención del problema.

Procedimientos de recuperación y restauración de sistemas SIN eliminación de posibles evidencias del

ataque.

Índices para la valoración de los daños, tanto desde el punto de vista económico como de imagen
corporativa.

Determinar en qué casos se tratará el incidente internamente y en qué casos se dará aviso a las Auto-
ridades.

Sopesar la contratación de personal externo para llevar a cabo la investigación.

Establecer las fases de la investigación.

Elaboración de informes y formularios tipo para comunicación del incidente tanto dentro como fuera
de la organización si fuese necesario.

La implantación de procedimientos adecuados en la gestión de archivos, registros y copias de seguridad

ayudan al auditor en su trabajo. A continuación, se exponen algunas recomendaciones:

Conocer y supervisar los parámetros de funcionamiento normal de los sistemas, tales como tráfico IP
usual, carga de transacciones, ancho de banda consumido, usuarios conectados, etc.
1 Diseño e implementación previo de la red informática, Auditoría de seguridad.
 Utilizar un servidor de registros central y establecer una política de mantenimiento y retención de esos
registros que permitan su estudio pasado el tiempo.

Activar al máximo de detalle la información que contendrán los archivos de registro, lo que facilita el
proceso de reconstrucción de lo sucedido.

Sincronizar todos los relojes de los servidores mediante, como el protocolo NTP (Network Time Pro-
tocol), tal que todos los registros tengan la misma hora.

Disponer de una base de conocimientos sobre incidentes, enlaces páginas de software antivirus, o
empresas y organizaciones especializadas en seguridad informática, así como suscribirse a sus listas
e-mail de notificaciones de alertas y vulnerabilidades.

Considere la experiencia como un factor irreemplazable, distinguiendo un ataque de un problema

técnico.

Otros factores a considerar son:

• Esterilidad de los medios informáticos.

• Verificación de los medios informáticos.
• Auditoría de los procedimientos realizados en la investigación.
• Administración del caso realizado.
• Documentación de los procedimientos, herramientas y resultados sobre los medios informáticos
analizados.
• Mantenimiento de la cadena de custodia de las evidencias digitales.
• Informe y presentación de resultados de los análisis de los medios informáticos.

13.6. Análisis forense

La informática forense se puede decir que es la ciencia de adquirir, preservar, obtener y presentar datos que
han sido procesados electrónicamente y guardados en un medio computacional.
Uno de los objetivos de la computación forense es: ”la necesidad de determinar los hechos ocurridos en
un evento donde se interactúa con equipos de cómputo, buscando esclarecer los hechos, determinando la
magnitud del incidente y los implicados” [46]. Pretende identificar material probatorio a ser utilizado en un
tribunal o simplemente que apoye la gestión de riesgos mejorando la prevención de futuros incidentes.”
El número de delitos informáticos viene en aumento a medida que avanza la tecnología, es por esto que
el análisis forense viene aumentando su importancia, ya que siempre innovan en la forma de atacar, y esto
conlleva a que se deben utilizar técnicas de análisis que estén acorde con la nueva tecnología. El análisis
forense se basa tres objetivos fundamentales:

La persecución y procesamiento judicial de los delincuentes.

La compensación de los daños causados por los criminales informáticos. La creación y aplicación de
medidas para prevenir casos similares
En toda investigación forense se deben obtener evidencias suficientes y apropiadas y conocer las condiciones
bajo las cuales dicha evidencia puede ser considerada como:

Admisible.

Autentica.

Completa.

Confiable.

Creíble.

Existe un procedimiento para realizar el análisis para la informática forense, estos sirven de base para las
personas que realizan esta práctica de manera adecuadamente.
Después de ocurridos los hechos se puede realizar el análisis en los laboratorios especializados con equipos
dedicados a fines forenses, estos tienen la capacidad de examinar completamente la tecnología contenida
dentro del sistema que haya surgido el incidente este análisis se le conoce como Post-mortem.
En el momento en que se presume que se está sufriendo un incidente de seguridad en un dispositivo se
pueden emplear herramientas de respuesta ante incidentes y realizar el análisis forense en el momento sin
modificar el sistema analizado, a este proceso se le llama análisis en caliente y luego de este se realiza el
análisis post-mortem.
Se tienen un conjunto de procedimientos donde su objetivo primordial es preservar la evidencia digital per-
mitiendo convertirse en la prueba en un proceso judicial; a este conjunto de pasos se conoce como cadena de
custodia.
La cual debe:

Reducir al máximo la cantidad de agentes implicados en el manejo o tratamiento de evidencias.

Mantener la idempresa de las personas implicadas desde la obtención hasta la presentación de las
evidencias.

Asegurar la firmeza de las evidencias.

Registros de tiempos, firmados por los agentes, en los intercambios entre estos de las evidencias. Cada
uno de ellos se hará responsable de las evidencias en cada momento.

Asegurar la firmeza de las evidencias cuando las evidencias están almacenadas asegurando su protec-
ción.

La secuencia de la cadena de la evidencia debe seguir el siguiente orden:

Recolección e identificación de evidencia.

Análisis.

Almacenamiento.

Preservación.

Transporte.
 Presentación en el juzgado.

Retorno a su dueño.

Los resultados de la cadena de custodia muestran:

• Quién obtuvo la evidencia.

• Dónde y cuándo la evidencia fue obtenida.
• Quién protegió la evidencia.
• Quién ha tenido acceso a la evidencia.

13.7. Usos de la tecnología forense/herramientas

Tal como lo señala Kata Y. [41], la tecnología forense puede utilizarse en:

Prosecución criminal: con el fin de recabar evidencia incriminatoria.

Litigación civil: casos que conlleven fraude, discriminación, acoso o divorcio.

Investigación de Seguros: cualquier tipo de evidencia encontrada que ayude a disminuir los costos de
reclamos por accidentes y compensaciones.

Temas corporativos: acoso sexual, robo, mal uso o apropiación de información, alteraciones de estados
financieros, corrupción.

Mantenimiento de la ley: La informática forense puede ser usada en la búsqueda inicial de órdenes
judiciales.

13.8. Fases de un análisis forense digital

Este proceso se basará en una metodología con enfoque de carácter cualitativo y una investigación explo-
ratoria y analítica, utilizando la técnica de análisis documental como insumo para el proceso analítico. La
metodología de desarrollo del documento será el ciclo Deming PHVA (Planear, Hacer, Verificar, Actuar), ya
que tiene un enfoque basado en procesos y facilita identificar, planificar, implementar y mejorar los procesos
y procedimientos que se deben tener en cuenta para lograr el objetivo.
El siguiente diagrama plantea la puesta en marcha de la metodología para realizar la guía propuesta por
Larrota Ardila, L S. et al. [47]
 Figura 13.1: Metodología Deming PHVA.

13.9. Técnicas para identificar delitos

Indagación.

Encuestas.

Inspección.

Comparaciones.

Observaciones.

En cuanto a las fases de la AFI existen varios planteamientos que coinciden en lo importante su planeación
y ejecución debe ser flexible pues, según el caso, se presentan particularidades.
En el siguiente cuadro se detallan las fases de una AFI:

13.10. Identificación del incidente

Búsqueda y recopilación de evidencias.
Una de las primeras fases del análisis forense comprende el proceso de identificación del incidente, que lleva
aparejado la búsqueda y recopilación de evidencias.
 Tabla 13.1: Fases de la auditoría forense
FASE 1 Planifi- En esta fase el auditor forense debe: Obtener un conocimiento
cación. general del caso investigado, Analizar todos los indicadores de
fraude y/o vulnerabilidad existentes, Evaluar el control interno
de ser posible y considerarlo necesario (es opcional). Investigar
para elaborar el informe de la investigación, en el cual decide si
amerita o no una investigación exhaustiva; es decir, existen sufi-
cientes indicios para considerar procedente la auditoría forense.
Al planificar una AFI debe tomar el tiempo necesario, evitando
extremos como la planificación exagerada o la improvisación.
FASE 2. Traba- En esta fase se ejecutan los procedimientos de auditoría forense
jo de Campo. definidos en la fase de planificación, más aquellos que se conside-
ren necesarios durante el transcurso de la investigación. Un aspec-
to importante en la ejecución de la auditoría forense es el sentido
de oportunidad, una investigación debe durar el tiempo necesa-
rio, sin excesos. El auditor forense debe conocer o asesorarse por
un abogado respecto de las normas jurídicas penales (para el de-
bido proceso) y otras personas relacionadas específicamente con
la investigación que está realizando. Si el auditor forense no rea-
liza con prolijidad y profesionalismo su trabajo, puede terminar
acusado por daño moral o similar.
FASE 3. Comu- Será permanente con los funcionarios que el auditor forense esti-
nicación de Re- me pertinente. Al comunicar resultados parciales o finales el audi-
sultados. tor debe ser cauto, prudente, estratégico y oportuno, debe limitar-
se a informar lo que fuere pertinente, un error en la comunicación
de resultados puede arruinar toda la investigación (muchas veces
se filtra información o se alerta antes de tiempo a los investigados
de los avances obtenidos).
FASE 4. Super- Esta última fase tiene por objetivo asegurar que los resultados de
visión del caso. la investigación forense sean considerados según su importancia
y evitar que queden en el olvido, lo que otorga a los perpetradores
del fraude impunidad.
13.11. Diagnóstico del problema
El profesional forense debe utilizar información y herramientas confiables y eficaces para tal propósito.
Parte del proceso del diagnóstico será la revisión cuidadosa del sistema operativo de la empresa investigada,
software de oficina, navegación por internet, etc. El problema puede involucrar la ausencia de un antivirus
confiable y controles de seguridad.

13.12. Forma de recabar información

Entre los programas más utilizados para conseguir información se encuentran FOCA y BELARC. El primero
de ellos se utiliza para encontrar metadatos (información oculta en documentos) mientras que el segundo
construye un perfil detallado del software y hardware instalados en la PC, ver Kata Y. [41]. Existen otros
programas de uso común, como: ENCASE, FORENSIC TOOLKIT, y WINHEX.

13.13. Reconocimiento de la evidencia digital como evidencia formal y válida

La evidencia digital en la administración de justicia en muchas partes del mundo continúa siendo una situa-
ción problemática por resolver Brungs, A y Jamieson , R. [44]. Es necesario alcanzar la mejor preparación
de profesionales con las mejores herramientas disponibles, y dotar de los recursos necesarios para alcanzar
este objetivo.

13.14. Acción que sigue al diagnostico

Luego de reunir toda la información, en forma de evidencia en torno al diagnóstico referido al manejo del
software, es recomendable solucionarlo en 3 fases:

1. Fase 1:
Adquirir un buen antivirus con licencia, que pueda garantizar la protección de la información de la em-
presa. Los antivirus piratas no ofrecen ninguna garantía de protección. En el mercado existen muchos
antivirus confiables, entre ellos están Kaspersky, Norton, Avast, Panda, y NOD32, etc.

2. Fase 2:
En cuanto al sistema operativo, es recomendable Enterprise Agreement, que es un programa completo
de licencias por volumen de Microsoft dirigido a grandes corporaciones que manejan más de 250 PC
y tienen un departamento de compras centralizado. Ellos normalmente, están siempre interesados en
una adecuada protección de su información, y están dispuestos a pagar un alto precio por su seguridad
informática.

3. Fase 3:
Adquisición de las licencias de información geográfica que se utiliza en la empresa (GIS).

En los actuales momentos, una plataforma tecnológica muy utilizada por las empresas es servidores con
sistema operativo Linux o derivados y clientes, Windows.
Otros:

Es necesario establecer:
 • Políticas de seguridad
• Acuerdos de confidencialidad

Gestión de archivos: Inventario, responsabilidad.

Seguridad de los recursos humanos: Antes, durante y después del empleo.

Seguridad física y ambiental: Áreas seguras, protección del equipo.

Gestión de las comunicaciones y operaciones: Protección contra malware, respaldo, seguridad de re-
des, intercambio de información.

Control de acceso: de usuarios y privilegios, contraseñas, de redes, de sistema operativo y la compu-

tación móvil.

Desarrollo y mantenimiento de los sistemas de información: software desarrollado dentro y fuera de

la empresa.

Gestión de incidentes: Control de eventos, Gestión de la continuidad comercial: Respuesta a fallos o

desastres críticos. Cumplimiento: Leyes y regulaciones, propiedad intelectual, etc.

13.15. Normas internacionalmente reconocidas

En respuesta a la necesidad de mejorar los procedimientos relacionados con la seguridad informática, bus-
cando proteger la información privada y/o del Estado y mejor preservarlo de manejos indeseados, es que
conforme fue evolucionando la tecnología, de forma paralela se fueron creando marcos normativos que den
adecuado soporte a las nuevas exigencias, sin que esto signifique que esto es un tema concluido.
Entre los distintos organismos relacionados comercial y/o institucionalmente con los temas de Seguridad de
la Información, están los siguientes:

Normas de Auditoría Generalmente Aceptadas : NAGA

ISACA: COBIT

British Standards Institute: BSI

International Standards Organization: Normas ISO

Departamento de Defensa de USA: Orange Book / Common Criteria

ITSEC – Information Technology Security Evaluation Criteria: White Book

Sarbanes Oxley Act, HIPAA

COSO Report

NORMA ISO 17799:2000

Es una norma, con carácter de estándar en la seguridad informática, y basada en la norma BS 7799, la
cual propone 10 áreas de dominio de control consideradas ”exitosas” que toda empresa debería establecer y
cumplir:
 Política de Seguridad de la Información

empresa de la Seguridad

Clasificación de los activos

Seguridad del Personal

Seguridad Física y Ambiental

Gestión de Comunicaciones y Operaciones

Control de Accesos

Desarrollo y Mantenimiento de Sistemas

Administración de la Continuidad de los Negocios Villacis, V. [43]

13.16. El Informe técnico

Consiste de una exposición detallada del análisis efectuado. Deberá describir en profundidad la metodología,
técnicas y hallazgos del equipo forense. A modo de orientación, contendrá, al menos, los siguientes puntos:

Antecedentes del incidente.

Recolección de los datos.

Descripción de la evidencia.

Entorno del análisis .

Descripción de las herramientas.

Análisis de la evidencia .

Información del sistema analizado .

Características del SO.

Aplicaciones.

Servicios.

Vulnerabilidades.

Metodología.

Descripción de los hallazgos.

Huellas de la intrusión.

Herramientas usadas por el atacante.

Alcance de la intrusión.
 El origen del ataque,

Cronología de la intrusión.

Conclusiones.

Recomendaciones específicas.

Referencias.

13.17. El Informe ejecutivo

Consiste en un resumen del análisis efectuado pero empleando una explicación no técnica, con lenguaje co-
mún, que expondrá los hechos más destacables de lo ocurrido en el sistema analizado.
Constará de pocas páginas, entre tres y cinco, y será de especial interés para exponer lo sucedido a per-
sonal no especializado en sistemas informáticos, como pueda ser el departamento de Recursos Humanos,
Administración, e incluso algunos directivos. En este informe describe lo siguiente:

Motivos de la intrusión.

Desarrollo de la intrusión.

Resultados del análisis.

Recomendaciones.
 Auditoría y los delitos informáticos
14
Unido al avance en los últimos tiempos de la tecnología informática y su influencia en casi todas las áreas de
la vida social, ha surgido una serie de comportamientos ilícitos denominados, de manera genérica, ”delitos
informáticos”.
El amplio uso de la tecnología, como producto de la globalización, no sólo ha traído beneficios, sino también
ha contribuido a la masificación de los delitos informáticos.
Este capítulo presenta la conceptualización y características de los delitos informáticos y el papel del auditor
informático con ellos.
El objetivo principal de este capítulo es la identificación de las pruebas de Bases de Datos para la Migración
y Validación de Datos en el entorno de las tecnologías de información en la actualidad.
Se inicia identificando los orígenes o razones por las cuales se llevan a cabo las migraciones de datos y los
problemas a los cuales se enfrentan y las razones por las que se presentan dichos problemas.
El propósito es identificar de qué manera las pruebas para las migraciones y validaciones de datos reducen
las probabilidades de ocurrencia de dichos problemas, para el beneficio no sólo de proyecto como tal, sino
de la empresa también.
Este capítulo no está orientado simplemente a la identificación de procesos y pruebas, sino también al reco-
nocimiento de la importancia que los datos tienen para las decisiones en las organizaciones y el impacto que
una buena calidad de los mismos tiene. Por ello, también es importante identificar aspectos que rodean el
tema, tales como los datos en primera instancia, las bases de datos, la migración y la validación, la calidad
de datos, las pruebas y una metodología.
La migración de datos es por lo general un proceso programático que puede ser automático o manual.

14.1. Motivos
Como consecuencia directa del rápido crecimiento de la sociedad, sus organizaciones y las tecnologías que
los apoyan, la velocidad con la cual crecen los volúmenes de datos e información dentro de las organizacio-
nes, un crecimiento que va desde un 25 % hasta posiblemente un 50 % anual, porcentaje que aumenta cada
año a medida que crecen las organizaciones, en las cuales la mayoría de esta información se encuentra en
formato digital.
Dichos proyectos de migración de datos se están volviendo más frecuentes cada año y va adquiriendo mayor
importancia la necesidad de reducir los riesgos o problemas, que proyectos de este tipo implican.

159
Hoy en día, las aplicaciones críticas del negocio deben estar disponibles 24/7/365 (24 horas al día, 7 días
a la semana, 365 días al año), dejando así pocas opciones por tiempos de inactividad para llevar a cabo las
migraciones de datos.
Dentro de las metodologías requeridas, una buena fase de planeación es uno de los aspectos más importantes;
otro aspecto de mucha importancia son las pruebas a las bases de datos a emplear y pruebas a los datos a ser
migrados, que pueden ayudar a reducir en un alto nivel los problemas con los cuales se enfrentan en etapas
de validación y post-migración.
Las necesidades tecnológicas cada vez se inclinan más hacia los lados de migraciones online, sin interferir
con los procesos diarios del negocio.
La última parte del trabajo estará compuesta por la descripción de algunas herramientas para la migración
y validación de datos, se analizará cuáles son las ventajas y desventajas para los proyectos de migración de
datos, los tipos de migración soportados, los diversos tipos de pruebas que les permiten a sus usuarios, etc.
Además, se analizarán algunos aspectos que deben tener en cuenta al momento de elegir herramientas para
facilitar las migraciones de datos.

14.2. Justificación
Las necesidades de almacenamiento de datos de las organizaciones han ido cambiando a medida que evolu-
cionan los sistemas de información y sus necesidades de organización y utilización de dichos datos.

14.3. Objetivo
Identificar, analizar y documentar las técnicas y metodologías actuales en la realización de pruebas de bases
de datos para la migración y validación de datos, incluyendo herramientas adicionales empleadas, para pro-
porcionar así elementos que sirvan como componentes para el desarrollo de una metodología unificada para
las pruebas de bases de datos.

14.4. Migración
Las razones para migrar datos contenidos en uno o más sistemas dependen de las necesidades del negocio
o de los cambios y avances tecnológicos en el entorno, pero aparte de estas, hay otras razones para llevar a
cabo una migración. Entre las que se encuentran:

Unificación de sistemas.

La principal razón por la cual se presentan las migraciones es el refrescamiento de las tecnologías,
como la actualización de las versiones de software de aplicaciones y de las bases de datos.

Implementación de nuevos sistemas.

Implementación de un sistema analítico (OLAP).

Cambios de hardware.

Cambio de software.
En un estudio realizado por Softek [58] se identifican los principales problemas de un proceso de migración
de datos. Inicialmente habían encuestado 280 compañías, de las cuales 75 % admitieron tener problemas
con el proceso de migración de datos. Mientras que 54 % identificaron que sus problemas eran de carácter
técnico por incompatibilidades entre origen y destino de los datos, 58 % de ellos dijeron que el tiempo de
inactividad extendido o inesperado era un resultado muy común entre los problemas que se presentan du-
rante la migración. Algo interesante que ese estudio preliminar encontró, es que 31 % de los encuestados
están demorando la adquisición de nuevos equipos o sistemas, simplemente por los problemas resultantes
del proceso de migración.
Durante este primer análisis del estudio de Softek, encontraron que la mayoría de los encuestados coincidían
con el hecho de que una migración de datos exitosa requiere una planeación efectiva y mucho personal,
identificando así dos suministros muy escasos o muy ocupados en los departamentos de tecnología de las
empresas; esos dos suministros son Tiempo y Personal Técnico.
El 75 % de los encuestados sostiene que el tiempo mínimo requerido para planear el proceso de migración
es de dos semanas, mientras que el otro 25 % sostiene que dicho tiempo debería ser de cuatro semanas, para
estar del lado seguro. Casi un 50 % afirma que un proyecto de migración de mediano tamaño1 requiere como
mínimo cuatro personas trabajando en el equipo de migración de tiempo completo.
En este punto hay que recordar cuáles son los tres factores más importantes en un proceso de migración
de datos: tiempo de inactividad, horas de trabajo del personal y costos. El estudio muestra que todos estos
factores son excedidos más del 50 % de las veces, todos estos excesos se traducen en costos para la organiza-
ción, distintos costos a los originalmente planeados para la migración, colocando en perspectiva si el costo
de emplear una herramienta de migración online es superior a los costos de no tenerla.
También encontraron que el mayor costo de una migración es la falta de procedimientos y pruebas para la
validación de los datos, 55 % de los encuestados dependen de las ”pruebas” de los usuarios en el sistema
de producción para determinar si la migración fue exitosa. Podrían pasar días o semanas antes de descubrir
algún problema con la migración, y eso en sí es un costo, el arreglo de dicho problema y el tiempo de inac-
tividad de las aplicaciones mientras se realiza el arreglo. ESG sostiene que la mayoría de las aplicaciones
para migraciones online realizan pruebas propias sobre los datos, para verificar lo mínimo, como integridad,
y permiten realizar verificaciones programáticas a los datos, para así tratar de reducir las probabilidades de
problemas después de la migración.

14.5. Riesgos
Algunos de los riesgos más importantes que corren las organizaciones cuando inician un proceso de migra-
ción son los siguientes:

Problemas que se originan durante el tiempo en el cual el sistema permanece fuera de servicio, ya sea
el sistema de origen o el sistema destino de los datos.
El problema es básicamente de coordinación, estimación de los tiempos de migración y administración
de los mismos.

Problemas funcionales inesperados en el sistema destino de los datos.

Y el problema más importante y de mayor peso es la pérdida y corrupción de los datos. Este es el problema
que genera las mayores pérdidas para las organizaciones en lo que respecta a tiempo y dinero.
1 Definiendo como migración de mediano tamaño, una con más de 2 y menos de 4 sistemas de origen de datos.
14.6. Datos
La calidad de los datos está obteniendo cada vez mayor importancia y atención dentro de las organizaciones.
Se están dando cuenta que los problemas con la calidad de los datos están derivando en problemas con
la información presentada y en consecuencia, afectando las decisiones tomadas con base en las mismas,
provocando pérdida de ingresos, tiempo y oportunidades. El costo de una mala calidad de los datos está
oculto y no es tan obvio si no se le está buscando.

14.6.1. ¿Qué es calidad de datos?

Una definición general y básica sobre qué es calidad es presentada por la ISO en el siguiente párrafo:

”La calidad es la suma de todos aquellos aspectos o características de un producto o servicio que
influyen en su capacidad para satisfacer las necesidades, expresadas o implícitas” (ISO 8402).

Una definición sobre la calidad de los datos, es la siguiente:

Ün dato tiene calidad si satisface los requerimientos de uso propuestos. Le falta calidad hasta
el punto en el que no satisfaga los requerimientos. En otras palabras, la calidad de los datos
depende tanto del uso propuesto como del dato mismo. Para satisfacer el uso propuesto, el dato
debe ser exacto, puntual o a tiempo, relevante, completo, entendible y confiable"2 .

Los datos se vuelven más valiosos todo el tiempo, a medida que se encuentran nuevas formas de uso de la
información para hacer a la organización más exitosa.
La calidad de los datos es medida con respecto a número de dimensiones: exactitud, relevancia, puntualidad,
completitud, entendible y confiabilidad. La dimensión de la exactitud o la precisión es la medida base de la
calidad de los datos. Si los datos no están bien, las otras dimensiones tienen poca importancia3 .
La culpa por la baja calidad de los datos por lo general recae sobre el área de TI.
Sin embargo, los datos son creados por personas fuera de TI y son utilizados por personas fuera de TI. El
área de TI es responsable por la calidad de los sistemas que almacenan y mueven los datos. La mayoría de
los problemas se encuentran fuera de TI. Algunos de problemas son:

Requerimientos de baja calidad.

Pruebas de aceptación del sistema de baja calidad.

Procesos de creación de datos de baja calidad.

Hay otros dos factores de gran importancia que afectan la calidad de los datos, que no se encuentran dentro
de las organizaciones, pero que forman parte de la evolución natural de la tecnología:

1. Las rápidas implementaciones y cambios de sistemas hace muy difícil controlar la calidad.

2. Los métodos, estándares, técnicas y herramientas para controlar la calidad.

han evolucionado a un paso más lento que los demás sistemas.

En general, se clasifica la fuente de datos de baja calidad o con problemas en cuatro áreas, que son:
2 "Data Quality. The Accuracy Dimension"– Jack E. Olson. Morgan Kaufmann Publishers. 2003. Pág. 24.
3 "Data Quality. The Accuracy Dimension"– Jack E. Olson. Morgan Kaufmann Publishers. 2003. Pág. 17
 Ingreso inicial de los datos al sistema.
Corrupción de los datos.
Movimiento y Re-estructuración de los datos.
La utilización de los datos.
La Figura 14.1, ver [53], muestra esas cuatro áreas y las formas en que pueden ocurrir los problemas.

Figura 14.1: Traducción de las Áreas donde se generan datos incorrectos.

14.7. Pruebas
Estas pruebas son conocidas como Pruebas de Bases de Datos para la Migración y la Validación de los Datos.
En la actualidad, las técnicas y/o metodologías para realizar estas pruebas no son muy conocidas, y para su
efecto son poco usadas. Las pruebas que se realizan en la actualidad en este tipo de implementaciones son
en su mayoría pruebas de desarrollo, tales como:
¿Se está trasladando la información completa? ¿Se crearon la misma cantidad de registros en el sistema
nuevo que en el actual?
¿Se está almacenando correctamente?
Entre otras, pero aparte de eso, las pruebas son mínimas.
la falta de metodologías estándares o procedimientos de prueba estándares para la migración y validación de
datos, aunque están presentes, su estructuración y diseño, aún no están al nivel de las demás metodologías
de pruebas de software.
Algunos de esos problemas son los siguientes4 :
Pérdida de datos.
Corrupción de datos.
Pobre calidad de datos.
Periodos extendidos de tiempos de inactividad de los sistemas involucrados.
Pérdida de negocio y clientes por la inactividad de los sistemas.
Sobrecosto para arreglar problemas post-migración.
4 ”The Hidden Cost of Data Migration” by Softek – 2006.
14.7.1. ¿Qué son pruebas de software?
”Una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente
especificadas, los resultados se observan y registran, y se realiza una evaluación de algún aspecto”.
(Software testing, prueba de software). Es el proceso empleado para identificar la correctitud, completitud,
seguridad y calidad en el desarrollo de un software para computadoras.
El proceso de testing es una investigación técnica que intenta revelar información de calidad acerca del
producto de software con respecto al contexto en donde operará.

14.7.2. Tipo de pruebas

14.7.2.1. Pruebas de unidad
La prueba de unidad se plantea a pequeña escala, y consiste en ir probando uno a uno los diferentes módulos
que constituyen una aplicación.
Normalmente se realiza una fase informal antes de entrar en la fase de pruebas.
La fase informal la lleva a cabo el propio desarrollador y consiste en ir ejecutando el código para convencerse
de que "básicamente, funciona". Esta fase suele consistir en pequeños ejemplos que se intentan ejecutar. Si
el módulo falla, se suele utilizar un depurador para observar la evolución dinámica del sistema, localizar el
fallo, y repararlo.
Después de realizar esto, cuando el módulo parece presentable, se entra en una fase de prueba sistemática.
En esta etapa se buscan fallos siguiendo algún criterio. Los criterios más utilizados son los denominados de
caja negra y caja blanca.
Una prueba es de caja negra cuando se descartan los detalles del código y se limita a lo que se ve desde el
exterior. Lo que se pretende es descubrir casos en los que el módulo no hace lo que se espera de él.
Una prueba de caja blanca es cuando se mira detenidamente el código que está escrito y se intenta determinar
en que punto del código se presenta la falla.

14.7.2.2. Pruebas de integración

Las pruebas de integración se llevan a cabo durante la construcción del sistema, involucran a un número
creciente de módulos y terminan probando el sistema como conjunto.
Estas pruebas se pueden plantear desde un punto de vista estructural o funcional. Las pruebas estructurales
de integración son similares a las pruebas de caja blanca, pero en lugar de referirse a sentencias del lenguaje,
se refiere a llamadas entre módulos. Se trata pues de identificar todos los posibles esquemas de llamadas y
ejercitarlos para lograr una buena cobertura de segmentos o de ramas.
Las pruebas funcionales de integración son similares a las pruebas de caja negra.
En esta se trata de encontrar fallos en la respuesta del módulo, cuando su operación depende de otros módu-
los. Así se va realizando una prueba a todo el sistema, según las especificaciones del usuario; estas también
se realizan con el manual de usuario.

14.7.2.3. Pruebas de aceptación

Las pruebas de aceptación son las que se plantea el cliente final, que decide qué pruebas va a aplicarle al
producto antes de darlo por bueno y pagarlo. El objetivo de quien prueba es encontrar los fallos lo antes
posible, en todo caso antes de pagarlo y antes de colocar el programa en producción.
Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación
de requisitos y del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues sería impre-
sentable de cara al cliente, sino una vez pasadas todas las pruebas de integración por parte del desarrollador.

14.7.2.4. Otros tipos de pruebas

Recorridos (walkthroughs): Es una técnica más aplicada en control de calidad que en pruebas, y con-
siste en sentar al lado de los desarrolladores una serie de críticos y estos leen el programa línea por
línea y piden explicaciones de todo. Entonces puede suceder que simplemente falta un comentario, o
que se detecte un error o que el código es muy complejo de entender.

Aleatorias (random testing): Estas se aplican porque muchos autores consideran que la probabilidad de
encontrar un error es igual que si se realizan pruebas aleatorias. Por esta razón comienzan las pruebas
con una serie de casos elegidos al azar. Esto mostrará los errores más evidentes. Pero esta prueba no
es suficiente.

Solidez (Robustness testing): En esta se prueba la capacidad del sistema para salir de situaciones pro-
vocadas por errores en el suministro de datos. Estas pruebas son importantes en sistemas con interfaz
al exterior.

Stress (Stress testing): En ciertos sistemas es muy conveniente realizar esta prueba para saber hasta
dónde son resistentes, es decir cuántos datos podría procesar, cuánta carga procesa la cpu.

Desempeño (Performance testing): Esta prueba sirve para saber el tiempo de respuesta, para saber
cuánto tiempo tarda el sistema en procesar un determinado número de datos, cuánta memoria necesita
para esto, cuánto disco duro.

14.7.3. ¿Qué es validación de datos?

En seguridad informática, la validación de datos es una de las áreas más importantes a tener en cuenta,
especialmente en el desarrollo de sistemas conectados a redes como Internet. Validar datos hace referencia a
verificar, controlar o filtrar cada una de las entradas de datos que provienen desde el exterior del sistema.
Es un proceso que asegura que un programa opere sobre datos limpios, correctos y útiles. Emplea rutinas,
frecuentemente conocidas como reglas de validación, que verifican la exactitud y la significancia del dato en
el sistema.
Algunos de los métodos más utilizados para realizar validaciones son:

1. Verificaciones de formato o imagen: Verifica que el dato esté en un formato específico.

2. Verificaciones del tipo de dato: Verifica el tipo de dato ingresado con respecto al esperado y presenta
mensajes de error cuando no se cumple.

3. Verificaciones de rango: Verifica que el dato se encuentre entre un rango especificado de datos.

4. Verificaciones de límites: A diferencia de la verificación de rango, este solo compara con respecto a
un límite, superior o inferior.

5. Verificaciones de presencia (o de datos nulos): Verifica que datos de importancia no tengan valores en
blanco (o nulos).
 6. Verificaciones de consistencia: Verifica los campos dentro de la base de datos para asegurar que los
datos estén en sus campos correspondientes.

Entre las validaciones que realizaban, se encuentran:

Comparar los datos migrados con la fuente para verificar que se migró el número correcto de datos.

Verificar que cualquier transformación de los datos migrados haya ocurrido como fue planeado.

Verificar que las tablas/columnas hayan sido migradas a las tablas/columnas correctas en la base de
datos destino.

Verificar que el software en el sistema destino sea capaz de funcionar con los datos migrados.

Validar aplicaciones con usuarios claves.

Verificación del dominio.

14.8. Tipos de migración de datos

Un ejemplo de esa clasificación es la realizada por Oracle Corporation, que sugiere dos tipos de migraciones:

1. Migración de la base de datos: es un proceso de migración en el cual se lleva la información de la base

de datos de un proveedor distinto a Oracle al motor de base de datos Oracle.

2. Migración de la Base de Datos y de la Aplicación: migración de la base de datos de otro proveedor y

las sentencias de acceso a la base de datos de la aplicación a la plataforma de Oracle. Las aplicaciones
pueden contener información de conexión, sentencias SQL dinámicas y llamadas a procedimientos
almacenados que tendrían que ser modificados.

Pero de forma general, se identifican dos tipos de migración, dependiendo de su tiempo (de uso o ejecución):

1. Migración única: Es un proceso que se lleva a cabo una sola vez, sin importar la razón por la cual se
esté realizando como cambio de aplicación, de bases de datos, de hardware, etc.
Es un proceso que se realizará una vez dentro de la organización, sin incluir las pruebas del proceso
que se realizaron, previo a la migración del sistema de producción5 .

2. Migración continua: Son procedimientos que se realizan continuamente dentro de la organización.

Estas migraciones se presentan a través de interfaces entre sistemas que comunican información con-
tinuamente entre ellos o los procesos ETL (Extraer, Transformar y Cargar) utilizados para actualizar
los Data Warehouse.

En la clasificación de los tipos de migración, siempre existirán migraciones de un tipo de base de datos
a otro, es decir, puede ser una migración de una base de datos relacional a una base de datos orientado a
objetos, o a una base de datos geoespacial. Sin importar el tipo de base de datos del cual se está migrando al
cual se va a migrar, los principios para la migración y validación de los datos son los mismos, y las pruebas
siguen los mismos fundamentos y principios, pero durante el desarrollo del plan de migración como tal, la
implementación de cada uno de esos pasos varía, según las necesidades y características de la base de datos
respectiva.
5 ”Data migration. Database Programming & Design” - Moriarty, T. y Hellwege, S. 1998.
14.9. Metodología
Dentro de la comunidad de las metodologías ágiles, están proponiendo una metodología para la prueba de
bases de datos, alguno de los aspectos de importancia que se pueden resaltar de allí, son el uso de:
1. Database Sandboxes: Es una de las mejores prácticas, en esta prueba se realizan varias copias de
la base de datos y se realizan experimentos con dichas bases de datos, como implementar nuevas
funcionalidades, agregar un nuevo factor a una funcionalidad existente, valida los cambios para probar
el test. La ventaja de esta prueba es que ayuda a reducir el riesgo de errores técnicos.

2. Prueba de escritura de la base de datos: Este test se divide en tres procesos:

Setup de la prueba: Se debe poner la base de datos en un estado conocido antes de realizar la
prueba.
Correr la prueba: Usando la herramienta de regresión de bases de datos, se corre la prueba de
base de datos como se correría con una aplicación.
Verificar los resultados: Se necesitará hacer ”table dumps” para obtener los valores actuales en
la base de datos para que se puedan comparar contra los resultados esperados.

En la comunidad ágil, dentro de la propuesta para pruebas de bases de datos hacen la sugerencia de qué
probar dentro de una base de datos. La Figura 14.2, ver [54], ilustra la estructura y los niveles en los cuales
sugieren realizar las pruebas a la base de datos y algunas posibles pruebas que se podrían realizar.

Figura 14.2: Diagrama sobre qué probar en una base de datos.

Dentro de la metodología se identifican 6 fases, que son:

1. Definición.

2. Análisis.
 3. Diseño.

4. Migración.

5. Transición.

6. Producción.

Cada una de esas fases puede o no presentar algunas de las siguientes actividades:

Entrenamiento.

Evaluación del Sistema Existente.

Arquitectura técnica.

Migración de la Base de Datos.

Migración de la Aplicación.

Migración de los Datos.

Pruebas.

Transición.

Administración del Proyecto.

Durante la fase de pruebas, se llevan a cabo pruebas sobre la base de datos Oracle y la aplicación (si es
necesario) para asegurarse, que:

Los datos migrados estén completos y sean correctos.

Las aplicaciones funcionen de la misma forma que antes.

La base de datos está produciendo los mismos resultados que la base de datos anterior.

La base de datos Oracle y la aplicación cumplen con los requerimientos operacionales y de desempeño.
Ver figura 14.3, [55].

Figura 14.3: Traducción del Modelo V con Migración a Base de Datos.

Analice la siguiente tabla tomada de Softek [56].

 Tabla 14.1: Ejemplo de un plan de migración.
Actividad Asignado a Estado Fecha culminación
Establecer un equipo de gestión de mi-
gración.
Recolectar los horarios de disponibili-
dad y producción.
Documentar procedimientos de Con-
trol de Cambios para que puedan ser in-
corporados a los planes y procedimien-
tos de migración.
Documentar el cronograma para las ac-
tividades de cambio de hardware y de
migración de datos.
Anunciar la migración al menos 30 días
antes de la fecha programada para la
migración.
Recolectar información sobre el en-
torno de los servidores y las aplicacio-
nes (listas y diagramas).
Trabajar con el proveedor para enten-
der y conocer la nueva configuración.
Crear un equipo técnico de migración.
Seguridad: Informar a los equipos de
seguridad sobre la migración.
Programar una simulación de la migra-
ción que incluya a todos los miembros
en el equipo de migración y una mues-
tra de los datos, que le permita a los
dueños de las aplicaciones realizar pro-
cesos de verificación pre- y post- mi-
gración.
Seguir el proceso de control de cam-
bios requeridos.
Emplear una "Lista de Chequeo del
Plan de Migración"para asegurar que
todos los pasos pre-migración se lleven
a cabo.

Analice la siguiente tabla de Softek [57].

 Tabla 14.2: Adaptación de requerimientos de diseño.
Servidores
Fabricante
Número de Procesadores
Número de particiones lógicas
(LPARs) o Dominios
Tipo de Sistema de Archivos
Sistema Operativo
Direccionamiento del Sistema Operati-
vos
Base de Datos a ser movida
Versión de la base de datos
tamaño de la base de datos
Requerimientos de disponibilidad de la
base de datos
Cluster
Almacenamiento
Proveedor y modelo
Tipos de Canales
Mapeo lógico a físico
Número de fuentes de las cuales se mi-
grará
Destinos de la migración
Red (si aplica)
Topología
Velocidad de la red
Bases de Datos
Fuentes
Destino
Número de objetos en la fuente
Tipos de objetos
Volumen de datos

14.10. Implementación
Debido a que estas dos fases son casi inseparables y se pueden trabajar en conjunto, fueron combinados en
una sola fase. Las pruebas se dividen en dos áreas centrales:

1. Errores Físicos: son sintácticos de naturaleza y pueden ser fácilmente identificados y resueltos. Los
errores físicos no guardan relación con la calidad del mapeo de los datos. Este nivel de pruebas está
tratando con las semánticas del lenguaje empleado para la transformación.

2. Errores Lógicos: Durante la implementación es cuando se identifican los errores lógicos. El primer
paso es ejecutar el mapeo. Aunque el mapeo se complete exitosamente, aún se deberían realizar las
siguientes preguntas.

¿Cuántos registros esperaban ser creados por el script?

¿Se creó el número correcto de registros? Sí no, ¿por qué?
 ¿Se han cargado los datos a los campos correctos?
¿Se han formateado los datos correctamente?

La verdadera prueba a los datos mapeados o migrados es darle acceso a los datos a los usuarios que
participaron en el análisis y diseño del sistema principal. Comenzarán a identificar elementos que
debieron ser migrados pero que no fueron identificados durante las sesiones de análisis y diseño.
La fase de Pruebas/Implementación debe ser alcanzada lo antes posible para garantizar que se lleve
a cabo antes de las fases de diseño y construcción del proyecto principal, para evitar sobrecosto por
cambios en el diseño del proyecto principal, debido a que los requerimientos para la migración de los
datos han seguido cambiando.

14.11. Auditor y estos delitos

La ley ha denominado al grupo que emplea la tecnología informática para delinquir como ”delitos informáti-
cos, criminalidad mediante computadoras, delincuencia informática, criminalidad informática”, entre otros.
Es necesario establecer el papel que tendrá auditor informático en relación con los delitos informáticos en la
empresa; el auditor que investigará este tipo de delito desde cualquier perspectiva se enfrentará a una tarea
compleja.

Conceptualización de los delitos informáticos

Fraude puede ser definido como engaño, acción contraria a la verdad o a la rectitud. La definición de
delito puede ser más compleja.
Los elementos integrantes del delito son:

• El delito es un acto humano, es una acción (u omisión).

• Dicho acto humano es antijurídico, lesiona o pone en peligro un interés jurídicamente protegido.
• Debe corresponder a un tipo legal (figura de delito), definido legalmente, ha de ser un acto típico.
• El acto de ser culpable, imputable a dolo (intención) o a culpa (negligencia), y una acción es
imputable cuando puede ponerse a cargo de una determinada persona.
• La ejecución u omisión del acto debe estar sancionada por una pena.

Por tanto, un delito es una acción ilegal realizada por una persona; el cual es tipificado y, si resulta culpable,
es sancionada por una pena.
El delito informático se define como toda acción (u omisión) culpable realizada por un ser humano, que
cause un perjuicio a personas sin que necesariamente se beneficie el autor o que, por el contrario, produzca
un beneficio ilícito a su autor aunque no perjudique de forma directa o indirecta a la víctima, tipificado por
La Ley, que se realiza en el entorno informático y que está sancionado con una pena.
De esta manera, los delitos informáticos son ”actitudes ilícitas que tienen a las computadoras como instru-
mento o fin (concepto atípico) o las conductas típicas, ilegales y culpables que tienen a las computadoras co-
mo instrumento o fin (concepto típico)”. Otros autores sostienen que los delitos informáticos son ”cualquier
comportamiento criminal en que la computadora está involucrada como material, objeto o mero símbolo”.
En este sentido, la informática es el objeto del ataque o el medio para cometer delitos.
La informática tiene características que la convierten en un medio idóneo para la comisión de distintas moda-
lidades delictivas, en especial de carácter patrimonial (estafas, apropiaciones indebidas, etc.). La idoneidad
proviene, básicamente, de la gran cantidad de datos que se acumulan, con la consiguiente facilidad de acceso
a ellos y la relativamente fácil manipulación de esos datos.

14.12. Características de este tipo de delitos

Son conductas criminales de cuello blanco6 , que sólo un determinado número de personas con ciertos
conocimientos y medios (técnicos) puede llegar a cometerlas.

Son acciones ocupacionales, en cuanto a que muchas veces se realizan cuando el sujeto se halla traba-
jando.

Son acciones de oportunidad, se aprovecha una ocasión creada o intensificada en el mundo de funcio-
nes y organizaciones del sistema tecnológico y económico.

Provocan serias pérdidas económicas, que casi siempre producen ”beneficios” económicos a aquellos
que las realizan.

Ofrecen posibilidades de tiempo y espacio, ya que en milésimas de segundo y sin una necesaria pre-
sencia física llegan a consumarse.

Son muchos los casos y pocas las denuncias, y todo ello debido a la misma falta de regulación por
parte del Derecho.

Son sofisticados y relativamente frecuentes en el ámbito militar e industrial.

Presentan grandes dificultades para su comprobación, esto por su mismo carácter técnico.

Tienden a proliferar cada vez más, por lo que requieren una urgente regulación. Por el momento siguen
siendo ilícitos impunes de manera manifiesta ante la ley.

14.13. Tipificar los delitos de acuerdo a sus características principales

Estos son:

Sabotaje informático.
Este término comprende aquellas conductas dirigidas a causar daños en el hardware o en el software
de un sistema. Los métodos utilizados para ello son de índole muy variada y han evolucionando ha-
cia técnicas cada vez más sofisticadas y de difícil detección. Básicamente, se diferencian dos grupos
de casos: por un lado, las conductas dirigidas a causar destrozos físicos y, por el otro, los métodos
dirigidos a causar daños lógicos.

Conductas dirigidas a causar daños físicos.

El primer grupo comprende todo tipo de conductas destinadas a la destrucción ”física” del hardware y
el software de un sistema (como causar incendios o explosiones, introducir piezas de aluminio dentro
de la computadora para producir cortocircuitos, derramar café o agentes cáusticos en los equipos,
etc.). En general, estas conductas son analizadas, desde el punto de vista jurídico, en forma similar a
la destrucción física de objetos previstos típicamente en el delito de daño.
6 Personaje sin rostro, de difícil o nula forma de identificación, que NO está presente en el hecho delictivo.
 Conductas dirigidas a causar daños lógicos.
El segundo grupo, relacionado con la técnica informática, se refiere a las conductas que causan des-
trozos ”lógicos”, o sea aquellos que producen la destrucción, ocultación, o alteración de datos y pro-
gramas contenidos en un sistema informático.
Este tipo de daño a un sistema se logra de diversas formas. Desde la más simple como desconectar
el computador de la electricidad mientras opera o el borrado de documentos o datos de un archivo,
hasta la utilización de los más complejos programas lógicos destructivos (crash programs) que pueden
destruir gran cantidad de datos en un tiempo mínimo.
Estos programas destructivos, utilizan distintas técnicas de sabotaje, inclusive en forma combinada.
Sin pretender realizar una clasificación rigurosa de estos métodos de destrucción lógica, se distinguen:
Bombas lógicas (time bombs): la actividad destructiva del programa comienza tras un plazo, sea por
el mero transcurso del tiempo (como días, semanas, meses o en una fecha o a una hora determinada),
o por la aparición una señal (que puede o no aparecer), como la presencia de un dato, de un código,
o cualquier mandato que, de acuerdo a lo determinado por el programador, es identificado por el pro-
grama como la señal para empezar a actuar.
Otra modalidad que actúa sobre los programas de aplicación es el llamado ”cáncer de rutinas” (”cancer
routine”). En esta técnica los programas destructivos tienen la particularidad de que se reproducen, por
sí mismos, en otros programas, arbitrariamente escogidos. Una variante perfeccionada de la anterior
modalidad es el ”virus informático” que es un programa capaz de multiplicarse por sí mismo y conta-
minar los otros programas que se hallan en el mismo disco rígido donde fue instalado y en los datos y
programas contenidos en los distintos discos con los que toma contacto a través de una conexión.

14.14. Fraude a través de computadoras

Consisten en la manipulación ilícita, por la creación de datos falsos o su alteración y/o procesos contenidos
en sistemas informáticos, para obtener ganancias ilícitas.
Los distintos métodos para estos fraudes se deducen de la forma de trabajo del sistema informático: en pri-
mer lugar, es posible alterar, omitir o introducir datos falsos, en un computador. Esta forma se conoce como
manipulación del input.
En segundo lugar, interferir en el procesamiento de la información, alterando el programa en el computador o
su secuencia lógica alojado. Esta modalidad puede ser cometida tanto al modificar los programas originales,
como al adicionar programas especiales que introduce el autor.
A diferencia de las manipulaciones del input que pueden ser realizadas por personas sin conocimientos espe-
ciales de informática, esta modalidad es más específicamente informática y requiere conocimientos técnicos
especiales.
Investigar el impacto de éstos actos en la vida social y tecnológica de la sociedad.
Analizar las consideraciones oportunas en el tratamiento de los delitos informáticos.
Mencionar las empresas que operan con mayor riesgo de ser víctimas de ésta clase de actos
Analizar la legislatura que enmarca a ésta clase de Delitos, desde un contexto Nacional e Internacional.
Definir el rol del auditor ante los delitos informáticos.
Presentar los indicadores estadísticos referentes a éstos actos delictivos.
14.15. Papel del auditor
Las preguntas de mayor importancia, de cierta forma, son:

¿Durante el proceso/metodología de Migración y Validación de Datos incluye o realiza pruebas (crea

planes de prueba para la migración y validación de datos)?

Si realizaban pruebas, se les preguntaba que tipos de pruebas y las razones por las cuales eran realiza-
das. ¿Hay un plan de Calidad de Datos para verificar los datos migrados? ¿Qué tipo de herramientas
son utilizadas para los procesos de Migración y Validación de Datos? ¿Las herramientas realizan o
permiten realizar pruebas?
 Bibliografía

[1] AUDITORÍA - M ONOGRAFIAS . COM, https://www.monografias.com/trabajos17/auditoria/auditoria.shtml

(accedido sep. 18, 2020).
[2] AUDITORÍA PARA EMPRESAS . T E EXPLICAMOS LO MAS BÁSICO | F IMAX,
https://www.fimax.es/sirve-una-auditoria-empresa/ (accedido sep. 18, 2020).
[3] E L DEBER SER DE LA AUDITORÍA, http://www.scielo.org.co/scielo.php?script=sci’_arttext&pid=S0123-
59232006000100004 (accedido sep. 18, 2020).
[4] I NFORME DE AUDITORÍA - Q UÉ ES , DEFINICIÓN Y CONCEPTO | E CONOMIPEDIA,
https://economipedia.com/definiciones/informe-de-auditoria.html (accedido sep. 18, 2020).
[5] I NFORME DE AUDITORÍA - Q UÉ ES , DEFINICIÓN Y CONCEPTO | E CONOMIPEDIA,
https://economipedia.com/definiciones/informe-de-auditoria.html (accedido sep. 18, 2020).
[6] L A AUDITORÍA SE DEFINE COMO UN PROCESO SISTEMÁTICO DE OBTENER Y EVALUAR,
https://www.eumed.net/ce/2016/3/auditoria.html (accedido sep. 18, 2020).
[7] E. E. DE E XCELENCIA , «Q UÉ ES AUDITAR SEGÚN ISO 19011, Escuela Europea de Excelencia,
abr. 17, 2019. https://www.escuelaeuropeaexcelencia.com/2019/04/que-es-auditar-segun-iso-19011/
(accedido sep. 18, 2020).
[8] S. H ERNÁNDEZ C ASTAÑEDA, Sobre la economía matemática: algunas reflexiones generales», Eco-
nomía Informa, vol. 388, pp. 7-21, sep. 2014, doi: 10.1016/S0185-0849(14)71347-7.
[9] WWW. ISO . ORG 2019, obp. ISO 19011:2019(es), Directrices para la auditoría de los ...
[10] N ORMAS DE AUDITORIA G ENERALES ACEPTADAS NAGA N ORMA T ÉCNICA C OLOMBIANA
ISO 19011:2002 N ORMA T ÉCNICA DE C ALIDAD NTC GP 1000:2009 MECI 1000:2005:,
https://docplayer.es/17039646-Normas-de-auditoria-generales-aceptadas-naga-norma-tecnica-
colombiana-iso-19011-2002-norma-tecnica-de-calidad-ntc-gp-1000-2009-meci-1000-2005.html
(accedido sep. 18, 2020).
[11] A LVIN , A. A. Y JAMES K. L OEBBECKE ., Auditing: An Integrated Approach. 2a. ed. N.J.: Prentice
Hall, 1980. 3 p..

175
[12] S OY AUMATELL , C RISTINA ., Auditoría de la Información. Barcelona, Editorial UOC, 2003. p. 20..

[13] S LOSSE , C ARLOS ET AL ., Auditoría un nuevo enfoque empresarial. 2da ed. Buenos Aires:Ed. Machi.
1999. 790 p..

[14] A RENS , A LVIN A. & ; L OEBBECKE , JAMES K., Auditoría: Un enfoque integral. México: Prentice-
Hall, 1996.

[15] C ONSEJO M EXICANO PARA LA I NVESTIGACIÓN Y D ESARROLLO DE N ORMAS DE I NFORMACIÓN

F INANCIERA (CINIF) E I NSTITUTO M EXICANO DE C ONTADORES P ÚBLICOS (IMCP). (2009),
Normas de información financiera. (28a ed.) México: CNINIF / IMCP..

[16] E CHENIQUE G ARCÍA , J OSÉ A NTONIO . (2001), Auditoría en informática. (2a ed.) México: McGraw
Hill.

[17] H ERNÁNDEZ H ERNÁNDEZ , E NRIQUE . (2002), Auditoría en informática. (2a ed.) México: CECSA.
Instituto Mexicano de Contadores Públicos. (2008), Normas y procedimientos de auditoría y Normas
para atestiguar versión estudiantil. (28a ed.) México: IMCP..

[18] M UÑOZ R AZO , C ARLOS . (2002), Auditoría en sistemas computacionales, México, Pearson Educa-
ción..

[19] T ÉLLEZ T REJO , B ENJAMÍN ROLANDO . (2004), Auditoría: un enfoque práctico. México: Cengange..

[20] P IATTINI V ELTHUIS , M ARIO G., P ESO NAVARRO , E MILIO DEL . (1997), Auditoría Informática: un
enfoque práctico. Madrid: Ra-Ma..

[21] H ISTORIA DE ISACA , http://www.isaca.org/About- ISACA/History/Espanol/Pages/default.aspx

[22] M ONTES A BIGAÍN .(2012) , La Metodología de la auditoría. Disponible en

http://www.uaeh.edu.mx/docencia/P_Presentaciones/tizayuca/gestion_tecnologica/Auditorias %20Tecnologicas.pdf.
Consultado el 12 de mayo de 2013.

[23] F INCOWSKY. F RANKLIN Y E NRIQUE B ENJAMÍN . (2007) , Au-

ditoría administrativa. 2da edición. México: Pearson Educación.
http://books.google.co.ve/books?id=Cg7So8EZjlIC&printsec=frontcover&hl=es#v=onepage&q&f=false..

[24] S TEVENSON , N ICK . 2003. , Cultural citizenship. Cultural citizenship y Cosmopolitan and multicul-
tural citizenship: world, nation, city and self. Maidenhead: Open University.

[25] C OMISIÓN NACIONAL BANCARIA Y DE VALORES (CNBV) 2012 , “Disposiciones de Carácter

General Aplicables a Instituciones de Crédito, Artículo 310”, México

[26] E NCICLOPEDIA DE LA AUDITORÍA . 2001 , Océano Grupo Editorial, Barcelona, España

[27] G ÓMEZ M ORALES , Á, S. , Auditoría operativa: una auditoría con valor agregado o para la calidad
total . [en línea].Chile. Facultad de Economía UCN Disponible en: <www.sanpedro.ucn.cl>.

[28] C ORNELLA , A., ”La información alimenta y ahoga. Información si, pero, ¿en qué condiciones?”
<http://www.infonomia.com/extranet/index.asp?idm=1&idrev=1&num=445>.

[29] B UCHANAN , S. J., ”The Information audit: an integrated strategic approach”.

<http://www.strath.ac.uk/Departments/InfoStrategy/>
[30] A SLIB I NFORMATION R ESOURCES M ANAGEMENT N ETWORK .,
http://www.aslib.co.uk/info/subjectsinfoaud.htm

[31] ACHA I TURMENDI , J. J OSÉ . (1994), Auditoría Informática en la empresa.

[32] ISACF. (1998), Objetivos de Control para la Información y Tecnología Relacionada. COBIT-ISACF.

[33] ISACA (2002), Normas Generales del Estándar de la ISACA. ISACA

[34] MAGERIT: GUÍA DE (2001), Ministerio de Administraciones Públicas. procedimientos. MAP y

BOE

[35] PATTINI M . Y NAVARRO E. DEL P ESO . (2001), Auditoría informática. Un enfoque práctico (2a
Edición). RA-MA, México

[36] W EBER R. (1999), Information systems control and audit. New Jersey: Prentice Hall, USA.

[37] A LONSO TAMAYO Á LZATE , (1999), ”Auditoría de Sistemas – Una visión práctica”

[38] J ORGE D OMÍNGUEZ C HÁVEZ , (2015), SEGURIDAD INFORMÁTICA PERSONAL Y CORPORATI-

VA (Segunda Parte), IEASS Editores, Venezuela

[39] J ORGE D OMÍNGUEZ C HÁVEZ , (2015), SEGURIDAD INFORMÁTICA PERSONAL Y CORPORATI-

VA (Primera Parte), IEASS Editores, Venezuela

[40] UNESCO, (2012), Directrices para la preservación del Patrimonio digital | Or-
ganización de las Naciones Unidas para la Educación, la Ciencia y la Cultura,
http://www.unesco.org/new/es/communication-and- information/resources/publications- and-
communication-materials/publications/full-list/guidelines-for-the-preservation-of-digital- heritage/.

[41] K ATA YOSHI (2013), Auditoría Forense Informática, Recuperado de: https://prezi.com/sb1iqve-
gece/auditoria-forense-informatica/

[42] C ANO , J EIMY, Introducción a la Informática Forense. Una disciplina técnico-legal, Retrieved from:
http://52.0.140.184/typo43/fileadmin/Revista_96/dos.pdf

[43] V ILLACIS RUIZ , V IVIANA M ARCELA (2006), Auditoria Forense.. Retrieved from:
https://es.scribd.com/doc/80973125/TESIS-Auditoria-Forense

[44] B RUNGS , A Y JAMIESON , R. (2003), Legal issues for computer forensics Proceedings for 14th
Australian Conference on Information Systems. Perth, Western Australia. November. Retrieved from:
http://52.0.140.184/typo43/fileadmin/Revista_96/dos.pdf

[45] INTERPOL, Los fenómenos delictivos están cambiando. Disponible en internet:

<URL:http://www.interpol.int/es/Acerca-de-INTERPOL/El-Complejo-Mundial- de-INTERPOL-
para-la-Innovaci %C3 %B3n>

[46] NUMPAQUE FRANCO, E DGAR A LEXANDER, Informática Forense En Colombia. Disponible en

internet: <URL: http://glaxeanf.com/lecturas-de-interes/seguridad-informatica
[47] L ARROTA A RDILA , L S., M ARTINEZ Z ABALA J. M., O RJUELA L ÓPEZ , V. F. (2014), Diseño de
una guía para la auditoría de análisis forense en dispositivos moviles basados en tecnología An-
droid para legislación colombiana, Tesis de especialización en auditoría de sistemas de información,
Facultad de Ingenieria, Universidad Católica de Colombia

[48] M ORENO C EVALLOS , J. R., & D UEÑAS H OLGUÍN , B. L. (2018), Sistemas de información
empresarial: la información como recurso estratégico. Dominio de las Ciencias, IV(1), 141-154.
https://dialnet.unirioja.es/servlet/articulo?codigo=6255073

[49] C ASTILLO P ÉREZ , A. A. (2015), Importancia de la calidad de la información de los sistemas infor-
máticos contables en las empresas del Perú, 2011-2013. In Crescendo. Ciencias Contables y Adminis-
trativas., II(2), 123-141. https://es.scribd.com/document/310295004/SISTEMAS-INFORMATICOS-
CONTABLES

[50] M ORA Q UIRÓS , E. (2017), Auditoría Informática. Instituto de Auditores Internos Costa Rica, 2215-
3004. https://www.iaicr.com/boletin/2017/articulos/26_ensayo_edna_mora.pdf

[51] LUQUE RUIZ, IRENE; GÓMEZ, MIGUEL ÁNGEL; LÓPEZ ESPINOSA, ENRIQUE; CE-
RRUELA GARCÍA, GONZALO (2002), ”Bases de datos desde Chen hasta Codd con ORACLE”.
Alfaomega Grupo Editor, Primera Edición. México

[52] J IM U TSLER (2006), .Avoiding Data-Migration Pitfalls"por . IBM systems Magazine, Julio/Agosto

[53] JACK E. O LSON (2006), "Data Quality. The Accuracy Dimension". Morgan Kaufmann Publishers.
Página 43.

[54] S COTT W. A MBLER, Sitio Web de la Comunidad Ágil http://www.agiledata.org/essays/databaseTesting.html

[55] O RACLE C ORPORATION, SQL Developer User Guide

[56] S OFTEK (2006), ”Best Practices for Data Migration”. Pág. 6.

[57] S OFTEK (2006), ”Best Practices for Data Migration”. Pág. 7.

[58] J ON W ILLIAM T OIGO . (2005), "Data Migration Headaches Underscored by Softek Survey". –
http://www.esj.com/news/article.aspx?EditorialsID=1266.
 Cuestionario Auditoría TI

El cuestionario comprende cuatro bloques temáticos, uno por cada área objeto de estudio. El primer bloque
corresponde al área de planificación y tiene como objetivo sondear la planeación que se realizó para formar
el área de sistemas. El segundo bloque es el correspondiente a los dispositivos de almacenamiento y tiene
como objetivo evaluar la administración, la aplicación y el uso de dispositivos hardware de almacenamien-
to de información electrónico de la organización. El tercer bloque es el correspondiente al funcionamiento
del centro de cómputo y tiene como objetivo evaluar el correcto funcionamiento y la organización del cen-
tro de cómputo. El cuarto bloque es el correspondiente a la seguridad física y su objetivo es verificar las
instalaciones que utiliza el área de sistemas.

14.16. Área de planificación

1. Sistemas de información

a) ¿La dirección general y ejecutiva ha considerado la importancia que tiene el estudio del sistema
de información?
Si: No:
b) ¿Se establecen los requisitos de información a largo plazo?
Si: No:
c) ¿Se ha realizado una planificación estratégica del sistema de información para la Empresa?
Si: No:
d) ¿Existe una metodología para llevar a cabo tal planificación?
Si: No:
e) ¿Está definida la función del director del sistema de información?
Si: No:
f ) ¿Existe un plan estratégico del departamento de sistema de información?
Si: No:

2. Recursos humanos

179
 a) ¿Se estudia la evolución del mercado y la adaptación del personal a dicha evolución?
Si: No:
b) ¿Los informáticos reciben noticias del momento tecnológico por revistas, notas técnicas, etc.?
Si: No:
c) ¿Se recibe formación y se planifica ésta mediante asistencia a cursos, seminarios, etc.?
Si: No:

3. Otros aspectos

a) ¿Los cambios en los sistemas informáticos son consecuencia de la planificación más que de la
presión por necesidades operativas?
Si: No:
b) ¿Se solicitan demostraciones sobre los nuevos artículos a los proveedores?
Si: No:
c) ¿Existe algún estudio de planificación del posible efecto de las cargas normales de trabajo y los
picos sobre los requerimientos tanto de equipos como de software?
Si: No:
d) ¿La entidad dispone de un plan informático?
Si: No:
e) ¿Se están siguiendo las directrices marcadas por el plan?
Si: No:
f ) ¿El plan recoge todos los diferentes aspectos relacionados con la función informática?
Si: No:
g) ¿Cuál es la inversión requerida en servicios, desarrollo y consulta a los usuarios?
B.S.

14.17. Almacenamiento
El segundo cuestionario corresponde a los dispositivos de almacenamiento y tiene como objetivo evaluar la
administración, la aplicación y el uso de dispositivos, hardware, de almacenamiento de información electró-
nico de la organización.
Cuestionario de Auditoría correspondiente a los dispositivos de almacenamiento:

1. Los locales asignados a los servidores de datos tienen:

Aire acondicionado ( )
Protección contra el fuego ( )
Cerradura especial ( )
Otra:

2. ¿Tienen los servidores de datos protección automática contra el fuego?

Si: No: (Señalar de que tipo)No:
 3. ¿Qué información mínima contiene el inventario de los servidores de datos?
Número de serie o carrete ( )
Número o clave del usuario ( )
Número del archivo lógico ( )
Nombre del sistema que lo genera ( )
Fecha de expiración del archivo ( )
Número de volumen ( )
Otros:

4. ¿Verifican con frecuencia la validez de los inventarios de los archivos magnéticos?

Si: No:

5. ¿En caso de existir discrepancia entre las cintas o discos y su contenido, se resuelven y explican
satisfactoriamente las discrepancias?
Si: No:

6. ¿Se tienen procedimientos que permitan la reconstrucción de un archivo en cinta a disco, el cual fue
inadvertidamente destruido?
Si: No:

7. ¿Se tienen identificados los archivos con información confidencial y se cuenta con claves de acceso?
Si: No:

8. ¿Cómo se tienen identificados los archivos con información confidencial?

9. ¿Con que tipo de claves de acceso se cuenta?

10. ¿Existe un control estricto de las copias de estos archivos?

Si: No:

11. ¿Qué medio se utiliza para almacenarlos?

Mueble con cerradura ( )
Bóveda ( )
Otro (especifique):

12. Este almacén está situado:

En el mismo edificio del departamento ( )
En otro lugar ( )
¿Cuál?

13. ¿Se borran los archivos de los dispositivos de almacenamiento, cuando se desechan estos?
Si: No:
14. ¿Se certifica la destrucción o baja de los archivos defectuosos?
Si: No:

15. ¿Se registran como parte del inventario las nuevas cintas que recibe la biblioteca?
Si: No:

16. ¿Se tiene un responsable, por turno, de los servidores de datos?

Si: No:

17. ¿Se realizan auditorías periódicas a los medios de almacenamiento?

Si: No:

18. ¿Qué medidas se toman en el caso de extravío de algún dispositivo de almacenamiento?

19. ¿Se restringe el acceso a los lugares asignados para guardar los dispositivos de almacenamiento, al
personal autorizado?
Si: No:

20. ¿Se tiene relación del personal autorizado para firmar la salida de archivos confidenciales?
Si: No:

21. ¿Existe un procedimiento para registrar los archivos que se prestan y la fecha en que se devolverán?
Si: No:

22. ¿Se lleva control sobre los archivos prestados por la instalación?
Si: No:

23. En caso de préstamo ¿Con que información se documentan?

Nombre de la institución a quién se hace el préstamo. Fecha de recepción ( / / )
Fecha en que se debe devolver ( / / )
Archivos que contiene:
Formatos:
Cifras de control ( )
Código de grabación ( )
Nombre del responsable que los presto:
Otros:

24. Indique qué procedimiento se sigue en el reemplazo de las cintas que contienen los archivos maestros:

25. ¿Se conserva la cinta maestra anterior hasta después de la nueva cinta?
Si: No:

26. ¿La operación de reemplazo es controlada por el operador?

Si: No:
 27. En los procesos que manejan archivos en línea, ¿Existen procedimientos para recuperar los archivos?
Si: No:

28. ¿Estos procedimientos para recuperar los archivos los conocen los operadores?
Si: No:

29. ¿Con qué periodicidad se revisan estos procedimientos?

MENSUAL ( )
ANUAL ( )
SEMESTRAL ( )
OTRA ( ):

30. ¿Existe un responsable en caso de falla?

Si: No:

31. ¿Existe un procedimiento para el manejo de la información del cuarto frío?

Si: No:

32. ¿El procedimiento para el manejo de la información del cuarto frío lo conoce y aplica el operador?
Si: No:

33. ¿Se distribuyen en forma periódica entre los jefes de sistemas y programación informes de archivos
para que liberen los dispositivos de almacenamiento?
Si: No: ¿Con qué frecuencia?:

14.18. Centro de cómputo

El tercer cuestionario corresponde al funcionamiento del centro de cómputo y este cuestionario tiene como
objetivo evaluar el correcto funcionamiento, así como la organización del centro de cómputo, tomando en
cuenta los reglamentos del área. Así como también revisar que estos reglamentos tengan como objetivo
mantener el orden del centro de cómputo.
Cuestionario de Auditoría correspondiente al funcionamiento del centro de cómputo:

1. ¿El lugar donde se ubica el centro de cómputo está seguro de inundaciones, robo o cualquier otra
situación que ponga en peligro los equipos?
Si: No:

2. ¿El centro de cómputo da hacia el exterior?

Si: No:

3. ¿El material con que está construido el centro de cómputo es confiable?

Si: No:

4. ¿Dentro del centro de cómputo existen materiales inflamables o que causen daño a los equipos?
Si: No: ¿Cuál?:
 5. ¿Existe lugar suficiente para los equipos?
Si: No:

6. ¿Aparte del centro de cómputo se cuenta con algún lugar para almacenar otros equipos de cómputo,
muebles, suministros, etc.?
Si: No: ¿Dónde?:

7. ¿Se cuenta con una salida de emergencia?

Si: No:

8. ¿Existen señalamientos que hagan visibles las salidas de emergencia?

Si: No: ¿Dónde?:

9. ¿Es suficiente la iluminación del centro de cómputo?

Si: No: ¿Por qué?:

10. ¿La temperatura a la que trabajan los equipos es la adecuada de acuerdo a las normas bajo las cuales
se rige?
Si: No:

11. ¿Se dispone de aire acondicionado?

Si: No:

12. ¿La ubicación de los aires acondicionado es adecuada?

Si: No:

13. ¿Existe algún otro medio de ventilación aparte del aire acondicionado?
Si: No: ¿Cuál?:

14. ¿El aire acondicionado emite algún tipo de ruido?

Si: No:

15. ¿El cableado se encuentra correctamente instalado?

Si: No:

16. ¿Se cuenta con los planos de instalación eléctrica?

Si: No:

17. ¿La instalación eléctrica del equipo de cómputo es independiente de otras instalaciones?
Si: No:

18. ¿Los equipos cuentan con un regulador?

Si: No:

19. ¿Se cuenta con equipo interrumpible?

Si: No:

20. ¿Se tiene switch de apagado en caso de emergencia en algún lugar visible?
Si: No:
21. ¿Los cables están dentro de paneles y canales eléctricos?
Si: No:

22. ¿Los interruptores de energía están debidamente protegidos y sin obstáculos para alcanzarlos?
Si: No:

23. ¿Se cuenta con alarma contra incendios?

Si: No:

24. ¿Dónde se encuentran ubicadas las alarmas contra incendios?

25. ¿Se cuenta con alarmas contra inundaciones?

Si: No:

26. ¿Dónde se encuentran ubicadas las alarmas contra inundaciones?

27. ¿Existen extintores?

SI ( )
¿Cuántos?:
NO ( )
Tipos de extintores: Manual ( )
Automático ( )
No existen ( )

28. ¿Hay algún tipo de control de entradas y salidas de usuario?

Si: No:

29. ¿El usuario respeta el control de entradas y salidas de usuario?

Si: No:

30. ¿Con qué tipo de programas cuentan en los equipos de cómputo?

31. ¿Cuentan con manuales para cada programa que se maneja?

Si: No:

32. ¿El personal conoce el contenido de estos manuales para cada programa?
Si: No:

33. ¿Qué tipo de mantenimiento realizan sobre los programas?

A. Preventivo ( )
B. Correctivo ( )
 34. ¿Por qué razón realizan ese tipo de mantenimiento?

35. ¿Qué materiales utilizan para realizar el mantenimiento del hardware?

36. ¿Tienen un lugar específico para guardar el material de mantenimiento de hardware?

Si: No:

37. ¿Qué materiales utilizan para realizar el mantenimiento de software?

38. ¿Tienen un lugar específico para guardar el material de mantenimiento de software?

Si: No:

39. ¿Los usuarios tienen la suficiente confianza como para presentar su queja si fallan los equipos?
Si: No:

40. ¿Se efectúan controles o revisiones del buen estado de los equipos de cómputo?
Si: No:

41. ¿Las inspecciones son realizadas por personal especializado como técnicos o mecánicos electrónicos?
Si: No:

42. ¿Los datos de clientes y proveedores se salvaguardan por parte del sistema?
Si: No:

43. ¿Se implementan medidas de seguridad en los computadores de los empleados para evitar que estos
ejecuten programas peligrosos?
Si: No:

44. ¿Existe un programa de protección de la información contra virus, spyware y diferentes ataques ciber-
néticos?
Si: No:

45. ¿Se usan claves para acceder a las bases de datos?

Si: No:

46. ¿Todos los empleados pueden acceder a estas?

Si: No:

14.19. Seguridad física

El cuarto cuestionario corresponde a la seguridad física y verifica las instalaciones que utiliza el área de
sistemas, ya que de esto depende la continuidad de los servicios que presta el área a la organización, en
cuanto a necesidades de información.
Cuestionario de Auditoría correspondiente a la seguridad física:
 1. ¿Se han adoptado medidas de seguridad en el departamento de sistemas de información?
Si: No:

2. ¿Existen una persona responsable de la seguridad?

Si: No:

3. ¿Existe personal de vigilancia en la institución?

Si: No:

4. ¿La vigilancia se contrata?

Directamente ( )
Por medio de empresas que venden ese servicio ( )

5. ¿Existe una clara definición de funciones entre los puestos clave?

Si: No:

6. ¿Se investiga a los vigilantes cuando son contratados directamente?

Si: No:

7. ¿Se controla el trabajo fuera de horario?

Si: No:

8. ¿Se registran las acciones de los operadores para evitar que realicen algunas pruebas que puedan dañar
los sistemas?
Si: No:

9. ¿Existe vigilancia en el departamento de cómputo las 24 horas?

Si: No:

10. ¿Existe vigilancia a la entrada del departamento de cómputo las 24 horas?

Vigilante ( )
Recepcionista ( )
Tarjeta de control de acceso ( )
Nadie ( )

11. ¿Se permite el acceso a los archivos y programas a los programadores, analistas y operadores?
Si: No:

12. ¿Se ha instruido a estas personas sobre qué medidas tomar en caso de que alguien pretenda entrar sin
autorización?
Si: No:

13. El edificio donde se encuentra la computadora está situado a salvo de:

Inundación ( )
Terremoto ( )
Fuego ( )
 Sabotaje ( )
Nada ( )

14. Describa brevemente la construcción del centro de cómputo, de preferencia proporcionando planos y
material con que construirlo y equipo (muebles,sillas, etc.) dentro del centro.

15. ¿Existe control en el acceso a este cuarto?

Por identificación personal ( )
Por tarjeta magnética ( )
Por claves verbales ( )
Otras ( )

16. ¿Son controladas las visitas y demostraciones en el centro de cómputo?

Si: No:

17. ¿Se registra el acceso al departamento de cómputo de personas ajenas a la dirección de informática?
Si: No:

18. Existe alarma en las instalaciones para:

Detectar fuego (calor o humo) de forma automática ( )
Avisar en forma manual la presencia del fuego ( )
Detectar una fuga de agua ( )
Detectar magnéticos ( )
No existe ( )

19. Estas alarmas están:

En el departamento de cómputo ( )
En el cuarto frío ( )
No están ( )
Otros:

20. ¿Existe alarma para detectar condiciones anormales del ambiente?

En el departamento de cómputo ( )
En el cuarto frío ( )
En otros lados:

21. ¿La alarma es perfectamente audible?

Si: No:

22. La alarma está conectada:

 Al puesto de guardias ( )
A la estación de bomberos ( )
A ningún otro lado ( )
Otros:

23. ¿Existen extintores de fuego?

Manuales ( )
Automáticos ( )
No existen ( )

24. ¿Se ha adiestrado el personal en el manejo de los extintores?

Si: No:

25. Los extintores, manuales o automáticos a base de Agua ( )

Gas ( )
Otros ( )

26. ¿Se revisa de acuerdo con el proveedor el funcionamiento de los extintores?

Si: No:

27. ¿Existen extintores automáticos activados por detectores de fuego?

Si: No:

28. Si los extintores automáticos son a base de agua, ¿se han tomado medidas para evitar que el agua cause
más daño que el fuego?
Si: No:

29. ¿Si los extintores automáticos son a base de gas?, ¿se ha tomado medidas para evitar que el gas cause
más daño que el fuego?
Si: No:

30. Existe un lapso de tiempo suficiente, antes de que funcionen los extintores automáticos para que el
personal:
¿Corte la acción de los extintores por tratarse de falsas alarmas?
Si: No:
¿corte la energía eléctrica?
Si: No:
¿abandone el local sin peligro de intoxicación?
Si: No:
¿Es inmediata su acción?
Si: No:

31. ¿Los interruptores de energía están debidamente protegidos, etiquetados y sin obstáculos para alcan-
zarlos?
Si: No:
32. ¿Existe salida de emergencia?
Si: No:

33. Esta puerta es posible abrirla: ¿Desde el interior? ( )

¿Desde el exterior? ( )
Ambos lados ( )

34. ¿Se revisa frecuentemente que no esté abierta o descompuesta la cerradura de esta puerta y de las
ventanas, si es que existen?
Si: No:

35. ¿Se ha adiestrado al personal en la forma en que se deben desalojar las instalaciones en caso de
emergencia?
Si: No:

36. Se ha tomado medidas para minimizar la posibilidad de fuego:

Evitando artículos inflamables en el departamento de cómputo ( )
Prohibiendo fumar a los operadores en el interior ( )
Vigilando y manteniendo el sistema eléctrico ( )
No se ha previsto ( )

37. ¿Se ha prohibido a los operadores el consumo de alimentos y bebidas en el interior del departamento
de cómputo para evitar daños al equipo?
Si: No:

38. ¿Se cuenta con copias de los archivos en lugar distinto al de la computadora?
Si: No:

39. ¿Cuándo se efectúan modificaciones a los programas, a iniciativa de quién es?

Usuario ( )
Director de informática ( )
Jefe de análisis y programación ( )
Programador ( )
Otras (especifique):

40. Las solicitudes de modificaciones a los programas se hacen en forma:

Oral ( )
Escrita ( )

41. Una vez efectuadas las modificaciones, ¿se presentan las pruebas a los interesados?
Si: No:

42. ¿Existe control estricto en las modificaciones?

Si: No:
 43. ¿Si se tienen terminales conectadas?, ¿se ha establecido procedimientos de operación?
Si: No:

44. Se verifica identificación:

De la terminal ( )
Del usuario ( )
No se pide identificación ( )

45. ¿Se ha establecido un número máximo de violaciones en sucesión para que la computadora cierre esta
terminal y se de aviso al responsable de ella?
Si: No:

46. ¿Existen controles y medidas de seguridad sobre las siguientes operaciones? ¿Cuáles son?
Recepción de documentos ( )
Información confidencial ( )
Captación de documentos ( )
Cómputo electrónico ( )
Programas ( )
Documentos de salida ( )
Archivos magnéticos ( )
Operación del equipo de computación ( )
En cuanto al acceso de personal ( )
Identificación del personal ( )
Policía ( )
Seguros contra robo e incendio ( )
Cajas de seguridad ( )
Otras (especifique) ( )

14.20. Otras preguntas

¿La organización ha definido claramente qué significa la TI para ella?

¿Se han documentado las áreas de responsabilidad del director de TI (CIO, en inglés)?

¿Se han considerado todas las áreas en el enfoque de auditoría de TI al evaluar el riesgo y definir el
universo de auditoría de TI?

¿Anualmente, la función de la auditoría interna realiza una evaluación efectiva del riesgo de TI?

¿Han participado en dicha evaluación especialistas en tecnologías de infraestructura, sistemas de apli-

cación y procesos de TI?

¿La evaluación de los riesgos tiene en cuenta la arquitectura tecnológica específica y la configuración
empleada por la organización?
¿Cómo se cuantifican los riesgos de TI?

¿Se considera tanto la estimación de su impacto como la de la probabilidad de su ocurrencia?

¿Qué referencias del sector y ”mejores prácticas” se utilizan para respaldar esas estimaciones?

¿En el universo de auditoría de TI, se planifican auditorías para cada nivel del entorno de TI?

¿Y de no ser así, por qué?

¿Existen circunstancias especiales o es que el plan de auditoría no es el óptimo?

¿Cómo se estiman los presupuestos de auditoría de TI?

¿Se han recopilado suficientes datos para respaldar una estimación correcta? ¿Se ha tenido en cuenta
la configuración específica de la tecnología?

¿Cómo se definen los procedimientos de auditoría de TI?

¿Se desarrollan internamente para el entorno específico de la organización, o se emplean cuestionarios

disponibles en el mercado?

¿Se han implementado estructuras de control y normas de TI dentro de la organización?

¿Si es así, cuáles?

¿En caso contrario, se han establecido internamente líneas de base para la seguridad y el control?

¿Si no se ha hecho, el DEA ha recomendado su implementación como parte de la auditoría de dirección

y gobierno de TI?

¿Se emplean herramientas para acelerar las auditorías de TI (por ejemplo, aceleradores o facilitadores
para la realización de pruebas)?

¿Si la respuesta es negativa, por qué no?

¿Si la respuesta es positiva, estas han sido probadas y aprobadas por la gestión de TI?

¿Con qué tipo de personal cuenta el departamento de TI?

¿Se emplean especialistas para las diversas tecnologías (por ejemplo, aplicaciones versus tecnologías
de infraestructura)?

¿Si la respuesta es negativa, por qué no?

¿Cómo se revisan los papeles de trabajo de auditoría de TI en cuanto a su adecuación y calidad?

¿Se ha establecido una estrategia de capacitación para los auditores de TI?

¿Se consideran todos los niveles del entorno de TI?

¿Se evalúan anualmente los temas emergentes y los riesgos para determinar su relevancia dentro de la
organización?

¿Cómo se identifican los temas emergentes dentro de la organización?

¿La función de auditoría ha sido comparada con determinados patrones de referencia y mejores prác-
ticas de la industria?

¿Se ha empleado la encuesta GAIN u otro repositorio de datos para facilitar el proceso?

¿Todas las auditorías de proceso contienen procedimientos que evalúan los parámetros de configura-
ción de las aplicaciones que automatizan los procesos?

¿Cómo se coordinan estos procesos entre los recursos de auditoría (procesos versus TI )?

¿Se borra la información que se encuentra en los dispositivos de almacenamiento como discos duros,
pendrives, cintas magnéticos y/o micro sd antes de que el hardware obsoleto o preparado para destruir,
salga o abandone la Empresa? ¿Cuáles son las aplicaciones utilizadas para tal efecto?

¿Los equipos robados o desaparecidos son registrados y reportados por la empresa ante los cuerpos
de seguridad del estado, a la vigilancia privada de la empresa y al grupo de seguridad informática
corporativa usando el formulario adecuado, bien con un informe físico en papel o bien a través de la
correspondiente página web corporativa?

¿Cuántos portátiles y computadores de sobremesa han sido robados de la unidad en el último año?

¿Cuáles son los procedimientos de seguridad establecidos por la unidad para las laptop, tabletas y
teléfonos inteligentes corporativos? ¿Cómo se procede para informar a los usuarios las políticas de la
empresa sobre la seguridad informática?

¿Los portátiles no asegurados y con información visible salen de la Empresa fuera del horario habitual
de trabajo?

¿Se identifican las laptop, tabletas y teléfonos inteligentes personales para su entrada en la empre-
sa?¿Se revisa su contendido a su salida?

¿Todos los servidores, computadores sobremesa y minitorres, laptop, tabletas y teléfonos inteligentes
corporativos tienen algún programa de cifrado de datos? Revisar si todos estos equipos portátiles,
incluidos los de backup, tienen instalados el PGP (Pretty Good Privacy) o algún sistema equivalente.

¿Quién mantiene las grabaciones de software para la unidad?

¿Qué herramienta se emplea para gestionar los recursos del software para la unidad?

¿La unidad tiene un inventario de licencias de software? Verificar si se dispone de un archivo Excel
donde se encuentran todas las licencias actualizadas

¿Existen licencias/copias de software adecuadas? ¿Están actualizadas?

¿Cuáles son los procesos para adquirir y revisar software?

¿La unidad está utilizando acuerdos de empresa relativos al precio para comprar software?

¿Cuál es la política de la unidad relativa a la instalación de software en computadores de empresa?

¿Esta política se comunica a los usuarios con cierta periodicidad? Si es así, ¿cómo?
¿Cómo verifica que el usuario no instale programas no autorizados en el equipo que le ha sido asig-
nado? ¿Se llevan a cabo auditorías periódicas de los computadores asignados a los usuarios? Si se
encuentra software no aprobado o no relacionado con el negocio, ¿se elimina del computador?

Documentos y pruebas de que los antivirus están instalados y de que su ejecución es correcta y se
están utilizando versiones actualizadas respecto a la fecha de Auditoría.

¿Está la presente unidad utilizando algún software antivirus diferente del estándar de la compañía (por
ejemplo Symantec/McAfee)?

¿Cómo se actualizan las definiciones de la base de datos de virus?

¿Se ha establecido una función de atención al usuario? Si es así, ¿cuál es el proceso y cómo está
sustentado?

¿Hay establecida una estructura basada en tipología de incidencias? ¿Existe documentación que iden-
tifica claramente quién es responsable de cada tipo de incidencia y de la resolución de cada problema?

¿Qué software se está utilizando para gestionar, almacenar y mantener los datos de los problemas?

Si la unidad externaliza el soporte de problemas relativos al software y/o hardware, ¿cuál es el nombre
del proveedor que externaliza?

• ¿Tiene la unidad un contacto con el proveedor de manera que le pueda comunicar/plantear cues-
tiones?
• ¿Se han realizado comparaciones entre proveedores?

¿Cómo se ha logrado que el cliente tome conciencia y haya sido formado respecto a la función de
soporte del problema (cuando era realizada por el departamento de sistemas de la unidad)?

¿Son adecuados los procedimientos para la gestión de problemas relativos a los sistemas de informa-
ción?

¿Realiza el servicio de atención a los usuarios el reseteo de las claves?

¿Las contraseñas se resetean a una contraseña común del tipo ”líder”?

Cuando se incorpora un nuevo empleado en nuestra empresa, el jefe del departamento al que pertenece,
tiene que solicitar a Alemania la creación de un nuevo usuario.

¿Se registran los cambios en un sistema de gestión de cambio o registro?

¿Las solicitudes de cambio son revisadas por personal funcional experto, que comprenda la necesidad
de dicho cambio? Están los cambios aprobados por el correspondiente Business Owner?

¿Hay notificaciones de los usuarios con un riesgo alto de cambio, que podría causar un apagado o
colapso de los sistemas?

¿Se manejan de una manera diferente los trabajos o proyectos identificados como breakfixes (proyectos
pequeños que requieren menos de 3 días de trabajo), alta prioridad o proyectos urgentes, grandes,
medios, pequeños cambios diferentemente?
¿Cuáles son los procesos para probar los cambios realizados antes de pasarlos a productivos? ¿Se
aplican cambios a un entorno o sistema de pruebas antes de pasarlos a productivo?

¿Hay algún plan documentado de implementación y de retorno realizado a propósito para cambios
significativos?

¿Hay personal de negocio apropiado y usuarios de sistemas adecuados e informados que estén presen-
tes cuando los cambios se vayan a mover a producción?

¿Existe algún plan para proveer del entrenamiento apropiado al equipo de miembros de los diferentes
departamentos afectados?

¿Han seguido los pasos correctos los proyectos elegidos para documentar la gestión de cambios?

¿Tuvieron los ejemplos de cambios que fueron elegidos, las correspondientes y apropiadas aprobacio-
nes?

¿Qué versión o versiones de SQL Server está o están siendo utilizadas actualmente? ¿Tienen todas
ellas licencia de uso activa?

¿Cuáles son los nombres de los servidores de base de datos SQL actualmente productivos y donde
están ubicados?

¿Qué servidores de desarrollo están utilizando SQL Server y dónde están localizados?

¿Cuáles son las funcionalidades de negocio de las bases de datos existentes y quien o quienes son sus
”business owners”?

¿Qué dependencia o impacto tienen las aplicaciones que utilizan bases de datos respecto del funciona-
miento de la unidad?

¿Quién es / son el/los administradores de las bases de datos (DBA)? ¿Quién es el backup del DBA?

¿Están ambos (DBA y DBA backup) adecuadamente entrenados?

¿Está disponible la documentación para crear bases de datos estructurales y objetos de bases de datos,
y existe asistencia o ayuda para el diseño eficiente de aplicaciones?

¿Ha existido recientemente algún problema? Preguntar y revisar la documentación sobre el desarrollo
realizado para un incidente recientemente reportado.

¿Cómo se supervisan habitualmente las bases de datos? ¿Quién recibe las alertas y en qué formato o
de qué manera?

¿Qué procesos se usan para el chequeo y gestión de base de datos a desarrollar y/o mantener? Copias
de seguridad de las bases de datos y restauración de las mismas.

¿Cuál es el proceso y frecuencia con la que están programados los backups de los datos almacenados
en las bases de datos?

¿Sabe el DBA o las personas apropiadas cómo recuperar datos perdidos o corruptos?

¿Qué método se usa o se usaría para recuperar y reconstruir datos perdidos o corruptos?
¿Cuándo fue la última vez en la que fue necesario hacer una restauración de datos? Revisar la docu-
mentación asociada a dicho problema y el proceso utilizado para su restauración y solución.

¿Existe un proceso formal de backup y restauración para los datos guardados en los servidores? Ase-
gurarse de que la reconstrucción de la sección asignada a la parte de datos del SQL Server está bien
documentada,

¿Están los backups almacenados en un lugar apartado? ¿Se puede verificar?

¿Pueden ser conseguidos los backups desde su emplazamiento externo habitual en menos de 24 horas?
¿Están realizados en modalidad 24x7?

¿Están los datos salvados en modo de backup normal o son backups incrementales?

Si los datos están archivados, ¿cuál es la política y el proceso para realizar su archivado? Explicarlo y
verificarlo.

¿Cuándo fue la última vez que se recuperaron datos perdidos o corruptos reales? ¿Qué proceso se
siguió? ¿Cuánto tiempo se invirtió en dicho proceso? Si no ha habido ningún proceso reciente de
reconstrucción de datos desde archivos de respaldo o de backup, ¿cuándo fue la última vez que se
desarrolló un proceso de restauración en modo test y cómo se verificó su correcto funcionamiento?
Preguntar para ver la documentación histórica del comentado proceso de restauración, sea real o en
modo test.

¿Qué bases de datos son consideradas críticas?

Para bases de datos críticas, ¿cuánto tiempo puede la unidad o empresa continuar su negocio sin ellas?

¿Existe un procedimiento adecuado Business Continuation Plan (BCP) y computer Disaster Recovery
Plan (cDRP) en el que esté incluido todo lo relativo a las bases de datos SQL?

¿Ha habido allí alguna caída súbita de aplicaciones o alguna falta de disponibilidad de algún aspecto
relativo a SQL? Preguntar para revisar los tickets o peticiones de resolución asociados con dicho
problema para su correcta documentación, escalación, y sobre todo la documentación de las "lessons
learned-lecciones aprendidas".

¿Sigue la adquisición del software SQL la normativa de la Empresa, división o los estándares de la
industria o negocio al que se dedica la Empresa?

¿A quién se le reportan y quien hace un seguimiento de los problemas derivados de SQL? Respuesta
del Auditado

¿Existe un nivel identificado para el escalado para el Soporte de problemas (Tier 1, 2, y 3)? ¿Cuáles
son los criterios o pautas que regulan este escalado?

¿Los permisos a las bases de datos para administradores / usuarios están regulados por grupos de
Directorio Activo?

¿Quién administra la entrada y salida de trabajadores de la Empresa (incluyendo outsiders o trabaja-

dores externos)? ¿Está centralizado este proceso?
Si los permisos de usuario se dan a user id (identificación de usuario), ¿está el DBA (administrador de
la base datos) incluido en el proceso de notificaciones de entrada y salida de la empresa? ¿Se desarrolla
una revisión periódica de los usuarios con permisos?

Verificar que los ”business owner” deben aprobar el acceso y el correspondiente nivel de acceso o de
permiso cuando las peticiones se hagan para solicitar accesos a tablas o a bases de datos, bien sea
directamente a través del SQL server o bien a través de algún aplicativo de desarrollo propio.

Revisar las normativas o roles para acceso a las carpetas de los Servidores de SQL para asegurar que
los grupos de Directorio Activo se están usando, y verificar que las personas que lo necesitan sólo
tienen los accesos que realmente requieren para su trabajo.

¿Cuál es el proceso de manejo de cambios para los cambios relativos al SQL Server y a las posibles
localizaciones de las bases de datos?

¿Son todos los cambios manejados siguiendo el proceso marcado en el punto anterior? Preguntar
para ver un número representativo de cambios realizados documentando las respuestas y los procesos
realizados en cada caso.

¿Cómo se manejan los requerimientos de cambios? Describir la inicialización de los cambios y el

seguimiento que se hace de ellos.

¿Cómo se priorizan los cambios? ¿Cómo se manejan los cambios de alta prioridad o que tengan ca-
rácter de urgencia?

¿Cómo se notifica al solicitante de cambios en las tablas del SQL Server, del estado de los mismos?

¿Hay procedimientos para notificar al personal de Soporte de los cambios realizados en los sistemas?
¿Y a los usuarios finales a los efectos que cada uno necesite?

¿Hay procedimientos para notificar a los usuarios finales de los cambios realizados en el sistema?

¿Los cambios requeridos son revisados por un personal funcional con el conocimiento suficiente y
aprobados por el correspondiente ”business owner”?

¿Son los cambios registrados y seguidos a través de un sistema de manejo de cambios? Preguntar por
la documentación existente al respecto.

¿Hay una aceptación del proceso de test junto con el departamento funcional que las utiliza? ¿Hay test
de resultados que muestren especialmente las diferencias encontradas, que estén grabados y que hayan
sido revisados?

¿Cuál es el proceso documentado a seguir para instalar una nueva versión del software de base de
datos?

¿Se aplicaron los cambios durante periodos relativamente tranquilos cuando el desastre pudo ser así
debidamente minimizado?

¿Hay un proceso de manejo de los cambios específicos que provea un plan de vuelta atrás? Preguntar
por un ejemplo del mismo para verificación.

¿Quién es el encargado de mover los cambios en las bases de datos, del servidor de test al productivo?
¿Hay un entorno de desarrollo diferente, separado del de producción?

¿Quiénes son los administradores principales de estas bases de datos y de sus back- ups? ¿Cuánto
tiempo llevan cumpliendo esta función? ¿Qué formación inicial y complementaria tienen para las
bases de datos (DBA)? Si el soporte no es para un DBA local, explicar cómo se realiza el acceso a la
red y el mantenimiento de las mismas.

¿Cuáles son los procedimientos documentados de la unidad y las normas para hacer frente a la manipu-
lación y al mantenimiento de programas de aplicaciones financieras y a sus datos? ¿Cómo se comunica
a los trabajadores del equipo de informática y analistas funcionales los sucesos realizados o a realizar
sobre estas bases de datos?

¿Quién es el responsable de la recuperación de una base de datos perdida o dañada (es decir Mdb, Dbf
y el espacio dedicado a ellas)?

Revisar la política, procedimiento, y los registros de datos usados diariamente y la restauración de

los mismos (es decir, la recuperación de datos en un momento específico del tiempo). ¿Cuándo fue
necesario hacer la última recuperación? ¿Con qué frecuencia se examina este proceso?

¿Cómo se realiza la supervisión/supervisación de la política de seguridad informática corporativa para

bases de datos, administración de aplicaciones y contraseñas (es decir, Oracle dba_audit, dba_profiles)?
¿Con qué frecuencia el ”business owner” y el jefe del IT revisan los usuarios y los permisos de los
grupos de acceso a las bases de datos?

¿Cuál es y dónde está guardado el proceso para la concesión / revisión de acceso de base de datos para
los usuarios (es decir, grupo de acceso, ficheros Mdb o las funciones de base de datos de Oracle)? Si
se utilizan grupos RACF o grupos de AD, obtener una lista de ellos y verificar quien tiene acceso a los
mismos.

¿Dónde se guardan y cuáles son los procedimientos para la administración de usuarios, acceso, trans-
ferencia de archivos, etc.? Si no está hecho, pedir al Coordinador de Recursos Humanos una lista de
los usuarios nuevos, de usuarios antiguos y también de los becarios o de los outsiders.

¿Se han encontrado cuentas inactivas? - ¿Se han encontrado cuentas con contraseñas que no caducan?
- ¿Alguna de estas cuentas son cuentas compartidas? (las cuentas de aplicación están bien, pero otras
cuentas deben tener un motivo para haber sido creadas de esta manera, es decir, con contraseñas que
nunca caducan) - ¿Hay un proceso de revisión de ambos periódico?

¿La configuración de seguridad local cumple o excede las políticas de seguridad informática global
del negocio?

¿Los servicios que se ejecutan en cada servidor son los adecuados? - ¿Hay un proceso de revisión de
servicios para garantizar que los servicios innecesarios dejen de funcionar? - Utilice la herramienta/la
aplicación SVCAudit para verificar los servicios que se ejecutan en el entorno Windows. - Estos ser-
vicios no deben funcionar o estar configurados para iniciarse automáticamente en un servidor sin un
motivo pertinente (verificar que se cumple)

¿Quién es el administrador Windows/linux/FreeBsd/Unix/Mac?

¿Tiene la unidad la responsabilidad de controlar remotamente las operaciones a otros lugares?

¿Existe un entorno de prueba para datos y/o aplicaciones?

¿Cuál es el proceso de identificar y reportar violaciones en los sistemas?

¿Quienes son los Administradores de red primario y su backup?

¿Además de los Administradores de red mencionados arriba, qué otras personas conocen las claves
administrativas?

¿Cada cuánto tiempo se cambian las claves administrativas?

¿Quién es el responsable de mantener y actualizar las configuraciones de los dispositivos de la red?

(núcleo y acceso a los switches, routers primarios y secundarios, entornos de fibra óptica, etc.).

¿Cómo se define y se controlan las conexiones a la red? (switches, routers, Access points). Procedi-
mientos documentados a estos efectos.

¿Están documentados a través de procedimiento las operaciones estándares (SOP) existentes para la
red física y para la red wireless?

¿Tiene la unidad alguna responsabilidad sobre el control remoto de las operaciones de otros lugares o
emplazamientos? ¿Han sido identificados estos lugares en el BCP (Business Continuation Plan)?

¿Qué diagramas/esquemas existen (del entorno de red, routers, Access points, y entorno wifi)? ¿Se
actualiza a menudo de acuerdo con los cambios introducidos en el entorno? Ver si el tiempo lo permite,
ejemplos de ello. Las actualizaciones y los esquemas de diseños actualizados deben estar disponibles,
así como diagramas de las coberturas wifi.

¿Qué servicios relacionados con la red están contratados a terceras empresas o a vendedores (ejemplos:
monitores, instalaciones, servicios de servidores, routers, Access points)? ¿Cada cuánto tiempo se
revisan estos contratos?

¿Qué tiempo de respuesta del servicio tiene marcado el vendedor en el contrato de nivel de acuerdo
(SLA) para reemplazo de hardware y/o soluciones de software? ¿Cada cuánto se revisa el acuerdo
SLA?

¿Proveen en tiempo y forma para la solución de problemas, para minimizar los posibles problemas
producidos en la unidad de negocio?

¿Se utilizan redes privadas virtuales (VPN)? Si es que sí, ¿qué nivel de control de seguridad se utiliza
para el acceso a las mismas?

¿Tienen conexión a otros proveedores o socios de negocio que no tengan infraestructura de red propia?

¿Hay usuarios de la Empresa u outsiders (externos) a la empresa, a los que se les permita el acceso
remoto en modo telefónico a la red (cualquier sistema de ”Rave” o accesos vía telefónica por web)?

¿Se está utilizando el entorno de red wifi? Si es que sí, responder a las siguientes preguntas. En otro
caso, se debe se saltar la sección de Wireless completa.

¿Qué seguridad o sistema de cifrado de datos Wireless estándar se está utilizando ((WEP, LEAP, EAP-
TLS, PEAP w/MSCHAPv2, u otro)?
¿Quién administra la infraestructura de red wireles (servidores, Access points, supervisión)?

¿Cómo se supervisa en la Empresa la red wireless?

¿Cuál es la topología de red LAN utilizada en la Empresa (Ethernet, Fast-Ethernet, token ring, Fiber
distributed data interface (FDDI)?

¿Qué tecnología Wireless se está utilizando actualmente en la Compañía? Note - Cat5, Cat5E, Cat6,
Wireless, y cable de fibra óptica son tecnologías actuales admitidas. ThinNet, ThickNet y cables
Coaxiales son sistemas wireless desactualizados.

¿Es redundante la construcción topológica de la red existente?

¿Cómo recibe el administrador de red los eventos reportados por la propia red?

¿Quién revisa los sucesos de eventos (event logs) y la frecuencia con la que suceden los mismos?

¿Ha habido algún corte de señal significativo –y no documentado o informado- en el pasado último
año? ¿Cuánto duró dicho corte de señal? ¿Cuáles fueron las causas? ¿Qué se hizo para solucionar el
problema?

Mostrar un ejemplo cómo recibe el administrador de red los eventos reportados por la propia red

¿Cómo se utilizan los sistema de alertas/monitorización para revisar y mantener los Access point,
routers, y switches?

¿Dónde están configurados los recursos de la red (por ejemplo, los servidores, los routers, y los Access
point)? ¿Dónde están copiadas y almacenadas dichas configuraciones? Si lo están remotamente, ¿quién
es la persona de contacto?

¿Qué herramienta de alertas en la red se utiliza? ¿Qué eventos y autenticaciones (logins) activos,
fallidos, pendientes, etc., se verifican?

¿Cómo está haciendo actualmente la unidad las copias de backup de las configuraciones? Verificar la
documentación relativa a procedimientos de backup de la red de área local (LAN).

¿Cómo recibe el administrador de red los eventos reportados por la propia red?

¿Cómo está controlado físicamente el acceso de los equipos a la red? ¿Quién tiene acceso a estos
entornos y equipos conectados? ¿Todos los recursos vitales están debidamente asegurados? ¿Hay re-
cursos localizados en áreas no seguras? Muchos equipos críticos de la red local/corporativa/wireless
suelen estar conectados a una UPS (equipo de alimentación ininterrumpida). Esta es la mejor práctica
pero no es un requerimiento mandatorio para la Auditoría.

Revisar toda la red/entorno wireless para proponer o chequear una apropiada disciplina de etiquetado.
Las conexiones de la red wireless deben ser chequeadas y etiquetadas para identificarlas correctamente
desde terminales específicos para esta funcionalidad, pero no es un requisito indispensable. correo

¿Los procesos de administración local se realizan periódicamente y son fáciles de mantener?

¿Se han comunicado las políticas de uso del mail para facilitar el poder hacer una utilización adecuada
de los recursos del negocio? ¿Saben los usuarios de la existencia del documento de las políticas de
correo electrónico de la Compañía? Recójanse evidencias tanto de la compartición de estos conoci-
mientos, como realidades físicas entre los usuarios de la Empresa

¿Hay un proceso apropiado de entrada y salida de personal de la Empresa?

¿Hay aplicaciones activas para ayudar a mantener los procesos en caso de producirse un cambio de
personal en un puesto específico (es decir, los procedimientos y los estándares están documentados)?

¿Sabe la unidad que existen cuotas de espacio para los servidores de email y se han revisado los ajustes
de correo electrónico para eliminar gastos de espacio innecesarios?

Se ha considerado tener o se han colocado ya limitaciones de espacio a los buzones y/o cuotas de
tamaño para envío y recepción de mail?

¿Cuál es el procedimiento de la Unidad para la retención de datos de buzones y el calendario para las
investigaciones judiciales en caso de utilizaciones ilícitas o fraudulentas de los mismos?

¿Cuál es el procedimiento de la Unidad para permitir el acceso a los recursos humanos o a la dirección,
en caso de necesidad de supervisión de las actividades de correo de un usuario si éste se encuentra bajo
investigación?

¿Cuál es la política de retención para las cintas de copia de seguridad (si acaso fuese diferente, por
cuestiones legales, de la política de retención de las copias de seguridad normales de Windows)?

¿El servidor de correo electrónico está situado en un entorno seguro y estable?

¿Hay aplicaciones activas para reducir o mitigar el riesgo de interrupción del sistema por ataques de
virus? ¿Se trata de un servicio local o centralizado desde la Corporación?

¿Está el software SAV (Symantec Antivirus) o ScanMail instalado en el servidor Exchange (de correo)
para escanear en busca de virus dentro de los correos electrónicos y archivos adjuntos? ¿Es alguno de
los mencionados el software de protección antivirus actual y hay un proceso de control de versiones
confiable? ¿Está licenciado a nivel corporativo o local? Arquitecturas de Firewall y conexiones con
redes públicas

En cuanto a las capacidades de acceso remoto, OWA o RPC sobre HTTP, ¿cuáles son las reglas confi-
guradas en el firewall o cortafuegos de acceso a internet para proteger estos servicios?

¿Se realiza copias de seguridad DE LA BASE DE DATOS (diariamente, semanalmente, mensualmen-

te, etc.)?

¿Existe una Política de respaldo?

Acerca del autor

Graduado en Física, Facultad de Ciencias, Universidad Nacional Autónoma de México (UNAM),

Doctor en Ciencias de la Computación, Instituto de Investigaciones en Matemáticas Aplicadas y
Sistemas (IIMAS) UNAM. Especialista en Economía Matemática, Centro de Investigación y Do-
cencia Económica, CIDE, México. Cursante del Doctorado en Minería de Datos, Modelos y Siste-
mas Expertos por la Universidad de Illinois en Urbana-Champaings (USA).
Auditor de sistemas informáticos certificado por Ernst & Young, Cleveland, Ohio, USA, 1985.
Ha sido profesor en la Facultad de Química y en la Facultad de Ingeniería, UNAM. Fue profesor en
el Departamento de Ciencias Básicas, Universidad de Las Américas en Cholula, (UDLAP), Puebla,
México y, durante seis años, profesor visitante en la Universidade Federal de Rio Grande do Sul
(Brasil), profesor y jefe de sistemas postgrados de agronomía y veterinaria, Universidad Central de
Venezuela (UCV), es profesor del Departamento de informática y del Departamento de Postgrado,
Universidad Politécnica Territorial de Aragua (UPT Aragua), Venezuela.
Expositor y conferencista a nivel nacional e internacional.
Es asesor en mejora de procesos, gestión de proyectos, desarrollo de software corporativo en los
sectores de servicios, banca, industria y e-gobierno.
El Dr. Domínguez es un especialista reconocido en base de datos, desarrollo de software y servido-
res en el área del software libre, así como un experto en LINUX DEBIAN.
En la actualidad orienta su trabajo a la creación y desarrollo de equipos de software de alto desem-
peño.
Autor de múltiples artículos y libros sobre la materia.