Auditoria a Aplicaciones en Desarrollo : Sep 21/2009 ING. MARTHA LUCIA PALACIOS 1 Auditoria a Aplicaciones en Desarrollo
Slide 2 : MLPH Auditoria- Videoconferencia 2 DESARROLLO Y MANTENIMIENTO DE SISTEMAS
Slide 3 : Revisión del
requerimiento Revisión de la
especificación Revisión
Proceso
selección Revisión
Proceso de
customización Revisión de
pruebas
e instalación Revisión de la
Entrega Auditoría del Desarrollo, Compra o Implementación de SI
Slide 4 : Fallas de Software Son errores de software introducidos durante cualquier fase de desarrollo (requerimientos, arquitectura, diseño, programación, configuración, mantenimiento)
Son de dos tipos:
Funcionales – software no funciona como debería
No funcionales - afectan la robustez, seguridad, performance, escalabilidad, carga y usabilidad del software
Son causadas por desarrollo informal y la falta de pruebas de software
Slide 5 : Desarrollo informal Incapacidad del equipo para cumplir con cronogramas establecidos
Brecha entre las área de técnica de negocios
Gran numero de fallas en versión final del software Costo de falla de requerimientos es mayor que costo de falla de diseño o de programación
Costo de falla aumenta con el tiempo
Slide 6 : Descubren errores funcionales y no funcionales
Proceso fundamental dentro de la ingeniería de software
Aumentan visibilidad de proyectos de desarrollo
Complementan control de calidad
Minimizan el tiempo al retorno de inversión y maximizan las ganancias en proyectos de software Pruebas de Software Niveles de testeo
Tipos de pruebas
Métodos manuales y automatizados
Herramientas
Entregables Ingeniería de pruebas
Slide 7 : La función de Desarrollo es una evolución del llamado Análisis y Programación de Sistemas y Aplicaciones.
A su vez, engloba muchas áreas, tantas como sectores informatizables tiene la empresa.
Una Aplicación pasa por las siguientes fases:
Prerequisitos del Usuario (único o plural) y del entorno
Análisis funcional
Diseño
Análisis orgánico (Preprogramacion y Programación)
Pruebas
Entrega a Explotación y alta para el Proceso. Auditoría Informática de Desarrollo de Proyectos o Aplicaciones:
Slide 8 : Estas fases deben estar sometidas a un exigente control interno, caso contrario, además del disparo de los costes, podrá producirse la insatisfacción del usuario.
Finalmente, la auditoría deberá comprobar la seguridad de los programas en el sentido de garantizar que los ejecutados por la maquina sean exactamente los previstos y no otros.
Una auditoría de Aplicaciones pasa por la observación y el análisis de las siguientes consideraciones:
Revisión de las metodologías utilizadas: Se analizaran éstas, de modo que se asegure la modularidad de las posibles futuras ampliaciones de la Aplicación y el fácil mantenimiento de las mismas.
Slide 9 : Estudio de Vialidad de la Aplicación. [importante para Aplicaciones largas, complejas y caras]
Definición Lógica de la Aplicación. [se analizará que se han observado los postulados lógicos de actuación, en función de la metodología elegida y la finalidad que persigue el proyecto]
Desarrollo Técnico de la Aplicación. [Se verificará que éste es ordenado y correcto. Las herramientas técnicas utilizadas en los diversos programas deberán ser compatibles]
Diseño de Programas. [deberán poseer la máxima sencillez, modularidad y economía de recursos]
Métodos de Pruebas. [ Se realizarán de acuerdo a las Normas de la Instalación. Se utilizarán juegos de ensayo de datos, sin que sea permisible el uso de datos reales]
Documentación. [cumplirá la Normativa establecida en la Instalación, tanto la de Desarrollo como la de entrega de Aplicaciones a Explotación]
Equipo de Programación. [Deben fijarse las tareas de análisis puro, de programación y las intermedias. En Aplicaciones complejas se producirían variaciones en la composición del grupo, pero estos deberán estar previstos]
Slide 10 : Satisfacción de usuarios: Una Aplicación técnicamente eficiente y bien desarrollada, deberá considerarse fracasada si no sirve a los intereses del usuario que la solicitó. La aquiescencia del usuario proporciona grandes ventajas posteriores, ya que evitará reprogramaciones y disminuirá el mantenimiento de la Aplicación.
Control de Procesos y Ejecuciones de Programas Críticos: El auditor no debe descartar la posibilidad de que se esté ejecutando un módulo que no se corresponde con el programa fuente que desarrolló, codificó y probó el área de Desarrollo de Aplicaciones. Se ha de comprobar la correspondencia biunívoca y exclusiva entre el programa codificado y su compilación. Si los programas fuente y los programa módulo no coincidieran podríase provocar, desde errores de bulto que producirían graves y altos costes de mantenimiento, hasta fraudes, pasando por acciones de sabotaje, espionaje industrial-informativo, etc. Por ende, hay normas muy rígidas en cuanto a las Librerías de programas; aquellos programas fuente que hayan sido dados por bueno por Desarrollo, son entregados a Explotación con el fin de que éste:
Copie el programa fuente en la Librería de Fuentes de Explotación, a la que nadie más tiene acceso
Compile y monte ese programa, depositándolo en la Librería de Módulos de Explotación, a la que nadie más tiene acceso.
Copie los programas fuente que les sean solicitados para modificarlos, arreglarlos, etc. en el lugar que se le indique. Cualquier cambio exigirá pasar nuevamente por el punto 1.
Slide 11 : Ejemplo de Plan para Revisión de Requerimientos
Requerimientos de Seguridad de los Sistemas : Análisis y especificaciones de los requerimientos de Seguridad de la aplicación AUDITORIA Requerimientos de Seguridad de los Sistemas
Requerimientos de Seguridad de los Sistemas : Requerimientos de Seguridad de los Sistemas
Requerimientos de Seguridad de los Sistemas : Requerimientos de Seguridad de los Sistemas
Requerimientos de Seguridad de los Sistemas : Requerimientos de Seguridad de los Sistemas
Seguridad en los Sistemas de Aplicación : Validación de datos de entrada
Controles de procesamiento interno
Autenticación de mensajes
Validación de los datos de salida Seguridad en los Sistemas de Aplicación
Requerimientos de Seguridad de los Sistemas : Requerimientos de Seguridad de los Sistemas
Seguridad en los Sistemas de Aplicación : Seguridad en los Sistemas de Aplicación VALIDACION DE
LOS DATOS DE ENTRADA ASEGURAR QUE SON CORRECTOS Y APROPIADOS CONTROLES APLICADOS A ENTRADAS DE TRANSACCIONES, DATOS PERMANENTES, TABLAS DE PARAMETROS
Seguridad en los Sistemas de Aplicación : Seguridad en los Sistemas de Aplicación CONTROLES DE PROCESAMIENTO INTERNO AREAS DE RIEGOS
CONTROLES Y VERIFICACIONES
Seguridad en los Sistemas de Aplicación : Seguridad en los Sistemas de Aplicación AUTENTICACION DE MENSAJES CAMBIOS NO AUTORIZADOS EN EL CONTENIDO DE UN MENSAJE TRANSMITIDO ELECTRÓNICAMENTE IMPLEMENTADO EN HARDWARE Y SOFTWARE
Seguridad en los Sistemas de Aplicación : Seguridad en los Sistemas de Aplicación VALIDACION DE DATOS DE SALIDA GARANTIZAR QUE EL PROCESAMIENTO DE LA INFORMACIÓN ALMACENADA SEA CORRECTO Y ADECUADO
Normas, procedimientos y métodos : Normas, procedimientos y métodos Considerar procedimientos para administrar requerimientos legales de acceso a claves criptográficas. Ej: Tener información (cifrada) en una forma clara la cual es necesaria para un caso judicial.
Normas, procedimientos y métodos : Normas, procedimientos y métodos
: Garantizar que los proyectos y actividades de soporte de TI se lleven a cabo de manera segura. Seguridad de los Archivos del Sistema
Control del Software Operativo : La actualización de las bibliotecas de programas operativos solo debe ser realizada por el bibliotecario designado una vez autorizada adecuadamente por la gerencia.
Si es posible, los sistemas en operaciones sólo deben guardar el código ejecutable. Control del Software Operativo
Slide 26 : El código ejecutable no debe ser implementado en un sistema operacional hasta tanto no se obtenga evidencia del éxito de las pruebas y de la aceptación del usuario, y se hayan actualizado las correspondientes bibliotecas de programas fuente.Se debe mantener un registro de auditoria de todas las actualizaciones a las bibliotecas de programas operativos.Las versiones previas de software deben ser retenidas como medida de contingencia.
El mantenimiento del software suministrado por el proveedor y utilizado en los sistemas operacionales debe contar con el soporte del mismo. Los parches de software deben aplicarse cuando pueden ayudar a eliminar o reducir las debilidades en materia de seguridad. Solo debe otorgarse acceso lógico o físico a los proveedores con fines de soporte y si resulta necesario, y previa aprobación de la gerencia. Las actividades del proveedor deben ser monitoreadas : El mantenimiento del software suministrado por el proveedor y utilizado en los sistemas operacionales debe contar con el soporte del mismo. Los parches de software deben aplicarse cuando pueden ayudar a eliminar o reducir las debilidades en materia de seguridad. Solo debe otorgarse acceso lógico o físico a los proveedores con fines de soporte y si resulta necesario, y previa aprobación de la gerencia. Las actividades del proveedor deben ser monitoreadas
Protección de los datos de prueba del sistema : Los datos de prueba deben ser protegidos y controlados. Las pruebas de aceptación del sistema normalmente requieren volúmenes considerables de datos de prueba, que sean tan cercanos como sea posible a los datos operativos.
Se debe evitar el uso de bases de datos operativas que contengan información personal.
Si se utiliza información de esta índole, esta debe ser despersonalizada antes del uso Protección de los datos de prueba del sistema
Controles para proteger los datos operativos cuando se utilizan con propósitos de prueba. : Los procedimientos de control de accesos, que se aplican a los sistemas de aplicación en operación deben aplicarse a los sistemas de aplicación de prueba.
Se debe llevar a cabo una autorización por separado cada vez que se copia información operativa a un sistema de aplicación de pruebas.
Se debe borrar la información operativa de un sistema de aplicación de prueba inmediatamente después de completada la misma.
La copia y el uso de información operacional deben ser registrados a fin de suministrar una pista de auditoria. Controles para proteger los datos operativos cuando se utilizan con propósitos de prueba.
Slide 30 : 30 Se debe mantener un control estricto del acceso a las bibliotecas de programa fuente, según los siguientes puntos:
Dentro de lo posible, las bibliotecas de programas fuente no deben ser almacenadas en los sistemas que está operativo.
Se debe designar a un bibliotecario de programas para cada aplicación.
El personal de soporte de TI no debe tener acceso irrestricto a las bibliotecas de programas fuente. Control de acceso a las bibliotecas de programa fuente
Slide 31 : Se debe designar a un bibliotecario de programas para cada aplicación.
El personal de soporte de TI no debe tener acceso irrestricto a las bibliotecas de programas fuente.
Los programas en desarrollo o mantenimiento no deben ser almacenados en las bibliotecas de programas fuente operacional.
La actualización de bibliotecas de programas fuente y la distribución de programas fuente a los programadores, solo debe ser llevada a cabo por el bibliotecario designado, con la autorización del gerente de soporte de TI para la aplicación pertinente.
Los listados de programas deben ser almacenados en un ambiente seguro.
Se debe mantener un registro de auditoria de todos los accesos a las bibliotecas de programa fuente.
Slide 32 : Las viejas versiones de los programas fuente deben ser archivadas con una clara indicación de las fechas y horas precisas en las cuales estaban en operaciones, junto con todo el software de soporte, el control de tareas, las definiciones de datos y los procedimientos.
El mantenimiento y la copia de las bibliotecas de programas fuente deben estar sujeta a procedimientos estrictos de control de cambios
PREGUNTAS : Sep 21/09 MLPH 33 PREGUNTAS
GRACIAS : GRACIAS SEPTIEMBRE 21/09 Auditoria de Sistemas 34