CISAChapter3
-
Upload
ramlyg-oiciniv-ohcagol-azi -
Category
Documents
-
view
14 -
download
1
Transcript of CISAChapter3
Curso de Repaso CISA 2011
Capítulo 3
Adquisición, Desarrollo e
Implementación de Sistemas de
Información
Agenda del Curso
• Objetivos de aprendizaje
• Discutir tareas y Conocimientos Relacionados
• Discutir temas específicos del capítulo
• Preguntas de ejemplo
Asegurar que el candidato CISA…Entienda y pueda proveer certeza de que las prácticas de gestión
para el desarrollo/ adquisición, pruebas, implementación,
mantenimiento, y eliminación de sistemas e infraestructura,
cumplirán los objetivos de la organización.
El contenido de este capítulo
representará aproximadamente
el 16% del examen CISA
(aproximadamente 32 preguntas)
% del Total de Preguntas del Examen CISA
Capítulo 4
14%
Capítulo 3
16%
Capítulo 2
15%
Capítulo 1
10%
Capítulo 6
14%
Capítulo 5
31%
Relevancia en el Examen
Objetivos de Aprendizaje
Sistema/Infraestructura Nuevo Desarrollado o Adquirido
Antes Durante Después
Implantación
Sistema/Infraestructura Anterior
¿ Existen procesos adecuados ?
Mitigan, Reducen o Eliminan Riesgos
EXISTEN CONTROLES EFICACES
3.2 Realización del Negocio
3.2.1 Administración de Portafolio y
Programas
3.2.2 Caso de Negocio: Desarrollo y
Aprobación
3.3.3 Realización de Beneficios
3.2.1 Administración de
Portafolio/Programas
• Un programa es un grupo de proyectos y tareas a realizar en un tiempo
específico, que están estrechamente vinculados a través de: objetivos
comunes, un presupuesto común, cronogramas y estrategias relacionadas
entre sí.
• Los programas tienen una vigencia determinada (fecha de inicio y de
terminación) y límites organizacionales.
Programa
Proyecto 1
Proyecto 2
Proyecto N
VENTAJAS
Optimización de resultados
Priorización
Coordinación de Recursos
Transferencia de
Conocimientos
3.2.2 Caso de Negocio
Desarrollo y Aprobación
Caso de Negocio: Apertura de Sucursal
Estudio de Factibilidad:
Desarrollado por, Durante …
Justificación:
Solucionará el problema …
Mejorará la situación ….
Facilitará ……….
Razones para
emprender el
proyecto
APROBADO
3.2.3 Técnicas de realización
de beneficios
La realización de beneficios requiere:
• Describir el beneficio
• Asignar una medida y un objetivo
• Establecer un plan de seguimiento y evaluación
• Documentar las dependencias y/o supuestos
• Establecer responsabilidades clave
• Validar los beneficios esperados por el negocio
• Planear el beneficio que se va a realizar
3.3 Estructura de la Gestión de
Proyectos
3.3.1 Aspectos Generales
3.3.2 Contexto y Ambiente
3.3.3 Tipos de Estructura Organizacional
3.3.4 Objetivos del Proyecto
3.3.5 Roles y Responsabilidades de Grupos y
Personas
3.3.1 Aspectos Generales
Proyecto 1
¿Quién lo inicia?
¿Cuánto tiempo durará?
¿Cómo se medirán los objetivos?
¿Cómo se tratarán desfases?
¿Quiénes estarán a cargo?
¿Cómo se documentará?
3.3.2 Contexto y Ambiente del
Proyecto
Estrategia del Negocio
Proyecto 1 Proyecto 2 Proyecto 3
Proyecto 4 Proyecto 5
Caso de Negocio (Business Case) Caso de Negocio (Business Case)
3.3.3 Tipos de Estructura
Organizacional de Proyectos
Por Influencia Gerente de ProyectoGerencias
Miembros de Proyecto
Pura
Gerente de Proyecto
Gerencias Miembros de Proyecto
Matriz
Gerente de Proyecto
Jefe Departamento Jefe Departamento
3.3.4 Objetivos del Proyecto
Caso del Negocio
Beneficios Esperados
OBJETIVOS GENERALES Ó
CLAVE
Elemento 1
Elemento 2
Elemento 3
OBJETIVOS ESPECÍFICOS
SMART
3.3.5 Roles y
responsabilidades de
grupos e individuos
• Alta gerencia
• Administración de usuarios
• Comité de Dirección de Proyecto
• Patrocinador del proyecto
• Gerente de Desarrollo de Sistemas
• Gerente de Proyecto
• Equipo de Desarrollo de Sistemas
• Equipo de usuarios del proyecto
• Oficial de seguridad
• Aseguramiento de la calidad
3.4 Prácticas de Gestión de
Proyectos
3.4.1 Planificación de Proyectos
3.4.2 Administración General de Proyectos
3.4.1 Planificación de
Proyectos
TAREA 1
TAREA 2
TAREA 3
RECURSO A
RECURSO B
PRODUCTO X PRODUCTOYPRODUCTO X PRODUCTO Y
3.4.1 Planificación de
Proyectos (Continuación)
Estimación del tamaño del software:
Líneas de código fuente
El método más sencillo y tradicional para medir el tamaño del software,
consiste en contar el número de líneas de código fuente, medidas en SLOC,
es denominado como kilo líneas de código (KLOC).
Análisis de puntos de función
Ampliamente usada para estimar la complejidad de desarrollar grandes
aplicaciones de negocios.
El resultado del análisis de punto de función (FPA en inglés), es la medida del
tamaño de un sistema de información, basada en el número y la
complejidad de las entradas, salidas, archivos, interfaces y consultas
(queries) con los que un usuario interactúa.
3.4.1 Planificación de
Proyectos (Continuación)
Cronograma y Tiempos
• Diagramas de Gantt
• Diagramas PERT
• Caja de Tiempo
3.4.2 Administración General
de Proyectos
• Gestión del alcance
• Gestión del uso de recursos
• Gestión del riesgo:
– Evaluar
– Mitigar
– Descubrir
3.4.2 Administración General
de ProyectosObjetivos Cumplidos
Caso de Negocio Implantado
Cierre de Proyecto
Entrega Formal y resolución
de temas contractuales
3.5 Auditoría de desarrollo, adquisición y
mantenimiento de sistemas
3.5.1 Estudio de factibilidad/viabilidad
3.5.2 Definición de requerimientos
3.5.3 Proceso de adquisición de software
3.5.4 Diseño y desarrollo detallados
3.5.5 Pruebas
3.5.6 Implementación
3.5.7 Revisión posterior a la implementación
3.5.8 Procedimientos de control de cambios
3.5 Auditoría del Desarrollo,
Adquisición y Mantenimiento de
Sistemas
• Las tareas del Auditor de SI en el desarrollo,
adquisición y mantenimiento de sistemas incluyen
generalmente lo siguiente:– Determinar los componentes, objetivos y requerimientos principales
de los usuarios hacia el sistema
– Determinar y clasificar por prioridad los riesgos principales y las
exposiciones
– Identificar los controles para mitigar los riesgos y las exposiciones del
sistema
– Monitorear el proceso de desarrollo de sistemas
– Participar en las revisiones posteriores a la implementación.
– Probar los procedimientos de mantenimiento de sistemas
– Evaluar el proceso de mantenimiento de sistemas
3.5.1 Estudio de
Factibilidad/Viabilidad
• El Auditor de Sistemas debe llevar a cabo las
siguientes funciones:
– Revisar la documentación producida en esta fase para
verificar si es razonable.
– Determinar si todas las justificaciones de costos /beneficios
son verificables.
– Identificar y determinar la criticidad de la necesidad que se
desea satisfacer.
– Determinar si se puede alcanzar una solución con los
sistemas ya existentes.
– Determinar si la solución escogida es razonable.
3.5.2 Definición de los
Requerimientos
• El auditor de SI debe realizar las siguientes funciones:
– Obtener el documento de definición detallada
– Identificar los miembros claves en el equipo del proyecto
– 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 respondan a las necesidades de los usuarios
– Revisar el diseño conceptual para asegurar que se han
definido 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
– Determinar si la aplicación es candidata para el uso de
rutina(s) integradas de auditoría
3.5.3 Proceso de Adquisición del
Software
• El auditor de SI debe realizar las siguientes funciones:
– Analizar la documentación a partir del estudio de factibilidad.
– Revisar el RFP (Request For Proposal).
– Determinar si el proveedor seleccionado está respaldado por
documentación de RFP.
– Asistir a las presentaciones de la agenda y los pilotos
realizados en presentaciones
– Revisar el contrato del proveedor antes de su firma.
– Asegurarse de que el contrato sea revisado por el asesor legal
antes de que sea firmado.
3.5.4 Diseño y Desarrollo
Detallado
• El auditor de SI debe realizar las siguientes funciones:– Revisar los diagramas de flujo del sistema para verificar si se ajusta
al diseño general.
– Revisar los controles para el ingreso de los datos, del procesamiento
y de los resultados, diseñados en el sistema para verificar si son los
apropiados.
– Entrevistar a los usuarios claves del sistema
– Evaluar si las pistas de auditoría son adecuadas
– Verificar la integridad de los cálculos y procesos claves
– Verificar que el sistema pueda identificar y procesar correctamente
los datos erróneos.
– Revisar los resultados de aseguramiento de calidad de los programas
desarrollados durante esta etapa.
– Verificar que se hayan efectuado todas las correcciones
recomendadas a los errores de programación.
3.5.4 Desarrollo y Pruebas
• Clasificaciones de pruebas
– Prueba de Unidad
– Prueba de Interfaz o de integración
– Prueba del Sistema
– Prueba de Aceptación Final
• Otros tipos de prueba– Prueba Alfa y Beta
– Prueba Piloto
– Prueba de la Caja Blanca
– Prueba de la Caja Negra
– Pruebas de Función /Validación }
– Pruebas de Regresión
– Prueba en Paralelo
– Pruebas de Sociabilidad
3.5.5 Pruebas
• El auditor de SI debe realizar las siguientes funciones:– Revisar el plan de pruebas para verificar si está completo.
– 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.
– 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 los planes de prueba de unidad y de sistema para determinar
si se planifican y ejecutan pruebas de controles internos.
– Revisar los resultados de las pruebas en paralelo para verificar si son
correctos.
3.5.6 Etapa de
Implementación
• Planeación de la Implementación:
• Entrenamiento a los usuarios finales
• Conversión de datos
– Refinado del escenario de migración
– Escenario de retorno / vuelta atrás (fallback/rollback)
• Técnicas de Cambio (Técnicas de salida a vivo y cortar y mover)
– Cambio en paralelo
– Cambio por fases
– Cambio abrupto
• Certificación/Acreditación
3.5.6 Etapa de Implementación
• El Auditor de SI debe verificar que se hayan obtenido
las firmas de aprobación apropiadas antes de la
implementación, y realizar lo siguiente:
– 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 que
está completa y para asegurarse de que la totalidad de las
actualizaciones recientes, a partir de la fase 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.
3.5.7 Revisión Post
Implementación
• El Auditor de SI debe realizar las siguientes
actividades:
– Determinar si se lograron los objetivos y requerimientos del
sistema.
– Determinar si se está midiendo y analizando el costo-beneficio
identificado en el estudio de factibilidad, y si los resultados son
reportados a la Gerencia con exactitud.
– Revisar las solicitudes de cambio a programas para evaluar el
tipo de cambios que requiere el sistema.
– Revisar los controles integrados en el sistema
– Revisar los registros de error de operación (logs)
– Revisar los controles de balance de entrada y salida y demás
informes
3.5.8 Procedimientos de Cambios
al Sistema y Proceso de
Migración de Programas
Metodología clara, precisa y altamente
difundida, que incluya:• Autorización: Usuario Final y de Sistemas
• Priorización
• Aceptación
• Marcha Atrás
• Monitoreo
• Organización documental
• Emergencia
3.5.8 Procedimientos de Cambios al Sistema y
Proceso de Migración de Programas
(Continuación)
• Para una muestra de cambios en el registro o log de
control de cambios se debe:– Determinar que los cambios a los requerimientos quedaron registrados
en documentos apropiados de cambio–desarrollo
– Determinar si los cambios fueron hechos como se documentaron
– Determinar si la documentación actual refleja el entorno cambiado
– Evaluar lo adecuado de los procedimientos existentes para probar los
cambios al sistema
– Revisar las evidencias 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
3.6 Sistemas de aplicaciones
de negocio
3.6.1 Comercio Electrónico
3.6.2 Intercambio electrónico de datos
3.6.3 Sistemas de Puntos de Venta
3.6.4 Banca y Finanzas Electrónicas y EFT
3.6.5 Sistemas Empresariales: ERP, MRP, SCM, CRM, Compras, Contabilidad
3.6.6 Cajeros automáticos
3.6.7 Sistemas de Inteligencia de Negocios BI
3.6.1 Comercio Electrónico
• Un Auditor de SI debe identificar y probar controles que
cubran los riesgos de:
– Confidencialidad
– Integridad
– Disponibilidad
– Autenticación y no repudio
– Traslado del Poder a los Clientes
3.6.2 Electronic Data Interchange EDI
• El auditor de SI debe evaluar a EDI para asegurar que
todas las transacciones entrantes de EDI sean
recibidas correctamente, traducidas, pasadas a una
aplicación y procesadas sólo una vez.
• Para alcanzar esta meta los auditores de SI deben
revisar lo siguiente:
– Los procesos de encripción de Internet
– Verificaciones de edición
– Verificación adicional computarizada
– Usar totales de control
– La validación del emisor versus los detalles del socio comercial
3.6.3 Sistemas de Punto de Venta
Los Sistema de Puntos de Venta o POS permiten la
captura de datos en el momento y en el lugar en que
ocurren las transacciones de ventas. Los instrumentos
de pago más comunes para operar con POS con las
tarjetas de crédito y las de débito.
Lo más importante para el Auditor de SI es determinar si
alguna información del tarjetahabiente está almacenada
en el sistema POS local por ejemplo números de tarjetas
de crédito, números de identificación principal PIN. Toda
información almacenada deberá estar encriptada.
3.6.4 Banca y Finanzas
Electrónicas y EFT
• Los bancos deben tener un proceso de administración
de riesgo que les permita identificar, medir, monitorear
y controlar su exposición al riesgo tecnológico.
• La administración del riesgo asociado a las nuevas
tecnologías tiene tres elementos esenciales:
– La administración del riesgo es responsabilidad de la
junta directiva y de la alta gerencia
– Implementar la tecnología es responsabilidad de la alta
gerencia de tecnología de información.
– Medir y monitorear el riesgo es responsabilidad de la
gerencia operativa.
3.6.4 Banca y Finanzas
Electrónicas y EFT
(Continuación)
• Los controles efectivos de administración de
riesgos para la banca electrónica incluyen
controles divididos en tres categorías:
– Supervisión por parte de la junta y de la gerencia
– Controles de Seguridad
– Administración del riesgo legal y del riesgo de
reputación
3.6.5 Sistemas Empresariales:
ERP, MRP, SCM, CRM
• ERP: Enterprise Resource Planning
• MRP: Manufacture Resource Planning
• SCM: Supply Chain Management
• CRM: Client Relationship Management
3.6.6 Cajeros Automáticos
(ATM)
• Las directrices de control interno que se recomiendan
para los ATM incluyen:
– Políticas y procedimientos escritos que cubran personal,
controles de seguridad, operaciones, soluciones a problemas,
cuadre y balance, etc
– Procedimientos para la emisión y protección de los PIN
durante el almacenamiento
– Procedimientos para la seguridad de los PIN durante la
entrega
– Los controles sobre adquisición de tarjeta plástica
– Los controles y pistas de auditoría de las transacciones que se
hayan efectuado en el ATM
3.6.7 Sistemas de Inteligencia de Negocio
• La inteligencia de negocio (BI: Business Intelligence)
es un amplio campo de TI que abarca la colección y
divulgación de información para asistir en la toma de
decisiones y evaluar el desempeño de la organización.
• Algunas áreas típicas en las que se aplica BI incluyen:
– Costo, eficiencia y calidad del proceso
– Satisfacción del cliente con las ofertas de productos y de
servicios
– Rentabilidad del cliente para el negocio
– Logros de los indicadores clave de desempeño KPIs por parte
de las unidades de negocio y del negocio en sí
– Administración del riesgo
3.7 Desarrollo/ Adquisición de
Infraestructura
3.7.1 Fases del proyecto de análisis
3.7.2 Planificación de implementación
3.7.3 Adquisición de Hardware
3.7 Desarrollo de
Infraestructura / Prácticas de Adquisición
• El análisis de la arquitectura física, la definición de una
nueva y el plan de acción necesario para moverse de
una a otra, es una tarea crítica para un departamento
de TI.
• Metas:
– Analizar exitosamente la arquitectura existente
– Diseñar una nueva arquitectura
– Escribir los requerimientos funcionales de esta nueva
arquitectura
3.7.2 Planificación de la
Implementación de la Infraestructura
Etapas de Planificación de la Implementación de la Infraestructura del Proyecto
Análisis de Requerimientos
1. Etapa de
Adquisición
2. Tiempo
de entrega
3. Plan de
Instalación
4. Plan de
Prueba de la
Instalación
3.7.2 Planificación de la
Implementación de la Infraestructura
(Continuación)
Análisis de Requerimientos
3.7.3 Adquisición de Hardware
• Para adquirir un sistema, la Invitación a Ofertar (ITT –
invitation to tender) debe incluir lo siguiente:
– Descripción de la organización
– Requerimientos de procesamiento de la información
– Requerimientos de Hardware
– Aplicaciones de software
– Requerimientos de soporte
– Requerimientos de escalabilidad
– Limitaciones
– Requerimientos de conversión
3.8 Controles de Aplicación
3.8.1 Generalidades
3.8.2 Controles de Entrada/Origen
3.8.3 Controles de Procesamientos
3.8.4 Controles de Salida
3.8.1 Controles de Aplicación
• Los controles de aplicación son controles sobre las
funciones de entrada (input), procesamiento y salida
(output) de datos. Incluyen métodos para asegurar:
– Que sólo datos completos, correctos y válidos son
ingresados y actualizados en un sistema aplicativo
– Que el procesamiento realice la tarea correcta
– Que los resultados del procesamiento satisfagan las
expectativas
– Que se mantengan apropiadamente los datos
3.8.1 Controles de Aplicación
(Continuación)• Las tareas del auditor de SI incluyen:
– Identificar los componentes significativos o importantes en
la aplicación y el flujo de las transacciones a través del
sistema
– Identificar las fortalezas de control de la aplicación
– Probar los controles para asegurar su funcionalidad y su
eficacia
– Evaluar el ambiente de control
– Considerar los aspectos operativos de la aplicación para
asegurar su eficiencia y su eficacia
3.8.2 Controles de Entrada/Origen
Autorización de entrada de datos
• La autorización de entrada verifica que todas las
transacciones hayan sido autorizadas y aprobadas por
la gerencia.
• Los tipos de autorización incluyen:
– Firmas en formularios para procesamientos por lote o
documentos fuente
– Controles de Acceso en Línea
– Contraseñas Únicas
– Identificación de Terminal o de estación de trabajo
– Documentos Fuente
3.8.2 Controles de Entrada/Origen
(Continuación)
Controles de procesamiento por lote (batch) y de
Balance
• Los controles de procesamiento por lote agrupan las
transacciones de entrada para proveer totales de control.
• Los tipos de controles por lote incluyen:
– Importe Monetario Total
– Total de elementos
– Total de documentos
– Totales calculados (Hash Totals)
• Los tipos de balance de lotes incluyen:
– Registros del Lote
– Cuentas de Control
3.8.2 Controles de Entrada/Origen
(Continuación)
Reporte y Manejo de Errores
• El procesamiento de los datos introducidos al sistema
requiere que existan controles que permitan verificar que los
datos son aceptados en el sistema correctamente, y que los
errores que se presentan en su ingreso son reconocidos y
corregidos.
• El tratamiento que se puede dar a los errores que se
presentan en el ingreso de datos puede ser:
– Rechazar Sólo las Transacciones que Tengan Errores
– Rechazar Todo el Lote de las Transacciones
– Mantener el Lote en Espera
– Aceptar el Lote y marcar las Transacciones que Contienen
Errores
3.8.2 Controles de Entrada/Origen
(Continuación)
Reporte y Manejo de Errores
• Las técnicas de control en el ingreso de datos incluyen:
– Registro o log de Transacciones
– Reconciliación de los Datos
– Documentación
– Procedimientos para la Corrección de Errores
– Anticipación
– Log de Transmisión
– Anular los Documentos Fuente
3.8.3 Controles de Procesamiento
Procedimientos de Validación y Edición de Datos
• Se deben establecer procedimientos para asegurar que
los datos que se ingresen al sistema sean validados y
editados tan cerca, como sea posible, del momento y
punto de origen de los mismos.
• La validación de datos permite identificar errores de
datos, datos incompletos o faltantes e inconsistencias
entre datos relacionados.
3.8.3 Controles de Procesamiento
(Continuación)
Controles de Procesamiento
• Los controles de procesamiento aseguran la
completitud y la exactitud de los datos acumulados.
• Las siguientes son técnicas de control de
procesamiento que pueden ser usadas:– Recálculos Manuales
– Edición
– Totales de Proceso a Proceso
– Controles Programados
– Verificación de Razonabilidad de los Valores Calculados
– Verificaciones de Límite sobre los Valores Calculados
– Reconciliación de los Totales de los Archivos -
– Reportes de Excepción
3.8.3 Controles de Procesamiento
(Continuación)
Procedimientos de Control de Archivos de Datos
• Los controles de archivo deben asegurar que
únicamente se realicen procesamientos autorizados
sobre los datos almacenados.
• Los archivos de datos, o incluso las tablas de base de
datos, caen generalmente en cuatro categorías:
– Parámetros de control de sistema
– Datos vigentes
– Datos Principales o Maestros /datos de balance
3.8.4 Controles de Salida
• Los Controles de Salida proveen garantía de que los
datos entregados a los usuarios serán presentados,
formateados y entregados en una forma consistente y
segura.
• Los controles de salida incluyen :– Registro y Almacenamiento de Formularios Negociables, Sensitivos y
Críticos en un Lugar Seguro
– Generación automatizada de Instrumentos Negociables, Formularios
y Firmas
– Distribución de Reportes
– Balance y Reconciliación
– Manejo de Errores en las Salidas
– Retención de Reportes
– Verificación de Recibo de los Reportes
3.9 Auditoría de los controles de
aplicación
3.9.1 Generalidades
3.9.2 Procedimientos realizados por usuarios
3.9.3 Pruebas de Integridad de Datos
3.9.4 Auditoría continua en línea
3.9.5 Pruebas de los sistemas de aplicaciones
3.9.1 Auditoria a los Controles de
Aplicación
• Las tareas del auditor de SI incluyen las
siguientes:
– Identificar los componentes significativos de la aplicación
y el flujo de transacciones a través del sistema
– Identificar las fortalezas de control de la aplicación y
evaluar el impacto de las debilidades de control para
desarrollar una estrategia de prueba, mediante el
análisis de la información acumulada
– Revisar la documentación del sistema de aplicación a fin
de obtener un entendimiento de la funcionalidad de la
aplicación
3.9.2 Procedimientos
realizados por los usuarios
• Separación de funciones
• Autorización de entrada
• Balance
• Control y corrección de errores
• Distribución de reportes
• Revisión y prueba de autorizaciones y capacidades de
acceso
3.9.3 Prueba de Integridad de los
Datos
• La prueba de integridad de los datos es un conjunto de pruebas
sustantivas que examinan la exactitud, completitud, consistencia y
autorización de los datos que son actualmente mantenidos en un sistema.
• Las pruebas de integridad de los datos indicarán las fallas en los
controles de entrada o de procesamiento.
• Cuatro requisitos de integridad de datos en línea conocidos
colectivamente como el principio ACID:
– Atomicidad
– Consistencia
– Aislamiento
– Durabilidad
3.9.4 Auditoría Continua en
Línea
• Provee un método para que el auditor de SI
recolecte evidencia sobre la confiabilidad del
sistema, mientras tiene lugar el procesamiento
normal.
• Las técnicas de auditoría continua son herramientas
de auditoría de SI importantes, en particular cuando
se usan en ambientes de procesamiento compartido,
que procesan un gran número de transacciones pero
dejan muy poco rastro en papel.
3.9.4 Técnicas de Auditoría
en Línea
• Hay cinco tipos de técnicas automatizadas de evaluación
aplicables a la auditoría continua en línea:
– Archivo de Revisión de Auditoría de Control de Sistemas y
Módulos de Auditoría Integrados (SCARF/ EAM : Systems
Control Audit Review File/ Embedded Audit Modules)
– Instantáneas (Snapshots)
– Ganchos de Auditoría (audit hooks)
– Facilidad de test integrada (ITF: Integrated Test Facility)
– Simulación continua e intermitente (CIS: Continuous and
intermittent simulation)
3.9.4 Pruebas de los sistemas de
aplicación
Analizar los Programas de Aplicación
Técnica Descripción Ventajas Desventajas
Instantánea
(Snapshot)
Registra el flujo de transacciones
seleccionadas a través de la secuencia
lógica dentro de los programas
Verifica la lógica del
programa
Requiere amplio
conocimiento del
ambiente de sistemas de
información
Mapeo Identifica la lógica específica del
programa que no ha sido probada y
analiza los programas durante su
ejecución para indicar si las
instrucciones han sido ejecutadas.
Aumenta la eficiencia
identificando código no
usado
Identifica potenciales
exposiciones
Costo del software
Rastreo y
Marcado
El rastreo muestra la pista de las
instrucciones ejecutadas durante una
aplicación.
El marcado implica colocar un
indicador en las transacciones
seleccionadas en los datos de entrada y
usar el rastreo para darles seguimiento.
Provee una imagen
exacta de la secuencia de
eventos.
Efectivo tanto con
transacciones en vivo
como simuladas.
Extensas cantidades de
tiempo de computadora.
Requiere conocimiento
profundo del programa de
aplicación.
Requiere programación
adicional para ejecutar
rutinas de rastreo.
Pruebas de Aplicación
3.9.4 Pruebas de los sistemas
de aplicación (Continuación)
Analizar los Programas de Aplicación
Técnica Descripción Ventajas Desventajas
Prueba de datos
/escritorio
Transacciones simuladas a través de
programas reales
Puede usar archivos
maestros reales o ficticios
La revisión del código
fuente es innecesaria
Puede usarse por sorpresa
Provee una revisión y
verificación objetiva de los
controles programados
Su uso inicial puede estar
limitado a funciones
específicas de programa,
minimizando el alcance y la
complejidad
Requiere un conocimiento
mínimo del ambiente del
sistema de información.
Difícil de asegurar que el
programa apropiado sea
verificado
Riesgo de no incluir todas
las transacciones
Requiere buen conocimiento
de los sistemas de aplicación
No prueba el archivo
maestro y los registros del
archivo maestro
Evaluación de
Sistema basada
en casos
Usa conjuntos de datos de prueba
desarrollados como parte de una prueba
integral de programas.
Verifica la operación correcta de los
sistemas antes de su aceptación, así como
también su revalidación periódica.
Prueba integral y prueba de
cumplimiento
Gran esfuerzo para
mantener los conjuntos de
datos.
Se requiere estrecha
cooperación entre todas las
partes.
Pruebas de Aplicación
3.9.4 Pruebas de los sistemas
de aplicación (Continuación)
Es necesario desarrollar los
programas
Elimina la necesidad de
preparar datos de prueba
Procesa los datos de producción utilizando
programas de computación que simulan la
lógica del programa de la aplicación
Simulación
paralela
Es necesario un
planeamiento cuidadoso
Los datos de prueba deben
ser aislados de los datos de
producción
La prueba periódica no
requiere un proceso separado
de prueba
Crea un archivo ficticio en la base de datos
con transacciones de prueba procesadas
simultáneamente con datos en vivo
Facilidad de
Prueba Integrada
Costos adicionales de
procesamiento
Verifica el nuevo sistema
antes de discontinuar el viejo
Procesa datos reales de producción a través
de los programas existentes y compara
resultados; es usada para verificar el
ambiente de producción cambiado antes de
reemplazar los procedimientos existentes
Operación
Paralela
DesventajasVentajasDescripciónTécnica
Analizar los Programas de Aplicación
Pruebas de Aplicación
Costo de desarrollo y
mantenimiento
Independiente del sistema de
producción
Controlado por el auditor.
No requiere ninguna
modificación a los sistemas
del ambiente de producción.
Usan software de auditoría para filtrar y
seleccionar las transacciones ingresadas al
ciclo regular de producción
Programas de
selección de
transacciones
Analizar los Programas de Aplicación
Técnica Descripción Ventajas Desventajas
Recolección de
datos de
auditoría
integrados
El software integrado en las aplicaciones
filtra y selecciona tanto las transacciones
entrantes como las transacciones generadas
durante la producción. Por lo general se
desarrolla como parte del desarrollo del
sistema. Los tipos incluyen:
Archivo de Revisión de Auditoría de Control
de Sistema (SCARF) – Pruebas de
razonabilidad determinadas por el auditor,
incorporadas al procesamiento normal.
Provee información para revisiones
posteriores.
Archivo Muestra de Revisión de Auditoría
(SARF) – escoge transacciones al azar para
proveer un archivo representativo para el
análisis.
Provee muestras y estadísticas
del ambiente de producción
Alto costo de desarrollo y
mantenimiento
Aspectos de
independencia del auditor
Registros
extendidos
Reúnen todos los datos que hayan sido
afectados por un programa en particular
Los registros son puestos en
un archivo conveniente
Aumentan los costos de
almacenamiento de datos y
los costos de desarrollo de
sistemas.
3.9.4 Pruebas de los sistemas
de aplicación(Continuación)
Pruebas de Aplicación