U.N.C.
AUDITORÍA OPERATIVA Y DE
F.C.E.
SISTEMAS SIS TEMAS COMPUTARIZ COMP UTARIZADO ADOS S
UNIDAD Nº XI Integrantes:
Bustos, Silvia. Cappellani, Mariana. Fabuel, Jimena. Farias, Daniel. Matilla, Ezequiel. Mauri, Romina. Miranda, Carolina. Porqueres, Patricia Verónica. Stolavai, Natalia.
AUDITORÍA DE SISTEMAS EN DESARROLLO INTRODUCCIÓN Según establece el COBIT en el punto M 4.2 y siguientes el auditor deberá ser independiente del auditado tanto en actitud como en apariencia (real y percibida). Los auditores no deberán estar relacionados con la sección o departamento que esté siendo auditado, y en la medida de lo posible, deberá también ser independiente de la propia empresa. De esta manera, la función de auditoría deberá ser suficientemente independiente del área auditada para concluir una auditoría en forma objetiva. La función de auditoría deberá asegurar el cumplimiento de los códigos aplicables de ética profesional y estándares de auditoría en todo lo que lleve a cabo. El debido cuidado profesional deberá observarse en todos los aspectos del trabajo de auditoría, incluyendo el respeto de estándares aplicables sobre auditoría y tecnología de información. La Gerencia deberá asegurar que los auditores responsables de las revisiones de las actividades de la función de servicios de información de la organización, sean técnicamente competentes y cuentan en forma general con las habilidades y conocimientos necesarios para desempeñar dichas revisiones en forma efectiva, eficiente y económica. La Gerencia deberá asegurar que el personal asignado a tareas de auditoría de sistemas de información, mantiene su nivel de competencia técnica mediante un programa adecuado de educación profesional continua.
LA TAREA DEL AUDITOR EN EL DESARROLLO DE SISTEMAS Existe un interesante debate acerca de cuál debe ser el papel del auditor en el desarrollo de nuevos sistemas, es decir, si debe participar o no en su elaboración. Podemos mencionar dos posturas: en contra están los que sostienen que el auditor no debe intervenir en la etapa de diseño e implementación de sistemas porque esto atentaría contra un requisito indispensable a la hora de hacer auditoría, que es la independencia (y también la objetividad) de criterio. La labor del auditor comienza para éstos recién cuando el sistema está en operación normal (Auditoría Tradicional). Por otro lado encontramos los que están a favor de su intervención, quienes postulan que no necesariamente afecta la independencia de criterio y que además otro de los requisitos para realizar una auditoría, es justamente que el sistema sea auditable, y para esto es necesario que en la etapa de su diseño se hayan incorporado controles, de tal manera que den al
auditor pistas de auditoría a la hora de realizar la revisión. Sin duda la insuficiencia o carencia de controles que debieron definirse en esta fase inicial dificulta e imposibilita la labor del auditor. Por ello tampoco parece aceptable sacrificar calidad y confiabilidad de un sistema por una exagerada valoración de la independencia, pues de todos modos puede subsanarse mediante la intervención de un auditor distinto en la prueba del sistema de aquél que realizó la función de consultoría en el diseño del mismo.
OBJETIVO DE LA AUDITORÍA DURANTE DESARROLLO DE SISTEMAS: El objetivo de la participación del auditor en el diseño de sistemas debiera ser identificar, evaluar y analizar los requerimientos de los usuarios; determinar los riesgos existentes y la exposición del sistema a los mismos, y finalmente identificar controles a ser incorporados a los sistemas de aplicaciones durante la fase de su desarrollo para justamente minimizar los antedichos riesgos.
También es importante que asesore a los miembros del equipo encargados del desarrollo del nuevo sistema sobre la incorporación de controles en el diseño y módulos de auditoría, que permitan una vez en funcionamiento del sistema la revisión de rutina a través de las pistas de auditoría. LA SELECCIÓN DE LOS AUDITORES INFORMÁTICOS
Según Yann Derrien, para poder realizar la labor de auditoría es imprescindible contar con un equipo interdisciplinario de profesionales que posean la idoneidad e independencia necesaria para desarrollar eficazmente dicha función. La selección de un equipo de auditoría podría ser realizada por alguno de los siguientes métodos: Anuncios en la prensa diaria nacional. Anuncios en la prensa de informática. Recurrir a gabinetes especializados. Participación en foros. Envío de fichas de la oficina a los departamentos de alumnos de escuelas superiores o universidades y asociaciones de antiguos alumnos. Envío de cartas a alumnos especializados en informática. Toda organización no confía en auditores jóvenes, salvo que posean experiencia previa. No es recomendable que el auditor se especialice en un tipo específico de actividad, sino que debe evolucionar para progresar y así adquirir competencias y fortalecer su experiencia. La evolución del auditor puede ser: TÉCNICA: será asignado a misiones que requieran capacidad técnica mayor. JERARQUICA: será responsable de misiones simples, para luego, progresivamente estar a cargo de las más complejas. EN LA NATURALEZA DEL OBJETIVO: se le asignan a auditores con experiencia las tareas de asesoría y asistencia, debido a que las mismas exigen capacidad técnica elevada y aptitudes comunicativas.
ALCANCE DE LA PARTICIPACIÓN DEL AUDITOR: 1 La participación de los auditores debe enfocarse en determinados puntos de control que debieran estar insertos en el cuerpo de los sistemas. Estos puntos son los que justamente permiten al auditor lograr adecuar los controles con el cumplimiento de políticas y procedimientos de la organización. Cada uno de estos controles debe permitir cumplir con un objetivo específico de auditoría. El auditor tendrá en las distintas etapas de desarrollo del nuevo sistema un papel activo de consultoría, que contribuya a la calidad y confiabilidad del proyecto de sistema y también de análisis de riesgos de cada fase. Para realizar esta tarea deberá contar con documentación elaborada de cada fase y mantener reuniones periódicas con el equipo del proyecto. Todo esto sin olvidar el principio de economía que debe estar presente en todo control (relación Costo/Beneficio), para lograr la mayor eficiencia en el uso de los recursos asignados.
INTERVENCIÓN DEL AUDITOR EN LAS DISTINTAS FASES DE DESARROLLO DEL SISTEMA A continuación se mencionan las distintas etapas en las que debería participar el auditor al desarrollar un sistema.
1. Desarrollo del Plan Maestro: Contiene los elementos para dar estructura a un sistema, los cuales son: Proyecto Prioridad u orden de desarrollo Recursos necesarios El auditor aquí debe verificar: Que exista compatibilidad entre el Plan Maestro y los objetivos corporativos fijados en el Planeamiento Estratégico de la organización. Que el Plan Maestro no incluya aplicaciones que produzcan esfuerzos duplicados y costos innecesarios. Que tienda a la integración de aplicaciones actuales y de propuestas de manera que los recursos sean eficientemente utilizados y evitar así duplicaciones. Que sea flexible, de manera que pueda adaptarse si cambian prioridades. Que los sistemas propuestos sean realmente útiles para los usuarios y que se mantengan las necesidades del negocio que motivaron su desarrollo. Que se hayan contemplado soluciones alternativas antes de decidir el desarrollo del nuevo sistema, como recurrir al servicio de un proveedor o utilizar un prototipo. Que se haya hecho un estudio de justificación económica del proyecto, que la gerencia lo haya aprobado y que, además, esté comprometida en su desarrollo. En definitiva que se haya adoptada la decisión adecuada valorando: Necesidades de usuarios. Disposición de recursos financieros, técnicos y operativos. Limitaciones de tiempo de desarrollo y oportunidad.
1
LARDENT, Alberto D., Sistemas de Información par la Gestión Empresaria. Procedimientos, Seguridad y Auditoria (2001,Bs. As. Prentice Hall), 363/379 pág.
2. Definición y análisis de requerimientos de usuarios: Esta fase tiene por objetivo responder al interrogante: “¿qué necesita el usuario?” Es decir, que características debe incluir el sistema para que sea útil a sus objetivos. La realización de todo proyecto exige el acuerdo entre informáticos y usuarios sobre el contenido de la aplicación a desarrollar. Este acuerdo se materializará por medio de un documento escrito denominado pliego de condiciones, que incluye el conjunto de especificaciones funcionales del futuro sistema de información, incluyendo las peticiones de mantenimiento de programas. Una participación activa del usuario, es fundamental para evitar construcciones erróneas o incompletas de los sistemas. La mala formación de los mismos causa la aplicación anárquica del sistema, originando riesgos, desinterés o rechazo. El papel del auditor aquí consiste en: Determinar quiénes son los miembros que intervienen en el proyecto de desarrollo del nuevo sistema y de ellos, a quiénes los usuarios les han manifestado (con claridad y precisión) sus necesidades. Revisar el diseño conceptual para cerciorarse que cubra con esas necesidades. Verificar que la gerencia aprobó el proyecto, presupuesto y recursos asignados. Verificar que se hayan contemplado los requerimientos que aseguren la preservación del control interno y las evidencias auditables del sistema. Determinar si se debe incorporar una rutina de auditoría para fines de revisión, luego de su implementación. Determinar la efectividad del sistema verificando si los requerimientos de los usuarios contemplan la emisión de informes de gestión.
3. Diseño lógico del sistema: Esta fase tiene por objetivo responder a la pregunta “¿de qué manera se pueden satisfacer esos requerimientos de los usuarios?” El diseño tiene dos etapas: Diseño lógico : Es la construcción funcional del sistema. (Especificaciones sobre
salidas de información, entradas de datos, archivos, base de datos, procedimientos; observables en un diagrama de flujos de datos). Las funciones del auditor aquí consisten en: Observar si los temas de auditoría se cubren satisfactoriamente. Asegurarse que el diseño se ajuste a bases establecidas originariamente y a estándares que se apliquen en la empresa. Verificar que se respeten criterios de separación de funciones. Con respecto a las especificaciones no informáticas sobre datos de entrada el auditor verificará que: El diseño de los formularios y su utilización garanticen contener los datos adecuados. Los formularios contengan numeración que facilita el control de su procesamiento. Se hayan definido las condiciones que permiten la aceptación de la calidad de los datos de entrada, como también el tratamiento para los rechazados, condiciones de corrección y reingreso al proceso. Existan adecuadas condiciones de control para el ingreso de datos online.
La salida se presente de manera que cubra necesidades de información del usuario sin que éste deba procesar o seleccionar manualmente la información que necesita. Con respecto a las especificaciones informáticas el rol del auditor es asegurar en cuanto a: a) Controles: Que en cada paso del proceso computarizado se generen totales de control que puedan ser cotejados con otros totales provenientes de cálculos obtenidos de manera independiente (controles cruzados). Que el sistema prevea la presencia de evidencias que faciliten la tares de la auditoría. Que existan controles que protejan al sistema contra usos no autorizados.
b) Entrada de datos: Que los controles de validación y consistencia sean adecuados y completos. Que los errores detectados en datos que intentan ingresar al proceso sean comunicados al responsable que los ingresó, para que los corrija y reingrese.
c) Archivos: Que los archivos maestros y de transacciones sean protegidos adecuadamente.
d) Salida de información: Que la salida responda a necesidades reales del usuario (contenido, forma, oportunidad). Que la entrega de documentación de salida o en la pantalla sea precedida por controles de validación y detección de errores. Que se tomen medidas de seguridad respecto a información calificada como confidencial.
Desarrollo físico o ingeniería del software:
Se refiere a la elaboración de programas y a la organización y carga de archivos. También incluye la conversión de datos del sistema vigente hacia el nuevo.
Las tareas del auditor en esta instancia son entre otras: Asegurar que se efectúen pruebas completas de cada uno de los programas. Revisar los flujogramas de cada programa para verificar la coherencia con el diseño general del sistema. Verificar que controles de entrada/salida diseñados para cada programa sean los apropiados para cada situación.
Verificar que los programas que se encuentran en desarrollo estén separados de los que ya se encuentran operativos, para evitar confusiones. Evaluar los rastros de auditoría que se programan en el sistema para rastrear información clave.
4. Prueba del sistema: Se realiza una vez finalizada las pruebas de cada programa y efectuadas las correcciones. Los programas que integran el sistema deben entrelazarse y formar una secuencia, la que debe probarse mediante datos de prueba. El auditor debe controlar todo el operativo. Sus tareas son: Que el plan de prueba sea completo, es decir, contemple todas las posibilidades. Verificar resultados de procesos cíclicos (de cierre de mes, cierre de ejercicio). Intentar accesos indebidos al sistema para verificar como funcionan las condiciones de seguridad.
5. Implantación: Esta fase solo se realiza si resultó exitosa la etapa “prueba del sistema”. Un tema importante a tener en cuenta por al auditor es la conversión de archivos del sistema anterior al nuevo, analizando riesgos, quién tendrá a cargo esa tarea, que controles existen para evitar errores, etc. Este es un punto que debe ser de especial cuidado y atención por el auditor. La migración a un nuevo sistema puede hacerse en paralelo (permite comparaciones) o en forma directa. Según el COBIT, en la etapa de adquisición e implementación del sistema se deben tener en cuenta los siguientes objetivos de control: 11.13 Estándares para Pruebas de Sistemas La metodología del ciclo de vida de desarrollo de sistemas de la organización debe proporcionar estándares que cubran los requerimientos de pruebas, verificación, documentación y retención para probar el sistema total, como parte de cada proyecto de desarrollo o modificación de sistemas de información. 1.10 Diseño de Pistas de Auditoría La metodología del ciclo de vida de desarrollo de sistemas de la organización debe asegurar que existan mecanismos adecuados para pistas de auditoría o que dichos mecanismos puedan ser desarrollados para la solución identificada y seleccionada. Los mecanismos deberán proporcionar la capacidad de proteger datos sensitivos (ej. identificación de usuarios contra divulgación o mal uso).
6. Post-instalación: (Mantenimiento) La auditoria de sistemas debe cumplir con sus planes de revisión. Este examen debe ser realizado por auditores distintos a los que actuaron como consultores en el proceso de desarrollo, para mantener el requisito de independencia.
Funciones específicas: Determinar si luego de que el nuevo sistema ha operado durante un lapso prudente, éste cubre satisfactoriamente los requerimientos y objetivos definidos en etapas iniciales del proyecto. Es imprescindible para esto conocer la opinión de los usuarios. Verificar que existan elementos de medición que permitan identificar los beneficios proyectados en el estudio de factibilidad y analizar resultados de aplicación del nuevo sistema. Examinar controles y ver si actúan conforme al diseño y requerimientos. Utilizar el módulo de auditoria que debió incorporarse al sistema para probar el comportamiento de operaciones clave.
Riesgos de desarrollo inadecuado: Si el desarrollo fue incompleto o débil puede crear situaciones de riesgo, por ejemplo que: El resultado final no satisface al usuario. El sistema implementado no acompaña el desarrollo del negocio. El sistema es poco utilizado y desaprovecha la inversión realizada. No existen controles o son débiles.
AUDITORIA DE SISTEMAS EN FUNCIONAMIENTO. CONTROLES PROGRAMADOS Son aquellos concebidos durante la etapa de análisis y concretados, luego, en los programas de aplicación correspondientes. De la cantidad, calidad y etapa del procesamiento que cubran, dependerá la exactitud e integridad de la información. CONTROLES PARA VALIDAR LA INFORMACIÓN DE ENTRADA Destinados a detectar los errores contenidos por la información que se ingresa a un sistema de computación. Éstos pueden establecerse en varias etapas del flujo de la información a través de un sistema: cuando los datos son leídos por una lectora de tarjetas u otro dispositivo, o bien en el momento en el que la información es ingresada mediante una terminal inteligente, o bien una terminal de otro tipo en línea con el computador. La validación deberá realizarse en el momento más próximo a la entrada de información, en algunas ocasiones esto no resulta posible por razones técnicas. Cuando los datos deben ser convertidos previamente a un soporte legible por el computador, la tendencia es instalar dispositivos de validación en las máquinas que practican la conversión, en lugar de esperar que el programa de validación realice esa tarea. Los controles para validar la información pueden realizarse en los siguientes niveles: Verificación de Caracteres: el control de cada carácter es practicado usualmente examinando los caracteres como un grupo o campo. De blancos: debe existir una indicación sobre cuáles son los campos que estarán en blanco y se verifica la existencia de una condición de igualdad, de no ser así hay un error. En principio es deseable reemplazar los blancos por ceros. Como norma general, los campos deberían ser perfograboverificados con ceros, en lugar de ser dejados en blanco.
De signos: se verifica para asegurar que se emplee el signo algebraico adecuado para el tipo de transacción procesada. De información numérica: se verifica para determinar que no contenga blancos dentro del campo y/o bits de zona erróneos. Los blancos son reemplazados por ceros. De información alfabética: normalmente no se producirá un inconveniente serio si se omite información alfabética, dado que puede agregarse en el registro la leyenda “sin descripción” y emitirse un mensaje para la corrección posterior del error. De tratarse de información vital para la aplicación (nombre de un empleado en el control de la liquidación de una nómina de haberes) debe indicarse inmediatamente la condición de error. Verificación de Campos: Controles de Secuencia: se emplean para verificar que la secuencia que siguen los campos es la correcta. Es necesario que exista una clara definición sobre lo que se entiende por secuencia, la misma puede ser ascendente o descendente. Secuencia puede significar que cada campo no es inferior al previo, que es superior al previo, o que es superior al previo en una unidad. Un problema que puede presentarse en el control de una secuencia, es la capacidad del sistema para continuar el procesamiento después de la aparición de un error. Un número incorrecto interrumpe la base de comparación y el impacto de dicha circunstancia dependerá, fundamentalmente, de la manera que se haya contemplado en las etapas previas de análisis y programación. Este tipo de controles combinados con la emisión de formularios con numeración de imprenta secuencial y unido a un estricto control sobre las existencias y utilización de dichos formularios, puede proporcionar un excelente control sobre una serie de aspectos de la parte no computarizada del sistema. De razonabilidad (o racionalidad): consiste en la programación de un juicio formulado previamente con respecto a la normalidad de cierta información. En la práctica puede resultar difícil establecer límites correctos de razonabilidad, por lo que la mejor solución a esto es experimentar y realimentar las constantes fijadas en función de la experiencia recogida. Ej.: el total de pedido por un cliente se compara con sus pedidos promedio, si el pedido excede tres veces este promedio, se emite un mensaje de excepción. Consistencia: un control de esta naturaleza establece relaciones que deben existir entre dos o más campos de un registro. En función de ello se determina la coherencia, congruencia o consistencia de la información respectiva. Es problema del analista la determinación de los campos que deberían verificarse en cuanto a su consistencia. En general, una cierta redundancia en este tipo de control no parece desaconsejable. Ej.: en el campo de horas trabajadas no hay información por cuanto el obrero estuvo enfermo, de acuerdo con la indicación del campo respectivo, no es posible que se liquiden horas extras a ese obrero, correspondientes a la quincena en cuestión. De rango: este control se aplica usualmente a un código, a efectos de verificar que esté comprendido dentro de un conjunto dado de caracteres o números. Límites: este control se emplea cuando es factible fijar topes superiores y/o inferiores a los valores, para ser aceptados. Cuando es posible establecer ambos límites, máximo y mínimo, el control se conoce con el nombre de rango. Este control es usado corrientemente y ofrece adecuada protección contra errores significativos, obviamente el grado de protección depende de la manera en que haya sido instrumentado el control. Una debilidad del mismo
es que el límite debe ser suficientemente amplio para poder aceptar toda la información válida posible. Este control no verifica que la información sea correcta, únicamente asegura que los valores se mantengan dentro de ciertos límites. Este tipo de control deberá emplearse para asegurar la corrección de información de entrada, actualizar y validar la información de salida. El empleo del control de límites se verá afectado por la acción prevista para el caso que la información no cumpla con los estándares fijados. Pueden darse dos circunstancias: 1) rechazo de toda información inválida; 2) emisión de un mensaje, pero la información continúa con el tratamiento previsto, teniendo en cuenta que en este caso los límites deben ser más estrictos. Ej.: el tiempo de horas extras no podrá exceder las 24 hs. semanales o el salario bruto mensual con bonificaciones no podrá ser superior en un 15% al salario anual. De existencia de un código: verificar la validez y existencia de un código, para ello se emplean tablas cuyo tamaño dependerá del número de códigos válidos a ser controlados. En el momento del diseño de las tablas, deberá reservarse la memoria suficiente para las futuras expansiones. De completamiento: este tipo de control verifica que no se hayan omitido campos de un registro. De fechas: su finalidad es determinar que la fecha del registro sea aceptable. Adicionalmente deberán fijarse límites para fechas futuras y pasadas. Ej.: la fecha puede consignarse en los registros utilizando dos dígitos para los días, mes y año (31/12/02).Los controles practicados sobre la fecha verifican que el mes caiga entre 01 y 12, el día entre 01 y 31, y el año de acuerdo con el año en curso. Dígitos de control: la técnica de dígito control es un importante medio para evitar los errores que pueden producirse en la transcripción o ingreso de los números de identificación (códigos) respectivos. Un dígito de verificación es un dígito redundante que se añade al número base como consecuencia de la aplicación de una fórmula matemática. El dígito puede agregarse como prefijo, sufijo (el más conocido y empleado) o insertarse dentro de los caracteres que componen el código. Cuando la información identificada por su código ingresa al sistema computarizado, el dígito control es separado del número básico, al cual se le aplica la fórmula matemática respectiva. El resultado obtenido es comparado con el dígito de control. En caso de coincidencia se asume la corrección del código ingresado y el procesamiento continúa. De existir discrepancia, se ha producido un error y hasta que el mismo no sea salvado no se procesa el registro. El dígito control se emplea para detectar errores accidentales como objetivo primario y subsidiariamente aquellos intencionales, ya fueran fraudulentos o maliciosos. Por todo lo anterior el desarrollo y empleo de fórmulas efectivas y eficientes de dígitos de control, contribuirá notablemente a reforzar la confiabilidad del sistema de control interno. Verificación de “lotes” o “batches”: Lote o batches: es uno de los métodos de control más simple y efectivo sobre la captura de datos, preparación y proceso de los mismos. El loteo consiste en el agrupamiento de transacciones que tienen algún tipo de relación entre sí. Es de suma importancia para el auditor el conocimiento de los variados controles que pueden ejercerse sobre el lote. Existen dos tipos de lote: lotes físicos, grupos de transacciones que constituyen una unidad física (ej.: documentos), y lotes lógicos, son un conjunto de transacciones reunidas de acuerdo con un principio lógico, más
que por el hecho de su continuidad física (ej.: varios empleados pueden ingresar información a un sistema empleando una terminal en-línea. Cada empleado lleva el control de las transacciones introducidas. El programa de ingreso de información agrupa la misma de acuerdo con el número de identificación de cada persona y, una vez transcurrido el lapso establecido prepara totales de control, los que deberán ser reconciliados con los totales de control individuales). Diseño de lotes: tener en cuenta el tamaño y la naturaleza de los lotes a emplear. Deberían respetarse estos principios: 1) El lote debe ser lo suficientemente pequeño para la ubicación de los errores si los controles de lote no balancean. 2) El lote debe ser lo adecuadamente grande, de tal forma que constituya una unidad de trabajo razonable-mente dimensionada. 3) El lote debería constituir una unidad lógica, por ejemplo, un conjunto de documentos representativos de un único tipo de transacción. Control de lote: su finalidad es asegurar la exactitud y completamiento de su contenido y confirmar que no se hayan perdido durante su movimiento físico. Para esto es necesario una tarjeta (hoja) de lote y un registro de control de lotes. La tarjeta para un lote físico generalmente contiene: nº de lote, totales de control de lote, información común para las diversas transacciones integrantes del lote, fecha de preparación del lote, información sobre los errores detectados en el lote, firma de los intervinientes en el tratamiento del lote. Para un lote lógico para de la información anterior quedará registrada. Controles sobre lotes: 1) Recuento de registros (o de documentos fuente): se practica un conteo de todos los registros comprendidos en un lote, el cual debe coincidir con el recuento que consta en la hoja. La no coincidencia indicará que se ha producido una omisión, adición o duplicación de los registros que deben someterse a control. 2) Totales del control: se trata de totales financieros. Todos los campos con información de tal naturaleza son acumulados y controlados con los totales del lote. Es una verificación típica que se ha practicado siempre sobre la información procesada por un sistema electrónico. Excepto que existan errores compensados, la coincidencia es una prueba que el lote es correcto y completo en cuanto a sus campos con montos financieros. 3) Totales de comprobación: es una acumulación de dígitos tomados de un campo de identificación o de control. Este tipo de control se establece únicamente con finalidades de verificación. Aunque las discrepancias determinadas proporcionan medios rápidos y seguros para localizar la transacción incorrecta, podría ocurrir que su acumulación ocasionará una carga adicional e inaceptable para el usuario. Este control debería implantarse solamente en los casos en los que la exactitud de la información de entrada se vea comprometida por problemas especiales. CONTROLES SOBRE EL PROCESAMIENTO: Verificaciones cruzadas (“cross footing”): en el sentido de control denota la suma cruzada o sustracción de dos o más campos y el balanceo del resultado a cero contra el resultado original (o previsto). Este es un control efectivo cuando los totales por débitos, créditos y el saldo de arrastre se mantienen para cada cuenta; los totales de débitos y créditos pueden cruzarse para verificar que la diferencia es igual al saldo. Este control puede emplearse también como base de recómputo o recálculo, mediante la reversión de las sumas y las restas.
Ej.: los totales de control pueden ser calculados para los salarios brutos, deducciones y neto a pagar. Al término del procesamiento, el monto neto debería ser igual al monto bruto menos las deducciones, o el monto neto más las deducciones, resultar igual al monto bruto. Balanceo de los archivos procesados parcialmente: por las características del disco magnético, únicamente es necesario consultar los registros necesarios para el caso. Desde que los registros inactivos no son tratados, el procedimiento de balanceo debe reposar sobre la premisa básica que la información contenida en ellos es correcta. Esta premisa es verificada a intervalos periódicos, mediante los controles de los saldos que permitan la adopción de las medidas correctivas necesarias. En el caso que el sistema de computación no realice este control automáticamente, el restante problema de verificación consiste en la determinación de si los registros activos son procesados correctamente y que un error producido en un registro puede ser detectado en el trata- miento previsto para el sistema. El medio de localizar errores a través de esta técnica, consiste en el establecimiento de los campos de saldos globales en adición a los campos con el detalle individual. Cada vez que se produce el tratamiento de un registro se procede a un control cruzado “antes” y “después” de su procesamiento, para obtener la seguridad que el registro estaba y permanece “balanceado”. Un total de todos los saldos de los registros afectados “antes” es conciliado con las modificaciones y el total de saldos “después”. Una vez practicada dicha conciliación, el total de las modificaciones es grabado en los registros que mantienen saldos de control que, de tal manera, reflejan el total correcto de saldos de todos los registros. Control sobre redondeos: los problemas de redondeo se producen cuando el nivel de precisión requerido en un cálculo aritmético es menor que el grado de precisión con el cual el cálculo se realiza efectivamente en la práctica. Existe un algoritmo muy conocido para el tratamiento de este problema. El auditor debería cerciorarse que tal algoritmo haya sido empleado por dos motivos. En primer lugar, podría no ser del conocimiento de un programador sin la experiencia suficiente. En segundo lugar, por cuanto una simple modificación a tal algoritmo pueda dar lugar a un delito informático. PROCEDIMIENTOS PARA EL CONTROL DE SALIDA. Anteriormente, la información de salida de un procesamiento computarizado se reflejaba en listados impresos en papel o formularios. El avance tecnológico ha introducido a los “mensajes en pantalla” como una nueva modalidad de salida. De manera que a los típicos controles del material impreso deben adicionarse los controles sobre los usuarios que estarán autorizados a acceder a información por pantalla, como también, bajo qué circunstancias. Algunos de los controles de salida más habituales son: Custodia de los formularios críticos o negociables: Los formularios en blanco deben estar protegidos contra robos o daños. Deberán mantenerse adecuados registros sobre la existencia y uso de los mismos, y cumplirse con planes de recuentos físicos. Conciliación entre formularios salidos del inventario y aquellos procesados: Una persona ajena a quien genere la impresión deberá conciliar y fundamentar las razones de las diferencias por errores de impresión, mutilaciones, etc. Conciliación de importes totales contenidos en las salidas: Deben conciliarse los importes totales de salida con los respectivos importes totales de datos de entrada al proceso asociado con esa salida. Al auditor le interesará verificar el procesamiento de transacciones en caso de ausencia de balanceo.
Control de distribución y verificación de recepción: Es necesario diferenciar los informes confidenciales de los generales. El control de distribución contribuye a mantener la confidencialidad de información reservada. Por otra parte, será necesario cerciorarse de la recepción correcta. Tiempo de retención de informes: Se deberán determinar los tiempos fijados desde el punto de vista legal y desde la normativa interna de la empresa. Información de salida para corrección de errores: Normalmente los programas prevén métodos de detección de errores, lo cual no implica que los procesos se interrumpan por esa circunstancia. En estos casos, los errores se imprimen en un listado o bien se muestran por pantalla, pero lo importante es verificar que los mismos queden registrados en almacenamiento transitorio hasta tanto se verifique su corrección y reingreso al proceso. El auditor revisará el procesamiento que utiliza el usuario para corregir y retornar los datos al proceso.
PARTICIPACIÓN DEL PROFESIONAL EN LA ELABORACIÒN DE NORMAS INTERNAS, DESARROLLO Y MANTENIMIENTO DE LOS SISTEMAS. MEDICIÓN DEL DESEMPEÑO En toda empresa, cualquiera sea su naturaleza o tamaño, siempre hay una necesidad de medir los esfuerzos y realizaciones hechas. El resultado de planear, organizar y dirigir puede ser medido. El establecimiento de metas, medidas o normas, el planear cómo alcanzarlos y luego poner en marcha el plan constituye una buena forma, práctica y organizada, de progresar. La tarea posterior consiste en comprobar lo bien que se ha hecho todo eso, precisar hasta dónde se alcanzaron las metas y establecer claramente los diferentes medios para inspeccionar l a obra. ¿Cómo medir el desempeño? Para el auditor, cuya función consiste en evaluar, las normas constituyen un instrumento de importancia. El hecho de la evaluación implica realizar mediciones. Al llevar a cabo su estudio, el auditor no sólo deberá familiarizarse bien con las normas de desempeño, sino que debe estar alerta a todo factor o factores adicionales que incluyan el determinar si las normas son atinadas, revisadas con frecuencia y modificadas para acomodarlas a las situaciones cambiantes, así como debidamente encauzadas, entendidas y aceptadas por los departamentos y personas involucradas. ¿Cuál es la unidad de medida, el estándar o la norma con la cual voy a medir o comparar el sistema de información? Este suele ser otro problema que surge a los auditores de sistemas de información, al no existir un patrón único aplicable. En términos generales podemos mencionar: Normas internas del ente: Algunas organizaciones de cierta envergadura suelen generar su propio conjunto de normas de funcionamiento materializadas en manuales de procedimientos, cursogramas, flujogramas, organigramas, documentación de sistemas, etc. lo que resulta más difícil es que estas normas reflejen el impacto que la informática a causado en sus sistemas, e incluyan pautas específicas sobre el tema. Aún en los casos en los que existan, deben mantenerse actualizadas por la velocidad de los cambios en este tipo de sistemas (actualizaciones en el equipamiento, en los sistemas operativos, en las aplicaciones y en las comunicaciones) Normas de organismos de control: Algunos organismos de control ya han emitido normas específicas referidas a Tecnología de la Información (TI) ejemplos de ellos en nuestro medio son: el Banco Central de la República
Argentina con su Comunicación A 2659, la Sindicatura General de la Nación con las “Pautas de Control Interno para Sistemas Computadorizados y Tecnología de Información”, el gobierno de la Provincia de Mendoza con sus “Normas de Seguridad de Sistemas de Información” y a través de la adopción de COBIT, etc. En algunos casos es necesario complementarlas con otras pautas o normas referidas a los otros componentes de un sistema de información distintos de la TI. Estándares emitidos por organizaciones especializadas: Organizaciones internacionales de profesionales han emitido normas aplicables a este tipo de auditorías, entre las más relevantes se pueden mencionar: Informe C.O.S.O. 5(Committee of Sponsoring Organizations) elaborado por la Treadway Commission, (EEUU 1.992) referido a pautas de control interno en general; C.O.B.I.T Objetivos de control para la información y la tecnología relacionada desarrollado por la I.S.A.C.A. Asociación de Auditoría y Control de Sistemas de Información. Ambos estándares se complementan abarcando prácticamente todos los aspectos relevantes de un S.I. Criterio del Auditor: es el menos recomendable y en general el más utilizado, la principal crítica que se le puede hacer como sensor es la falta de objetividad, ya que es la opinión del auditor sobre lo que debería ser, y por lo general suele ser muy discutida, salvo casos de observaciones muy evidentes, o una muy buena fundamentación del criterio utilizado.
HERRAMIENTAS Y TÉCNICAS PARA LA AUDITORÍA INFORMÁTICA: 2 CUESTIONARIOS: Las auditorías informáticas se materializan recabando información y documentación de todo tipo. Los informes finales de los auditores dependen de sus capacidades para analizar las situaciones de debilidad o fortaleza de los diferentes entornos. El trabajo de campo del auditor consiste en lograr toda la información necesaria para la emisión de un juicio global objetivo, siempre amparado en hechos demostrables, llamados también evidencias. Para esto, suele ser lo habitual comenzar solicitando la cumplimentación de cuestionarios preimpresos que se envían a las personas concretas que el auditor cree adecuadas, sin que sea obligatorio que dichas personas sean las responsables oficiales de las diversas áreas a auditar. Estos cuestionarios no pueden ni deben ser repetidos para instalaciones distintas, sino diferentes y muy específicos para cada situación, y muy cuidados en su fondo y su forma. Sobre esta base, se estudia y analiza la documentación recibida, de modo que tal análisis determine a su vez la información que deberá elaborar el propio auditor. El cruzamiento de ambos tipos de información es una de las bases fundamentales de la auditoría. Cabe aclarar, que esta primera fase puede omitirse cuando los auditores hayan adquirido por otro medios la información que aquellos preimpresos hubieran proporcionado.
2
ACHA ITURMENDI, J. José, Auditoría informática en la empresa (1994, Madrid, Paraninfo), 67/73 pág.
ENTREVISTAS: El auditor comienza a continuación las relaciones personales con el auditado. Lo hace de tres formas: Mediante la petición de documentación concreta sobre alguna materia de su responsabilidad. Mediante “entrevistas” en las que no se sigue un plan predeterminado ni un método estricto de sometimiento a un cuestionario. Por medio de entrevistas en las que el auditor sigue un método preestablecido de antemano y busca unas finalidades concretas. La entrevista es una de las actividades personales más importante del auditor; en ellas, éste recoge más información, y mejor matizada, que la proporcionada por medios propios puramente técnicos o por las respuestas escritas a cuestionarios. Aparte de algunas cuestiones menos importantes, la entrevista entre auditor y auditado se basa fundamentalmente en el concepto de interrogatorio; es lo que hace un auditor, interroga y se interroga a sí mismo. El auditor informático experto entrevista al auditado siguiendo un cuidadoso sistema previamente establecido, consistente en que bajo la forma de una conversación correcta y lo menos tensa posible, el auditado conteste sencillamente y con pulcritud a una serie de preguntas variadas, también simples. Sin embargo, esta sencillez es solo aparente. Tras ella debe existir una preparación muy elaborada y sistematizada, y que es diferente para cada caso particular. Su objeto es conocer la opinión que tienen los usuarios sobre los servicios proporcionados, así como la difusión de las aplicaciones de la computadora y de los sistemas en operación. Las entrevistas se deberán hacer, en caso de ser posible, a todos los usuarios o bien en forma aleatoria a algunos de los usuarios, tanto de los más importantes como de los de menor importancia, en cuanto al uso del equipo. CHECKLIST: El auditor profesional y experto es aquél que reelabora muchas veces sus cuestionarios en función de los escenarios auditados. Tiene claro lo que necesita saber, y por qué. Sus cuestionarios son vitales para el trabajo de análisis, cruzamiento y síntesis posterior, lo cual no quiere decir que haya de someter al auditado a unas preguntas estereotipadas que no conducen a nada. Muy por el contrario, el auditor conversará y hará preguntas “normales”, que en realidad servirán para la cumplimentación sistemática de sus Cuestionarios, de sus Checklists. Hay opiniones que descalifican el uso de las Checklists, ya que consideran que leerle una pila de preguntas recitadas de memoria o leídas en voz alta descalifica al auditor informático. Pero esto no es usar Checklists, es una evidente falta de profesionalismo. El profesionalismo pasa por un procesamiento interno de información a fin de obtener respuestas coherentes que permitan una correcta descripción de puntos débiles y fuertes. El profesionalismo pasa por poseer preguntas muy estudiadas que han de formularse flexiblemente. El conjunto de estas preguntas recibe el nombre de Checklist. Salvo excepciones, las Checklists deben ser contestadas oralmente, ya que superan en riqueza y generalización a cualquier otra forma. El auditor deberá aplicar la Checklist de modo que el auditado responda clara y escuetamente. Se deberá interrumpir lo menos posible a éste, y solamente en los casos en que
las respuestas se aparten sustancialmente de la pregunta. En algunas ocasiones, se hará necesario invitar a aquél a que exponga con mayor amplitud un tema concreto, y en cualquier caso, se deberá evitar absolutamente la presión sobre el mismo. Algunas de las preguntas de las Checklists utilizadas para cada sector, deben ser repetidas. En efecto, bajo apariencia distinta, el auditor formulará preguntas equivalentes a las mismas o a distintas personas, en las mismas fechas, o en fechas diferentes. De este modo, se podrán descubrir con mayor facilidad los puntos contradictorios; el auditor deberá analizar los matices de las respuestas y reelaborar preguntas complementarias cuando hayan existido contradicciones, hasta conseguir la homogeneidad. El entrevistado no debe percibir un excesivo formalismo en las preguntas. El auditor, por su parte, tomará las notas imprescindibles en presencia del auditado, y nunca escribirá cruces ni marcará cuestionarios en su presencia. Los cuestionarios o Checklists responden fundamentalmente a dos tipos de “filosofía” de calificación o evaluación: Checklist de rango: Contiene preguntas que el auditor debe puntuar dentro de un rango preestablecido (por ejemplo, de 1 a 5, siendo 1 la respuesta más negativa y el 5 el valor más positivo). Ejemplo de Checklist de rango: Se supone que se está realizando una auditoría sobre la seguridad física de una instalación y, dentro de ella, se analiza el control de los accesos de personas y cosas al Centro de Cálculo. Podrían formularse las preguntas que figuran a continuación, en donde las respuestas tienen los siguientes significados: 1: Muy deficiente. 2: Deficiente. 3: Mejorable. 4: Aceptable. 5: Correcto. Se figuran posibles respuestas de los auditados. Las preguntas deben sucederse sin que parezcan clasificadas previamente. Basta con que el auditor lleve un pequeño guión. La cumplimentación de la Checklist no debe realizarse en presencia del auditado. -¿Existe personal específico de vigilancia externa al edificio? -No, solamente un guarda por la noche que atiende además otra instalación adyacente.
-Para la vigilancia interna del edificio, ¿Hay al menos un vigilante por turno en los aledaños del Centro de Cálculo? -Si, pero sube a las otras 4 plantas cuando se le necesita. -¿Hay salida de emergencia además de la habilitada para la entrada y salida de máquinas? -Si, pero existen cajas apiladas en dicha puerta. Algunas veces las quitan. -El personal de Comunicaciones, ¿Puede entrar directamente en la Sala de Computadoras? -No, solo tiene tarjeta el Jefe de Comunicaciones. No se la da a su gente mas que por causa muy justificada, y avisando casi siempre al Jefe de Explotación. El resultado sería el promedio de las puntuaciones: (1 + 2 + 2 + 4) /4 = 2,25 Deficiente.
Checklist Binaria: Es la constituida por preguntas con respuesta única y excluyente: Si o No. Aritméticamente, equivalen a 1(uno) o 0(cero), respectivamente. Ejemplo de Checklist Binaria: Se supone que se está realizando una Revisión de los métodos de pruebas de programas en el ámbito de Desarrollo de Proyectos. -¿Existe Normativa de que el usuario final compruebe los resultados finales de los programas? -¿Conoce el personal de Desarrollo la existencia de la anterior normativa? -¿Se aplica dicha norma en todos los casos? -¿Existe una norma por la cual las pruebas han de realizarse con juegos de ensayo o copia de Bases de Datos reales? Las Checklists de rango son adecuadas si el equipo auditor no es muy grande y mantiene criterios uniformes y equivalentes en las valoraciones. Permiten una mayor precisión en la evaluación que en la checklist binaria. Sin embargo, la bondad del método depende excesivamente de la formación y competencia del equipo auditor. Las Checklists Binarias siguen una elaboración inicial mucho más ardua y compleja. Deben ser de gran precisión, como corresponde a la suma precisión de la respuesta. Una vez construidas, tienen la ventaja de exigir menos uniformidad del equipo auditor y el inconveniente genérico del frente a la mayor riqueza del intervalo. No existen Checklists estándar para todas y cada una de las instalaciones informáticas a auditar. Cada una de ellas posee peculiaridades que hacen necesarios los retoques de adaptación correspondientes en las preguntas a realizar.
CONCLUSION La Auditoría de Sistema en Desarrollo compromete la condición básica para el ejercicio de la auditoría, que es justamente la independencia de criterio del auditor con respecto al sistema objeto de examen. Existen muchos que están a favor de la intervención del auditor en el desarrollo del sistema. Entendemos que esto es posible, siempre y cuando se mantenga dicha condición básica.
BIBLIOGRAFÍA
LARDENT, Alberto D., Sistemas de Información par la Gestión Empresaria. Procedimientos, Seguridad y Auditoria, Prentice Hall. DERRIEN, Yann, Técnicas de la Auditoria Informática (1995, Colombia, Alfaomega Marcombo). ACHA ITURMENDI, J. José, Auditoría informática en la empresa (1994, Madrid, Paraninfo).
