AUDITORÍA DEL DESARROLLO DE SISTEMAS

Presentación del tema: "AUDITORÍA DEL DESARROLLO DE SISTEMAS"— Transcripción de la presentación:

1 AUDITORÍA DEL DESARROLLO DE SISTEMAS
AUDITORÍA APLICADA A LA INFORMÁTICA AUDITORÍA DEL DESARROLLO DE SISTEMAS

2 Introducción Los auditores de sistemas de información suelen encontrarse con carencias o insuficiencias de controles que podrían haberse incorporado en el momento de su diseño; esto provoca que la auditoría se dificulte al no tener pistas que posibiliten la revisión. En los comienzos, la auditoría comenzaba cuando el sistema entraba en operación normal, ya que se argumentaba que no debían involucrarse en el desarrollo. El argumento que sustenta esto es que si el auditor participa en el diseño e implementación de un sistema y se satisface de los controles que él mismo incorporó quedaría inhabilitado para opinar, luego de la implementación, acerca de la falta de adecuación de esos mismos controles.

3 Objetivos de la Auditoría de Desarrollo de Sistemas
• Determinar los objetivos y requerimientos básicos de los usuarios del sistema e identificar las áreas afectadas por el mismo. • Determinar y clasificar los riesgos y exposición a riesgos del sistema. • Procurar la identificación de los controles necesarios con el propósito de minimizar los riesgos y exposiciones a riesgos del sistema • Asesorar a los miembros integrantes del proyecto de desarrollo del sistema respecto de la incorporación de controles en el diseño y de módulos de auditoría, que permita las revisiones de rutina a través de las pistas de auditoría. • Asegurar que se sigan los pasos definidos en la metodología de desarrollo aplicada.

4 Puntos de Control El alcance de la participación del auditor en el desarrollo de los sistemas debe enfocarse hacia la determinación de puntos de control que deberían estar en los sistemas. Estos puntos clave son aquellos que permiten al auditor definir la adecuación de los controles y el cumplimiento de las políticas y procedimientos en la organización.

5 Revisión del desarrollo del ciclo de vida de los sistemas de información
Para efectuar la tarea de revisión, el auditor debe disponer de la documentación elaborada en cada una de las fases, así como también, mantener periódicas reuniones con los miembros del proyecto a fin de participar en el momento en el cual su contribución sea más útil. Durante el desarrollo del ciclo de vida, el auditor debe: • Analizar los riesgos asociados y las exposiciones a riesgos que son inherentes en cada fase • Prever de mecanismos de control adecuados para minimizar esos riesgos • Tener en cuenta que el costo de administrar los controles no sea mayor que el valor de los riesgos que intenta minimizar

6 Desarrollo del Plan Maestro
Antes del concreto desarrollo de proyectos de sistemas de información, las organizaciones deben formular un Plan Maestro. El Plan Maestro es un instrumento para estructurar sistemas. Identifica aquellos proyectos planeados para futuro y el orden de las prioridades, además prevé los recursos necesarios para desarrollarlos.

7 Desarrollo del Plan Maestro
El interés del auditor debe estar dirigido a verificar los siguientes aspectos: 1. Que exista un Plan Maestro Sistemático 2. Que esté estructurado de tal forma que se pueda determinar en qué etapa del desarrollo se encuentra cada aplicación. 3. Que en el plan no se incluyan aplicaciones que produzcan esfuerzos duplicado 4. Que el plan tienda a la integración de aplicaciones actuales y de propuestas 5. Que el plan sea lo suficientemente flexible 6.Que los sistemas propuestos sean realmente necesarios y que los usuarios hagan un buen uso de estos

8

9 Participantes y funciones en el desarrollo del sistema
Alta gerencia Planifica, aprueba proyectos Asigna recursos para su elaboración Gerencias Usuarias Responsable definición de requerimientos Revisión pruebas de sistemas Capacitación de usuarios Gerencia de sistema de información Soporte técnico , desarrollo, instalación. Mantenimiento en operación del sistema

10 Participantes y funciones en el desarrollo del sistema
Líder del proyecto Monitorea los proyectos Dirige a los participantes Verifica el cumplimiento de estándares Coordina las tareas entre usuarios Responsable definición de requerimientos Cumple la tarea asignada Análisis del sistema Diseño Programación documentación Usuarios Definen requerimientos Revisan Pruebas Informan resultados

