auditoría de sistemas de información
DESCRIPTION
No cabe duda que los sistemas y tecnologías de la información (SI/TI) se han convertido en recursos indispensables para las organizaciones hoy en día. Muchas empresas e instituciones requieren del uso de los recursos computacionales para mejorar y optimizar sus procesos de negocio. En la medida que se incrementa el uso de dichos recursos se incrementan también los problemas. Una manera de disminuir los riesgos generados a partir de los problemas suscitados por el uso de SI/TI, sobre todo por su uso intensivo, es mediante la revisión técnica y detallada de SI/TI. Esta revisión se traduce en un proceso denominado Auditoría de Sistemas de Información o Auditoría Informática.TRANSCRIPT
Pág. 1
Auditoría de Sistemas de Información
Luis Otake
Pág. 2
Cuaderno de trabajo de
Auditoría de Sistemas de Información Autor
Luis Otake
Chiclayo, 2012 Escuela de Ing. De Sistemas y Computación Facultad de Ingeniería Universidad Católica Santo Toribio de Mogrovejo
Copyright 2012, by the Contributing Authors. Esta obra se publica bajo una Creative Commons License.
Cuaderno de trabajo elaborado para la Escuela de Ing. De Sistemas y
Computación. Facultad de Ingeniería. Universidad Católica Santo Toribio de Mogrovejo - USAT is licensed under a Creative Commons Reconocimiento-NoComercial-
Compartir Igual 3.0 Unported License.
Pág. 3
PRESENTACIÓN
El presente trabajo pretende ser una guía para el desarrollo de la asignatura de
Auditoría de Sistemas de Información.
Se ha tratado de incluir los aspectos básicos de la especialidad, a fin de que el
estudiante pueda conocer y aplicar los conocimientos en el ámbito de la Auditoría,
Control interno y Aseguramiento de las tecnologías de la información.
Pág. 4
ÍNDICE
ÍNDICE DE FIGURAS ................................................................................................... 7
ÍNDICE DE TABLAS ..................................................................................................... 8
LISTA DE SÍMBOLOS Y ABREVIATURAS ................................................................... 9
INTRODUCCIÓN ........................................................................................................ 10
EL PROCESO DE AUDITORÍA DE SISTEMAS DE INFORMACIÓN .......................... 11
1.1. Conceptos previos ........................................................................................ 11
1.2. Definición de Auditoría de Sistemas de Información ..................................... 13
1.3. Objetivos de la Auditoría de Sistemas de Información .................................. 13
1.4. El Proceso de Auditoría ................................................................................ 13
1.5. Tiempos en el Proceso ................................................................................. 14
1.6. Ámbito de Actuación ..................................................................................... 14
1.7. Chief Audit Executive (CAE) ......................................................................... 20
ESTÁNDARES Y DIRECTRICES DE AUDITORÍA DE SISTEMAS DE INFORMACIÓN
................................................................................................................................... 21
2.1. Marco general de normas de ISACA para la auditoría de SI ......................... 21
2.2. Relación entre normas, directrices y procedimientos .................................... 21
2.3. Código de ética profesional (ISACA) ............................................................. 21
2.4. Estándares de Auditoría ............................................................................... 22
2.5. Directrices de Auditoría ................................................................................. 23
2.6. Herramientas y técnicas ............................................................................... 24
ANÁLISIS DE RIESGOS DE TECNOLOGÍAS DE LA INFORMACIÓN ....................... 26
3.1. Análisis de Riesgos ...................................................................................... 26
3.2. Marco referencial del Análisis de Riesgo ...................................................... 26
3.3. Marco de riesgos de TI ................................................................................. 27
3.4. Riesgos de TI ............................................................................................... 27
3.5. Categorías de los riesgos de TI .................................................................... 27
3.6. Apetito de riesgo ........................................................................................... 28
CONTROL INTERNO INFORMÁTICO ........................................................................ 29
4.1. Control Interno .............................................................................................. 29
4.2. Control Interno Informático o de TI................................................................ 30
4.3. Objetivo de control interno informático o de TI .............................................. 31
EL MARCO REFERENCIAL DE COBIT ...................................................................... 34
Pág. 5
5.1. La misión de COBIT ..................................................................................... 34
5.2. Definición y características de COBIT ........................................................... 34
5.3. Planear y Organizar (PO) ............................................................................. 40
5.4. Adquirir e Implementar (AI) ........................................................................... 40
5.5. Entregar y Dar Soporte (DS) ......................................................................... 41
5.6. Monitorear y Evaluar (ME) ............................................................................ 41
5.7. Objetivos de control ...................................................................................... 41
5.9. Modelos de madurez .................................................................................... 46
REALIZACIÓN DE UNA AUDITORÍA DE SISTEMAS DE INFORMACIÓN ................. 49
6.1. Metodología para realizar Auditoría de SI ..................................................... 49
6.2. El Proceso de Auditoría ................................................................................ 52
6.3. Requerimientos del Proceso de Auditoría ..................................................... 52
6.4. Directriz general de Auditoría ........................................................................ 54
6.5. Pruebas de cumplimiento vs. Pruebas sustantivas ....................................... 55
6.6. Evidencia ...................................................................................................... 55
AUTOEVALUACIÓN DE CONTROL (CSA) ................................................................ 57
7.1. Definición ...................................................................................................... 57
7.2. Objetivos del CSA ......................................................................................... 57
7.3. Beneficios del CSA ....................................................................................... 57
7.4. Desventajas del CSA .................................................................................... 58
7.5. El rol del auditor en el CSA ........................................................................... 58
DOCUMENTACIÓN DE LA AUDITORÍA DE SISTEMAS DE INFORMACIÓN ............ 59
8.1. Contenido de la Documentación ................................................................... 59
8.2. Propuesta para integrar los papeles de trabajo ............................................. 60
8.3. El formato de la documentación .................................................................... 60
EL INFORME DE AUDITORÍA .................................................................................... 62
9.1. Definición de Informe .................................................................................... 62
9.2. Estructura del Informe................................................................................... 62
9.3. Ejemplo de la estructura de un Informe de Auditoría..................................... 62
GOBIERNO Y GESTIÓN DE TECNOLOGÍAS DE LA INFORMACIÓN....................... 66
9.1. Gobierno Corporativo.................................................................................... 66
9.2. Gobierno de TI .............................................................................................. 66
9.3. Áreas de enfoque del gobierno de TI ............................................................ 68
9.4. Marcos de gobierno de TI ............................................................................. 68
9.5. El rol de la auditoría en el gobierno de TI...................................................... 69
9.6. Auditoría a la estructura e implementación del Gobierno de TI ..................... 70
Pág. 6
9.7. Revisión de compromisos contractuales ....................................................... 71
9.8. Planeación de continuidad del negocio (BCP) .............................................. 71
9.9. Planeación de continuidad del negocio de SI ................................................ 72
9.10. Elementos de un BCP ............................................................................... 72
9.11. Auditoría al Plan de Continuidad del Negocio............................................ 72
ADQUISICIÓN, DESARROLLO E IMPLEMENTACIÓN DE SISTEMAS DE
INFORMACIÓN .......................................................................................................... 74
11.1. Auditoría de los controles de aplicación .................................................... 74
11.2. Auditoría de desarrollo, adquisición y mantenimiento de sistemas ............ 74
OPERACIONES, MANTENIMIENTO Y SOPORTE DE SISTEMAS DE INFORMACIÓN
................................................................................................................................... 82
12.1. Auditoría de la Infraestructura y de las Operaciones ................................. 82
PROTECCIÓN DE LOS ACTIVOS DE INFORMACIÓN ............................................. 91
13.1. Auditoría de acceso lógico ........................................................................ 91
13.2. Auditoría a la seguridad de infraestructura de red ..................................... 91
13.3. Auditoría a los controles ambientales ........................................................ 92
REFERENCIAS BIBLIOGRÁFICAS ............................................................................ 93
Pág. 7
ÍNDICE DE FIGURAS
Figura 1: Marco referencial del análisis de riesgo [8] 27 Figura 2: Clasificación de los riesgos de TI [9] 28 Figura 3: La jerarquía de los controles de TI [10] 31 Figura 4: Relación entre recursos de TI y entrega de servicios [8] 37 Figura 6: Relación entre procesos de negocio, información y recursos de TI [8] 38 Figura 6: Dominios, procesos y actividades [8] 38 Figura 7: El Cubo de COBIT [11] 39 Figura 8: Los cuatro dominios interrelacionados de COBIT [11] 39 Figura 9: Organización y navegación de los objetivos de control de TI [8] 44 Figura 10: Fronteras de los controles de negocio, generales de TI y de aplicación [11] 45 Figura 11: Representación gráfica de los modelos de madurez [11] 46 Figura 12: El proceso de control [8] 47 Figura 13: Directriz general de Auditoría [8] 55 Figura 14: Gobierno Corporativo [8] 66 Figura 15: Gobierno de TI [8] 67 Figura 16: Áreas de enfoque del gobierno de TI [11] 68
Pág. 8
ÍNDICE DE TABLAS
Tabla 1: Distribución de tiempos en el proceso de auditoría [6] ............................................... 14 Tabla 2: Clasificaciones de control [7] ..................................................................................... 29 Tabla 3: Requerimientos del proceso de auditoría [8] .............................................................. 53
Pág. 9
LISTA DE SÍMBOLOS Y ABREVIATURAS
SI: Sistema de información
TI: Tecnología de la información
ISACA: Asociación de Auditoría y Control de Sistemas de Información
IIA: Instituto de Auditores Internos
ISO: Organización Internacional para la Estandarización
BIA: Análisis del impacto del negocio
BCP: Plan de continuidad del negocio
DRP: Plan de recuperación de desastres
RPO: Punto de recuperación objetivo
RTO: Tiempo de recuperación objetivo
HW: Hardware
SW: Software
CAE: Chief Audit Executive
ITIL: Biblioteca de Infraestructura de TI
EAM: Módulo integrado de auditoría
RFP: Solicitud de propuesta
RFC: Solicitud de cambio
UAT: Prueba de aceptación de usuario
UPS: Suministro ininterrumpido de alimentación
Pág. 10
INTRODUCCIÓN
No cabe duda que los sistemas y tecnologías de la información (SI/TI) se han
convertido en recursos indispensables para las organizaciones hoy en día. Muchas
empresas e instituciones requieren del uso de los recursos computacionales para
mejorar y optimizar sus procesos de negocio. En la medida que se incrementa el uso
de dichos recursos se incrementan también los problemas. Una manera de disminuir
los riesgos generados a partir de los problemas suscitados por el uso de SI/TI, sobre
todo por su uso intensivo, es mediante la revisión técnica y detallada de SI/TI. Esta
revisión se traduce en un proceso denominado Auditoría de Sistemas de Información o
Auditoría Informática.
El presente documento pretende ser una guía para el estudiante de la asignatura de
Auditoría de Sistemas de Información o similar. Se ha recopilado información de
fuentes importantes y destacadas en la especialidad, y se han tomado referencias de
instituciones mundialmente reconocidas en el campo como ISACA (Asociación de
Auditoría y Control de Sistemas de Información) e IIA (Instituto e Auditores Internos).
Pág. 11
CAPÍTULO I
EL PROCESO DE AUDITORÍA DE SISTEMAS DE INFORMACIÓN
En este capítulo inicial del documento se tratan los conceptos iniciales e importantes, y
las características relevantes acerca del proceso de auditoría de SI. Es necesario
revisar este capítulo primero para tener una noción más clara de los aspectos básicos
de la auditoría de SI.
1.1. Conceptos previos
Los términos utilizados en el ámbito informático suelen ser muy confusos inicialmente.
Es por ello que en esta primera parte nos centraremos en despejar las dudas
referentes a ciertos conceptos, los cuales nos permitirán aprovechar mucho mejor el
presente trabajo.
1.1.1. Sistema
La Real Academia de la Lengua Española define Sistema como [1]:
Conjunto de reglas o principios sobre una materia racionalmente
enlazados entre sí.
Conjunto de cosas que relacionadas entre sí ordenadamente
contribuyen a determinado objeto.
La definición de Sistema es entonces muy genérica y amplia.
1.1.2. Información
La información “es un recurso muy importante para las personas y las organizaciones,
pero no toda información es útil” [2]. Analice el siguiente relato [2]:
Dos personas que viajan en un globo aerostático encuentran viento inesperado
que los saca de su ruta. Cuando consiguen descender le preguntan a un
granjero: “¿Dónde estamos?” y el granjero contesta: “¡Sobre mi sembradío!”
Los viajeros se miran entre sí y uno exclama: “¡Vaya información, muy precisa
Pág. 12
y totalmente inútil!” Para ser útil, la información debe ser relevante, completa,
precisa y actual.
1.1.3. Sistema de Información (SI) y Sistema Informático
Un sistema de información “está formado por todos los componentes que colaboran
para procesar los datos y producir información” [2].
En una organización, un sistema de información está formado por los datos, el
hardware, el software, las telecomunicaciones, las personas y los procedimientos. Por
ello, “un sistema de información se ha vuelto un sinónimo de un sistema de
información basado en computadoras” [2] o llamado también sistema informático.
1.1.4. Tecnología de la Información (TI)
La tecnología de la información (TI) está conformada por: hardware, software y
comunicaciones.
1.1.5. Informática
La Real Academia de la Lengua Española define Informática como un “conjunto de
conocimientos científicos y técnicas que hacen posible el tratamiento automático de la
información por medio de ordenadores” [1].
1.1.6. Hardware
Son “los componentes físicos de la computadora” [2].
1.1.7. Software
Es “una serie de instrucciones para que una computadora ejecute uno o varios
procesos, como mostrar textos, manipular números, copiar o eliminar documentos” [2].
Son “programas de computadora y la documentación asociada” y “se pueden
desarrollar para algún cliente en particular o para un mercado general” [3].
Existen dos tipos de software [2]:
Pág. 13
Software de aplicaciones: Permite a los usuarios concretar una aplicación o
tarea específica, como el procesamiento de textos, el análisis de inversiones, la
manipulación de datos o la administración de proyectos.
Software del sistema: Permite la operación del software de aplicaciones de
una computadora, y administra la interacción entre la CPU, la memoria, el
almacenamiento, los dispositivos de entrada/salida y otros componentes de la
computadora.
1.2. Definición de Auditoría de Sistemas de Información
La Auditoría de SI o Auditoría Informática es el “proceso de recoger, agrupar y evaluar
evidencias para determinar si un sistema informatizado salvaguarda los activos,
mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la
organización y utiliza eficientemente los recursos” [4].
Para Muñoz Razo [5]:
Es la revisión técnica, especializada y exhaustiva que se realiza a los sistemas
computacionales, software e información utilizados en una empresa, sean
individuales, compartidos y/o de redes, así como a sus instalaciones,
telecomunicaciones, mobiliario, equipos periféricos y demás componentes.
Dicha revisión se realiza de igual manera a la gestión informática, el
aprovechamiento de sus recursos, las medidas de seguridad y los bienes de
consumo necesarios para el funcionamiento del centro de cómputo.
1.3. Objetivos de la Auditoría de Sistemas de Información
Evaluar el uso adecuado de los sistemas para el correcto ingreso de los datos, el
procesamiento adecuado de la información y la emisión oportuna de sus resultados en
la institución, incluyendo la evaluación en el cumplimiento de las funciones, actividades
y operaciones de funcionarios, empleados y usuarios involucrados con los servicios
que proporcionan los sistemas computacionales a la empresa.
1.4. El Proceso de Auditoría
Las cinco tareas del proceso de auditoría son:
Pág. 14
• Desarrollar e implementar una estrategia de auditoría de SI basada en los
riesgos de la organización en cumplimiento con las normas, directrices y
mejores prácticas de auditoría de SI.
• Planear auditorías específicas para validar que la TI y los sistemas de negocio
están protegidos y controlados.
• Llevar a cabo auditorías de conformidad con las normas, directrices y mejores
prácticas de auditoría de SI para lograr los objetivos planeados de auditoría.
• Comunicar los problemas o situaciones que surjan, los riesgos potenciales y
los resultados de la auditoría a las partes interesadas clave.
• Asesorar sobre la implementación de la gestión de riesgos y las prácticas de
control dentro de la organización al tiempo que se mantiene la independencia.
1.5. Tiempos en el Proceso
Estudiosos en el proceso de auditoría proponen la siguiente estructura de tiempos en
cada fase:
Tabla 1: Distribución de tiempos en el proceso de auditoría [6]
Fase del proceso de auditoría Tiempo a utilizar
Planificación 1/3
Ejecución 1/3
Información (presentación y documentación) 1/3
1.6. Ámbito de Actuación
El papel de la auditoría de SI es amplio y complejo; por lo tanto, encontramos muchos
problemas asociados, los cuales pueden agruparse de la siguiente manera [6]:
La función de análisis de SI
La función de diseño y construcción de SI
La administración y control de SI
El entorno operativo de los SI
La adaptación e implementación de TI
La seguridad de la función informática
La gestión de la función informática
El procesamiento electrónico de los datos
1.6.1. Problemas asociados a la función de análisis de SI
Pág. 15
Falta de integralidad entre las aplicaciones
Información redundante
Parque computarizado caótico
Rumbo indeterminado del Departamento de Informática
Aplicaciones que no soportan la misión de la empresa
Ausencia de un plan estratégico de SI
Identificación de necesidades de información falsas
Vida útil de los SI cortos
Necesidades de información insatisfechas
Poca participación de los usuarios
Poca adaptabilidad a necesidades de información futuras
Obsolescencia de la tecnología
Falta de política de mantenibilidad de los sistemas
Improvisación en el desarrollo de SI
Presencia de desarrollos por usuarios finales
Soluciones de información inmediatistas
1.6.2. Problemas asociados a la función de diseño y construcción de SI
Sistemas de difícil operación por los usuarios
Sistemas ineficaces
Sistemas inseguros
Sistemas de difícil mantenibilidad
Sistemas que no satisfacen las necesidades de información de los usuarios
Sistemas no confiables
Sistemas no confidenciales
Sistemas mal documentados
Sistemas que no guardan el estándar del índice de modificabilidad
Sistemas que no guardan el estándar del índice de comprensibilidad
Sistemas que no guardan el estándar del índice de testeabilidad
Sistemas ineficientes
Sistemas con la interfaz de usuario poco amigable
Sistemas de vida útil corta
Sistemas sujetos a permanentes modificaciones
Pág. 16
Sistemas que no se alcanzan a implantar
Sistemas que se dejan de utilizar una vez que se implantan
Sistemas que no aprovechan la riqueza informática de los datos por el mal
empleo del procedimiento de normalización de entidades y rompimiento de las
cardinalidades de muchos a muchos
Sistemas que no propician la integralidad con otros SI de la organización
Sistemas que no facilitan la generación de información estratégica para la
organización
Sistemas no adaptables a futuras necesidades de información
Sistemas demasiados complejos en su modelamiento de datos
Sistemas con redundancia de datos
1.6.3. Problemas asociados a la administración y control de SI
Ausencia de políticas y objetivos corporativos
Políticas de personal inadecuadas
Inexistencia de un Plan Estratégico Corporativo
Inexistencia de un Plan Estratégico de Sistemas y/o Tecnología Informática
Falta de control de calidad
Deficientes relaciones de los usuarios con el área de TI
Estructura organizacional y funcional demasiado jerárquica
Recursos informáticos obsoletos
Inexistencia de un sistema de control interno
Ausencia de indicadores de gestión
Incoherencia entre los objetivos informáticos y los objetivos corporativos
Ausencia de manual de funciones y procedimientos
Inexistencia de metodologías de desarrollo de SI
Inexistencia de un Plan de Evaluación de Control Interno
Ausencia de un Comité de Sistemas
Falta de metodologías para gerenciar proyectos de TI
Compromiso gerencial escaso
1.6.4. Problemas asociados al entorno operativo de los SI
Falta de políticas, normas y procedimientos de operación de los sistemas
Falta de políticas, normas y procedimientos de mantenibilidad de los sistemas
Pág. 17
Falta de programación y ejecución en las tareas de operación
Inapropiada infraestructura locativa
Inapropiada infraestructura eléctrica
Escasa infraestructura de hardware y software
Obsoleta infraestructura de comunicaciones
Deficiente infraestructura de respaldo de datos
Ausencia de integralidad entre los sistemas
Falta de registro de desempeño y trabajos realizados
Ausencia de confiabilidad
Inexistencia de segregación de funciones
La utilización incorrecta de los equipos y medios
La no garantía de continuidad en el procesamiento electrónico de datos (PED)
La no garantía de seguridad de los registros
Falta de políticas de restricciones de acceso
Inexistencia de un Plan de Contingencias
Falta de políticas de backup
Ausencia de convenios con otros centros de procesamiento de datos
Inexistencia de programas de mantenimiento preventivo y correctivo
Actualización del Plan de Contingencias
Falta de simular el Plan de Contingencias
Inexistencia de contratos con bancos o firmas de seguridad para guardar
información procesada como de programas fuentes
Falta de stock adecuado de partes y suministros de cómputo
Presupuesto insuficiente
1.6.5. Problemas asociados a la adaptación e implementación de la TI
Inexistencia de planes de capacitación en línea.
No tener implementado un sistema de soporte ejecutivo (SSE).
No tener implementado un sistema para el soporte de decisiones (SSD).
No tener recursos de software para realizar minería de datos (Data Mining).
No tener implementado una bodega de datos (Data Warehouse).
No poseer un sistema de control de gestión.
No tener aplicativos orientados a la Web.
Ausencia de políticas orientadas hacia el e-Commerce.
Pág. 18
Ausencia de políticas orientadas hacia soluciones ERP (Enterprise Resource
Planning).
La no implantación de soluciones SCM (Supply Chain Management).
La no implantación de soluciones CRM (Customer Relationship Management).
La no implantación de soluciones BI (Business Intelligence).
Carencia de la infraestructura de computación y comunicación para implantar el
gobierno digital.
Inexistencia del software y hardware para soportar grupos de trabajo
(Groupware).
Inexistencia del software y hardware para soportar el flujo de trabajo
(Workflow).
Inexistencia del software y hardware para soportar el sistema de atención al
cliente (SAC).
Inexistencia de personal altamente capacitado.
Inexistencia de equipos de trabajo de alto rendimiento.
La falta de un rediseño estructural y funcional.
Inexistencia de una plataforma computacional empresarial.
Inexistencia de una plataforma computacional inter-empresarial.
Ausencia de políticas orientadas hacia el comercio exterior.
Ausencia de un gobierno integrado.
Ausencia de un gobierno interconectado con otros.
No tener implementado un sistema de información para trabajadores del
conocimiento.
1.6.6. Problemas asociados a la seguridad de la función informática
Ausencia de políticas de seguridad.
Inexistencia de controles que eviten el acceso físico.
Inexistencia de controles que eviten el acceso lógico.
Inapropiados controles de protección del hardware y el software.
Ausencia de políticas de mantenimiento del hardware y el software.
Vulnerabilidad en la transmisión de datos.
Inexistencia de políticas de backup.
La no existencia de planes de recuperación.
Inexistencia de políticas de generación de passwords.
La no tenencia del software para generar passwords proactivos.
Pág. 19
La no tenencia del software de encriptación de la información.
La ausencia del software y hardware que soporte la política del “muro de fuego”
o firewall.
La falta de políticas para la detección de intrusos.
La no implementación de registros de auditoría por cada SI.
La no existencia de la función de administrador de la base de datos.
La no existencia de elementos de protección contra daños físicos originados en
la naturaleza como incendios, inundaciones, terremotos, u originadas por el
hombre como asonadas y terrorismo.
1.6.7. Problemas asociados a la gestión de la función informática
La existencia de diversas plataformas computacionales no integradas.
La no existencia de un SI que soporte el nivel gerencial.
La no existencia de un SI que soporte el nivel ejecutivo.
La no existencia de un SI que soporte el nivel de los trabajadores del
conocimiento.
La falta de integralidad entre los diversos SI.
La utilización poco eficaz de los recursos informáticos.
Estándares de productividad de los SI bajos.
La no concordancia de los objetivos de los sistemas con los objetivos
corporativos.
La no aplicación de modelos cibernéticos a la función informática.
La no implantación de soluciones empresariales integrales que faciliten
administrar con eficiencia las operaciones de la empresa.
La no implantación de nuevas prácticas de hacer negocios.
La no existencia de un sistema de control de gestión de la información.
La no tenencia de herramientas de software y hardware para gestionar
conocimiento.
La no aplicación de los paradigmas tecnológicos de sistemas abiertos,
interconexión, cliente/servidor, tiempo real, bodega de datos, modelos
cibernéticos, descubrimiento del conocimiento en bases de datos, momentos
de la verdad1 y aplicativos Web.
1 El momento de la verdad es el preciso instante en que el cliente se pone en contacto con el servicio de
una empresa y sobre la base de este contacto se forma una opinión acerca de la calidad del mismo.
Pág. 20
La no aplicación de los paradigmas organizacionales de estandarización de
procesos, emponderamiento, independencia del espacio y el tiempo,
flexibilidad, reingeniería, inmediatez y/o oportunidad en la atención al cliente,
especialización de habilidades, pertenencia, equipos de alto desempeño y
novedosas relaciones exteriores.
1.6.8. Problemas asociados al procesamiento electrónico de los datos
La no estandarización de procedimientos de captura, entrada e introducción de
datos en el sistema.
La no integralidad de los datos durante el procesamiento.
La no documentación de los errores de proceso.
La falta de implementar bitácoras que registren todo el proceso.
La falta de segregar funciones durante el procesamiento.
La falta de pistas de auditoría.
La no normalización de la producción y distribución de las salidas del sistema.
La falta de controlar el acceso a la base de datos.
La falta de privacidad de los datos contenidos en la base de datos.
La no utilización de una metodología formal de desarrollo de SI.
La realización de una deficiente modelación conceptual durante la etapa de
análisis de sistemas.
La definición de un no buen modelo de datos durante la etapa de diseño de
sistemas.
La existencia de inapropiadas interfases de usuario.
La no existencia de los manuales del sistema como del usuario.
El no empleo de lenguajes estructurados u orientados a objetos durante la
etapa de prototipado.
La no realización de pruebas previas a la implantación.
La no normalización de los procedimientos de captura de datos en línea.
La no encriptación de la información a transmitir.
1.7. Chief Audit Executive (CAE)
CAE es un ejecutivo independiente de alto nivel con la responsabilidad general de la
Auditoría Interna. También es llamado Director de Auditoría, Director de Auditoría
Interna, Auditor General, o Contralor General.
Pág. 21
CAPÍTULO II
ESTÁNDARES Y DIRECTRICES DE AUDITORÍA DE SISTEMAS DE INFORMACIÓN
2.1. Marco general de normas de ISACA para la auditoría de SI
ISACA define tres conceptos importantes [7]:
• Normas: Definen los requisitos obligatorios para la auditoría y para los reportes
de auditoría de SI
• Lineamientos (directrices): Brindan una guía para aplicar las normas.
Determina cómo implementar las normas
• Procedimientos (herramientas y técnicas): Ofrecen ejemplos de
procedimientos que debe seguir un auditor. Los documentos de procedimientos
brindan información sobre la manera de cumplir con las normas cuando se está
realizando un trabajo de auditoría, pero no establecen requisitos
2.2. Relación entre normas, directrices y procedimientos
Las normas o estándares deben ser cumplidas por el auditor de SI, mientras que los
lineamientos proveen una guía sobre cómo puede el auditor implementar las normas
en diversas tareas de auditoría. Los procedimientos (herramientas y técnicas) proveen
ejemplos de pasos que puede realizar el auditor para implementar las normas en una
tarea específica de auditoría.
El auditor debe hacer uso de su juicio profesional cuando use las directrices y los
procedimientos.
2.3. Código de ética profesional (ISACA)
El código de ética profesional planteado por ISACA contiene siete aspectos
importantes [7]:
1. Apoyar la implementación y fomentar el cumplimiento de las normas, los
procedimientos y los controles apropiados en los SI.
Pág. 22
2. Ejecutar sus labores con objetividad, diligencia y cuidado profesional, de
conformidad con las normas y mejores prácticas profesionales.
3. Servir en el interés de las partes interesadas en una forma legal y honesta, y al
mismo tiempo mantener altos estándares de conducta y de carácter, y no
involucrarse en actos que puedan desacreditar la profesión.
4. Mantener la privacidad y la confidencialidad de la información obtenida en el
curso de su función a menos que la autoridad legal requiera su revelación.
Dicha información no será usada para beneficio personal ni será revelada a
terceros.
5. Mantener competencia en sus respectivos campos y comprometerse a
emprender únicamente las actividades que se espera que puedan realizar con
competencia profesional.
6. Informar a las personas adecuadas los resultados del trabajo realizado,
revelando todos los hechos significativos de los que tengan conocimiento.
7. Apoyar la formación profesional de las partes interesadas para mejorar su
comprensión sobre seguridad y control de SI.
2.4. Estándares de Auditoría
Los estándares aplicables a la auditoría de SI son [7]:
S1 Estatuto de Auditoría
S2 Independencia
S3 Ética Profesional y Estándares
S4 Competencia Profesional
S5 Planificación
S6 Ejecución del Trabajo de Auditoría
S7 Reportes
S8 Actividades de Seguimiento
S9 Irregularidades y Actos Ilegales
S10 Gobierno de TI
S11 Uso de la Evaluación de Riesgos en la Planificación de Auditoría
S12 Materialidad de la Auditoría
S13 Uso del Trabajo de Otros Expertos
S14 Evidencia de Auditoría
S15 Controles de TI
S16 Comercio Electrónico
Pág. 23
2.5. Directrices de Auditoría
Las directrices de auditoría son las siguientes [7]:
G1 Uso del trabajo de otros auditores, con efecto a partir del 1 de marzo de
2008
G2 Requerimiento de Evidencia de Auditoría, con efecto a partir del 1 de mayo
de 2008
G3 Uso de Técnicas de Auditoría Asistidas por Computadora (CAATs), con
efecto a partir del 1 de marzo de 2008
G4 Contratación de servicios externos de actividades de SI para otras
organizaciones, con efecto a partir del 1 de mayo de 2008
G5 Estatuto de Auditoría, con efecto a partir del 1 de febrero de 2008
G6 Conceptos de materialidad para la Auditoría de Sistemas de Información,
con efecto a partir del 1 de mayo de 2008
G7 Debido Cuidado Profesional, con efecto a partir del 1 de marzo de 2008
G8 Documentación de la Auditoría, con efecto a partir del 1 de marzo de 2008
G9 Consideraciones de Auditoría para Casos de Irregularidades, con efecto a
partir del 1 de septiembre de 2008
G10 Muestreo de Auditoría, con efecto a partir del 1 de agosto de 2008
G11 Efecto de los Controles Generales de SI, con efecto a partir del 1 de
agosto de 2008
G12 Relación organizacional e Independencia, con efecto a partir del 1 de
agosto de 2008
G13 Uso de la Evaluación de riesgos en la Planificación de la Auditoría, con
efecto a partir del 1 de agosto de 2008
G14 Revisión de los Sistemas de Aplicación, con efecto a partir del 1 de
octubre de 2008
G15 Planificación Revisada, con efecto a partir del 1 de mayo de 2010
G16 Efecto de Terceros en los Controles de TI de una Organización, con efecto
a partir del 1 de marzo de 2009
G17 Efecto del Rol No Auditor sobre la Independencia del Auditor de SI, con
efecto a partir del 1 de mayo de 2010
G18 Gobierno de TI, con efecto a partir del 1 de mayo de 2010
G19 Irregularidades y Actos Ilegales, Eliminada, 1 de septiembre de 2008
G20 Reportes, con efecto a partir del 1 de enero de 2003
Pág. 24
G21 Revisión de Sistemas de Planificación de Recursos Empresariales (ERP),
con efecto a partir del 1 de agosto de 2003
G22 Revisión del Comercio Electrónico Negocio-a-Consumidor (B2C), con
efecto a partir del 1 de octubre de 2008
G23 Revisión del Ciclo de Vida de Desarrollo de Sistemas (SDLC), con efecto
a partir del 1 de agosto de 2003
G24 Banca por Internet, con efecto a partir del 1 de agosto de 2003
G25 Revisión de Redes Privadas Virtuales, con efecto a partir del 1 de julio de
2004
G26 Revisión de Proyectos de Reingeniería de Procesos de Negocio (BPR),
con efecto a partir del 1 de julio de 2004
G27 Computación Móvil, con efecto a partir del 1 de septiembre de 2004
G28 Cómputo Forense, con efecto a partir del 1 de septiembre de 2004
G29 Revisión Posterior a la Implementación, con efecto a partir del 1 de enero
de 2005
G30 Competencia, con efecto a partir del 1 de junio de 2005
G31 Privacidad, con efecto a partir del 1 de junio de 2005
G32 Revisión del Plan de Continuidad del Negocio desde una perspectiva de
TI, con efecto a partir del 1 de septiembre de 2005
G33 Consideraciones Generales sobre el Uso de Internet, con efecto a partir
del 1 de marzo de 2006
G34 Responsabilidad, Autoridad y Rendición de cuentas, con efecto a partir del
1 de marzo de 2006
G35 Actividades de seguimiento, con efectos a partir del 1 de marzo de 2006
G36 Controles Biométricos, con efecto a partir del 1 de febrero de 2007
G37 Gestión de Configuración, con efecto a partir del 1 de noviembre de 2007
G38 Control de Acceso, con efecto a partir del 1 de febrero de 2008
G39 Organizaciones de TI, con efecto a partir del 1 de mayo de 2008
G40 Revisión de Prácticas de Gestión de Seguridad, con efecto a partir del 1
de octubre de 2008
G41 Retorno sobre la inversión en seguridad (ROSI), efectiva a partir del 1 de
mayo de 2010
G42 Aseguramiento continuo, efectiva a partir del 1 de mayo de 2010
2.6. Herramientas y técnicas
Pág. 25
Las herramientas y técnicas son las siguientes:
P1 Evaluación de Riesgos de SI, con efecto a partir del 1 de julio de 2002
P2 Firmas Digitales, con efecto a partir del 1 de julio de 2002
P3 Detección de Intrusos, con efecto a partir del 1 de agosto de 2003
P4 Virus y Otros Códigos Maliciosos, con efecto a partir del 1 de agosto de
2003
P5 Autoevaluación de Control de Riesgos, con efecto a partir del 1 de agosto
de 2003
P6 Cortafuegos (firewalls), con efecto a partir del 1 de agosto de 2003
P7 Irregularidades y Actos Ilegales, con efecto a partir del 1 de noviembre de
2003
P8 Evaluación de la Seguridad - Pruebas de Penetración y Análisis de
Vulnerabilidades, con efecto a partir del 1 de septiembre de 2004
P9 Evaluación de los Controles de Gestión sobre las Metodologías de
Encriptación, con efecto a partir del 1 de enero de 2005
P10 Control de Cambios de Aplicación del Negocio, con efecto a partir del 1 de
octubre de 2006
P11 Transferencia Electrónica de Datos (EFT), con efecto a partir del 1 de
mayo de 2007
Pág. 26
CAPÍTULO III
ANÁLISIS DE RIESGOS DE TECNOLOGÍAS DE LA INFORMACIÓN
3.1. Análisis de Riesgos
Es parte de la planificación de auditoría y ayuda a identificar los riesgos y las
vulnerabilidades para que el auditor de SI pueda determinar los controles necesarios
para mitigar los riesgos [7].
Es importante que el auditor de SI tenga una comprensión clara de los siguientes
aspectos [7]:
El propósito y la naturaleza del negocio, el entorno en el que opera el negocio y
los riesgos del negocio relacionados
La dependencia en tecnología y dependencias relacionadas que procesan y
entregan información del negocio
Los riesgos para el negocio que supone el uso de TI y de las dependencias
relacionadas y cómo impactan en el logro de las metas y los objetivos del
negocio
Una buena visión general de los procesos del negocio y del impacto de TI y los
riesgos relacionados en los objetivos de los procesos del negocio
3.2. Marco referencial del Análisis de Riesgo
El modelo comienza a partir de la valoración de los activos, que consiste en que la
información tiene los criterios requeridos para ayudar a alcanzar los objetivos del
negocio. El paso siguiente es el análisis de vulnerabilidad, que trata acerca de la
importancia de los criterios de información dentro del proceso bajo revisión. Luego se
tratan las amenazas, es decir, aquello que puede provocar una vulnerabilidad. La
probabilidad de amenaza, el grado de vulnerabilidad y la severidad del impacto se
combinan para concluir acerca de la evaluación del riesgo. Esto es seguido por la
selección de controles (contramedidas) y una evaluación de su eficacia, que también
identifica el riesgo residual. La conclusión es un plan de acción [8].
Pág. 27
Figura 1: Marco referencial del análisis de riesgo [8]
3.3. Marco de riesgos de TI
El marco de riesgos de TI (IT Risk Framework) es “un marco basado en un conjunto
de principios y guías, procesos de negocio y directrices de gestión que se ajustan a
estos principios” [9]. Establece las mejores prácticas con el fin de establecer un marco
para las organizaciones para identificar, gobernar y administrar los riesgos asociados
al negocio. Este marco se complementa con COBIT.
El marco de riesgos de TI es utilizado para ayudar a implementar el gobierno de TI.
3.4. Riesgos de TI
Son un componente del universo de riesgos a los que está sometida una organización
[9].
3.5. Categorías de los riesgos de TI
Los riesgos de TI pueden clasificarse de diversas maneras (Figura 2):
El valor de los riesgos de TI permitidos: Asociado con las oportunidades no
aprovechadas para mejorar la eficiencia o efectividad de los procesos de
negocio, o la capacidad de soportar nuevas iniciativas, a través del uso de la
tecnología.
Programas de TI y riesgos en las entregas de proyectos: Asociada a la
contribución de IT sobre nuevas soluciones de negocio, generalmente en forma
de proyectos y programas.
Pág. 28
Operaciones de TI y riesgos en las entregas de servicios: Asociadas con
todos los aspectos relacionados con los servicios y sistemas de TI, los cuales
puede producir pérdidas o reducción del valor a la organización.
Figura 2: Clasificación de los riesgos de TI [9]
3.6. Apetito de riesgo
Es la cantidad de riesgo que una entidad está dispuesta a aceptar cuando trata de
alcanzar sus objetivos. Se puede definir en la práctica en términos de combinaciones
de la frecuencia y la magnitud de un riesgo. El apetito de riesgo puede y será diferente
entre las organizaciones [9].
Pág. 29
CAPÍTULO IV
CONTROL INTERNO INFORMÁTICO
El presente capítulo intenta resumir y explicar uno de los conceptos más importantes
de la auditoría de sistemas de información: el control interno informático o de TI.
Primero se explican las características del control interno y posteriormente las
características del control interno de TI.
4.1. Control Interno
Control se define como “las políticas, procedimientos, prácticas y estructuras
organizacionales diseñadas para garantizar razonablemente que los objetivos del
negocio serán alcanzados y que los eventos no deseables serán prevenidos o
detectados y corregidos” [8]. Esta definición ha sido adaptada del reporte COSO
(Committee of Sponsoring Organisations of the Treadway Commission. Internal
Control-Integrated Framework, 1992).
Los controles internos son implementados para reducir los riesgos para la
organización, y operan en todos los niveles de dicha organización para mitigar su
exposición a riesgos que potencialmente podrían impedirle alcanzar sus objetivos del
negocio [7].
Existen dos aspectos clave que los controles deben atender [7]: qué debería lograrse y
qué debería evitarse.
Los controles pueden ser: preventivos, detectivos o correctivos (Tabla 2).
Tabla 2: Clasificaciones de control [7]
Clase Función Ejemplos
Preventivos Detectan los problemas antes de que aparezcan.
Monitorean tanto la operación como las entradas.
Intentan predecir los problemas potenciales antes de que ocurran y realizan ajustes.
Evitan que ocurra un error, omisión o acto malicioso.
Emplean sólo personal calificado.
Segregan funciones (factor disuasivo).
Controlan el acceso a instalaciones físicas.
Utilizan documentos bien diseñados (evita errores).
Establecen procedimientos adecuados para la autorización de transacciones.
Completan verificaciones de edición programadas.
Pág. 30
Utilizan software de control de acceso que permita que sólo el personal autorizado tenga acceso a archivos sensibles.
Utilizan software de encriptación para evitar la divulgación no autorizada de datos.
Detectivos Utilizan controles que detectan e informan la ocurrencia de un error, omisión o acto fraudulento.
Totales de comprobación (hash totals).
Puntos de verificación en trabajos de producción.
Controles de eco en telecomunicaciones.
Mensajes de error en etiquetas de cintas.
Verificación duplicada de cálculos.
Reporte de rendimiento periódico con variaciones.
Informes de cuentas vencidas.
Funciones de auditoría interna.
Revisión de registros (logs) de actividad para detectar intentos de acceso no autorizado.
Correctivos Minimizar el impacto de una amenaza.
Remediar problemas descubiertos por controles detectivos.
Identificar la causa de un problema.
Corregir errores que surgen de un problema.
Modificar los sistemas de procesamiento para minimizar futuras ocurrencias del problema.
Planificación de contingencia.
Procedimientos de respaldo.
Procedimientos de nueva ejecución.
4.2. Control Interno Informático o de TI
El control interno informático “controla diariamente que todas las actividades de
sistemas de información sean realizadas cumpliendo los procedimientos, estándares y
normas fijados por la Dirección de la Organización y/o Dirección de Informática, así
como los requerimientos legales” [4]. Suele ser un órgano de staff o de apoyo de la
Dirección del Departamento de Informática.
La misión del control de TI es asegurarse de que las medidas que se obtienen de los
mecanismos implantados por cada responsable sean correctas y válidas [4].
Pág. 31
La jerarquía de los controles de TI (Figura 3) representa una lógica de “arriba abajo”.
Los diferentes elementos de la jerarquía no son mutuamente excluyentes, sino que
están conectados y pueden entremezclarse [10]:
Gobernabilidad: Políticas.
Gestión: Estándares, Organización y Gestión, Controles Físicos y del Entorno.
Técnico: Controles de Software de Sistemas, Controles de Desarrollo de
Sistemas, Controles basados en Aplicación.
Figura 3: La jerarquía de los controles de TI [10]
4.3. Objetivo de control interno informático o de TI
Es “una sentencia del resultado o propósito que se desea alcanzar implementando
procedimientos de control en una actividad de TI particular” [8]. Esta definición ha sido
adaptada del reporte SAC (Systems Auditability and Control Report, The Institute of
Internal Auditors Research Foundation, 1991 y 1994).
Un objetivo de control se refiere a cómo debe funcionar un control interno [4].
Los objetivos de control de TI [11]:
Proporcionan un conjunto completo de requerimientos de alto nivel a
considerar por la gerencia para un control efectivo de cada proceso de TI.
Pág. 32
Son sentencias de acciones de gerencia para aumentar el valor o reducir el
riesgo.
Consisten en políticas, procedimientos, prácticas y estructuras
organizacionales.
Están diseñadas para proporcionar un aseguramiento razonable de que los
objetivos de negocio se conseguirán y que los eventos no deseables se
prevendrán, detectarán y corregirán.
Los objetivos de control interno informático pueden incluir [7]:
La salvaguarda de activos. La información en los sistemas automatizados está
protegida contra accesos inadecuados y se la mantiene actualizada.
Asegurar la integridad de los ambientes de sistemas operativos en general,
incluyendo las operaciones y gestión de la red.
Asegurar la integridad de los ambientes de sistemas de aplicación sensibles y
críticos, incluyendo información contable/financiera y de gestión (objetivos de
información) y de los datos del cliente a través de:
o Autorización para el ingreso de datos. Cada transacción es autorizada e
introducida una sola vez.
o Validación de la entrada de datos. Cada dato ingresado es validado y
no causará impacto negativo al procesamiento de las transacciones.
o Exactitud e integridad del procesamiento de transacciones. Todas las
transacciones son registradas e ingresadas en la computadora en el
período correcto.
o Confiabilidad de las actividades de procesamiento de información en
general.
o Exactitud, integridad y seguridad de la información de salida.
o Integridad, disponibilidad y confidencialidad de la base de datos.
Asegurar la identificación y autenticación apropiada de los usuarios de los
recursos de SI (usuarios finales así como también soporte de infraestructura).
Aseguramiento de la eficiencia y efectividad de las operaciones (objetivos
operativos).
Cumplimiento con los requerimientos de los usuarios, con las políticas y los
procedimientos organizacionales, así como con las leyes y reglamentaciones
aplicables (objetivos de cumplimiento).
Aseguramiento de la disponibilidad de los servicios de TI desarrollando planes
de continuidad del negocio (BCP) y de recuperación de desastres (DRP).
Pág. 33
Mejora de la protección de datos y sistemas desarrollando un plan de
respuesta a incidentes.
Aseguramiento de la integridad y confiabilidad de los sistemas implementando
procedimientos efectivos de gestión de cambios.
La gerencia de la empresa necesita tomar decisiones relativas a estos objetivos de
control para [11]:
Seleccionar aquellos aplicables.
Decidir aquellos que deben implementarse.
Elegir como implementarlos (frecuencia, extensión, automatización, etc.)
Aceptar el riesgo de no implementar aquellos que podrían aplicar.
Pág. 34
CAPÍTULO V
EL MARCO REFERENCIAL DE COBIT
COBIT es un marco de trabajo ampliamente usado para el aseguramiento de TI y para
la auditoría de SI. Por lo tanto, es muy importante conocer sus características más
relevantes.
5.1. La misión de COBIT
Investigar, desarrollar, hacer público y promover un marco de control de gobierno de TI
autorizado, actualizado, aceptado internacionalmente para la adopción por parte de las
empresas y el uso diario por parte de gerentes de negocio, profesionales de TI y
profesionales de aseguramiento.
5.2. Definición y características de COBIT
COBIT proviene del inglés “Control Objectives for Information and related Technology”
y se traduce como Objetivos de Control para la Información y Tecnologías
Relacionadas. Es un conjunto completo de recursos que contiene toda la información
que las organizaciones necesitan para adoptar un marco de trabajo de gobierno de TI
y control [12]. Este marco de trabajo (framework) “proporciona un modelo de procesos
de referencia y un lenguaje común para que todos en la empresa visualicen y
administren las actividades de TI”; para “la medición y monitoreo del desempeño de TI,
comunicándose con los proveedores de servicios e integrando las mejores prácticas
de administración” [11].
COBIT da soporte al gobierno de TI al brindar un marco de trabajo que garantiza que
[11]:
TI está alineada con el negocio
TI habilita al negocio y maximiza los beneficios
Los recursos de TI se usan de manera responsable
Los riesgos de TI se administran apropiadamente
Para gobernar efectivamente TI, es importante determinar las actividades y los riesgos
que requieren ser administrados.
Pág. 35
COBIT contribuye a las necesidades de la empresa en [12]:
Establecer una relación mensurable entre los requerimientos del negocio y las
metas de TI.
Organizar las actividades de TI dentro de un modelo de procesos generalmente
aceptado.
Identificar los recursos principales de TI para ser aprovechados.
Definir los objetivos de control de gestión a ser considerados.
Proporcionar herramientas para la gestión:
o Metas y métricas (indicadores) de desempeño de TI permitido a ser
medido.
o Modelos de madurez de la capacidad del proceso permitido como punto
de referencia.
o Gráficos de responsable, rendición de cuentas (accountable),
consultado e informado (RACI) para aclarar los roles y
responsabilidades.
Los procesos de TI, requerimientos del negocio y objetivos de control de COBIT
definen lo que hay que hacer para implementar una estructura de control efectiva para
mejorar el rendimiento de TI y direccionar la solución de TI y los riesgos de entrega de
servicio [12].
El concepto fundamental de COBIT se refiere a que “el enfoque del control en TI se
lleva a cabo visualizando la información necesaria para dar soporte a los procesos de
negocio y considerando a la información como el resultado de la aplicación combinada
de recursos relacionados con la Tecnología de Información que deben ser
administrados por procesos de TI” [8].
Para satisfacer los objetivos del negocio, la información necesita concordar con ciertos
criterios a los que COBIT hace referencia como requerimientos de negocio para la
información [5]:
Requerimientos de calidad:
Calidad
Costo
Entrega o Distribución (de servicio)
Pág. 36
Requerimientos fiduciarios (COSO):
Efectividad y eficiencia de las operaciones
Confiabilidad de la información
Cumplimiento de leyes y regulaciones
Requerimientos de seguridad:
Confidencialidad
Integridad
Disponibilidad
A partir de lo anterior (requerimientos de Calidad, Fiduciarios y de Seguridad), COBIT
extrae siete categorías distintas, ciertamente superpuestas [8], [11] :
Efectividad: Se refiere a que la información relevante sea pertinente para el
proceso del negocio, así como a que su entrega sea oportuna, correcta,
consistente y de manera utilizable.
Eficiencia: Se refiere a la provisión de información a través de la utilización
óptima (más productiva y económica) de recursos.
Confidencialidad: Se refiere a la protección de información sensible contra
divulgación no autorizada.
Integridad: Se refiere a la precisión y completitud de la información, así como
a su validez de acuerdo con los valores y expectativas del negocio.
Disponibilidad: Se refiere a la disponibilidad de la información cuando ésta es
requerida por el proceso de negocio ahora y en el futuro. También se refiere a
la salvaguarda de los recursos necesarios y capacidades asociadas.
Cumplimiento: Se refiere al cumplimiento de aquellas leyes, regulaciones y
acuerdos contractuales a los que está sujeto el proceso del negocio, es decir,
criterios de negocio impuestos externamente, así como políticas internas.
Confiabilidad: Se refiere a proporcionar la información apropiada para que la
gerencia administre la entidad y ejerza sus responsabilidades fiduciarias y de
gobierno.
Los recursos de TI se definen de la siguiente manera [11]:
Las aplicaciones incluyen tanto sistemas de usuario automatizados como
procedimientos manuales que procesan información.
Pág. 37
La información son los datos en todas sus formas, de entrada, procesados y
generados por los sistemas de información, en cualquier forma en que sean
utilizados por el negocio.
La infraestructura es la tecnología y las instalaciones (hardware, sistemas
operativos, sistemas de administración de base de datos, redes, multimedia,
etc., así como el sitio donde se encuentran y el ambiente que los soporta) que
permiten el procesamiento de las aplicaciones.
Las personas son el personal requerido para planear, organizar, adquirir,
implementar, entregar, soportar, monitorear y evaluar los sistemas y los
servicios de información. Estas pueden ser internas, por outsourcing o
contratadas, de acuerdo a como se requieran.
Una forma de ver la relación de los recursos de TI con respecto a la entrega de
servicios se describe en la Figura 4:
Figura 4: Relación entre recursos de TI y entrega de servicios [8]
Con el fin de asegurar que los requerimientos del negocio para la información se
cumplan, es necesario definir, implementar y monitorear adecuadas medidas de
control sobre esos recursos. ¿Cómo pueden entonces las empresas estar satisfechas
respecto a que la información obtenida presente las características que necesitan? Es
aquí donde se requiere de un sano marco referencial de Objetivos de Control para TI.
La Figura 5 ilustra este concepto.
Pág. 38
Figura 5: Relación entre procesos de negocio, información y recursos de TI [8]
Existen tres niveles de actividades de TI al considerar la administración de sus
recursos. En la base se encuentran las actividades y tareas necesarias para alcanzar
un resultado medible. Las actividades cuentan con un concepto de ciclo de vida,
mientras que las tareas son consideradas más discretas. Los procesos se definen
como “una serie de actividades o tareas conjuntas con „cortes‟ naturales (de control)”
[8]. En el nivel superior se encuentran los dominios, que se encargan de agrupar los
procesos de manera natural.
Figura 6: Dominios, procesos y actividades [8]
Por lo tanto, COBIT puede ser enfocado desde tres puntos estratégicos (puntos de
vista) diferentes: (1) requerimientos de negocio (criterios de información); (2) recursos
Pág. 39
de TI, y (3) procesos de TI. Los tres elementos forman el llamado Cubo de COBIT que
se muestra a continuación:
Figura 7: El Cubo de COBIT [11]
Figura 8: Los cuatro dominios interrelacionados de COBIT [11]
COBIT define las actividades de TI en un modelo genérico de procesos organizado en
cuatro dominios. Estos dominios son [11]:
Planear y Organizar (PO): Proporciona dirección para la entrega de
soluciones (AI) y la entrega de servicio (DS).
Adquirir e Implementar (AI): Proporciona las soluciones y las pasa para
convertirlas en servicios.
Pág. 40
Entregar y Dar Soporte (DS): Recibe las soluciones y las hace utilizables por
los usuarios finales.
Monitorear y Evaluar (ME): Monitorea todos los procesos para asegurar que
se sigue la dirección provista.
Los dominios se equiparan a las áreas tradicionales de TI de planear, construir,
ejecutar y monitorear.
5.3. Planear y Organizar (PO)
Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la
manera en que TI puede contribuir de la mejor manera al logro de los objetivos del
negocio. Además, la realización de la visión estratégica requiere ser planeada,
comunicada y administrada desde diferentes perspectivas. Finalmente, se debe
implementar una estructura organizacional y una estructura tecnológica apropiada.
Este dominio cubre los siguientes cuestionamientos típicos de la gerencia:
¿Están alineadas las estrategias de TI y del negocio?
¿La empresa está alcanzando un uso óptimo de sus recursos?
¿Entienden todas las personas dentro de la organización los objetivos de TI?
¿Se entienden y administran los riesgos de TI?
¿Es apropiada la calidad de los sistemas de TI para las necesidades del
negocio?
5.4. Adquirir e Implementar (AI)
Para llevar a cabo la estrategia de TI, las soluciones de TI necesitan ser identificadas,
desarrolladas o adquiridas así como implementadas e integradas en los procesos del
negocio. Además, el cambio y el mantenimiento de los sistemas existentes está
cubierto por este dominio para garantizar que las soluciones sigan satisfaciendo los
objetivos del negocio. Este dominio, por lo general, cubre los siguientes
cuestionamientos de la gerencia:
¿Es probable que los nuevos proyectos generan soluciones que satisfagan las
necesidades del negocio?
¿Es probable que los nuevos proyectos sean entregados a tiempo y dentro del
presupuesto?
Pág. 41
¿Trabajarán adecuadamente los nuevos sistemas una vez sean
implementados?
¿Los cambios no afectarán a las operaciones actuales del negocio?
5.5. Entregar y Dar Soporte (DS)
Este dominio cubre la entrega en sí de los servicios requeridos, lo que incluye la
prestación del servicio, la administración de la seguridad y de la continuidad, el soporte
del servicio a los usuarios, la administración de los datos y de las instalaciones
operativos.
Por lo general cubre las siguientes preguntas de la gerencia:
¿Se están entregando los servicios de TI de acuerdo con las prioridades del
negocio?
¿Están optimizados los costos de TI?
¿Es capaz la fuerza de trabajo de utilizar los sistemas de TI de manera
productiva y segura?
¿Están implantadas de forma adecuada la confidencialidad, la integridad y la
disponibilidad?
5.6. Monitorear y Evaluar (ME)
Todos los procesos de TI deben evaluarse de forma regular en el tiempo en cuanto a
su calidad y cumplimiento de los requerimientos de control. Este dominio abarca la
administración del desempeño, el monitoreo del control interno, el cumplimiento
regulatorio y la aplicación del gobierno. Por lo general abarca las siguientes preguntas
de la gerencia:
¿Se mide el desempeño de TI para detectar los problemas antes de que sea
demasiado tarde?
¿La Gerencia garantiza que los controles internos son efectivos y eficientes?
¿Puede vincularse el desempeño de lo que TI ha realizado con las metas del
negocio?
¿Se miden y reportan los riesgos, el control, el cumplimiento y el desempeño?
5.7. Objetivos de control
Pág. 42
Cada uno de los procesos de TI de COBIT tiene un objetivo de control de alto nivel y
varios objetivos de control detallados. Como un todo, representan las características
de un proceso bien administrado.
Los objetivos de control detallados se identifican por dos caracteres que representan el
dominio (PO, AI, DS y ME) más un número de proceso y un número de objetivo de
control. Además de los objetivos de control detallados, cada proceso de TI tiene
requerimientos de control genéricos que se identifican con PCn, que significa Control
de Proceso número. Se deben tomar como un todo junto con los objetivos de control
del proceso para tener una visión completa de los requerimientos de control.
Los objetivos de control genérico son [11]:
PC1 Metas y Objetivos del Proceso
Definir y comunicar procesos, metas y objetivos específicos, medibles, accionables,
reales, orientados a resultado y en tiempo (SMARRT) para la ejecución efectiva de
cada proceso de TI. Asegurando que están enlazados a las metas de negocio y se
soportan por métricas adecuadas.
PC2 Propiedad del Proceso
Asignar un dueño para cada proceso de TI, y definir claramente los roles y
responsabilidades del dueño del proceso. Incluye, por ejemplo, responsabilidad del
diseño del proceso, interacción con otros procesos, rendición de cuentas de los
resultados finales, medición del desempeño del proceso y la identificación de mejora
de las oportunidades.
PC3 Proceso Repetible
Diseñar y establecer cada proceso clave de TI de tal manera que sea repetible y
consecuentemente produzca los resultados esperados. Proveer una secuencia lógica
pero flexible y escalable de actividades que lleve a los resultados deseados y que sea
lo suficientemente ágil para manejar las excepciones y emergencias. Usar procesos
consistentes, cuando sea posible, y ajustarlos sólo cuando no se pueda evitar.
PC4 Roles y Responsabilidades
Definir las actividades clave y entregables finales del proceso. Asignar y comunicar
roles y responsabilidades no ambiguas para la ejecución efectiva y eficiente de las
Pág. 43
actividades clave y su documentación, así como la rendición de cuentas para los
entregables finales del proceso.
PC5 Políticas, Planes y Procedimientos
Definir y comunicar cómo todas las políticas, planes y procedimientos que dirigen los
procesos de TI están documentados, revisados, mantenidos, aprobados,
almacenados, comunicados y usados para el entrenamiento. Asignar
responsabilidades para cada una de estas actividades y en momentos oportunos,
revisar si se ejecutan correctamente. Asegurar que las políticas, planes y
procedimientos son accesibles, correctos, entendidos y actualizados
PC6 Desempeño del Proceso
Identificar un conjunto de métricas que proporcionen visión de las salidas y el
desempeño del proceso. Establecer objetivos que se reflejen en las metas del proceso
y los indicadores de desempeño de tal manera que permitan el logro de las metas de
los procesos.
Definir como los datos son obtenidos. Comparar las medidas actuales con los
objetivos y tomar las acciones sobre las desviaciones cuando sea necesario. Alinear
métricas, objetivos y métodos con el enfoque de monitoreo global del desempeño de
TI.
Cabe aclara que los objetivos de control no son necesariamente aplicables en todos
los casos y en cualquier lugar; por lo tanto, se sugiere que se realice una evaluación
de riesgos de alto nivel para determinar sobre qué objetivos se necesita enfocarse
específicamente y cuáles pueden ignorarse [8]. Asimismo, los objetivos de control de
COBIT han sido definidos de forma genérica, por ejemplo, sin depender de la
plataforma técnica.
La Figura 9 muestra cómo están organizados los objetivos de control de TI de COBIT.
Pág. 44
Figura 9: Organización y navegación de los objetivos de control de TI [8]
5.8. Controles generales de TI y Controles de Aplicación [11]
COBIT asume que el diseño e implementación de los controles de aplicación
automatizados son responsabilidad de TI, y están cubiertos en el dominio de Adquirir e
Implementar (AI), con base en los requerimientos de negocio definidos, usando los
criterios de información de COBIT. La responsabilidad operativa de administrar y
controlar los controles de aplicación no es de TI, sino del dueño del proceso de
negocio.
Por lo tanto, la responsabilidad de los controles de aplicación es una responsabilidad
conjunta, fin a fin, entre el negocio y TI, pero la naturaleza de la responsabilidad
cambia de la siguiente manera:
La empresa es responsable de:
o Definir apropiadamente los requisitos funcionales y de control
o Usar adecuadamente los servicios automatizados
TI es responsable de:
o Automatizar e implementar los requisitos de las funciones de negocio y
de control
Pág. 45
o Establecer controles para mantener la integridad de controles de
aplicación.
Por lo tanto, los procesos de TI de COBIT abarcan a los controles generales de TI,
pero sólo los aspectos de desarrollo de los controles de aplicación; la responsabilidad
de definir y el uso operativo es de la empresa.
Figura 10: Fronteras de los controles de negocio, generales de TI y de aplicación [11]
La siguiente lista ofrece el conjunto recomendado de objetivos de control de
aplicaciones. Identificados por ACn, de Control de Aplicación número (por sus siglas
en inglés) [11]:
AC1 Preparación y Autorización de Información Fuente.
Asegurar que los documentos fuente están preparados por personal autorizado y
calificado siguiendo los procedimientos establecidos, teniendo en cuenta una
adecuada segregación de funciones respecto al origen y aprobación de estos
documentos. Los errores y omisiones pueden ser minimizados a través de buenos
diseños de formularios de entrada. Detectar errores e irregularidades para que sean
informados y corregidos.
AC2 Recolección y Entrada de Información Fuente.
Establecer que la entrada de datos se realice en forma oportuna por personal
calificado y autorizado. Las correcciones y reenvíos de los datos que fueron
erróneamente ingresados se deben realizar sin comprometer los niveles de
autorización de las transacciones originales. En donde sea apropiado para
reconstrucción, retener los documentos fuente originales durante el tiempo necesario.
Pág. 46
AC3 Chequeos de Exactitud, Integridad y Autenticidad
Asegurar que las transacciones son exactas, completas y válidas. Validar los datos
ingresados, y editar o devolver para corregir, tan cerca del punto de origen como sea
posible.
AC4 Integridad y Validez del Procesamiento
Mantener la integridad y validación de los datos a través del ciclo de procesamiento.
Detección de transacciones erróneas no interrumpe el procesamiento de
transacciones válidas.
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores
Establecer procedimientos y responsabilidades asociadas para asegurar que la salida
se maneja de una forma autorizada, entregada al destinatario apropiado, y protegida
durante la transmisión; que se verifica, detecta y corrige la exactitud de la salida; y que
se usa la información proporcionada en la salida.
AC6 Autenticación e Integridad de Transacciones
Antes de pasar datos de la transacción entre aplicaciones internas y funciones de
negocio/operativas (dentro o fuera de la empresa), verificar el apropiado
direccionamiento, autenticidad del origen e integridad del contenido. Mantener la
autenticidad y la integridad durante la transmisión o el transporte.
5.9. Modelos de madurez
Figura 11: Representación gráfica de los modelos de madurez [11]
Pág. 47
5.10. El proceso de control
Consiste de cuatro pasos [8]:
Se especifica un estándar de desempeño deseado para un proceso.
Existe un medio de saber qué está sucediendo en el proceso.
La unidad de control compara la información con el estándar.
Si lo que realmente está sucediendo no cumple con el estándar, la unidad de
control dirige aquella acción correctiva a tomar, en forma de información para el
proceso.
Figura 12: El proceso de control [8]
El proceso debe llevarse a cabo teniendo en cuenta lo siguiente:
La responsabilidad en el proceso de TI debe ser claro y la responsabilidad no
debe ser ambigua.
Los estándares pueden ser de una amplia variedad (planes y estrategias de
alto nivel, indicadores clave de desempeño o KPI, y factores críticos de éxito o
CSF). Los estándares deben estar claramente documentados, mantenidos y
comunicados, así como la responsabilidad de la custodia.
El proceso de control debe estar bien documentado en cuanto a cómo funciona
y con responsabilidades claras.
La oportunidad, integridad y conveniencia de la información de control, así
como también otra información, son básicas para el buen funcionamiento de un
sistema de control.
Pág. 48
Tanto la información de control como la información de acción correctiva
tendrán que cumplir los requerimientos de evidencia, con el fin de establecer la
responsabilidad después del evento.
Pág. 49
CAPÍTULO VI
REALIZACIÓN DE UNA AUDITORÍA DE SISTEMAS DE INFORMACIÓN
Para llevar a cabo una auditoría de SI se requiere de un conjunto ordenado de
acciones y procedimientos específicos, de acuerdo a las necesidades especiales de la
organización, así como del tipo de auditoría de SI que se vaya a realizar. Una
metodología de revisión nos permitirá diseñar correctamente los pasos a seguir,
haciendo más sencillo el seguimiento, desarrollo y aplicación de las etapas y eventos
propuestos.
Este capítulo explica brevemente la metodología propuesta por Muñoz Razo [5], la
cual debe tomarse como una guía para el auditor de SI.
6.1. Metodología para realizar Auditoría de SI
Primera etapa: Planeación de la auditoría de SI
P.1 Identificar el origen de la auditoría
P.2 Realizar una visita preliminar al área que será evaluada
P.3 Establecer los objetivos de la auditoría
P.4 Determinar los puntos que serán evaluados en la auditoría
P.5 Elaborar planes, programas y presupuestos para realizar la auditoría
P.6 Identificar y seleccionar los métodos, herramientas, instrumentos y
procedimientos necesarios para la auditoría
P.7 Asignar los recursos y sistemas computacionales para la auditoría
Segunda etapa: Ejecución de la auditoría de SI
E.1 Realizar las acciones programadas para la auditoría
E.2. Aplicar los instrumentos y herramientas para la auditoría
E.3 Identificar y elaborar los documentos de desviaciones encontradas
E.4 Elaborar el dictamen preliminar y presentarlo a discusión
E.5 Integrar el legajo de papeles de trabajo de la auditoría
Tercera etapa: Dictamen de la auditoría de SI
D.1 Analizar la información y elaborar un informe de situaciones detectadas
Pág. 50
D.2 Elaborar el dictamen final
D.3 Presentar el informe de auditoría
A continuación se detalla cada uno de los puntos correspondientes a la primera etapa:
P.1 Identificar el origen de la auditoría
P.1.1 Por solicitud expresa de procedencia interna
P.1.2 Por solicitud expresa de procedencia externa
P.1.3 Como consecuencia de emergencias y condiciones especiales
P.1.4 Por riesgos y contingencias informáticas
P.1.5 Como resultado de los planes de contingencia
P.1.6 Por resultados obtenidos de otras auditorías
P.1.7 Como parte del programa integral de auditoría
P.2 Realizar una vista preliminar al área que será evaluada
P.2.1 Vista preliminar de arranque
P.2.2 Contacto inicial con funcionarios y empleados del área
P.2.3 Identificación preliminar de la problemática del área de sistemas
P.2.4 Prever los objetivos iniciales de la auditoría
P.2.5 Calcular los recursos y personas necesarias para la auditoría
P.3 Establecer los objetivos de la auditoría
P.3.1 Objetivo general
P.3.2 Objetivos particulares
P.3.3 Objetivos específicos de la auditoría de SI
P.4 Determinar los puntos que serán evaluados en la auditoría
P.4.1 Evaluación de las funciones y actividades del personal del área de
sistemas
P.4.2 Evaluación de las áreas y unidades administrativas del centro de
cómputo
P.4.3 Evaluación de la seguridad de los SI
P.4.4 Evaluación de la información, documentación y registros de los sistemas
P.4.5 Evaluación de los sistemas, equipos, instalaciones y componentes
(recursos humanos, hardware, software, información, bases de datos, etc.)
P.4.6 Elegir los tipos de auditoría que serán utilizados
Pág. 51
P.4.7 Determinar los recursos que serán utilizados en la auditoría (personal,
equipos, dinero, etc.)
P.5 Elaborar planes, programas y presupuestos para realizar la auditoría
P.5.1 Elaborar el documento formal de los planes de trabajo para la auditoría
P.5.2 Contenido de los planes para realizar la auditoría
P.5.3 Elaborar el documento formal de los programas de auditoría
P.5.4 Elaborar los programas de actividades para realizar la auditoría
P.5.5 Elaborar los presupuestos para la auditoría
P.6 Identificar y seleccionar los métodos, herramientas, instrumentos y
procedimientos necesarios para la auditoría
P.6.1 Establecer la guía de ponderación de los puntos que serán evaluados
P.6.2 Elaborar la guía de la auditoría
P.6.3 Elaborar los documentos necesarios para la auditoría
P.6.4 Determinar herramientas, métodos, y procedimientos para la auditoría de
SI
P.6.5 Diseñar los sistemas, programas y métodos de pruebas para la auditoría
P.7 Asignar los recursos y sistemas computacionales para la auditoría
P.7.1 Asignar los recursos humanos para la realización de la auditoría
P.7.2 Asignar los recursos informáticos y tecnológicos para la realización de la
auditoría
P.7.3 Asignar los recursos materiales y de consumo para la realización de la
auditoría
P.7.4 Asignar los demás recursos para la realización de la auditoría
La segunda etapa es la de ejecución, en la cual el auditor o grupo de auditores deben
cumplir con lo planificado en la primera etapa.
El detalle de la tercera etapa se muestra a continuación:
D.1 Analizar la información y elaborar un informe de situaciones detectadas
D.1.1 Analizar los papeles de trabajo
D.1.2 Señalar las situaciones encontradas
D.1.3 Comentar las situaciones encontradas con el personal de las áreas
afectadas
Pág. 52
D.1.4 Realizar las modificaciones necesarias
D.1.5 Elaborar un documento de situaciones relevantes
D.2 Elaborar el dictamen final
D.2.1 Analizar la información y elaborar un documento de desviaciones
detectadas
D.2.2 Elaborar el informe y el dictamen de auditoría
D.2.3 Comentar el informe y el dictamen con los directivos del área
D.2.4 Realizar las modificaciones necesarias
D.3 Presentar el informe de auditoría
D.3.1 Elaboración del dictamen formal
D.3.2 Integración del informe de auditoría
D.3.3 Presentación del informe de auditoría
D.3.4 Integración de los papeles de trabajo
6.2. El Proceso de Auditoría
La estructura generalmente aceptada del proceso de auditoría es [8]:
Identificación y documentación
Evaluación
Pruebas de cumplimiento
Pruebas sustantivas
El proceso de TI, por lo tanto, se audita mediante [8]:
La obtención de un entendimiento de los riesgos relacionados con los
requerimientos del negocio y de las medidas relevantes de control.
La evaluación de la conveniencia de los controles establecidos.
La valoración del cumplimiento probando si los controles establecidos están
funcionando como se espera, de manera consistente y continua.
La comprobación que existe el riesgo de que los objetivos de control no se
estén cumpliendo mediante el uso de técnicas analíticas y/o consultando
fuentes alternativas.
6.3. Requerimientos del Proceso de Auditoría
Pág. 53
Luego de definir qué se va a auditar tenemos que determinar el enfoque o estrategia
más apropiada para llevar a cabo el trabajo de auditoría, haciendo lo siguiente [8]:
Determinar el alcance correcto de la auditoría. Es necesario investigar,
analizar y definir:
o Los procesos del negocio involucrados.
o Las plataformas y los SI que están apoyando el proceso del negocio,
así como la interconectividad con otras plataformas o sistemas.
o Los roles y responsabilidades de TI definidas, incluyendo las
correspondientes al outsourcing interno y/o externo.
o Los riesgos del negocio y las decisiones estratégica asociadas.
Identificar los requerimientos de información que tienen una relevancia
particular con respecto a los procesos del negocio.
Identificar los riesgos inherentes de TI, así como el nivel general de
control que puede asociarse con el proceso del negocio. Para lograrlo
identificamos:
o Los cambios recientes en el ambiente del negocio que tienen impacto
sobre TI.
o Los cambios recientes al ambiente de TI, nuevos desarrollos, etc.
o Los incidentes recientes relevantes para los controles y el ambiente del
negocio.
o Los controles de monitoreo de TI aplicados por la administración.
o Los reportes recientes de auditoría y/o certificación.
o Los resultados recientes de auto evaluaciones.
Seleccionar los procesos relevantes de COBIT, así como también los
recursos que se aplican a los mismos.
Determinar una estrategia de auditoría basándose en el plan detallado de
auditoría.
Tabla 3: Requerimientos del proceso de auditoría [8]
Definir el alcance de la auditoría Procesos del negocio involucrados
Plataformas, sistemas y su
interoperatividad, que apoyan los procesos
Roles, responsabilidades y estructura
organizacional
Identificar los requerimientos de Importancia para el proceso de negocio
Pág. 54
información relevantes para el proceso de
negocio
Identificar los riesgos inherentes de TI y el
nivel general de control
Cambios recientes e incidentes en el
ambiente del negocio y de la tecnología
Resultados de auditorías,
autoevaluaciones, y certificación
Controles de monitoreo aplicados por la
administración
Seleccionar procesos y plataformas a
auditar
Procesos
Recursos
Fijar una estrategia de auditoría Controles vs. riesgos
Pasos y tareas
Puntos de decisión
6.4. Directriz general de Auditoría
A continuación (Figura 13) se muestra los requerimientos genéricos para auditar
procesos de TI. Está orientado hacia la comprensión del proceso y la determinación de
la propiedad y deberá ser el fundamento y el marco referencial para todas las
directrices detalladas de auditoría [8].
Obtención de un entendimiento Los pasos de auditoría que se deben realizar para documentar las actividades que generan inconvenientes a los objetivos de control, así como también identificar las medidas/procedimientos de control establecidas. Entrevistar al personal administrativo y de staff apropiado para lograr la comprensión de:
Los requerimientos del negocio y los riesgos asociados
La estructura organizacional
Los roles y responsabilidades
Políticas y procedimientos
Leyes y regulaciones
Las medidas de control establecidas
La actividad de reporte a la administración (estatus, desempeño, acciones) Documentar el proceso relacionado con los recursos de TI que se ven especialmente afectados por el proceso bajo revisión. Confirmar el entendimiento del proceso bajo revisión, los KPI del proceso, las implicaciones de control, por ejemplo, mediante una revisión paso a paso del proceso.
Evaluación de los Controles Los pasos de auditoría a ejecutar en la evaluación de la eficacia de las medidas de control establecidas o el grado en el que se logra el objetivo de control. Básicamente, decidir qué se va a probar, si se va a probar y cómo se va a probar. Evaluar la conveniencia de las medidas de control para el proceso bajo revisión mediante la consideración de los criterios identificados y las prácticas estándares de la industria, los CSF de las medidas de control y la aplicación del juicio profesional del auditor:
Existen procesos documentados
Pág. 55
Existen resultados apropiados
La responsabilidad y el registro de las operaciones son claros y efectivos
Existen controles compensatorios, en donde es necesario concluir el grado en que se cumple el objetivo de control.
Valoración del Cumplimiento Los pasos de auditoría a realizar para asegurar que las medidas de control establecidas estén funcionando como es debido, de manera consistente y continua, y concluir sobre la conveniencia del ambiente de control. Obtener evidencia directa o indirecta de puntos/períodos seleccionados para asegurarse que se ha cumplido con los procedimientos durante el período de revisión, utilizando evidencia tanto directiva como indirecta. Realizar una revisión limitada de la suficiencia de los resultados del proceso. Determinar el nivel de pruebas sustantivas y trabajo adicional necesarios para asegurar que el proceso de TI es adecuado.
Justificar/Comprobar el Riesgo Los pasos de auditoría a realizar para justificar el riesgo de que no se cumpla el objetivo de control mediante el uso de técnicas analíticas y/o consultas a fuentes alternativas. El objetivo es respaldar la opinión e “impresionar” a la administración para que se tome acción. Los auditores tienen que ser creativos para encontrar y presentar esta información que con frecuencia es sensitiva y confidencial. Documentar las debilidades de control y las amenazas y vulnerabilidades resultantes. Identificar y documentar el impacto real y potencial; por ejemplo, mediante el análisis de causa-efecto. Brindar información comparativa; por ejemplo, mediante benchmarks.
Figura 13: Directriz general de Auditoría [8]
Esta misma plantilla se aplica luego a los 34 procesos de COBIT.
6.5. Pruebas de cumplimiento vs. Pruebas sustantivas
Las pruebas de cumplimiento “consisten en recolectar evidencia con el propósito de
probar el cumplimiento de una organización con procedimientos de control”; mientras
que en las pruebas sustantivas “la evidencia se recoge para evaluar la integridad de
transacciones individuales, datos u otra información” [7].
Una prueba de cumplimiento “determina si los controles están siendo aplicados de
manera que cumplen con las políticas y los procedimientos de gestión”. Una prueba
sustantiva “fundamenta la integridad de un procesamiento real” [7].
6.6. Evidencia
Es cualquier información usada por el auditor de SI para determinar si la entidad o los
datos que están siendo auditados cumplen con los criterios u objetivos establecidos, y
soporta las conclusiones de la auditoría [7].
Pág. 56
Las técnicas para recopilación de evidencia pueden ser [7]:
Revisión de las estructuras organizacionales de SI
Revisión de políticas y procedimientos de SI
Revisión de los estándares de SI
Revisión de la documentación de SI
Entrevistas al personal apropiado
Observación de procesos y desempeño de empleados
Repetición de ejecución
Inspección y verificación
Pág. 57
CAPÍTULO VII
AUTOEVALUACIÓN DE CONTROL (CSA)
7.1. Definición
Es “una técnica de la dirección que asegura a las partes interesadas, los clientes y
otros que el sistema de control interno de la organización es confiable”. Además,
“asegura que los empleados estén conscientes de los riesgos del negocio y que
realicen revisiones proactivas periódicas de los controles” [7].
CSA es “una serie de herramientas que abarcan desde simples cuestionarios hasta
talleres de facilitación diseñados para recopilar información sobre la organización,
solicitándola a los que tienen conocimientos de trabajo cotidiano de un área así como
también a sus gerentes” [7].
7.2. Objetivos del CSA
El objetivo primario es apalancar la función de auditoría interna cambiando algunas de
las responsabilidades de monitoreo de control a las áreas funcionales [7].
7.3. Beneficios del CSA
Algunos beneficios del CSA son [7]:
Detección temprana de riesgos
Controles internos más efectivos y mejorados
Creación de equipos cohesivos a través de la participación de los empleados
Desarrollo de un sentido de propiedad de los controles en los empleados y en
los dueños del proceso y reducción de su resistencia a controlar las iniciativas
de mejoramiento
Mayor conciencia de los empleados sobre los objetivos organizacionales y
mayor conocimiento sobre riesgos y controles internos
Mayor comunicación entre los mandos operativos y la alta dirección
Empleados sumamente motivados
Proceso mejorado de calificación en auditorías
Pág. 58
Reducción en el costo del control
Mayor seguridad para las partes interesadas y los clientes
Seguridad mínima para la alta dirección sobre lo adecuado de los controles
internos, según requerimientos de diversas agencias regulatorias y de leyes
tales como la Ley Sarbanes-Oxley de los EEUU.
7.4. Desventajas del CSA
Las posibles desventajas son [7]:
Podría confundirse con un reemplazo de la función de auditoría
Se le considera como una carga de trabajo adicional (por ejemplo, un informe
más a ser presentado a la dirección)
No implementar las mejoras sugeridas podría dañar la moral de los empleados
La falta de motivación puede limitar la efectividad en la detección de controles
débiles.
7.5. El rol del auditor en el CSA
Los auditores se convierten en profesionales del control interno y facilitadores de
evaluaciones, mientras que la gerencia cliente es el participante en el proceso de CSA
[7].
Pág. 59
CAPÍTULO VIII
DOCUMENTACIÓN DE LA AUDITORÍA DE SISTEMAS DE INFORMACIÓN
Todo lo que el auditor de SI lleva a cabo en un proceso de auditoría de SI debe ser
documentado, de tal forma que los procedimientos, metodologías y hallazgos
encontrados queden debidamente sustentados. La documentación cumple entonces,
un rol fundamental.
8.1. Contenido de la Documentación
La documentación de la auditoría de SI o llamado también papeles de trabajo, son el
soporte fundamental para la auditoría de SI. Le sirve de apoyo al auditor al emitir una
opinión y para contar (por escrito) con las evidencias necesarias que le permitan
sostener sus comentarios [5]. Los papeles de trabajo pueden ser considerados como
“el puente o la interfaz entre los objetivos de auditoría y el informe final” [7].
Existen muchas formas de elaborar y utilizar los papeles de trabajo de una auditoría de
SI, “las cuales estarán determinadas por la experiencia, conocimientos y habilidades
del auditor, así como por su necesidad de usar los documentos y medios de cómputo
para concentrar la información” [5].
La documentación de la auditoría o papeles de trabajo debe incluir, como mínimo, lo
siguiente [7]:
La planificación y preparación del alcance y de los objetivos de la auditoría.
La descripción y/o recorridos en el área de auditoría vista.
El programa de auditoría.
Los pasos de auditoría realizados y la evidencia de auditoría recopilada.
El uso de servicios de otros auditores y expertos.
Los hallazgos, conclusiones y recomendaciones de auditoría.
La relación de la documentación de auditoría con la identificación y las fechas
de documentos.
También se recomienda que la documentación incluya:
Una copia del informe emitido como resultado del trabajo de auditoría.
Pág. 60
Evidencia de revisión supervisora de auditoría.
8.2. Propuesta para integrar los papeles de trabajo
Muñoz Razo [5] propone el siguiente esquema para elaborar el legajo de los papeles
de trabajo de la auditoría de SI:
Hoja de identificación
Índice de contenido de los papeles de trabajo
Dictamen preliminar (borrador)
Resumen de las desviaciones detectadas (las más importantes)
Situaciones encontradas (situaciones, causas y soluciones)
Programa de trabajo de auditoría
Guía de auditoría
Inventario de software
Inventario de hardware
Inventario de consumibles
Manual de organización
Descripción de puestos
Reportes de pruebas y resultados
Respaldos (backups) de datos, discos y programas de aplicación de auditoría
Respaldos (backups) de las bases de datos y de los sistemas
Guías de claves para el señalamiento de los papeles de trabajo
Cuadros y estadísticas concentradores de información
Anexos de recopilación de información
Diagramas de flujo, de programación y de desarrollo de sistemas
Testimoniales, actas y documentos legales de comprobación y confirmación
Análisis y estadísticas de resultados, datos y pruebas de comportamiento del
sistema
Otros documentos de apoyo para el auditor
8.3. El formato de la documentación
El formato de la documentación y los medios son opcionales, pero las buenas
prácticas indican que los papeles de trabajo posean fecha, firmas, páginas numeradas,
Pág. 61
que sean relevantes, completos, claros, independientes y que se etiqueten y archiven
debidamente y se mantengan en custodia [7].
8.4. Claves del auditor para marcar papeles de trabajo
Son las marcas de carácter informal que utiliza exclusivamente el auditor o grupo de
auditores, con el fin de facilitar la uniformidad de los papeles de trabajo y para
identificarlos mejor. Tienen un significado preciso que todos los auditores conocen y se
utilizan para destacar aspectos importantes de los documentos que van revisando [5].
Pág. 62
CAPÍTULO IX
EL INFORME DE AUDITORÍA
9.1. Definición de Informe
Son “el producto final del trabajo de auditoría de SI” y es utilizado por el auditor de SI
para reportar a la gerencia los hallazgos y recomendaciones [7].
9.2. Estructura del Informe
A pesar de que no existe un formato específico para un informe de auditoría,
usualmente tendrán la estructura y contenido siguientes [7]:
Una introducción.
Una buena práctica es incluir los hallazgos de la auditoría en secciones
diferentes, y agruparlos por importancia y/o receptor previsto.
La conclusión y la opinión generales del auditor de SI respecto a si los
controles y procedimientos examinados durante la auditoría son los adecuados,
y los riesgos potenciales reales identificados como consecuencia de las
deficiencias detectadas.
Las reservas o calificaciones del auditor de SI con relación a la auditoría (si los
controles y procedimientos examinados son adecuados o inadecuados).
Los hallazgos detallados y las recomendaciones de la auditoría. La decisión de
qué incluir en los distintos niveles de los informes de auditoría depende de la
orientación provista por la alta dirección.
Una variedad de hallazgos, algunos de los cuales pueden ser
considerablemente importantes mientras que otros son menores en su
carácter.
El auditor de SI debería tomar la decisión final acerca de qué incluir o excluir del
informe de auditoría, y debería preocuparse por proporcionar un informe balanceado,
que describa no solamente los aspectos negativos en términos de hallazgos, sino
también comentarios constructivos sobre procesos y controles en perfeccionamiento o
sobre controles efectivos ya existentes.
9.3. Ejemplo de la estructura de un Informe de Auditoría
Pág. 63
Existen muchas maneras de elaborar un informe de auditoría de SI. Una de ellas es la
utilizada por la Oficina del Contralor de Puerto Rico, la cual posee un sitio Web2 en
donde es posible descargar los diferentes informes de auditoría de SI que esta Oficina
elabora.
A continuación se detalla la estructura empleada por la Oficina del Contralor de Puerto
Rico [13]:
Carátula
Contiene el título del informe, la fecha de presentación, el nombre de la organización y
del área auditada y el período auditado.
Contenido
Viene a ser la tabla de contenido del informe, en donde se muestran las partes del
informe y las páginas correspondientes.
Información sobre la unidad auditada
Se detalla acerca de las características relevantes de la organización y de la unidad
auditada.
Responsabilidad de la gerencia
Aquí se presentan las responsabilidades y principios de la gerencia de la organización.
Alcance y metodología
En esta parte se comenta acerca del intervalo de tiempo que cubrió la auditoría, las
normas de auditoría tomadas en cuenta, y cómo se realizaron las pruebas. Se explica
también la metodología a seguir, como por ejemplo:
Entrevistas a funcionarios, a empleados y a particulares
Inspecciones físicas
Examen y análisis de informes y de documentos generados por la unidad
auditada
Examen y análisis de informes y de documentos suministrados por fuentes
externas
Pruebas y análisis de procedimientos de control interno y de otros procesos
2 http://www.ocpr.gov.pr
Pág. 64
Confirmaciones de información pertinente.
Opinión
Es un comentario breve del auditor, en un párrafo, el cual tiene el siguiente esquema:
“Las pruebas efectuadas demostraron que las operaciones de (el área
auditada) en lo concerniente a (la revisión o evaluación que se realizó) no se
realizaron conforme a las normas generalmente aceptadas en este campo.”
“Los hallazgos del 1 al (indicar el total de hallazgos), clasificados como
principales, se comentan en la parte de este Informe titulada RELACIÓN DETALLADA
DE HALLAZGOS.”
Recomendaciones
En esta parte se clasifican las recomendaciones de acuerdo a las personas, áreas o
puestos de trabajo a los cuales va dirigido.
Cartas a la gerencia
Se describe aquí los detalles sobre el envío del borrador de los hallazgos del Informe a
los directores o alta dirección de la organización.
Comentarios de la gerencia
Se indica si el funcionario principal y los exfuncionarios de la unidad auditada
efectuaron comentarios sobre el borrador de los hallazgos del informe, que le envía el
auditor. Dichos comentarios se consideran al revisar el borrador del informe; y se
incluyen al final del hallazgo correspondiente, de forma objetiva y conforme a las
normas establecidas.
Cuando la gerencia no provee evidencia competente, suficiente y relevante para
refutar un hallazgo, este prevalece y se añade al final del mismo la siguiente
aseveración: Consideramos las alegaciones de la gerencia, pero determinamos que el
hallazgo prevalece.
Agradecimiento
Se agradece a los auditados que participaron en la auditoría.
Relación detallada de hallazgos
Pág. 65
En el informe de auditoría se incluyen solamente los hallazgos significativos
determinados por las pruebas realizadas. Estos se clasifican como principales o
secundarios:
Los hallazgos principales incluyen las desviaciones de disposiciones sobre
las operaciones de la unidad auditada que tienen un efecto material, tanto en el
aspecto cuantitativo como en el cualitativo.
Los hallazgos secundarios son los que consisten en faltas o errores que no
han tenido consecuencias graves.
Los hallazgos poseen los siguientes atributos:
Situación: Los hechos encontrados en la auditoría indicativos de que no se
cumplió con uno o más criterios.
Criterio: El marco de referencia para evaluar la situación. Es principalmente
una ley, un reglamento, una carta circular, un memorando, un procedimiento,
una norma de control interno, una norma de sana administración, un principio
de contabilidad generalmente aceptado, una opinión de un experto o un juicio
del auditor.
Efecto: Lo que significa, real o potencialmente, no cumplir con el criterio.
Causa: La razón fundamental por la cual ocurrió la situación.
Anexos
Contienen información adicional o complementaria al informe de auditoría.
Pág. 66
CAPÍTULO X
GOBIERNO Y GESTIÓN DE TECNOLOGÍAS DE LA INFORMACIÓN
9.1. Gobierno Corporativo
Las empresas son gobernadas por buenas (o mejores) prácticas generalmente
aceptadas para asegurar que la empresa cumpla sus metas asegurando que lo
anterior esté garantizado por ciertos controles. Desde estos objetivos fluye la dirección
de la organización, la cual dicta ciertas actividades a la empresa usando sus propios
recursos. Los resultados de las actividades de la empresa son medidos y reportados
proporcionando insumos para el mantenimiento y revisión constante de los controles,
comenzando el ciclo de nuevo.
Figura 14: Gobierno Corporativo [8]
Gobierno corporativo se define como “el sistema por el cual se dirigen y controlan las
corporaciones de negocios” (Sir Adrian Cadbury, International Corporate Governance
Meeting, Hanoi, Vietnam3); es un conjunto de responsabilidades y prácticas usadas
por la gerencia de una organización para proveer dirección estratégica, para garantizar
de este modo, que las metas se puedan alcanzar, los riesgos sean manejados de
manera adecuada y los recursos organizacionales sean utilizados apropiadamente [7].
9.2. Gobierno de TI
3 (6/12/2004), p. 3, http://www.oecd.org/dataoecd/18/47/34080477.pdf
Pág. 67
También TI es gobernado por buenas (o mejores) prácticas para asegurar que la
información de la empresa y sus tecnologías relacionadas apoyan sus objetivos del
negocio, estos recursos son utilizados responsablemente y sus riesgos son manejados
apropiadamente. Estas prácticas conforman una base para la dirección de las
actividades de TI las cuales pueden ser enmarcadas en la Planeación y Organización,
Adquisición e Implementación, Entrega de Servicios y Soporte y Monitoreo para los
propósitos duales como son el manejo de riesgo (para obtener seguridad, confiabilidad
y cumplimiento) y la obtención de beneficios (incrementando la efectividad y
eficiencia). Los reportes son enfocados sobre los resultados de las actividades de TI,
los cuales son medidos contra diferentes prácticas y controles y el ciclo comienza otra
vez.
Figura 15: Gobierno de TI [8]
El gobierno de TI es uno de los dominios del gobierno corporativo y se define como
“una estructura de relaciones y procesos para dirigir y controlar la empresa con el fin
de lograr sus objetivos al añadir valor mientras se equilibran los riesgos contra el
retorno sobre TI y sus procesos” [8].
Un elemento clave del gobierno de TI es la alineación del negocio con TI que conlleva
al logro del valor de negocio [7].
Fundamentalmente, al gobierno de TI le incumben dos aspectos [7]:
Pág. 68
Que TI entregue valor al negocio, impulsado por la alineación estratégica de TI
con el negocio.
Que los riesgos de TI sean gestionados, impulsado por la integración de la
responsabilidad en la empresa.
El gobierno de TI define quién toma decisiones, cómo toman esas decisiones, y
cuándo [14].
9.3. Áreas de enfoque del gobierno de TI
COBIT4 da soporte al gobierno de TI (Figura 16) a través de un marco de trabajo que
garantiza que:
TI está alineada con el negocio
TI habilita al negocio y maximiza los beneficios
Los recursos de TI se usan de manera responsable
Los riesgos de TI se administran apropiadamente.
Figura 16: Áreas de enfoque del gobierno de TI [11]
9.4. Marcos de gobierno de TI
Algunos ejemplos de los marcos de gobierno de TI son [7]:
COBIT (ver capítulo V)
4 Objetivos de Control para la Información y la Tecnología Relacionada
Pág. 69
ISO/IEC 27001 (ISO 27001): Es un conjunto de buenas prácticas que
proporcionan orientación a las organizaciones que aplican y mantienen
programas de seguridad de la información. Originalmente se publicó en el
Reino Unido como el estándar británico 7799 (BS7799) y se convirtió en un
estándar muy conocido en la industria.
ITIL (Biblioteca de Infraestructura de TI): Fue desarrollada en el Reino Unido
por la Oficina de Comercio del Gobierno del Reino Unido (OGC), en
colaboración con IT Service Management Forum y es un marco detallado con
información práctica sobre cómo lograr el éxito de gestión de servicios
operacionales de TI.
Catálogos de protección de niveles mínimos de TI o Catálogos
Grundschutz de TI: Son una recopilación de documentos de la Oficina Federal
Alemana para la seguridad en TI (FSI). Los documentos son útiles para
detectar y combatir los puntos débiles de seguridad en el entorno de TI.
ISM3 (Modelo de madurez para la gestión de la seguridad de la información):
Es un modelo que se basa en el proceso de madurez de ISM para la
seguridad.
AS8015-2005: Es el estándar australiano para el gobierno corporativo de TIC.
AS8015 se adoptó como estándar ISO/IEC 38500 en mayo de 2008.
ISO/IEC 38500:2008: Proporciona un marco para el gobierno efectivo de TI.
Ayuda a aquellos en el nivel más alto de la organización a entender y cumplir
con sus obligaciones legales, reglamentarias y éticas con respecto al uso de TI
de su organización. Se aplica a todo tipo de organizaciones. Proporciona
principios de orientación para los directores de organizaciones sobre el uso
efectivo, eficiente y aceptable de TI en sus organizaciones.
9.5. El rol de la auditoría en el gobierno de TI
La auditoría tiene un rol significativo en una implementación exitosa del gobierno de TI
dentro de la organización. Provee importantes recomendaciones de prácticas a la alta
dirección, para ayudar a mejorar la calidad y la efectividad de las iniciativas del
gobierno de TI implementadas, y a asegurar el cumplimiento de las iniciativas del
gobierno de TI [7].
El auditor de SI necesita evaluar los siguientes aspectos [7]:
Pág. 70
La alineación de la función de SI con la misión, la visión, los valores, los
objetivos y las estrategias de la organización.
El logro por parte de la función de SI de los objetivos de desempeño
establecidos por el negocio (por ejemplo, efectividad y eficiencia).
Los requerimientos legales, ambientales, de calidad de la información,
fiduciarios, de seguridad y de privacidad.
El ambiente de control de la organización.
Inversión/gasto en TI.
9.6. Auditoría a la estructura e implementación del Gobierno de TI
Algunos de los indicadores más significativos de los problemas potenciales que le
preocupan a un auditor de SI son [7]:
Actitudes desfavorables del usuario final
Costos excesivos
Gasto por encima del presupuesto
Proyectos atrasados
Alta rotación del personal
Personal con poca experiencia
Errores frecuentes de HW/SW
Exceso de solicitudes atrasadas de usuarios
Largo tiempo de respuesta de la computadora
Numerosos proyectos de desarrollo interrumpidos o suspendidos
Compras de HW/SW sin soporte o sin autorización
Frecuentes ampliaciones de capacidad de HW/SW
Informes de excepción largos
Reportes de excepciones a los que no se les hizo seguimiento
Motivación deficiente
Ausencia de planes de reemplazo
Confianza en uno o dos miembros clave del personal
Falta de capacitación adecuada.
La siguiente documentación debe ser revisada [7]:
Las estrategias, planes y presupuestos de TI
Documentación de políticas de seguridad
Cuadros organizativos/funcionales
Pág. 71
Descripciones de los puestos de trabajo
Reportes del comité directivo
Procedimientos de desarrollo de sistemas y de cambio de programas
Procedimientos de operaciones
Manuales de RRHH
Procedimientos de QA
9.7. Revisión de compromisos contractuales
El auditor de SI debe verificar la participación de la gerencia en el proceso de
contratación y debe asegurar un nivel adecuado de revisión oportuna del cumplimiento
del contrato. El auditor de SI podrá efectuar una revisión, por separado, del
cumplimiento en una muestra de dichos contratos.
Al revisar una muestra de los contratos, el auditor de SI debe evaluar la adecuación de
los siguientes términos y condiciones:
Niveles de servicio
Derecho a auditar o reportar auditorías de terceros
Poner el SW en custodia de un tercero
Penalizaciones por incumplimiento
Acatamiento de las políticas y procedimientos de seguridad
Protección de información de clientes
Proceso de cambio de contrato
Terminación de contrato y cualquier penalización apropiada.
9.8. Planeación de continuidad del negocio (BCP)
El propósito de la continuidad del negocio/recuperación en caso de desastre es
“permitir que una empresa continúe ofreciendo servicios críticos en caso de que ocurra
una interrupción y que sobreviva a una interrupción desastrosa de las actividades” [7].
Para ello es necesario contar con una planificación y un compromiso rigurosos de los
recursos para prever tales eventos de forma adecuada.
El BCP es básicamente responsabilidad de la alta gerencia y toma en consideración
[7]:
Pág. 72
Las operaciones críticas que son necesarias para la supervivencia de la
organización
Los recursos humanos/materiales que los soportan.
9.9. Planeación de continuidad del negocio de SI
El enfoque es el mismo que en el BCP y debe estar alineado con la estrategia de la
organización. La criticidad de las diferentes aplicaciones de la organización depende
de la naturaleza del negocio, así como del valor de cada aplicación para el negocio [7].
El BCP/DRP del SI es un componente principal de la estrategia general de continuidad
del negocio y recuperación en caso de desastre de una organización [7].
9.10. Elementos de un BCP
Un BCP debe incluir [7]:
Plan de continuidad de las operaciones
DRP
Plan de restablecimiento del negocio
También puede incluir:
Continuidad del plan de apoyo/Plan de contingencias de TI
Plan de comunicaciones de crisis
Plan de respuesta a incidentes
Plan de transporte
Plan de emergencia del ocupante
Plan de evacuación y reubicación de emergencia
9.11. Auditoría al Plan de Continuidad del Negocio
Las tareas del auditor de SI abarcan [5]:
Comprender y evaluar la estrategia sobre la continuidad del negocio y su
conexión con los objetivos del negocio
Revisar los hallazgos de BIA5 para asegurarse de que se reflejen las
prioridades actuales del negocio y los controles actuales
5 Análisis de impacto del negocio
Pág. 73
Evaluar los BCP a fin de determinar su conveniencia y difusión, al revisar los
planes y compararlos con las correspondientes estándares o reglamentos
gubernamentales, incluidos RTO6, RPO7 etc., definidos por el BIA
Verificar la eficacia de los BCP mediante la revisión de los resultados de las
pruebas realizadas anteriormente por SI y el personal de usuario final
Evaluar el almacenamiento externo para asegurar su conveniencia al
inspeccionar la instalación y verificar sus contenidos y controles de seguridad y
ambiental
Verificar los trámites para transportar los medios de respaldo a fin de
asegurarse de que satisfagan los requerimientos apropiados de seguridad
Evaluar la capacidad del personal para responder efectivamente en situaciones
de emergencia, al revisar los procedimientos de emergencia, la capacitación de
empleados y los resultados de las pruebas y los ensayos
Velar por el establecimiento y vigencia del proceso para mantener los planes y
porque éste abarque las revisiones tanto periódicas como no programadas
Evaluar si los manuales sobre la continuidad del negocio y los procedimientos
están redactados de una manera sencilla y fácil de comprender. Esto puede
lograrse mediante entrevistas y al determinar si todas las partes involucradas
comprenden sus atribuciones y responsabilidades con respecto a las
estrategias sobre la continuidad del negocio.
6 Tiempo de recuperación objetivo
7 Punto de recuperación objetivo
Pág. 74
CAPÍTULO XI
ADQUISICIÓN, DESARROLLO E IMPLEMENTACIÓN DE SISTEMAS DE INFORMACIÓN
11.1. Auditoría de los controles de aplicación
Las tareas del auditor de SI incluyen las siguientes [7]:
Identificar los componentes significativos de la aplicación y el flujo de
transacciones a través del sistema, y lograr la comprensión detallada de la
aplicación, revisando la documentación disponible y entrevistando el personal
apropiado.
Identificar las fortalezas del control de aplicación y evaluar el impacto de las
debilidades de control para desarrollar una estrategia de prueba, analizando la
información acumulada.
Revisar la documentación del sistema de aplicación para proporcionar una
comprensión de la funcionalidad de la aplicación. Si la aplicación es muy
grande se debe realizar una revisión selectiva.
El auditor de SI debe revisar la siguiente documentación [7]:
Documentos de metodología de desarrollo del sistema
Especificaciones de diseño funcionales
Cambios del programa
Manuales de usuario
Documentación de referencia técnica
11.2. Auditoría de desarrollo, adquisición y mantenimiento de sistemas
En este tipo de auditoría, la tarea del auditor de SI puede ocurrir una vez que finaliza el
proyecto o, rara vez, durante el proyecto y pueden ser las siguientes [7]:
Determinar los componentes, objetivos y requerimientos principales del sistema
para identificar las áreas que requieran controles, reuniéndose con los
miembros claves del área de desarrollo de sistemas y del equipo de usuarios
del proyecto.
Determinar y clasificar por prioridad los riesgos principales y las exposiciones
del sistema, por medio de discusiones con los miembros del equipo de
Pág. 75
desarrollo de sistemas y de equipo de usuarios del proyecto para permitir la
selección de controles apropiados.
Identificar los controles para mitigar los riesgos y las exposiciones del sistema,
utilizando referencias de fuentes autorizadas y por medio de discusiones con
los miembros del equipo de desarrollo de sistemas y de usuarios del proyecto.
Aconsejar al equipo del proyecto respecto al diseño del sistema y a la
implementación de los controles evaluando los controles disponibles y
participando en discusiones con los miembros del equipo de desarrollo de
sistemas y de usuarios del proyecto.
Monitorear, supervisar y controlar (realizar el seguimiento) al proceso de
desarrollo de sistemas para asegurar que se hayan implementado los
controles, que se cumplan los requerimientos del usuario y del negocio y que
se siga la metodología de desarrollo/adquisición de sistemas, reuniéndose
periódicamente con los miembros del equipo de desarrollo de sistemas y de
usuarios del proyecto y revisando la documentación y los productos a ser
entregados.
Participar en revisiones posteriores a la implementación.
Evaluar los estándares y procedimientos de mantenimiento del sistema para
asegurar que sean adecuadas por medio de la revisión de la documentación
apropiada, la discusión con el personal clave y la observación.
Probar los procedimientos de mantenimiento de sistemas para asegurar que se
estén aplicando como se describe en los estándares por medio de la discusión
y del examen de los registros que los respaldan.
Evaluar el proceso de mantenimiento de sistemas para determinar si se
lograron los objetivos de control analizando los resultados de las pruebas y
otras evidencias de auditoría.
Determinar si la seguridad de la biblioteca de producción es adecuada para
asegurar la integridad de los recursos de producción identificando y probando
los controles existentes.
11.2.1. Gestión de proyectos
El auditor de SI debe [7]:
Analizar los riesgos y exposiciones asociados inherentes a cada etapa del
SDLC y debe asegurar que estén establecidos los mecanismos apropiados de
Pág. 76
control para minimizar estos riesgos en una forma eficiente y teniendo en
cuenta el costo/beneficio de los controles.
Obtener documentación de las distintas etapas y asistir a las reuniones del
equipo de proyectos ofreciendo asesoramiento al equipo de proyectos durante
todo el proceso de desarrollo de los sistemas.
Hacer una evaluación de la capacidad del equipo de proyectos para producir
resultados claves en las fechas prometidas.
Revisar si las siguientes actividades de gestión de proyectos son adecuadas:
o Niveles de supervisión por parte del comité del proyecto/consejo
directivo
o Métodos de gestión de riesgos dentro del proyecto
o Manejo de problemas
o Gestión de costos
o Procesos de planificación y gestión de las dependencias
o Procesos de reporte a la alta gerencia
o Procesos de control de cambios
o Participación de la gerencia de partes interesadas
o Proceso de aprobación. Como mínimo, aprobaciones con firma del
responsable de desarrollo de sistemas y gestión de usuarios para el
costo del proyecto y/o uso del sistema.
11.2.2. Estudio de factibilidad/viabilidad
El auditor de SI debe [7]:
Revisar la documentación producida en esta fase para verificar si es razonable.
Determinar si toda la justificación de costos/beneficios son verificables y los
mismos deben ser presentados mostrando los beneficios anticipados que se
van a obtener.
Identificar y determinar la importancia crítica de la necesidad que se desea
satisfacer.
Determinar si se puede alcanzar una solución con los sistemas ya existentes.
En caso contrario, revisar la evaluación de las soluciones alternativas para
verificar si éstas son razonables.
Determinar si la solución escogida es razonable.
11.2.3. Definición de los requerimientos
Pág. 77
El auditor de SI debe [7]:
Obtener el documento de definición detallada de los requerimientos y verificar
si son correctos por medio de entrevistas con los departamentos relevantes de
usuario.
Identificar los miembros claves en el equipo del proyecto y verificar que todos
los grupos de usuarios afectados estén debidamente representados.
Verificar que la iniciación del proyecto y el costo del mismo hayan recibido la
debida aprobación de la Gerencia.
Revisar las especificaciones conceptuales del diseño para asegurar que el
mismo atiende a las necesidades del usuario.
Revisar el diseño conceptual para asegurar que se hayan definido las
especificaciones de control.
Determinar si un número razonable de proveedores recibió la propuesta que
cubra el alcance del proyecto y los requerimientos del usuario.
Revisión de especificaciones de UAT8.
Determinar si la aplicación es candidata para el uso de rutina(s) integradas de
auditoría. En caso afirmativo, solicitar que la rutina sea incorporada en el
diseño conceptual del sistema.
11.2.4. Proceso de adquisición de software
El auditor debe [7]:
Analizar la documentación del estudio de factibilidad/viabilidad para determinar
si la decisión de adquirir una solución fue apropiada.
Revisar el RFP9 para asegurar que éste cubre los puntos apropiados.
Determinar si el proveedor seleccionado está respaldado por la documentación
de RFP.
Asistir a las presentaciones programadas con agenda y pilotos de salas de
conferencia para asegurar que el sistema coincide con la respuesta del
proveedor a la RFP.
Revisar el contrato del proveedor antes de su firma para asegurarse que
incluye los puntos enumerados.
Asegurarse de que el contrato sea revisado por el asesor legal antes de que
sea firmado.
8 User Acceptance Testing: Prueba de aceptación final
9 Request for proposal: Solicitud de propuesta
Pág. 78
11.2.5. Diseño y desarrollo detallados
El auditor de SI debe [7]:
Revisar los diagramas de flujo del sistema para verificar si se ajusta al diseño
general. Verificar que se hayan obtenido las debidas aprobaciones para
cualquier cambio y que todos los cambios hayan sido discutidos y aprobados
por la Gerencia de Usuario apropiada.
Revisar los controles para el ingreso de los datos, del procesamiento y de los
resultados, diseñados en el sistema para verificar si son apropiados.
Entrevistar a los usuarios claves del sistema para determinar su comprensión
de cómo operará el sistema y evaluar su nivel de participación en el diseño de
los formatos de pantalla y reportes de salida.
Evaluar si las pistas de auditoría son adecuadas para permitir que se rastreen y
se evidencie la responsabilidad por las transacciones del sistema.
Verificar la integridad de los cálculos y procesos claves.
Verificar que el sistema pueda identificar y procesar los datos erróneos
correctamente.
Revisar los resultados de aseguramiento de la calidad de los programas
desarrollados durante esta etapa.
Verificar que se hayan efectuado todas las correcciones de los errores de
programación y que se hayan codificado las pistas de auditoría o los módulos
integrados de auditoría (EAMs) recomendados, en los programas apropiados.
11.2.6. Pruebas
El auditor de SI debe [7]:
Revisar el plan de pruebas para verificar la integridad y con evidencia que
indique la participación del usuario como por ejemplo en la definición de los
escenarios de pruebas y/o la aprobación de los resultados obtenidos y
considerar una repetición de la ejecución de las pruebas críticas.
Efectuar una reconciliación de los totales de control y de los datos convertidos.
Revisar los informes de errores para verificar su precisión para reconocer los
datos erróneos y para la resolución de errores.
Verificar el procesamiento cíclico para establecer si es correcto (procesamiento
de fin de mes, fin de año, etc.).
Pág. 79
Entrevistar a los usuarios finales del sistema para verificar si entienden los
nuevos métodos, los nuevos procedimientos y las instrucciones de operación.
Revisar, durante esta fase, la documentación del sistema y de los usuarios
finales para determinar su integridad y verificar si es correcta.
Revisar los resultados de las pruebas en paralelo para verificar si son exactos.
Verificar que la seguridad del sistema esté funcionando como se diseñó
mediante el desarrollo y ejecución de pruebas de acceso.
Revisar los planes de las pruebas de unidad y del sistema para determinar si
se planifican y realizan pruebas de los controles internos.
Revisar las pruebas de aceptación por parte de los usuarios (UAT) y
asegurarse de que el software aceptado ha sido entregado al equipo de
implementación. El proveedor no debería ser capaz de reemplazar esta
versión.
Revisar los procedimientos utilizados para registrar y hacer seguimiento del
reporte de errores.
11.2.7. Etapa de implementación
El auditor de SI debe [7]:
Verificar que se hayan obtenido las firmas de aprobación apropiadas antes de
la implementación.
Revisar los procedimientos programados para agendar y poner en
funcionamiento el sistema junto con los parámetros del sistema usados para la
ejecución del cronograma de producción.
Revisar toda la documentación del sistema para asegurar su integridad y para
asegurarse de que la totalidad de las actualizaciones recientes, a partir de las
fases de pruebas, hayan sido incorporadas.
Verificar todas las conversiones de datos para asegurarse de que estén
correctas y completas antes de implementar el sistema en producción.
11.2.8. Revisión posterior a la implementación
El auditor de SI debe [7]:
Determinar si se lograron los objetivos y requerimientos del sistema, prestando
atención a la utilización que hace el usuario del sistema y la satisfacción
general de éste con el sistema.
Pág. 80
Determinar si se está midiendo y analizando el costo-beneficio identificado en
el estudio de factibilidad/viabilidad, y si los resultados son reportados a la
Gerencia con exactitud.
Revisar las solicitudes de cambio (RFC) a programas para evaluar el tipo de
cambios que requiere el sistema.
Revisar los controles integrados en el sistema para asegurarse que los mismos
estén operando en conformidad con el diseño. Si se incluyó un EAM en el
sistema, usar este módulo para probar las operaciones claves.
Revisar los registros de error de operación para determinar si hay algún
problema de recursos o de operación inherente en el sistema.
Revisar los controles de balance de entrada y salida y demás informes para
verificar que el sistema esté procesando los datos correctamente.
11.2.9. Procedimientos de cambios al sistema y proceso de migración de
programas
El auditor de SI debe considerar lo siguiente [7]:
El uso y la existencia de una metodología para autorizar, priorizar y rastrear los
requerimientos de cambios al sistema solicitados por el usuario.
Si los procedimientos de cambio de emergencia son considerados en los
manuales de operación.
Si el control de cambios es un procedimiento formal tanto para el usuario como
para los grupos de desarrollo.
Si el registro de control de cambios asegura que todos los cambios
presentados fueron resueltos.
La satisfacción del usuario con la rotación, tiempo y costo, de las solicitudes de
cambio.
Qué tan adecuadas son las restricciones de seguridad de acceso sobre las
fuentes y los módulos ejecutables en producción.
Qué tan adecuados son los procedimientos de la organización para efectuar los
cambios de urgencia en programas.
Qué tan adecuadas son las restricciones de seguridad de acceso sobre el uso
de los IDs de inicio de sesión.
Para una selección de cambios en el registro de control de cambios se debe [7]:
Pág. 81
Determinar que los cambios a los requerimientos quedaron registrados en
documentos apropiados de cambio, desarrollo, tales como los documentos de
programa y de operaciones.
Determinar que los cambios fueron hechos como se documentaron.
Determinar que la documentación actual refleja el ambiente cambiado.
Evaluar lo adecuado de los procedimientos existentes para probar los cambios
al sistema.
Revisar las evidencias (probar los planes y los resultados) para asegurar que
los procedimientos fueron llevados a cabo como fueron prescritos por los
estándares organizacionales.
Revisar los procedimientos establecidos para asegurar la integridad del código
fuente y del ejecutable.
Revisar los módulos ejecutables de producción y verificar que haya una y sólo
una versión correspondiente del código fuente del programa.
Además, el auditor de SI debe revisar todo el proceso de gestión de cambios para
posibles mejoras en cuanto a conocimiento, tiempo de respuesta, efectividad de
respuesta, y satisfacción del usuario con el proceso.
Pág. 82
CAPÍTULO XII
OPERACIONES, MANTENIMIENTO Y SOPORTE DE SISTEMAS DE INFORMACIÓN
12.1. Auditoría de la Infraestructura y de las Operaciones
A continuación se enumeran las áreas más importantes que se deben revisar mientras
se realiza este tipo de auditoría.
12.1.1. Revisiones de hardware
Áreas que se deben revisar
Preguntas que se deben considerar
Plan de adquisición de hardware
¿Está el plan alineado con los requerimientos del negocio?
¿Se compara el plan periódicamente con los planes del negocio para garantizar su sincronización constante con los requerimientos del sistema?
¿Está el plan sincronizado con los planes de SI?
¿Se han desarrollado los criterios para la adquisición de hardware?
¿Es el entorno el adecuado para acomodar el hardware instalado actualmente y el nuevo hardware que deba ser agregado en conformidad con el plan aprobado de adquisición de hardware?
¿Se documentaron en forma adecuada las especificaciones de hardware y software, los requerimientos de instalación y el probable plazo asociado con las adquisiciones planificadas?
Adquisición de hardware
¿Está la adquisición en línea con el plan de adquisición de hardware?
¿La administración de SI ha emitido por escrito las declaraciones de su política en relación con la adquisición y uso de microcomputadoras y se han comunicado estas declaraciones a los usuarios?
¿Se han establecido procedimientos y formularios para facilitar el proceso de aprobación de adquisición?
¿Se ha presentado un análisis de costo-beneficio con las solicitudes?
¿Se han canalizado las compras a través del departamento de compras para optimizar el proceso, evitar duplicaciones, aprovechas los beneficios de cantidad y calidad tales como descuentos por volúmenes?
Gestión de capacidad y monitoreo
¿Los criterios usados en el plan de monitoreo del desempeño del hardware se basan en los datos históricos y en el análisis obtenido de los registros de problemas de SI, cronogramas de procedimientos, reportes de los sistemas de contabilidad de los trabajos, cronogramas y reportes de mantenimiento preventivo?
¿Se realiza una revisión constante del desempeño y la capacidad del hardware y software de sistema?
¿Es adecuado el monitoreo del equipo, para el cual se ha programado el contacto con su fabricante (sin manual ni la intervención humana) en caso de falla del mismo?
Programa de mantenimiento preventivo
¿Se supervisa la frecuencia de mantenimiento indicada por los respectivos vendedores de hardware?
¿Se realiza el mantenimiento fuera de los períodos pico de trabajo?
¿Se realiza el mantenimiento preventivo en momentos en los que el
Pág. 83
sistema no esté ejecutando aplicaciones críticas o delicadas?
Disponibilidad de hardware e informes de utilización
¿Es el programa el apropiado para cumplir con la programación de las cargas de trabajo y los requerimientos del usuario?
¿Es el programa flexible para poder aceptar el mantenimiento preventivo de hardware requerido?
¿Están los recursos de SI disponibles en forma oportuna para los programas de aplicaciones críticos?
Registros de problemas Informes de sistemas de contabilidad de los trabajos
¿Revisó el personal de administración de SI los problemas de funcionamiento de hardware, repetición de ejecuciones, terminaciones anormales del sistema y las acciones del operador?
12.1.2. Revisiones del sistema operativo
Áreas que se deben revisar
Preguntas que se deben considerar
Procedimientos de selección de software de sistema
¿Cumplen con los planes de SI de corto y largo alcance?
¿Cumplen con los requerimientos de SI?
¿Están debidamente alineados con los objetivos del negocio?
¿Incluyen un panorama de las capacidades del software y de las opciones de control?
Estudio de viabilidad/ factibilidad Proceso de selección
¿Son los objetivos y fines propuestos para el sistema consistentes con las solicitud/propuesta?
¿Se aplican los mismos criterios a todas las propuestas?
El análisis de costo-beneficio de procedimientos de software del sistema ha abordado:
o ¿Costos financieros directos asociados con el producto? o ¿Costo de mantenimiento del producto? o ¿Requerimientos de hardware y la capacidad del producto? o ¿Requerimientos de capacitación y de soporte técnico? o ¿Impacto del producto sobre la fiabilidad del procesamiento? o ¿Impacto sobre la seguridad de los datos? o ¿Estabilidad financiera de las operaciones del proveedor?
Software de seguridad del sistema
¿Se han establecido procedimientos para restringir la posibilidad de evadir los controles de acceso lógico de seguridad?
¿Se han establecido procedimientos para limitar el acceso a la capacidad de interrupción del sistema?
¿Se han establecido procedimientos para administrar los parches de software y mantener actualizado el software de sistema?
¿Son las disposiciones de seguridad física y lógica existentes adecuadas para restringir los accesos a las consolas principales?
¿Se cambiaron las contraseñas del software del sistema suministradas por el proveedor en el momento de la instalación?
Implementación de software del sistema
Los controles son adecuados en: o ¿Procedimientos de cambio? o ¿Procedimientos de autorización? o ¿Funciones de seguridad de acceso? o ¿Requerimientos de documentación? o ¿Documentación de pruebas del sistema? o ¿Pistas de auditoría? o ¿Controles de acceso sobre el software en producción?
Documentación de autorización
¿Se han documentado las adiciones, eliminación o cambios a la autorización de acceso?
¿Existe documentación de intentos de violación? De se así, ¿ha habido seguimiento?
Pág. 84
Documentación del sistema
Las siguientes áreas se documentan adecuadamente: o ¿Estados de control de instalación? o ¿Tablas de parámetros? o ¿Definiciones de salida? o ¿Registros (logs)/informes de actividad?
Actividades de mantenimiento de software del sistema
¿Está disponible la documentación de cambios realizados al software del sistema?
¿Son las versiones actuales del software respaldadas por el proveedor?
Controles de cambios al software del sistema
¿Está el acceso a las bibliotecas que contienen el software del sistema limitado a la o las personas que necesitan contar con dicho acceso?
¿Son los cambios al software documentados de manera apropiada y probados antes de su implementación?
¿Es el software debidamente autorizado antes de ser trasladado del ambiente de prueba al ambiente de producción?
Controles sobre la instalación del software del sistema cambiado
¿Se han implementado todos los nivele de software?
¿Se han llevado a cabo actualizaciones del anterior?
¿Están los cambios en el software del sistema programados para los momentos en que los que éstos tengan un impacto menor en el procesamiento de SI?
¿Se ha establecido un plan escrito para aprobar los cambios al software del sistema?
¿Son los procedimientos de prueba adecuados para ofrecer una garantía razonable de que los cambios aplicados al sistema corrigen los problemas que se conocen y que no crean nuevos problemas?
¿Las pruebas se están concluyendo como se planificó?
¿Los problemas encontrados durante la realización de las pruebas han sido resueltos y los cambios han sido sometidos a prueba nuevamente?
¿Se han establecido los procesos de reversión o restauración en caso de falla de producción?
12.1.3. Revisiones de la base de datos
Áreas que se deben revisar
Preguntas que se deben considerar
Esquema lógico ¿Existen todas las entidades que contiene el diagrama de entidad-relación como tablas o vistas?
¿Están todas las relaciones representadas mediante claves externas?
¿Se especifican las limitaciones con claridad?
¿Están permitidos los ceros en las claves externas solamente si están conformes con la cardinalidad expresada en el modelo entidad-relación?
Esquema físico ¿Se ha realizado la asignación de espacio (almacenamiento) inicial y de extensión para las tablas, registros, índices y áreas temporales según los requerimientos?
¿Están presentes los índices por clave primaria o claves de acceso frecuente?
Si la base de datos no está regulada por estándares, ¿se acepta la justificación?
Informes de tiempo de acceso
¿Se usan los índices para minimizar los tiempos de acceso?
¿Se han construido los índices en forma correcta?
Si se utilizan búsquedas abiertas que no se basan en los índices, ¿éstas se justifican?
Controles de seguridad de la base de datos
¿Se identifican dentro de la base de datos los niveles de seguridad para todos los usuarios y sus funciones, y se justifican los derechos de acceso para todos los usuarios y/o grupos de usuarios?
Interfaces con otros
¿Afectan los procedimientos de importación y exportación la integridad y confidencialidad de los datos?
Pág. 85
programas/ software
¿Se han establecido mecanismos y procedimientos para asegurar el manejo adecuado de la consistencia e integridad durante los accesos simultáneos?
Procedimientos y controles de respaldo y recuperación ante desastres
¿Existen procedimientos de respaldo y recuperación ante desastres para asegurar la confiabilidad y disponibilidad de la base de datos?
¿Existen controles técnicos para garantizar una alta disponibilidad y/o una rápida recuperación de la base de datos?
Controles de SI respaldados por la base de datos
¿Es apropiado el acceso a los datos compartidos?
¿Se utilizan los procedimientos de cambio adecuados para asegurar la integridad del software de administración de la base de datos?
¿Está la redundancia de los datos minimizada por el sistema de administración de la base de datos? Donde existen datos redundantes, ¿se mantiene la referencia cruzada apropiada dentro del diccionario de datos del sistema o de otra documentación?
¿Se mantiene la integridad del diccionario de datos del sistema de administración de la base de datos?
12.1.4. Revisiones de infraestructura e implementación de la red
Áreas que se deben revisar
Preguntas que se deben considerar
Controles físicos
Dispositivos de hardware de red Servidor de archivos Documentación
¿Están los dispositivos de hardware de red ubicados en una instalación segura y restringidos al administrador de red?
¿Está el alojamiento de los servidores de archivos de red bloqueado o protegido de alguna otra forma para evitar el retiro de tarjetas, chips o el computador mismo?
Registros de llave
¿Se controlan las llaves para acceder a las instalaciones de archivos de red a fin de evitar el riesgo de un acceso no autorizado?
¿Están las llaves de acceso asignadas solamente a las personas correspondientes, por ejemplo al administrador de red y al personal de soporte?
Elija una muestra de llaves que tienen las personas que no tienen acceso autorizado para las instalaciones del servidor de archivos de la red y para el armario de cableado a fin de determinar que estas llaves no permitan el acceso a estas instalaciones.
Armario de cableado de red y cableado de transmisión
¿Están los cables protegidos físicamente?
Controles ambientales
Instalación del servidor
¿Son los controles de humedad y temperatura adecuados?
¿Se han establecido medidas de protección contra la electricidad estática?
¿Se han colocado los protectores de picos de corriente?
¿Se ha instalado un sistema de supresión de incendios y ha sido probado/verificado periódicamente?
¿Se encuentran los extinguidores de incendios cerca y han sido inspeccionados regularmente?
¿Está la red equipada con UPS10
que permita a la red operar en caso de fluctuaciones menores de la energía eléctrica o ser apagado debidamente en caso de un corte prolongado de energía?
¿Se ha instalado el aislamiento electromagnético?
10
Suministro ininterrumpido de alimentación
Pág. 86
¿Se supervisa el suministro de energía de los componentes de la red en forma adecuada para garantizar que cumpla con las especificaciones del fabricante?
¿Están los medios de almacenamiento de respaldo protegidos de daños ambientales?
¿Se mantiene la instalación del servidor libre de polvo, humo y de otros materiales, como alimentos?
Controles de seguridad lógica
Contraseñas ¿Se les asigna a los usuarios contraseñas únicas?
¿Se les solicita a los usuarios cambiar las contraseñas periódicamente?
¿Son las contraseñas encriptadas y no se muestran en la pantalla de la computadora cuando se ingresan?
Acceso de usuario a la red
¿Se basa el acceso de usuarios a la red en una autorización escrita y se otorga sobre la base de la necesidad de saber/hacer, y sobre la base de las responsabilidades de la persona?
¿Se desactivan automáticamente las estaciones de trabajo de red después de un corto período de inactividad?
¿Está prohibido el acceso remoto al supervisor del sistema?
¿Son todos los intentos de inicio de sesión (logon) con la cuenta de supervisor capturados en el sistema computarizado?
¿Son las actividades realizadas mediante las cuentas de supervisor o del administrador sometidas a una verificación independiente?
¿Mantiene el supervisor de red actualizada la información con relación a todas las líneas de comunicación conectadas con el exterior?
Solicitudes de cambio de acceso a la red
¿Son las solicitudes de cambio de acceso a la red autorizadas por el gerente correspondiente? ¿Se utilizan formularios estándar?
¿Se documentan las solicitudes de inserciones, cambios y eliminaciones de acceso lógico de la red?
Planes de prueba
¿Son apropiados los planes de prueba de implementación, conversión y aceptación de la red distribuida de procesamiento de datos, hardware y enlaces de comunicación, desarrollados por la organización?
Informes de seguridad
¿Sólo ocurren accesos autorizados?
¿Se revisan los informes de seguridad en forma apropiada y oportuna?
En el caso de usuarios no autorizados, ¿son los procedimientos de seguimiento apropiados y oportunos?
Mecanismos de seguridad
¿Se han identificado en la red todos los archivos/conjuntos de datos sensibles y se han determinado los requerimientos para su seguridad?
¿Se controlan todos los cambios del software del sistema operativo utilizado por la red y realizados por la administración de SI (o en los sitios de usuarios)? ¿Puede el administrador de red o los responsables de la red detectar estos cambios en forma oportuna?
¿Las personas sólo tienen acceso a las aplicaciones, procesadores de transacciones y conjuntos de datos autorizados?
¿Están los comandos del sistema que afectan a más de un sitio de la red restringidos a una terminal y a una persona autorizada con una responsabilidad de control general de la red y autorización de seguridad?
¿Se usa la encriptación de la red para codificar datos sensibles?
¿Se establecieron los procedimientos para asegurar controles efectivos sobre el hardware y el software usados por los departamentos atendidos por la red de procesamiento distribuido?
¿Son las políticas y procedimientos de seguridad apropiados para el entorno:
o Altamente distribuido? - ¿Está la seguridad bajo control de la administración de usuarios individuales?
o Distribuido? - ¿Está la seguridad bajo la dirección de la administración de usuarios, pero acata las directrices establecidas por la administración de SI?
o Mixto? - ¿Está la seguridad bajo la dirección de la administración de usuarios individuales pero la responsabilidad total permanece
Pág. 87
en la administración de SI? o Centralizado? - ¿Está la seguridad bajo la dirección de
administración de SI, donde el personal de la administración de SI mantiene una relación estrecha con la administración de usuario?
o Altamente centralizado? - ¿Está la seguridad bajo el completo control de la administración de SI?
Procedimientos de operación de red
¿Se aplica debidamente a todos los conjuntos de datos de la red los procedimientos para asegurar la compatibilidad de los datos y se han determinado los requerimientos para su seguridad?
¿Se han instalado mecanismos adecuados de reinicio y recuperación en todos los lugares de usuarios atendidos por la red de procesamiento distribuido?
¿Se ha diseñado la red distribuida de SI para asegurar que un fallo en el servidor de servicio en cualquiera de los sitios tendrá un efecto mínimo sobre el servicio continuado para los demás sitios atendidos por la red?
¿Existen disposiciones que aseguren el cumplimiento de las leyes y reglamentos que rijan la transmisión de datos?
Entrevista a la persona responsable del mantenimiento de la seguridad de la red
¿La persona está consciente de los riesgos asociados con el acceso físico y lógico que deben minimizarse?
¿Está consciente de la necesidad de monitorear activamente los inicios de sesión (logons) y dar cuenta de los cambios de empleado?
¿La persona tiene la capacidad de conocer cómo mantener y monitorear el acceso?
Entrevista a los usuarios
¿Los usuarios están conscientes de las políticas de administración con relación a la seguridad de la red y la confidencialidad?
12.1.5. Revisiones de las operaciones de SI
Áreas que se deben revisar
Preguntas que se deben considerar
Observación del personal de SI
¿Se han implementado controles para asegurar la eficiencia de las operaciones y la adhesión a los estándares y políticas establecidos?
¿Existe una supervisión adecuada?
¿Se han implementado controles con respecto a la revisión de la gestión de SI, la integridad de los datos y la seguridad?
Acceso a los operadores
¿Está restringido a los operadores el acceso a los archivos y la documentación?
¿Se han limitado las responsabilidades por la operación de las computadoras y los equipos periféricos relacionados?
¿Está restringido el acceso para corregir problemas relacionados con los programas y los datos?
¿Se debe restringir el acceso a los utilitarios que permiten hacer correcciones al software y/o los datos del sistema?
¿Está limitado el acceso al código fuente de producción y las bibliotecas de datos (incluyendo la ejecución de procedimientos)?
Manuales del operador
¿Son adecuadas las instrucciones sobre: o El manejo de la computadora y sus equipos periféricos? o Los procedimientos de inicio y cierre? o Las acciones que se deben realizar en caso de que falle la
máquina o el programa? o Los registros que se deben conservar? o Las funciones normales del trabajo y las actividades restringidas?
Acceso a la biblioteca
¿Tiene prohibido el bibliotecario el acceso al hardware de computadora?
¿Tiene el bibliotecario acceso solamente al sistema de gestión de cintas?
¿Se proporciona acceso a las instalaciones de la biblioteca solamente al personal autorizado?
¿Restringe el software de elaboración de cronogramas de producción la
Pág. 88
eliminación de archivos?
¿Debe manejar el bibliotecario el recibo y la devolución de medios externos que entren a la biblioteca?
¿Se mantienen registros (logs) de las actividades de inicio y fin de sesión en relación con los archivos de datos y medios de almacenamiento?
Contenido y ubicación del almacenamiento fuera de línea
¿Están claramente identificados con su contenido los medios de almacenamiento de archivos fuera de línea que contienen los programas y datos del sistema de producción?
¿Están ubicadas las instalaciones de la biblioteca lejos de la sala de computadoras?
¿Son adecuadas las políticas y procedimientos para: o Administrar la biblioteca fuera de línea? o Registrar la entrada y salida de los medios de almacenamiento,
incluyendo los requerimientos de autorizaciones de firma? o Identificar, etiquetar, entregar y recuperar archivos de respaldo
ubicados fuera de sitio? o Hacer inventario del sistema para determinar los medios de
almacenamiento locales y fuera de sitio, incluyendo las ubicaciones específicas donde se almacena cada cinta?
o Eliminar de forma segura los medios de almacenamiento, incluyendo los requerimientos de autorizaciones de firma?
Procedimientos para manejar archivos
¿Se han establecido procedimientos para controlar la recepción y envío de archivos y medios secundarios de almacenamiento desde y hacia otros lugares?
¿Se utilizan etiquetas para las cintas internas a fin de asegurar que se elijan los medios de almacenamiento correctos para el procesamiento?
¿Son adecuados estos procedimientos y concuerdan con la intención y la autorización de la gerencia?
¿Se están aplicando estos procedimientos? Introducción de datos
¿Están autorizados los documentos de introducción de datos y contienen estos documentos las firmas apropiadas?
¿Se ha realizado la conciliación de los totales por lotes?
¿Existe segregación de funciones entre la persona que introduce los datos y la persona que verifica si los datos introducidos están correctos y si hay errores?
¿Se está generando los informes de control? ¿Son exactos los informes? ¿Se mantienen y revisan los informes?
Operaciones lights-out
A menudo se otorga acceso remoto a la consola principal a los operadores disponibles para fines de contingencia, como por ejemplo una falla en el software automatizado. ¿Está suficientemente limitado el acceso a las funciones de seguridad para proteger el sistema contra uso no autorizado?
¿Permiten los planes de contingencia identificar adecuadamente un desastre en las instalaciones automatizadas?
¿Se han documentado y probado adecuadamente el software de operación automatizada y los procedimientos manuales de contingencia en el sitio de recuperación?
¿Están presentes controles de cambios a los programas y controles de acceso?
¿Se llevan a cabo pruebas del software periódicamente, en especial cuando se aplican cambios o actualizaciones?
¿Existen garantías de que no hay errores ocultos por el software y que todos los errores son notificados por el operador?
12.1.6. Revisión de planificaciones (scheduling) o cronogramas
Áreas que se Preguntas que se deben considerar
Pág. 89
deben revisar
Aplicaciones programadas regularmente Fechas tope de entradas Tiempo de preparación de los datos Tiempo estimado de procesamiento Fechas tope de salidas Procedimientos para recolectar, reportar y analizar los indicadores de desempeño
¿Se incluyen los ítems en los acuerdos de nivel de servicio (SLA)=
Funcionan los ítems conforme a los SLA?
Programa de trabajo
¿Se han identificado las aplicaciones críticas y se les asignó la prioridad más alta?
¿Se han establecido las prioridades de procesamiento para otras aplicaciones y se han justificado las prioridades asignadas?
¿Coinciden los programas de trabajos urgentes/de repetición con la prioridad asignada?
¿Facilitan los procedimientos de elaboración de programas la utilización óptima de los recursos computarizados y cumplen con los requerimientos de servicio?
¿Registran los operadores los trabajos que se deben procesar y los archivos de datos requeridos?
¿Los operadores programan los trabajos de procesamiento de una manera predeterminada y los ejecutan utilizando software de planificación automatizada o planificación manual?
Programa diario de trabajos
¿Es la cantidad de personal que se asigna a cada turno adecuada para procesar la carga de trabajo?
¿Sirve el programa diario de trabajos como una pista de auditoría? ¿Especifica el programa diario de trabajos a cada turno de operadores de computadoras el trabajo que se debe realizar, la secuencia en la que se deben ejecutar los programas y cuándo se puede hacer el trabajo que tiene baja prioridad?
¿Pasa cada operador al final de un turno un estado de los trabajos realizados y los motivos por los que no se terminó algún trabajo que estaba programado al planificador de trabajos o al siguiente turno de operadores?
Registro (log) de consola
¿Se realizaron y completaron los trabajos de acuerdo con el programa?
Si no fue así, ¿son válidas las razones?
Registros (logs) de excepciones
¿Obtienen los operadores aprobación escrita o electrónica de los propietarios cuando preparan el programa de trabajos a pedido?
¿Registran los operadores todas las solicitudes de procesamiento de excepciones?
¿Revisan los operadores el registro (log) de procesamiento de excepciones para determinar si los procedimientos realizados son apropiados?
Re-ejecución de trabajos
¿Son debidamente autorizadas y registradas todas las re-ejecuciones de trabajos para que la gerencia de SI las revise?
¿Se han establecido procedimientos para repetir la ejecución de trabajos a fin de asegurar que se usen los archivos de entrada correctos y que los trabajos posteriores en la secuencia también se vuelvan a ejecutar si
Pág. 90
fuera apropiado?
Personal ¿Tiene el personal capacitado para asignar o cambiar programas o prioridades de trabajos autorización para hacerlo?
12.1.7. Revisiones de reportes gerenciales de problemas
Áreas que se deben revisar
Preguntas que se deben considerar
Entrevista al personal de operaciones de SI
¿Se han desarrollado procedimientos documentados para guiar al personal de operaciones de SI en las actividades de registro (logging), análisis, solución y escalamiento de problemas de manera oportuna, de acuerdo con la intención y autorización de la gerencia?
Procedimientos utilizados por el departamento de SI Documentación de las operaciones
¿Son adecuados los procedimientos para registrar, evaluar y resolver o escalar los problemas de operación o procesamiento?
¿Son adecuados los procedimientos utilizados por el departamento de SI para recolectar estadísticas relacionadas con el rendimiento del procesamiento en línea y es exacto y completo el análisis?
¿Se registran todos los problemas identificados por las operaciones de SI para su verificación y solución?
Registros de rendimiento Entradas sobresalientes del registro (log) de errores Registros (logs) de llamadas del centro de soporte (help desk)
¿Existen problemas durante el procesamiento?
¿Son válidas las razones de las demoras en el procesamiento de los programas de aplicación?
¿Son significativos y recurrentes los problemas identificados, y las acciones realizadas para prevenir su recurrencia?
¿Se resolvieron los problemas de procesamiento de manera oportuna y la solución fue completa y razonable?
¿Hay problemas recurrentes que no se han notificado a la gerencia de SI?
Pág. 91
CAPÍTULO XIII
PROTECCIÓN DE LOS ACTIVOS DE INFORMACIÓN
13.1. Auditoría de acceso lógico
El auditor de SI debe [7]:
Obtener una comprensión general de los riesgos de seguridad que enfrenta el
procesamiento de la información a través de una revisión de la documentación
relevante, la consulta, la observación, la evaluación del riesgo y las técnicas de
evaluación.
Documentar y evaluar los controles sobre las rutas potenciales de acceso al
sistema para determinar si son adecuados, eficientes y efectivos revisando las
funciones apropiadas de seguridad de hardware y software e identificando
cualesquiera deficiencias o redundancias.
Probar los controles sobre las rutas de acceso para determinar si están
funcionando y son efectivas aplicando las técnicas apropiadas de auditoría.
Evaluar el ambiente de control de acceso para determinar si se logran los
objetivos de control analizando los resultados de las pruebas y otras evidencias
de auditoría.
Evaluar el ambiente de seguridad para determinar si es adecuado revisando
las políticas escritas, observando las prácticas y los procedimientos y
comparándolos con los estándares o las prácticas y los procedimientos de
seguridad apropiados que usan otras organizaciones.
13.2. Auditoría a la seguridad de infraestructura de red
El auditor de SI debe [7]:
Revisar los diagramas de red (LAN, MAN, WAN) que identifican la
infraestructura interconectada de las organizaciones, la cual incluiría pasarelas,
cortafuegos, enrutadores, conmutadores, concentradores, servidores de
acceso, módems, etc.
Identificar el diseño de red implementado, incluyendo la estrategia de IP usada,
la segmentación de enrutadores y conmutadores para el ambiente de la
localidad, y configuraciones y protocolos WAN.
Pág. 92
Determine si existen las políticas de seguridad, estándares, procedimientos y
orientación aplicables sobre la administración y el uso de la red y si éstos se
han dado a conocer al personal y a los administradores de la red.
Identificar quién es el responsable de la seguridad y operación de las
conexiones de Internet y evaluar si tiene suficientes conocimientos y
experiencia para asumir dicho rol.
Determinar si se han considerado los problemas legales que surgen del uso de
Internet.
Si se externaliza el servicio, revisar los acuerdos de nivel de servicio para
asegurar que incluyan disposiciones para la seguridad además de
disponibilidad y calidad de servicio.
Revisar los procedimientos del administrador de red para asegurar que los
componentes de hardware y software estén actualizados en respuesta a
nuevas vulnerabilidades.
13.3. Auditoría a los controles ambientales
Los procedimientos de prueba son los siguientes [7]:
Detectores de agua y de humo
Extintores manuales de incendio
Sistemas de supresión de incendios
Inspección periódica del departamento de bomberos
Paredes, pisos y techos a prueba de incendios alrededor de la sala de
computadoras
Protectores de voltaje
Líneas de energía provenientes de dos subestaciones
Plan totalmente documentado y probado de la continuidad del negocio
Cableado colocado en paneles y conductos eléctricos
UPS/Generador
Planes documentados y probados de evacuación durante emergencias
Control de humedad/temperatura
Pág. 93
REFERENCIAS BIBLIOGRÁFICAS
[1] Real Academia Española. (2012, Marzo) Real Academia Española. [Online].
http://buscon.rae.es
[2] Effy Oz, Administración de los sistemas de información, Quinta ed. México:
Thomson, 2008.
[3] Ian Sommerville, Ingeniería de Software, Sexta ed. México: Pearson Educación,
2002.
[4] Mario Piattini Velthuis, Emilio Del Peso Navarro, and Mar Del Peso Ruiz,
Auditoría de Tecnologías y Sistemas de Información, Primera edición ed. México:
Alfaomega, 2008.
[5] Carlos Muñoz Razo, Auditoría en Sistemas Computacionales. México: Pearson
Educación, 2002.
[6] Álvaro Iván Jiménez Alzate, Una Visión Sistémica de la Auditoría Informática.
Cali, Colombia: Universidad Santiago de Cali, 2009.
[7] ISACA, Manual de Preparación al Examen CISA 2011. EEUU, 2010.
[8] IT Governance Institute, Directrices de Auditoría, Tercera ed. EEUU, 2000.
[9] ISACA, Marco de Riesgos de TI. EEUU, 2009.
[10] The Institute of Internal Auditors, Global Technology Audit Guide: Information
Technology Controls. Florida, EEUU, 2005.
[11] IT Governance Institute, COBIT 4.1. EEUU, 2007. [Online].
http://www.isaca.org/Pages/DocumentDownloadRegistration.aspx?file=http://ww
w.isaca.org/Knowledge-Center/cobit/Documents/cobiT4.1spanish.pdf
[12] IT Governance Institute, COBIT Control Practice: Guidance to Achieve Control
Objectives for Successful IT Governance, Segunda ed. EEUU, 2007.
[13] Oficina del Contralor de Puerto Rico. (2011, Septiembre) Informes publicados de
la Oficina del Contralor de Puerto Rico. [Online].
http://www.ocpr.gov.pr/informes_en_PDF/pdf_2011_2012/ti/TI-12-04.pdf
[14] John Baschab and Jon Piot, The Executive's Guide to Information Technology,
Segunda ed. EEUU: John Wiley & Sons, 2007.