Auditoría de Sistemas de Información Luis Otake
Pág. 1
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-NoComercialCompartir Igual 3.0 Unported License.
Pág. 2
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. 3
Í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. 4
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. 5
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. 6
ÍNDICE DE FIGURAS
Figura 1: Marco referencial del análisis de riesgo [8] Figura 2: Clasificación de los riesgos de TI [9] Figura 3: La jerarquía de los controles de TI [10] Figura 4: Relación entre recursos de TI y entrega de servicios [8] Figura 6: Relación entre procesos de negocio, información y recursos de TI [8] Figura 6: Dominios, procesos y actividades [8] Figura 7: El Cubo de COBIT [11] Figura 8: Los cuatro dominios interrelacionados de COBIT [11] Figura 9: Organización y navegación de los objetivos de control de TI [8] Figura 10: Fronteras de los controles de negocio, generales de TI y de aplicación [11] Figura 11: Representación gráfica de los modelos de madurez [11] Figura 12: El proceso de control [8] Figura 13: Directriz general de Auditoría [8] Figura 14: Gobierno Corporativo [8] Figura 15: Gobierno de TI [8] Figura 16: Áreas de enfoque del gobierno de TI [11]
Pág. 7
27 28 31 37 38 38 39 39 44 45 46 47 55 66 67 68
Í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. 8
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. 9
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. 10
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. 11
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. 12
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. 13
•
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
1.6.
Tiempo a utilizar
Planificación
1/3
Ejecución
1/3
Información (presentación y documentación)
1/3
Á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. 14
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. 15
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. 16
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. 17
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. 18
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. 19
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. 20
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. 21
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. 22
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. 23
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. 24
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. 25
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. 26
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. 27
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. 28
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 Preventivos
Función 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.
Pág. 29
Ejemplos 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.
Detectivos
Utilizan controles que detectan e informan la ocurrencia de un error, omisión o acto fraudulento.
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.
4.2.
Control Interno Informático o de TI
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. 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. Planificación de contingencia. Procedimientos de respaldo. Procedimientos de nueva ejecución.
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. 30
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. 31
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. 32
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. 33
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. 34
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
consultado
responsable, e
informado
rendición (RACI)
de para
cuentas
(accountable),
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. 35
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. 36
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. 37
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. 38
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. 39
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. 40
¿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. 41
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. 42
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
almacenados,
TI
están
documentados,
comunicados
y
usados
revisados,
mantenidos,
para
entrenamiento.
el
aprobados, 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. 43
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. 44
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. 45
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. 46
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. 47
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. 48
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. 49
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. 50
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. 51
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. 52
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. 53
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
Procesos Recursos
auditar 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. 54
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. 55
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. 56
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. 57
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. 58
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. 59
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. 60
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. 61
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. 62
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 Web 2 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
2
Pruebas y análisis de procedimientos de control interno y de otros procesos
http://www.ocpr.gov.pr
Pág. 63
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. 64
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. 65
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.
3
Gobierno de TI
(6/12/2004), p. 3, http://www.oecd.org/dataoecd/18/47/34080477.pdf
Pág. 66
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. 67
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]:
4
COBIT (ver capítulo V)
Objetivos de Control para la Información y la Tecnología Relacionada
Pág. 68
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. 69
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. 70
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. 71
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. 72
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 7
Tiempo de recuperación objetivo Punto de recuperación objetivo
Pág. 73
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. 74
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. 75
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. 76
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 9
User Acceptance Testing: Prueba de aceptación final Request for proposal: Solicitud de propuesta
Pág. 77
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. 78
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. 79
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. 80
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. 81
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 Plan de adquisición de hardware
Adquisición hardware
de
Gestión capacidad monitoreo
de y
Programa de mantenimiento preventivo
Preguntas que se deben considerar ¿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? ¿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? ¿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? ¿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. 82
Disponibilidad de hardware e informes de utilización
Registros problemas Informes sistemas contabilidad los trabajos
de de de de
sistema no esté ejecutando aplicaciones críticas o delicadas? ¿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? ¿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 Procedimientos de selección de software de sistema Estudio viabilidad/ factibilidad Proceso selección
Software seguridad sistema
Preguntas que se deben considerar
de
de
de del
Implementación de software del sistema
Documentación de autorización
¿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? ¿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? ¿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? 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? ¿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. 83
Documentación del sistema
Actividades de mantenimiento de software del sistema Controles de cambios al software del sistema
Controles sobre la instalación del software del sistema cambiado
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? ¿Está disponible la documentación de cambios realizados al software del sistema? ¿Son las versiones actuales del software respaldadas por el proveedor? ¿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? ¿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 Esquema lógico
Esquema físico
Informes tiempo acceso
de de
Controles de seguridad de la base de datos Interfaces con otros
Preguntas que se deben considerar ¿Existen todas las entidades que contiene el diagrama de entidadrelació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? ¿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? ¿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? ¿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? ¿Afectan los procedimientos de importación y exportación la integridad y confidencialidad de los datos?
Pág. 84
programas/ software Procedimientos y controles de respaldo y recuperación ante desastres Controles de SI respaldados por la base de datos
¿Se han establecido mecanismos y procedimientos para asegurar el manejo adecuado de la consistencia e integridad durante los accesos simultáneos? ¿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? ¿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 Controles físicos Dispositivos de hardware de red Servidor de archivos Documentación Registros de llave
Preguntas que se deben considerar ¿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?
¿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. ¿Están los cables protegidos físicamente?
Armario de cableado de red y cableado de transmisión Controles ambientales Instalación del ¿Son los controles de humedad y temperatura adecuados? servidor ¿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. 85
¿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 ¿Se basa el acceso de usuarios a la red en una autorización escrita y se usuario a la red 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 ¿Son las solicitudes de cambio de acceso a la red autorizadas por el cambio de gerente correspondiente? ¿Se utilizan formularios estándar? acceso a la red ¿Se documentan las solicitudes de inserciones, cambios y eliminaciones de acceso lógico de la red? Planes de ¿Son apropiados los planes de prueba de implementación, conversión y prueba aceptación de la red distribuida de procesamiento de datos, hardware y enlaces de comunicación, desarrollados por la organización? Informes de ¿Sólo ocurren accesos autorizados? seguridad ¿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 ¿Se han identificado en la red todos los archivos/conjuntos de datos seguridad 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. 86
Procedimientos de operación de red
Entrevista a la persona responsable del mantenimiento de la seguridad de la red Entrevista a los usuarios
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? ¿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? ¿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? ¿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 Observación del personal de SI
Acceso a los operadores
Manuales operador
Acceso a biblioteca
del
la
Preguntas que se deben considerar ¿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? ¿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)? ¿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? ¿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. 87
Contenido y ubicación del almacenamiento fuera de línea
Procedimientos para manejar archivos
Introducción de datos
Operaciones lights-out
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? ¿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? ¿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? ¿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? 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. 88
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 Programa de trabajo
Programa diario de trabajos
Registro (log) de consola Registros (logs) de excepciones
Re-ejecución de trabajos
¿Se incluyen los ítems en los acuerdos de nivel de servicio (SLA)= Funcionan los ítems conforme a los SLA?
¿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? ¿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? ¿Se realizaron y completaron los trabajos de acuerdo con el programa? Si no fue así, ¿son válidas las razones? ¿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? ¿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. 89
Personal
fuera apropiado? ¿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 Entrevista al personal de operaciones de SI Procedimientos utilizados por el departamento de SI Documentación de las operaciones Registros de rendimiento Entradas sobresalientes del registro (log) de errores Registros (logs) de llamadas del centro de soporte (help desk)
Preguntas que se deben considerar ¿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? ¿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? ¿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. 90
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. 91
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. 92
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.
Pág. 93