11 Participantes y funciones en el desarrollo del sistema
Aseguramiento de Calidad Revisa y controla el cumplimiento de estándares de calidad Responsable de seguridad Verifica políticas de seguridad El sistema responda de acuerdo a las políticas de seguridad Asesora las medidas de seguridad Verifica la seguridad del sistema antes de su implantación Auditoria de Sistemas Evalúa la razonabilidad de los resultados Verifica la presencia de controles en el sistema Asegurar que el sistema sea auditable y contenga rastro de auditoría Formula las nuevas tareas del sistema Verifica la ejecución de pruebas

12 Auditoría de la adquisición de software
Una de las soluciones es la compra de software ya elaborado, el auditor de sistemas deberá revisar la aplicación de criterios de evaluación como los que se indican a continuación: Solvencia e idoneidad del proveedor Recupero del código fuente Documentación de respaldo del producto Nivel de satisfacción de otros clientes. Capacidad del proveedor

13 Proveedores de buena reputación que ofrezcan productos originales, serán mas confiables, se deberá analizar si el proveedor respalda el producto por tecnología actualizadas o si la tecnología que ofrece se volverá obsoleta. Solvencia e idoneidad del proveedor Recupero del código fuente Documentación de respaldo del producto Nivel de satisfacción de otros clientes

14 Solvencia e idoneidad del proveedor
El contrato del producto debe prever una cláusula que permita adquirir el código fuente y debe asegurar que se incluyan en el acuerdo de depósito del código fuente, los arreglos de programas y actualizaciones. Recupero del código fuente Documentación de respaldo del producto Nivel de satisfacción de otros clientes

15 Solvencia e idoneidad del proveedor
Recupero del código fuente Se debe incluir la documentación lo mas detallada para que el usuario resuelva los problemas que se pudieran presentar en las operaciones. Documentación de respaldo del producto Nivel de satisfacción de otros clientes

16 Solvencia e idoneidad del proveedor
Recupero del código fuente Documentación de respaldo del producto Observar el comportamiento del producto en un ambiente de producción y demostración Nivel de satisfacción de otros clientes

17 El contrato debe incluir la descripción especifica del producto
Especificar el tipo de documentación que acompañará al producto, capacitación para su uso, notificar sobre nuevas versiones El contrato de incluir si el usuario podrá efectuar modificaciones a los programas y en caso afirmativo bajo que condiciones. Cláusulas de depósito de software Deberá prever solución para casos de recuperación de desastres Capacidad del proveedor para actualizar el producto

18 Auditoría de Modificaciones a programas
Se deberá seguir los siguientes aspectos: Autorización de cambios Concordancia entre código fuente y Código objeto Pista de auditorías para seguimiento de cambios Documentación de programas Documentación de sistemas

19 1. Autorización de cambios
2. Concordancia entre código fuente y Código objeto Es necesaria la autorización para modificar parte de un sistema que ya se encuentra en producción. Esta autorización debe provenir de un usuario involucrado. El auditor de sistema deberá acentuar tarea de control en aquellas situaciones de emergencia en las que suele obviarse el cumplimiento del compromiso de autorización La biblioteca de código fuente debe contener exactamente las mismas versiones de programas que la biblioteca de código objeto. El auditor debe asegurarse de que cada vez que se transfiera un programa a la biblioteca de código fuente, el programa objeto ejecute exactamente las mismas funciones que aquel

20 3. Pistas de auditoría para seguimiento de cambios
Todos los cambios de programas deben quedar registrados, de modo que se posibilite cualquier análisis posterior. Las pistas de auditoría sobre estos cambios se refieren a: Solicitud de cambio y aprobación. Fecha y hora de la modificación del programa Identificación del personal actuante en la modificación Instrucciones antes y después de la modificación

21 4. Documentación de programas
Dentro de la documentación de programas deben existir evidencias de los cambios operados en los mismos, incluyen: Solicitud del cambio Motivos del cambio Resultado de análisis Especificación del cambio Resultados de las pruebas efectuadas

22 5. Documentación de Sistemas
Las modificaciones pueden provocar cambios en la documentación del sistema del cual forman parte esos programas. El auditor deberá verificar concordancia entre una y otra documentación. Especialmente en cuanto a: Diagramas de flujo del sistema Descripción del proceso Contenido del diccionario de datos Descripción de corridas de programas Documentación de usuario final

23 GRACIAS