Upload
fernando-galindo
View
126
Download
6
Embed Size (px)
Citation preview
ESCUELA POLITÉCNICA NACIONAL
FACULTAD DE INGENIERÍA DE SISTEMAS
APLICACIÓN DE COBIT 4.1 EN LA AUDITORÍA DE UNA APLICACIÓN INFORMÁTICA TIPO WEB DE UNA INSTITUCIÓN FINANCIERA.
PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENI ERO EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN
CORAISACA AREVALO JENNY LOURDES [email protected]
LLUMIQUINGA PILLAJO CÉSAR FERNANDO
DIRECTOR: ING. ANDRÉS LARCO [email protected]
QUITO, NOVIEMBRE 2012
ii
DECLARACIÓN
Nosotros, Jenny Lourdes Coraisaca Arévalo y César Fernando Llumiquinga Pillajo,
declaramos bajo juramento que el trabajo aquí descrito es de nuestra autoría, que no
ha sido previamente presentado para ningún grado o calificación profesional y que
hemos consultado las referencias bibliográficas que se incluyen en este documento.
A través de la presente declaración cedemos nuestros derechos de propiedad
intelectual correspondientes a este trabajo a la Escuela Politécnica Nacional, según
lo establecido en la Ley de Propiedad Intelectual, por su Reglamento y por la
normatividad constitucional vigente.
Jenny Lourdes Coraisaca Arévalo
César Fernando Llumiquinga Pillajo
iii
CERTIFICACIÓN Certifico que el presente trabajo fue desarrollado por Jenny Lourdes Coraisaca
Arévalo y César Fernando Llumiquinga Pillajo, bajo mi supervisión.
Ing. Andrés Larco
DIRECTOR DEL PROYECTO
iv
AGRADECIMIENTO
Agradezco a mi madre por el sacrificio y amor que ha demostrado para ofrecerme su
legado más grande que es la educación.
A mis tíos José y Bachita por hacer el papel de padres sustitutos ante la ausencia
física de mamá.
A mi abuelita que con sus consejos y oraciones siempre me ha llenado de buenas
energías para salir adelante.
A mi compañero Fernando por su dedicación en la culminación de este proyecto y
por ser ese amigo incondicional durante toda nuestra carrera universitaria.
A Lenin, por su paciencia y comprensión para la realización de este trabajo.
A Andrés Larco, por su empuje, dirección y “jaladas de oreja” cuando fue necesario
hacerlo.
Jenny.
v
Quiero empezar agradeciendo a las personas más importantes de mi vida…Mi mami
Carmen, mi papá Arturo. Gracias madre por estar siempre a mi lado, gracias por
todo tu apoyo darme ánimo y palabras de aliento cuando las cosas no me salían
bien. Gracias padre por brindarme tu apoyo y darme la mejor herencia que un padre
puede dar a su hijo “el estudio”.
Gracias a mis hermanos Sandra y Edwin, por ser un apoyo incondicional, por ser mis
amigos y compañeros que siempre estuvieron ahí cuando los necesite.
Mi querida amiga y compañera Jennicita, como no agradecerte de todo corazón, por
todo el aguante, la paciencia de estos años y por soportarme en mis momentos de
estrés y enojo. Gracias por siempre brindarme tu apoyo y ser mi mejor amiga. Sin ti,
hubiera sido complicado llegar a la consecución de esta meta que algún día nos
planteamos.
Gracias a mis compañeros de trabajo especialmente a Jessy y Alejita que creyeron
en mí y que con sus consejos me dieron ánimo para seguir adelante en este
proyecto.
También, quiero agradecer a mis amigos y compañeros de carrera, que me
brindaron su mano amiga cuando lo necesite.
Finalmente un sincero agradecimiento a Andrés Larco, nuestro tutor de tesis y amigo,
por la paciencia y guía en la consecución de este trabajo.
Fernando.
vi
DEDICATORIA
A mi madre, abuelita y hermana, quienes siempre han estado apoyándome en todo
momento y ofreciéndome un ambiente familiar hermoso, que me ha enseñado a
valorar y entender lo realmente importante en mi vida.
Jenny
Dedico este trabajo a esas personas maravillosas que siempre han estado a mi lado
en los momentos buenos y no tan buenos en mi vida, mis padres, mis hermanos y en
especial a mi sobrina Danita, porque con su sola presencia llena de alegría y amor
cada uno de mis días.
Fernando
vii
CONTENIDO
PRESENTACIÓN ........................................................................................................ 1
RESUMEN .................................................................................................................. 2
CAPITULO 1 - MARCO TEÓRICO .............................................................................. 3
1.1 AUDITORÍA DE APLICACIONES INFORMÁTICAS TIPO WEB UTILIZANDO DIRECTRICES DE AUDITORÍA DE COBIT 4.1 ...................................................... 3
1.1.1 AUDITORÍA DE SISTEMAS DE INFORMACIÓN .................................... 3
1.1.2 APLICACIONES WEB ............................................................................. 4
1.1.3 MARCO DE TRABAJO DE COBIT 4.1 .................................................... 5
1.1.4 INTRODUCCIÓN A LAS DIRECTRICES DE COBIT PARA AUDITORÍA DE APLICACIONES ........................................................................................... 11
1.2 DEFINICIÓN DE CONTROLES PARA LA AUDITORIA DE APLICACIONES INFORMÁTICAS .................................................................................................... 13
1.2.1 OBJETIVOS DEL CONTROL INTERNO .................................................. 14
1.2.2 CONTROLES GENERALES DE TI ............................................................ 15
1.2.3 CONTROLES DE APLICACIÓN ................................................................ 15
1.2.4 ANÁLISIS DE LOS PROCESOS COBIT 4.1 Y OBJETIVOS DE CONTROL PARA AUDITORÍA DE APLICACIONES INFORMÁTICAS. ............................... 19
1.3 MARCOS DE TRABAJO PARA EL DESARROLLO DE LA AUDITORÍA ......... 24
1.3.1 COBIT 4.1 .................................................................................................. 24
1.3.2 ITIL V3 ....................................................................................................... 24
1.3.3 ISO 27002 .................................................................................................. 27
1.3.4 INTERRELACIÓN DE LOS ESTÁNDARES COBIT 4.1, ITIL V3, E ISO/IEC 27002 PARA AUDITORÍA DE APLICACIONES INFORMÁTICAS. .................... 29
CAPITULO 2 PLAN DE AUDITORIA DE LA APLICACIÓN WEB ............................ 30
2.1. ESTUDIO DE LA APLICACIÓN WEB “CAJERO DE VENTANILLAS” A SER AUDITADA ............................................................................................................. 30
2.1.1 DESCRIPCIÓN .......................................................................................... 30
2.1.2 ARQUITECTURA FÍSICA .......................................................................... 30
viii
2.1.2.1 Servidores ............................................................................................... 31
2.1.3 ARQUITECTURA LOGICA ........................................................................ 32
2.1.4 MÓDULOS Y TRANSACCIONES DE LA APLICACIÓN CV ...................... 33
2.2. ELABORACIÓN DEL PROGRAMA DE AUDITORÍA ...................................... 35
2.2.1 ELABORACIÓN DEL PROGRAMA DE AUDITORÍA PARA LA EVALUACIÓN DE LA APLICACIÓN WEB .......................................................... 36
2.3. DEFINICIÓN DEL ALCANCE DEL PROGRAMA DE AUDITORÍA ................. 46
2.3.1. FACTOR 1: CRITERIOS QUE ORIENTAN A LA SEGURIDAD................ 46
2.3.2 FACTOR 2. CRITERIOS QUE SE FOCALIZAN EN LA CALIDAD ............ 47
2.3.3 FACTOR 3. CUMPLIMIENTO .................................................................... 47
2.3.4 FACTOR 4. RECURSOS INVOLUCRADOS EN LOS PROCESOS .......... 47
CAPITULO 3. EJECUCIÓN DEL PLAN DE AUDITORÍA ......................................... 50
3.1. RELEVAMIENTO Y EJECUCIÓN DE LA AUDITORÍA ................................... 50
3.2. ANÁLISIS DE RIESGOS DE LAS VULNERABILIDADES IDENTIFICADAS .. 53
3.2.1 MATERIALIDAD DE LOS HALLAZGOS .................................................... 55
3.2.2 EVALUACIÓN DE RIESGOS ................................................................... 58
3.3. ELABORACIÓN DEL INFORME FINAL ...................................................... 65
CAPITULO 4: CONCLUSIONES Y RECOMENDACIONES...................................... 79
4.1. CONCLUSIONES ........................................................................................... 79
4.2. RECOMENDACIONES ................................................................................... 81
BIBLIOGRAFÍA ......................................................................................................... 83
GLOSARIO ................................................................................................................ 85
ANEXOS ................................................................................................................... 86
ix
LISTA DE TABLAS Tabla 1. 1 Definición de Directrices de Auditoría ....................................................... 11 Tabla 1. 2 Directrices - Auditoría de Aplicaciones ..................................................... 13 Tabla 1. 3 Clasificación Tipos de Control .................................................................. 14 Tabla 1. 4 Controles de Aplicación ............................................................................ 16 Tabla 1. 5 Controles ACn de acuerdo al tipo de control ............................................ 18 Tabla 1. 6 Análisis de los procesos COBIT 4.1 y Objetivos de control ..................... 19 Tabla 2. 1 Descripción Servidores ............................................................................. 31
Tabla 2. 2 Descripción Clientes ................................................................................. 32 Tabla 2. 3 Herramientas de Desarrollo ...................................................................... 32 Tabla 2. 4 Elementos Módulo Transacciones............................................................ 34 Tabla 2. 5 Elementos Módulo Consultas ................................................................... 35
Tabla 2. 6 Elementos Módulo Reportes .................................................................... 35 Tabla 2. 7 Elementos Módulo Control ....................................................................... 35 Tabla 2. 8 Elementos Módulo Herramientas ............................................................. 35 Tabla 2. 9 Importancia del Programa de Auditoría .................................................... 36
Tabla 2. 10 Programa de Auditoría ......................................................................... 37 Tabla 3. 1 Interrelación: Vulnerabilidad, Amenaza, Riesgo ....................................... 55 Tabla 3. 2 Hallazgos de vulnerabilidades Identificados y Riesgos Asociados ........... 56 Tabla 3. 3 Definición de Significancia de Riesgo ....................................................... 59 Tabla 3. 4 Modelo Estándar para análisis de Riesgo. ............................................... 60 Tabla 3. 5 Análisis y Evaluación de Riesgos ............................................................. 61 Tabla 3. 6 Análisis de la Observación 1 - Usuarios : ex - empleados ........................ 68 Tabla 3. 7 Análisis Observación 2 - Uso de usuarios genéricos................................ 69 Tabla 3. 8 Análisis Observación 3 - Usuarios sin depurar Call Center. ..................... 70 Tabla 3. 9Análisis Observación 1- Usuarios sin depurar área operativa. .................. 70 Tabla 3. 10 Análisis Observación 5- Transacciones sin validación previa. ............... 71 Tabla 3. 11 Análisis Observación 6 - Procedimientos para parametrización, no documentado ............................................................................................................. 72 Tabla 3. 12 Análisis Observación 8 – Aplicación sin log de parametrización ............ 73 Tabla 3. 13 Análisis Observación 8 - Falta de revisión de logs. ................................ 74 Tabla 3. 14 Análisis Observación 9 - Problemas frecuentes de la aplicación. .......... 75 Tabla 3. 15 Análisis Observación 10 - Planes de contingencia no probados ............ 76 Tabla 3. 16 Procedencia de las Observaciones del Informe Final ............................. 78
x
LISTA DE FIGURAS Figura 1. 1 Arquitectura Básica Aplicación Web .......................................................... 5
Figura 1. 2 Estructura COBIT 4.1 ................................................................................ 7
Figura 1. 3 Marco de Trabajo COBIT 4.1 .................................................................... 9
Figura 1. 4 Relación entre controles definidos COBIT 4.1 ........................................ 10
Figura 1. 5 Objetivos de Control de Aplicación vs Criterios de Información .............. 18
Figura 2. 1 Arquitectura de la Aplicación .................................................................. 31
Figura 2. 2 Distribución Servidores .......................................................................... 31
Figura 2. 3 Arquitectura Lógica de la Aplicación ...................................................... 32
Figura 2. 4 Módulos Aplicación Cajero de Ventanillas ............................................ 34
1
PRESENTACIÓN
La evolución de los sistemas de información en las instituciones financieras del
Ecuador ha generado la necesidad de garantizar la integridad, disponibilidad,
confidencialidad de la información y su grado de apoyo al proceso de negocio, en
todos los ámbitos que a tecnología de la información se refieren. En consecuencia el
procesamiento de la información y la rapidez con la que se realiza son de vital
importancia en las instituciones financieras, provocando que cada vez necesiten de
más control sobre sus datos y los sistemas que utilizan.
El presente trabajo de Auditoría Informática, se ha realizado a la aplicación web
Cajero de Ventanillas, que es una de las principales aplicaciones con la que cuenta
la institución financiera y que se encuentra relacionada directamente con el cliente,
con el fin de identificar y corregir los hallazgos de vulnerabilidades que pueden
provocar riesgos para la institución y sus clientes.
La propuesta de auditoría permitirá seleccionar los objetivos de control a ser
auditados en la aplicación informática tipo web, como resultado se obtendrá un
informe con el detalle de los hallazgos de vulnerabilidades o inexistencia de
controles, los riesgos que pueden ocasionar y los planes de mitigación
recomendados.
Con los hallazgos de vulnerabilidades, los riesgos asociados a éstas y las
recomendaciones emitidas para mitigar las mismas, la institución financiera podrá
aceptar o no las sugerencias para definir un plan de mejora de la aplicación auditada.
Por razones de seguridad y confidencialidad de la información, no se mencionará el
nombre de la institución financiera, ni de la aplicación informática auditada, tampoco
detalles que permitan identificarlas.
2
RESUMEN
El presente proyecto de titulación está compuesto de cuatro capítulos y anexos, que
tienen como principal objetivo, presentar los resultados de la auditoría realizada a la
aplicación web de una institución financiera, utilizando las directrices de auditoría de
COBIT 4.1.
En el Capítulo I se define los principales conceptos que intervienen en la auditoría
informática de aplicaciones, la descripción general del tipo de aplicación que se
utilizará como caso de estudio, se describen los controles, las directrices de COBIT
4.1 utilizados para la auditoría de aplicaciones y se presenta el cuadro comparativo
con los principales marcos de trabajo que pueden ser utilizados para una auditoría
informática, como: COBIT 4.1, ITIL V3, ISO 27002.
En el Capítulo II se detallan las características de la aplicación que va a ser auditada,
se elaborará el programa de auditoría en base a las directrices seleccionadas para la
auditoría de aplicaciones informáticas y se definirá el alcance del programa tomando
en consideración factores definidos de acuerdo a los criterios de información dados
por COBIT 4.1.
En el Capítulo III se presenta la ejecución de la auditoría de la aplicación informática
tipo web, el análisis de riesgos de los hallazgos de vulnerabilidades y la elaboración
del informe final de auditoría con las recomendaciones emitidas a la institución
financiera, para mitigar los riesgos identificados en aplicación informática.
Finalmente en el Capítulo IV se presentan las conclusiones y recomendaciones del
presente proyecto.
3
CAPITULO 1 - MARCO TEÓRICO
El presente capítulo define los principales conceptos que intervienen en la auditoría
informática de aplicaciones, el caso de estudio a realizarse es de una aplicación web;
se describen los controles, las directrices de COBIT 4.1 utilizados para la auditoría de
aplicaciones, y se presenta el análisis comparativo con los principales marcos de
trabajo que pueden ser utilizados para una auditoría informática.
1.1 AUDITORÍA DE APLICACIONES INFORMÁTICAS TIPO WEB
UTILIZANDO DIRECTRICES DE AUDITORÍA DE COBIT 4.1
1.1.1 AUDITORÍA DE SISTEMAS DE INFORMACIÓN
Según el Manual de Preparación del Examen CISA 2011, se define a la Auditoría de
Sistemas de Información1como: “Proceso mediante el cual se recolecta y evalúa la
evidencia para determinar si los Sistemas de Información (SI) y los recursos
relacionados protegen adecuadamente los activos, mantienen la integridad y
disponibilidad de los datos y del sistema, proveen información relevante y confiable,
logran de forma efectiva las metas organizacionales, usan eficientemente los
recursos y tienen en efecto los controles internos que proveen una certeza razonable
de que los objetivos del negocio, operacionales y de control serán alcanzados y que
los eventos no deseados serán evitados o detectados y corregidos de forma
oportuna”. La auditoría de una aplicación es parte de la Auditoría de Sistemas de
Información y se refiere a la verificación de los controles de la aplicación que pueden
ser manuales ó programados y que sirven para garantizar la integridad y exactitud de
los registros. El auditor de SI debe identificar las fortalezas o debilidades de dichos
controles.
Una auditoría de aplicaciones informáticas se puede realizar cuando:
- El sistema o aplicación se está evaluando para su adquisición. 1En el contexto de la Auditoría de Sistemas, los Sistemas de Información se refieren a un conjunto de elementos hardware, software, recursos humanos y datos, interrelacionados para la administración y procesamiento de la información, esta interpretación puede variar dependiendo del campo en el que se esté aplicando.
4
- Antes de que el sistema de aplicación entre en producción (pre-ejecución) y
- Después de que la aplicación ha entrado en producción.
Los objetivos y el alcance de una auditoría de aplicaciones, pueden variar pero
deben incluir:
- Los objetivos y el alcance de la revisión.
- El auditor que va a ejecutar la revisión.
- Una declaración sobre la independencia de los auditores de los proyectos o
aplicaciones a ser auditadas.
- Inicio de la revisión.
- El tiempo que tomará la revisión.
- Entrega de informes.
- Arreglo para las reuniones de cierre y discusiones de los informes.
1.1.2 APLICACIONES WEB
Son aplicaciones a las que se accede vía web por una red como internet o una
intranet. Las aplicaciones web no se ejecutan en computadores personales, estas
alojan sus componentes en infraestructuras diferentes (hardware y software) de tal
forma que múltiples usuarios puedan acceder a éstas de forma simultánea.
1.1.2.1 Arquitectura
La arquitectura de una aplicación define como se organizan los distintos módulos que
la componen. En una aplicación web, la arquitectura está basada en el modelo
cliente / servidor, se define básicamente los siguientes elementos:
- Cliente: navegador (Front end).
- Servidor: servidor web (Middleware).
- Servidor Datos: Base de Datos (Back end).
- Comunicación: Protocolo HTTP, TCP/IP.
5
Figura 1. 1Arquitectura Básica Aplicación Web
Fuente: http://rua.ua.es/dspace/bitstream/10045/4412/5/03c-AplicacionesWeb.pdf
Cliente :
- Gestiona las peticiones del usuario y la recepción de las páginas que provienen
del servidor.
- Interpreta documentos HTML.
Servidor Web El servidor web habilita el acceso mediante el protocolo http a un sitio web
realizando conexiones con el cliente generando una respuesta del lado del cliente.
Protocolos de Comunicación - IP: Internet Protocol.
- TCP: Transmition Control Protocol.
- HTTP: Hipertext Transfer Protocol.
1.1.3 MARCO DE TRABAJO DE COBIT 4.1
COBIT (Control Objectives for Information and related Technology)Objetivos de
Control para la Información y Tecnologías relacionadas, es un marco de trabajo
creado por la Asociación de Auditoría y Control de Sistemas de Información, ISACA
(Information Systems Audit and Control Association) para las Tecnologías de la
información (TI) y de Gobierno de TI constituyéndose como un marco de referencia y
un conjunto de herramientas de soporte que permiten a la gerencia cerrar la brecha
con respecto a los requerimientos de control, temas técnicos, riesgos de negocio y
comunicar ese nivel de control a los Interesados.
6
COBIT fue publicado por primera vez en 1996, la versión actual, COBIT 4.1 se
publicó en 2007. ISACA finalizó la versión de COBIT 5 para finales del año 2011 y su
publicación fue en el año 2012.
COBIT 4.1 brinda un marco de trabajo para administrar y controlar las actividades de
TI y sustenta cinco requerimientos para un marco de control, estos son:
1. Enfoque en el negocio
COBIT consigue un enfoque fuerte en el negocio al alinear los objetivos de TI con los
objetivos del negocio.
2. Orientación a procesos
Con la propiedad de los procesos definida, asignada y aceptada, la organización está
mejor capacitada para mantener el control durante los períodos de cambios rápidos o
crisis organizacional.
3. Aceptación general
COBIT es un estándar probado y globalmente aceptado para alinear TI al Negocio.
COBIT provee a sus usuarios la siguiente información:
- Dirección ejecutiva.- Para obtener valor de las inversiones y para balancear
las inversiones en riesgo y control en un ambiente de TI con frecuencia
impredecible.
- Gerencia del negocio.- Para obtener certidumbre sobre la administración y
control de los servicios de TI, proporcionados internamente o por terceros.
- Gerencia de TI.- Para proporcionar los servicios de TI que el negocio requiere
para dar soporte a la estrategia del negocio de una forma controlada y
administrada.
- Auditores.- Para respaldar sus opiniones y/o para proporcionar asesoría a la
gerencia sobre controles internos.
7
4. Requerimientos regulatorios
Las organizaciones utilizan COBIT para verificar el cumplimiento de las regulaciones
exigidas por las entidades de control (internas / externas) en torno al desempeño de
TI.
5. Lenguaje común
COBIT se aplica a los SI de toda la empresa. Está basado en la filosofía que TI
necesita ser administrados por un conjunto de procesos naturalmente agrupados
para proveer la información pertinente y confiable que requiere una organización
para lograr sus objetivos.
1.1.3.1. Estructura
COBIT se divide en tres niveles: Dominios, Procesos y Actividades
En el Figura 1.2 se resume la estructura de COBIT 4.1 que define que los recursos
de TI son manejados por procesos de TI para lograr que las metas de TI respondan a
los requerimientos del negocio.
Figura 1. 2 Estructura COBIT 4.1
Fuente: http://www.isaca.org/Knowledge-Center/COBIT/Documents/COBIT4.1spanish.pdf
8
Dominios.- Agrupación natural de procesos, normalmente corresponden a un
dominio o una responsabilidad organizacional. Estos dominios son:
- Planear y Organizar.
- Adquirir e Implementar.
- Entregar y Dar Soporte.
- Monitorear y Evaluar.
Procesos.- COBIT subdivide a TI en 34 procesos de acuerdo a las áreas de
responsabilidad de planear, construir, ejecutar y monitorear, ofreciendo una visión
de punta a punta de las TI. Los conceptos de arquitectura empresarial ayudan a
identificar aquellos recursos esenciales para el éxito de los procesos, estos son:
- Aplicaciones.- Entendido como los sistemas de información, que integran
procedimientos manuales y sistematizados.
- Datos.- Todos los objetos de información. Considera información interna y
externa, estructurada o no, gráficas, sonidos, etc.
- Tecnología.- Incluye hardware y software básico, sistemas operativos,
sistemas de administración de bases de datos, de redes,
telecomunicaciones, multimedia, etc.
- Instalaciones.- Incluye los recursos necesarios para alojar y dar soporte a
los sistemas de información.
- Recurso Humano.- Por la habilidad, conciencia y productividad del
personal para planear, adquirir, prestar servicios, dar soporte y monitorear
los sistemas de Información.
Actividades .- Acciones requeridas para lograr un resultado medible.
El marco de trabajo COBIT 4.1 se muestra en el Figura 1.3, está compuesto por
cuatro dominios que contienen 34 procesos genéricos.
9
Figura 1. 3 Marco de Trabajo COBIT 4.1
Fuente: http://www.isaca.org/Knowledge-enter/COBIT/Documents/COBIT4.1spanish.pdf
1.1.3.2 Objetivos de Control
COBIT define objetivos de control para los 34 procesos, así como para el proceso
general y los controles de aplicación.
Control se define como las políticas, procedimientos, prácticas y estructuras
organizacionales diseñadas para brindar una seguridad razonable que los objetivos
10
de negocio se alcanzarán y los eventos no deseados serán prevenidos o detectados
y corregidos.
Los objetivos de control de TI de COBIT 4.1 están organizados por proceso de TI, en
total se describen 302 objetivos de control detallados. Además, de los objetivos de
control detallados, cada proceso COBIT tiene requerimientos de control genéricos
que se identifican con PCn() que significa Process Control Number (Número de
Control de Proceso). También, ofrece un conjunto de objetivos de control de
aplicaciones, identificados por ACn() que significa Application Control Number
(Número de Control de Aplicación).
En el Figura 1.4 se muestra la relación entre los controles definidos por COBIT 4.1.
Figura 1. 4 Relación entre controles definidos COBIT 4.1
Fuente: http://www.isaca.org/Knowledge-enter/COBIT/Documents/COBIT4.1spanish.pdf
11
1.1.4 INTRODUCCIÓN A LAS DIRECTRICES DE COBIT PARA AUDITO RÍA DE
APLICACIONES
Las Directrices son guías orientadas a proveer a la Gerencia de TI, la dirección para
mantener bajo control la información de la empresa y sus procesos relacionados,
para monitorear el logro de las metas organizacionales y para monitorear el
desempeño de cada proceso de TI.
Las directrices de COBIT se constituyen como los Objetivos de Control de Alto Nivel
(Procesos definidos de COBIT 4.1, correspondiente a cada dominio). Un ejemplo de
directriz de auditoría: PO9 Evaluar y Administrar Riesgos de TI, asociado a los objetivos
de control detallados, utilizándolos para proporcionar a la gerencia la certeza o
recomendaciones de mejoramiento.
Tabla 1. 1 Definición de Directrices de Auditoría
Fuente: Elaborado por los autores
1.1.4.1 Objetivos de las Directrices
- Contar con una estructura para auditar y evaluar controles.
- Proveer información sobre cómo cumplir la Auditoría de SI.
- Ayudar a los directivos a identificar en qué casos los controles son suficientes,
o para asesorarlos respecto a los procesos que requieren ser mejorados.
- Constituir una guía para el auditor de SI, el mismo que debe:
o Usar el juicio profesional para aplicarlas.
o Poder justificar cualquier diferencia.
1.1.4.2 Directrices de COBIT 4.1 orientadas a la auditoria de aplicaciones informáticas
Para cumplir con una auditoría de aplicaciones informáticas, las directrices más
relevantes que se pueden utilizar, son las detalladas en la Tabla 1.2 en donde se
marca con una X aquellas sugeridas por ISACA y aquellas que han sido definidas por
la institución financiera para los procesos de auditoría.
12
Análisis realizado Directrices de COBIT 4.1
Sug
erid
as p
or
ISA
CA
(G
142 )
A u
tiliz
arse
seg
ún
defin
icio
nes
de la
in
stitu
ción
fin
anci
era
para
los
proc
esos
de
audi
torí
a.
Crit
erio
s de
In
form
ació
n su
gerid
os p
or
ISA
CA
(G
14)
PO2 - Definir la arquitectura de la Información X
P04 - Definir Procesos, Organización y Relaciones de TI X
PO7 - Administrar Recursos Humanos de TI X
S
PO8 – Administrar Calidad X S
P09 - Evaluar y Administrar Riesgos de TI X
P
AI2 - Adquirir y Mantener el Software Aplicativo X X
P
AI6 – Administrar Cambios X X S
AI7 - Instalar y Acreditar Soluciones y Cambios X
DS2 - Administrar Servicios de Terceros X
DS3 - Administrar Desempeño y Capacidad X X
S
DS4 - Garantizar la Continuidad del Servicio X
DS5 - Garantizar la Seguridad de los Sistemas X X
P
DS10 - Administrar los Problemas X X S
DS11 - Administrar los Datos X X S
ME2 - Monitorear y Evaluar el Control Interno X
P
AC2Recolección y Entrada de Información Fuente X
AC3 Verificaciones de exactitud, totalidad, y autenticidad X
2Directriz de auditoría definida por ISACA que describe las prácticas recomendadas para la revisión de los sistemas de aplicación, vigente desde Noviembre 2001. La información completa de la Directriz G14, se encuentra en http://www.isaca.org/Knowledge-Center/Standards/Documents/G14-AppSysRev-15Oct08.pdf
13
AC4 Integridad y Validez del Procesamiento X
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores X
AC6 Autenticación e integridad de transacciones X
Tabla 1. 2 Directrices - Auditoría de Aplicaciones
Fuente: Elaborado por los autores
Según la directriz G14 definida por ISACA, los criterios de información para una
revisión de sistemas de aplicación son:
P= Primarios : Disponibilidad, confiabilidad, integridad y confidencialidad. S= Secundarios : Cumplimiento, eficacia y eficiencia.
Además, existen directrices de auditoría de Sistemas de Información definidas por
ISACA, que pueden ser de mucha utilidad para el auditor al momento de planificar
una auditoría de aplicaciones informáticas. El auditor debe considerarlas utilizando
su criterio profesional para su aplicación y estar preparado para justificar cualquier
desviación. Estas se describen en el Anexo 1: Directrices de auditoría de Sistemas
de Información definidas por ISACA, para el presente proyecto destaca la Directriz
G14.
1.2 DEFINICIÓN DE CONTROLES PARA LA AUDITORIA DE
APLICACIONES INFORMÁTICAS
Según el Manual de Preparación del Examen CISA 2011, los controles se definen
como: políticas, procedimientos, prácticas y estructura organizacional implantados
con la finalidad de reducir riesgos. Son establecidos para proveer seguridad
razonable de que los objetivos de la organización serán alcanzados. Existe dos
aspectos claves que los controles deben atender son:
- Qué debería lograrse.
- Qué debería evitarse.
14
A continuación se describe en la Tabla 1.3 la clasificación de los diferentes tipos de
control.
Tabla 1. 3 Clasificación Tipos de Control
Fuente: Manual de Preparación del Examen CISA 2011
1.2.1 OBJETIVOS DEL CONTROL INTERNO
El objetivo de control interno son los resultados deseados que deben ser alcanzados
con la implementación de actividades de control, que son las tareas que se deben
realizar para cumplir dicho objetivo. Por ejemplo:
- Cumplimiento de las políticas corporativas.
- Confiabilidad de los procesos.
- Confiabilidad de los servicios de TI, entre otros.
Clase Función Ejemplos Preventivos - Detectan los problemas antes de que
aparezcan. - Monitorean tanto la operación como las
entradas. - Intentan predecir los problemas
potenciales antes de que ocurran y realizan ajustes.
- Evitan que ocurra un error, omisión o acto malicioso.
- Segregar funciones. - Controlar acceso a instalaciones
físicas. - Utilizar documentos bien
diseñados. - Establecer procedimientos
adecuados para la autorización de transacciones.
Detectivos - Utilizan controles que detectan e informan la ocurrencia de un error, omisión ó acto fraudulento.
- Revisión de logs de seguridad o transacciones para detectar intentos de acceso no autorizado.
- Revisión de logs transaccionales para identificar transacciones inusuales.
Correctivos - Minimizar el impacto de una amenaza - Remediar errores descubiertos por
controles detectivos. - Identificar la causa de un problema. - Corregir errores que surgen de un
problema. - Modificar los sistemas de procesamiento
para minimizar futuras ocurrencias del problema.
- Planificación de contingencia. - Procedimientos de respaldo.
15
Una variante de los objetivos de control interno son los objetivos de control de TI, que
son objetivos de control interno orientados a procesos de TI. Por ejemplo:
- Salvaguarda de activos.
- Eficacia y eficiencia de operaciones.
- Integridad de la información sensitiva.
- Integridad de la información financiera para accionistas / público, autorización
de las transacciones, entre otros.
1.2.2 CONTROLES GENERALES DE TI
Los Controles Generales de TI están dirigidos a los controles del ambiente
computacional y de los sistemas operativos. Por ejemplo:
- Estrategia y dirección de TI.
- Desarrollo de sistemas y control de cambios.
- Operaciones de procesamiento de datos.
- Procedimientos de aseguramiento de calidad del procesamiento de datos.
- Controles de acceso físico.
- Planeación de continuidad del negocio / Recuperación de desastres
- Redes y comunicaciones.
- Administración de bases de datos.
1.2.3 CONTROLES DE APLICACIÓN
Los controles de aplicación consisten de actividades manuales y/o automatizadas ó
una combinación de las dos, que aseguran que la información cumple con ciertos
criterios, están dirigidos a las aplicaciones computacionales individuales que
soportan los procesos del negocio. Por ejemplo:
- Acceso a las funciones de las aplicaciones.
- Validaciones en la entrada de datos.
- Niveles de autorización para transacciones en la aplicación.
- Reportes.
- Pistas de auditoría, entre otros.
16
Los controles de aplicación se establecen sobre funciones de entrada,
procesamiento y salida de datos, como se describe en la Tabla 1.4.
Tipo Control Función Objetivo
Controles de Entrada/Origen:
Mantener la integridad de los datos que son ingresados al sistema
Ingresar datos completos, correctos y válidos.
Controles de Procesamiento Generalmente automatizados, proveen una forma de asegurar que el procesamiento de las transacciones sea completa, adecuada y autorizada
Validar que el procesamiento realice la tarea correcta.
Controles de salida: Direccionan a las operaciones que fueron realizadas con los datos. Se puede establecer comparaciones entre las salidas generadas y los ingresos realizados
Obtener resultados que satisfagan las expectativas.
Controles de integridad Verificar la integridad y consistencia de los datos procesados
Datos completos y válidos durante todo el proceso.
Tabla 1. 4 Controles de Aplicación
Fuente: Manual de Preparación del Examen CISA 2011
COBIT 4.1 define seis controles de aplicación ACn, como se mencionó
anteriormente, en la sección: 1.1.3.2 Objetivos de Control, Estos son:
AC1 Preparación y Autorización de Información Fuent e.
Asegurar que los documentos fuente están preparados por personal autorizado y
calificado siguiendo los procedimientos establecidos, teniendo en cuenta una
adecuada segregación de funciones respecto al origen y aprobación de estos
documentos. Los errores y omisiones pueden ser minimizados a través de buenos
diseños de formularios de entrada. Detectar errores e irregularidades para que sean
informados y corregidos.
AC2 Recolección y Entrada de Información Fuente.
Establecer que la entrada de datos se realice en forma oportuna por personal
calificado y autorizado. Las correcciones y reenvíos de los datos que fueron
erróneamente ingresados se deben realizar sin comprometer los niveles de
17
autorización de las transacciones originales. En donde sea apropiado para
reconstrucción, retener los documentos fuentes originales durante el tiempo
necesario.
AC3 Chequeos de Exactitud, Integridad y Autenticida d
Asegurar que las transacciones son exactas, completas y válidas. Validar los datos
ingresados, y editar o devolver para corregir, tan cerca del punto de origen como sea
posible.
AC4 Integridad y Validez del Procesamiento
Mantener la integridad y validación de los datos a través del ciclo de procesamiento.
Detección de transacciones erróneas no interrumpe el procesamiento de
transacciones válidas.
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores
Establecer procedimientos y responsabilidades asociadas para asegurar que la
salida se maneja de una forma autorizada, entregada al destinatario apropiado, y
protegida durante la transmisión; que se verifica, detecta y corrige la exactitud de la
salida y que se usa la información proporcionada en la salida.
AC6 Autenticación e Integridad de Transacciones
Antes de pasar datos de la transacción entre aplicaciones internas y funciones de
negocio/operativas (dentro o fuera de la empresa), verificar el apropiado
direccionamiento, autenticidad del origen e integridad del contenido. Mantener la
autenticidad y la integridad durante la transmisión o el transporte.
En la Tabla1.5 se muestra los tipos de control ACn de acuerdo al tipo de control.
18
Tipos de Control Controles de Aplicación- ACn
Ejemplos
Controles de Entrada/Origen
AC1 AC2 AC3
- Autorización de entrada de datos firmas en formularios por lotes ó documentos de origen, controles de acceso en línea, contraseñas, identificación de terminal o estación de trabajo.
Controles de Procesamiento
AC4 - Re-cálculos manuales en base a muestras para asegurarse que los datos fueron procesados correctamente.
- Verificación de edición para validar que los datos ingresados y procesados por una aplicación sean íntegros y válidos.
Controles de salida AC5 - Registro y almacenamiento de formularios negociables, sensibles y críticos en un lugar seguro.
- Distribución de reportes de acuerdo a parámetros de distribución autorizada.
Controles de integridad AC6 - Controles en los procesos de modificación, inserción, eliminación ó actualización de datos, para garantizar que la información sea válida a lo largo de todo el proceso.
Tabla 1. 5 Controles ACn de acuerdo al tipo de cont rol
Fuente: http://auditoriasistemasucb.pbworks.com/f/ProcesosCOBIT41_ig.pdf
COBIT 4.1 define la relación P=primaria ó S= secundaria entre los Objetivos de
Control de Aplicación y los Criterios de Información.
Figura 1. 5 Objetivos de Control de Aplicación vs Criterios de Información
Fuente: http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/ Pages/COBIT-and-
Application-Controls-A-Management-Guide.aspx
19
1.2.4 ANÁLISIS DE LOS PROCESOS COBIT 4.1 Y OBJETIVOS DE CONTROL PARA AUDITORÍA DEAPLICACIONES
INFORMÁTICAS.
Las directrices de COBIT utilizadas para la auditoría de aplicaciones informáticas, están representados por varios de
los procesos de los Dominios de COBIT 4.1 y de sus objetivos de control asociados. A continuación se presenta un
análisis de los procesos de COBIT 4.1 y de los objetivos de control que pueden utilizarse para planificar y efectuar una
auditoría de aplicaciones informáticas tipo web o de cualquier otra arquitectura, los que se utilizarán son aquellos
definidos según análisis realizado por los autores descritos en la Tabla 1. 2 Directrices - Auditoría de Aplicaciones.
Proceso de COBIT 4.1
Definición del Proceso Objetivos de Control COBIT 4.1
PO2
Definir la
arquitectura
de información
La función de los sistemas de información crea y actualiza periódicamente el modelo de información del negocio y define los sistemas apropiados para optimizar el uso de esta información. Esto abarca el desarrollo de un diccionario de datos y las reglas de sintaxis de datos de la organización, el esquema de clasificación de los datos y los niveles de seguridad. Este proceso mejora la calidad de la gestión de toma de decisiones, al garantizar la entrega de información confiable y segura, facilitando la racionalización de los recursos de sistemas de información para satisfacer adecuadamente las estrategias empresariales. Este proceso de TI también es necesario para consolidar la responsabilidad de reportar el estado de la integridad y la seguridad de los datos, ampliando la eficacia y el control del intercambio de información entre las aplicaciones y la organización.
PO2.4
Gestión de integridad
Tabla 1. 6 Análisis de los procesos COBIT 4.1 y Objetivos de control para auditoría de aplicaciones informáticas.
Fuente : Elaborado por los Autores en base a COBIT 4.1.
20
Proceso de
COBIT 4.1
Definición del Proceso Objetivos de Control COBIT 4.1
PO4 Definir los
procesos,
organización y
relaciones de TI
Una organización de TI está definida en base a las necesidades de personal, las aptitudes, funciones, obligación de rendir cuenta, autoridad, roles, responsabilidades y la supervisión. Esta organización se incrusta en un marco de procesos de TI que garantice la transparencia y el control, así como la participación de altos ejecutivos y la gerencia de la organización. Un comité de estrategia asegura que la junta de supervisión de las TI, y uno o más comités de dirección en la que participan las áreas de negocios y TI, determinen la priorización de los recursos de TI de acuerdo a las necesidades del negocio. Se habilitan los procesos, las políticas y los procedimientos administrativos para todas las funciones, con especial atención al control y garantía de calidad, gestión de riesgos, seguridad de la información, propiedad de datos y sistemas, y la segregación de funciones. TI es involucrada en los procesos relevantes de decisión para asegurar el soporte oportuno de los requerimientos del negocio.
PO4.11 Segregación de funciones
AI2 Adquirir y mantener software aplicativo
Las aplicaciones se hacen disponibles en línea con los requerimientos del negocio. Este proceso cubre el diseño de las aplicaciones, la inclusión correcta de los controles de aplicación y los requerimientos de seguridad, así como el desarrollo y la configuración alineados con los estándares. Esto le permite a las organizaciones apoyar apropiadamente sus operaciones de negocios con las aplicaciones automatizadas correctas.
AI2.3 Control y auditabilidad de las aplicaciones.
AI6 Gestionar cambios
Todos los cambios relacionados con la infraestructura y aplicaciones dentro del entorno de producción, inclusive los mantenimientos de emergencia y los parches, se gestionan formalmente y de modo controlado. Los cambios (inclusive sobre procedimientos, procesos y parámetros de servicio y de sistema) son registrados, evaluados y autorizados antes de su implementación y comparados contra los resultados luego de su implementación. Esto asegura una mitigación de los riesgos que afecten negativamente la estabilidad o integridad del entorno de producción.
AI6.1 Estándares y procedimientos para cambios. AI6.2 Evaluación de impacto, priorización y autorización. AI6.3 Cambios de emergencia. AI6.4 Seguimiento y reporte de estado de los cambios. AI6.5 Cierre y documentación del cambio
Continuación Tabla 1. 6 Análisis de los procesos COBIT 4.1 y Objetivos de control para auditoría de aplicaciones informáticas.
21
Proceso de COBIT 4.1
Definición del Proceso Objetivos de Control COBIT 4.1
AI7 Instalar y acreditar soluciones y cambios
Los nuevos sistemas necesitan entrar en operación una vez que se ha completado el desarrollo, lo que requiere de pruebas adecuadas en un entorno dedicado con datos de prueba relevantes, la definición del despliegue e instrucciones de migración, la planificación de la liberación, el pase a producción y una revisión luego de su implementación. Esto asegura que los sistemas en operación estén alineados con las expectativas y resultados acordados.
AI7.6 Pruebas de cambios. AI7.7 Pruebas de aceptación final. AI7.8Promoción a producción.
DS2 Gestionar los servicios de terceros
La necesidad de asegurar que los servicios de terceros (proveedores, vendedores y asociados) cumplan con los requerimientos del negocio requiere un proceso de gestión de terceros. Este proceso se realiza definiendo claramente los roles, responsabilidades y expectativas en los acuerdos con terceros así como la revisión y monitoreo de tales acuerdos en busca de eficacia y cumplimiento. La gestión eficaz de servicios de terceros minimiza el riesgo de negocio asociado con el incumplimiento de proveedores.
DS2.3 Gestión de riesgos de proveedores. DS2.4 Monitoreo del desempeño de proveedores
DS3 Gestionar el desempeño y la capacidad
La necesidad de gestionar el desempeño y la capacidad de los recursos de TI requiere de un proceso para su revisión periódica, lo que incluye pronosticar necesidades futuras basándose en requerimientos de carga de trabajo, almacenamiento y contingencia. Este proceso provee la garantía de que los recursos de información que soportan los requerimientos del negocio estén disponibles en forma continua.
DS3.4 Disponibilidad de recursos de TI
DS4 Garantizar la continuidad del servicio
La necesidad de proveer servicios continuos de TI requiere del desarrollo, mantenimiento y pruebas de planes de continuidad de TI, utilizar almacenamiento de respaldos fuera de las instalaciones y proporcionar entrenamiento periódico sobre el plan de continuidad. Un proceso eficaz de servicio continuo minimiza la probabilidad y el impacto de una interrupción de un servicio crítico de TI en funciones y procesos claves del negocio.
DS4.2 Planes de Continuidad de TI DS4.4 Mantenimiento del Plan de Continuidad de TI DS4.8 Recuperación y Reanudación de los Servicios de TI DS4.9 Almacenamiento externo de respaldos
Continuación Tabla 1. 6 Análisis de los procesos COBIT 4.1 y Objetivos de control para auditoría de aplicaciones informáticas.
22
Proceso de COBIT 4.1
Definición del Proceso Objetivos de Control COBIT 4.1
DS5 Garantizar la seguridad de los sistemas
La necesidad de mantener la integridad de la información y proteger los activos de TI precisa de un proceso de gestión de seguridad, lo que incluye establecer y mantener los roles, las responsabilidades, políticas, estándares y procedimientos de seguridad de TI. Además, realizar monitoreos de seguridad y pruebas periódicas e implementar acciones correctivas para identificar debilidades de seguridad o incidentes. Una gestión efectiva de seguridad protege todos los activos de TI para minimizar el impacto de vulnerabilidades de seguridad e incidentes en el negocio.
DS5.3 Gestión de identidad. DS5.4 Gestión de cuentas de usuario. DS5.11 Intercambio de datos Sensitivos
DS10 Administrar Problemas
Una efectiva administración de problemas requiere la identificación y clasificación de problemas, el análisis de las causas desde su raíz, y la resolución de problemas. El proceso de administración de problemas también incluye la identificación de recomendaciones para la mejora, el mantenimiento de registros de problemas y la revisión del estatus de las acciones correctivas. Un efectivo proceso de administración de problemas mejora los niveles de servicio, reduce costos y mejora la conveniencia y satisfacción del usuario.
DS10.1 Identificación y Clasificación de Problemas
DS11 Gestionar datos
La gestión eficaz de datos precisa de la identificación de las necesidades de datos. El proceso de gestión de datos también incluye el establecimiento de procedimientos eficaces para la gestión de la biblioteca de medios, backup, restauración y una adecuada eliminación de los medios. La gestión de datos ayuda a garantizar la calidad, oportunidad y disponibilidad de los datos del negocio.
DS11.1 Requerimientos del negocio para la gestión de datos DS11.2 Acuerdos para el almacenamiento y la conservación DS11.3 Sistema de gestión de librería de medios DS11.4 Eliminación DS11.5 Respaldo y restauración DS11.6 Requisitos de seguridad para la gestión de datos
Continuación Tabla 1. 6 Análisis de los procesos COBIT 4.1 y Objetivos de control para auditoría de aplicaciones informáticas.
23
Proceso de COBIT 4.1
Definición del Proceso Objetivos de Control COBIT 4.1
AC2 Recolección y Entrada de Información Fuente
Establecer que la entrada de datos se realice en forma oportuna por personal calificado y autorizado. Las correcciones y reenvíos de los datos que fueron erróneamente ingresados se deben realizar sin comprometer los niveles de autorización de las transacciones originales. En donde sea apropiado para reconstrucción, retener los documentos fuentes originales durante el tiempo necesario.
AC2 Recolección y Entrada de Información Fuente
AC3 Verificaciones de exactitud, totalidad, y autenticidad
Asegurar que las transacciones son exactas, completas y válidas. Validar los datos ingresados, y editar o devolver para corregir, tan cerca del punto de origen como sea posible.
AC3 Verificaciones de exactitud, totalidad, y autenticidad
AC4 Integridad y Validez del Procesamiento
Mantener la integridad y validación de los datos a través del ciclo de procesamiento. Detección de transacciones erróneas no interrumpe el procesamiento de transacciones válidas.
AC4 Integridad y Validez del Procesamiento
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores
Establecer procedimientos y responsabilidades asociadas para asegurar que la salida se maneja de una forma autorizada, entregada al destinatario apropiado, y protegida durante la transmisión; que se verifica, detecta y corrige la exactitud de la salida; y que se usa la información proporcionada en la salida.
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores
AC6 Autenticación e integridad de transacciones
Antes de pasar datos de la transacción entre aplicaciones internas y funciones de negocio/operativas (dentro o fuera de la empresa), verificar el apropiado direccionamiento, autenticidad del origen e integridad del contenido. Mantener la autenticidad y la integridad durante la transmisión o el transporte.
AC6 Autenticación e integridad de transacciones
Continuación Tabla 1. 6 Análisis de los procesos COBIT 4.1 y Objetivos de control para auditoría de aplicaciones informáticas.
24
1.3 MARCOS DE TRABAJO PARA EL DESARROLLO DE LA
AUDITORÍA
Actualmente existen varios estándares reconocidos internacionalmente cuya
misión principal es guiar a las empresas al logro de sus objetivos y mejoras en
su gobierno de TI en base a lo denominado como mejores prácticas, dichos
estándares deben aplicarse al negocio dependiendo de la particularidad del
mismo y de los procesos a auditarse.
Las mejores prácticas de TI posibilitan y soportan:
- Una mejor gestión de TI que es esencial para el éxito de la estrategia de
la empresa.
- Un gobierno eficaz de las actividades de TI.
- Un marco de referencia eficaz para la gestión de políticas, controles
internos y prácticas definidas, que es necesario para que todos sepan lo
que hay que hacer.
- Muchos otros beneficios, incluyendo ganancia de eficiencias, menor
dependencia de expertos, menos errores, mejora de la confianza de los
socios de negocios y de entidades reguladores.
A continuación se detalla el marco de trabajo para los tres estándares que en la
actualidad están ampliamente utilizados a nivel global, estos son: COBIT 4.1,
ITIL v3 e ISO 27002.
1.3.1 COBIT 4.1
La estructura de COBIT 4.1 ha sido detallada en la sección 1.1.3 – Marco de
Trabajo COBIT 4.1.
1.3.2 ITIL V3
ITIL por sus siglas en inglés significa Information Technology Infrastructure
Library (Biblioteca de la Infraestructura de TI). Sus orígenes se remontan a la
década de los 80 cuando el gobierno británico, preocupado por la calidad de
25
los servicios TI de los que dependía la administración, solicito a una de sus
agencias la CCTA, Central Computer and Telecommunications Agency
(Agencia Central para la Informática y las Telecomunicaciones), que se
convirtió en la OGC, Office of Government Commerce (Oficina de Comercio
Gubernamental), en abril del 2001, para que desarrollara un estándar para la
provisión eficiente de servicios TI.
ITIL V3 es una serie de publicaciones que se utilizan para describir y optimizar
un marco de trabajo para la Gestión de la calidad de Servicio dentro de una
organización. La filosofía de ITIL es globalmente reconocida como la fundación
de las mejores prácticas de la Gestión de Servicio de TI. Su objetivo de mejorar
la calidad de los servicios TI ofrecidos, evitar los problemas asociados a los
mismos y en caso de que estos ocurran ofrecer un marco de actuación para
que estos sean solucionados con el menor impacto y rapidez.
1.3.2.1 Estructura
ITIL v3 consta de cinco libros basados en el ciclo de vida del servicio, estos son:
Estrategia del Servicio.
Se enfoca en el estudio de mercado y posibilidades mediante la búsqueda de
servicios innovadores que satisfagan al cliente tomando en cuenta la real
factibilidad de su puesta en marcha. Así mismo se analizan posibles mejoras
para servicios ya existentes.
Diseño del Servicio
Una vez identificado un posible servicio el siguiente paso consiste en analizar
su viabilidad. Para ello se toman factores tales como infraestructura disponible,
capacitación del personal y se planifican aspectos como seguridad y
prevención ante desastres. Para la puesta en marcha se toman en
consideración la reasignación de cargos (contratación, despidos, ascensos,
jubilaciones, entre otros), la infraestructura y software a implementar.
26
Transición del Servicio
Antes de poner en marcha el servicio se deben realizar pruebas. Para ello se
analiza la información disponible acerca del nivel real de capacitación de los
usuarios, estado de la infraestructura, recursos TI disponible, entre otros.
Luego se prepara un escenario para realizar pruebas; se replican las bases de
datos, se preparan planes de rollback (reversión) y se realizan las pruebas.
Luego de ello se limpia el escenario hasta el punto de partida y se analizan los
resultados, de los cuales dependerá la implementación del servicio. En la
evaluación se comparan las expectativas con los resultados reales.
Operación del Servicio
En este punto se monitorea el funcionamiento del servicio, se registran
eventos, incidencias, problemas, peticiones y accesos al servicio.
Mejora Continua del Servicio
Se utilizan herramientas de medición y feedback para documentar la
información referente al funcionamiento del servicio, los resultados obtenidos,
problemas ocasionados, soluciones implementadas, entre otros. Para ello se
debe verificar el nivel de conocimiento de los usuarios respecto al nuevo
servicio, fomentar la investigación referente al servicio y compartir la
información al resto de los usuarios.
1.3.2.2 Funciones, procesos y roles
ITIL marca una clara distinción entre funciones y procesos, adicional incorpora
el concepto de rol.
Función : es una unidad especializada en la realización de una cierta actividad
y es la responsable de su resultado. Las funciones incorporan todos los
recursos y capacidades necesarias para el correcto desarrollo de dicha
actividad. Las funciones tienen como principal objetivo dotar a las
organizaciones de una estructura acorde con el principio de especialización.
Proceso: es un conjunto de actividades interrelacionadas orientadas a cumplir
un objetivo específico.
27
Los procesos comparten las siguientes características:
- Cuantificables y se basan en el rendimiento.
- Tienen resultados específicos.
- Tienen un cliente final que es el receptor de dicho resultado.
- Se inician como respuesta a un evento.
El Centro de Servicios y la Gestión del Cambio son dos claros ejemplos de
función y proceso respectivamente.
Rol: es un conjunto de actividades y responsabilidades asignadas a una
persona o un grupo. Una persona o grupo puede desempeñar simultáneamente
más de un rol. Hay cuatro roles genéricos que juegan un papel especialmente
importante en la gestión de servicios TI:
- Gestor del Servicio.- Es el responsable de la gestión de un servicio
durante todo su ciclo de vida: desarrollo, implementación,
mantenimiento, monitorización y evaluación.
- Propietario del Servicio .- Es el último responsable cara al cliente y a la
organización TI de la prestación de un servicio específico.
- Gestor del Proceso.- Es el responsable de la gestión de toda la
operativa asociada a un proceso en particular: planificación,
organización, monitorización y generación de informes.
- Propietario del Proceso.- Es el último responsable frente a la
organización TI de que el proceso cumple sus objetivos. Debe estar
involucrado en su fase de diseño, implementación y cambio asegurando
en todo momento que se dispone de las métricas necesarias para su
correcta monitorización, evaluación y eventual mejora.
1.3.3 ISO 27002
El estándar internacional fue publicado por la ISO (www.iso.org/ISO/home.htm)
y la IEC, que establecieron el comité técnico mixto ISO/IEC JTC 1. La fuente
histórica para el estándar fue BS 7799-1, cuyas partes esenciales fueron
tomadas en el desarrollo de la norma ISO/IEC 17799:2005. Su primera edición
28
en el año 2000 y actualizada en junio de 2005. Se puede clasificar como las
mejores prácticas actuales en materia de sistemas de gestión de seguridad de
la información.
El objetivo del estándar ISO/IEC 27002:2005 es brindar información a los
responsables de la implementación de seguridad de la información de una
organización. Es definida como una buena práctica para desarrollar y mantener
normas de seguridad y prácticas de gestión en una organización para mejorar
la fiabilidad en la seguridad de la información en las relaciones inter-
organizacionales.
1.3.3.1 Estructura
Se definen las estrategias de 133 controles de seguridad organizados bajo 11
dominios. La ISO 27002 recalca la importancia de la gestión del riesgo y
establece que no es necesario aplicar cada parte, sino sólo aquellas que sean
relevantes de acuerdo a las necesidades de la organización.
Proporciona recomendaciones de las mejores prácticas en la gestión de la
seguridad de la información a todos los interesados y responsables en iniciar,
implantar o mantener sistemas de gestión de la seguridad de la información. La
seguridad de la información se define en el estándar como: la preservación de
la confidencialidad (asegurando que sólo quienes estén autorizados pueden
acceder a la información), integridad (asegurando que la información y sus
métodos de proceso son exactos y completos) y disponibilidad (asegurando
que los usuarios autorizados tienen acceso a la información y a sus activos
asociados cuando lo requieran).
La ISO 27002 incluye once secciones principales, estas son:
1. Política de Seguridad de la Información.
2. Organización de la Seguridad de la Información.
3. Gestión de Activos de Información.
4. Seguridad de los Recursos Humanos.
5. Seguridad Física y Ambiental.
6. Gestión de las Comunicaciones y Operaciones.
29
7. Control de Accesos.
8. Adquisición, Desarrollo y Mantenimiento de Sistemas de Información.
9. Gestión de Incidentes en la Seguridad de la Información.
10. Gestión de Continuidad del Negocio.
11. Cumplimiento.
Dentro de cada sección, se especifican los objetivos de los distintos controles
para la seguridad de la información.
1.3.4 INTERRELACIÓN DE LOS ESTÁNDARES COBIT 4.1, IT IL V3,
EISO/IEC 27002 PARA AUDITORÍA DE APLICACIONES
INFORMÁTICAS.
Las mejores prácticas y los estándares ayudan a posibilitar un gobierno eficaz
de las actividades de TI.
El uso de estándares y mejores prácticas tales como COBIT 4.1, ITIL v3 e
ISO/IEC 27002, mejora el desempeño, transparencia y control sobre
actividades de TI.
Para el presente trabajo utilizaremos COBIT 4.1. Sin embargo se determina
que se puede combinar las directrices de otros estándares, las mejores
prácticas de TI deben ajustarse a los requisitos del negocio y ser integradas
entre sí y con los procedimientos internos.
En el Anexo 2 : Interrelación de los Marcos de Trabajo COBIT-ITIL-ISO27002,
se describe el análisis de los procesos de COBIT 4.1 y sus objetivos de control
que se indican en la Tabla 1. 6: Análisis de los procesos COBIT 4.1 y Objetivos
de control para auditoría de aplicaciones informáticas, para la ejecución de una
auditoría de aplicaciones, los cuales han sido mapeados a secciones
específicas de ITIL e ISO/IEC 27002.
30
CAPITULO 2 PLAN DE AUDITORIA DE LA APLICACIÓN WEB 2.1. ESTUDIO DE LA APLICACIÓN WEB “CAJERO DE
VENTANILLAS” A SER AUDITADA
La aplicación a ser auditada se la denominará como: Cajero de Ventanillas
(CV) que es aquella usada por los cajeros en ventanilla para procesar las
transacciones de depósitos, retiros, pago de cheques, pago a proveedores,
recaudaciones entre otros.
2.1.1 DESCRIPCIÓN
La aplicación CV, está basada en la Arquitectura Windows DNA3, que significa
por sus siglas en inglés: Windows Distributed InterNet Applications Architecture
(Arquitectura de Aplicaciones de Internet Distribuida).
El cliente trabaja en computadoras personales enlazados a un servidor de red,
los componentes pueden ser instalados en un servidor de componentes ó en
servidor de aplicaciones.
2.1.2 ARQUITECTURA FÍSICA
La infraestructura para implementar el modelo de computación distribuida en
Internet en el que está basado el sistema CV, se muestra en el Figura 2.1.
3 Windows DNA es la nomenclatura utilizada por Microsoft para definir a una colección de tecnologías que permiten a la plataforma Windows e internet trabajar en conjunto. Algunas de sus tecnologías son el Active X, DHTML y COM.
31
Figura 2. 1 Arquitectura de la Aplicación
Fuente: Entidad Bancaria
2.1.2.1 Servidores
La distribución y configuración de los servidores está basada en el siguiente
esquema:
Figura 2. 2 Distribución Servidores
Fuente: Entidad Bancaria
Descripción Cantidad Software
Servidor Web 3 Sistema Operativo Windows 2003 Server.
Microsoft Frameworks 1.0
Servidor de Base de Datos 1 Sistema Operativo Windows 2003 Server.
SQL Server 2000
Tabla 2. 1 Descripción Servidores
Fuente: Entidad Bancaria
32
2.1.2.2 Clientes
Descripción Cantidad Software
PC´s Agencias 250 Sistema Operativo Windows XP ó
superior.
Microsoft Internet Explorer 6.0 o superior.
Tabla 2. 2 Descripción Clientes
Fuente: Entidad Bancaria 2.1.2.3 Herramientas de Desarrollo
La aplicación ha sido desarrollada con plataforma .NET. La siguiente tabla
muestra los diferentes leguajes que permitieron desarrollar el aplicativo CV.
Ambiente Herramienta de Desarrollo
Código Interfaz Cliente Jscript, VbScript, HTML
Actives Visual Basic 6.0
Componentes de Negocio C#
Código Servidor Asp.NET
Tabla 2. 3 Herramientas de Desarrollo
Fuente: Entidad Bancaria
2.1.3 ARQUITECTURA LOGICA
Se identifica los componentes internos, cada uno de los cuales será
responsable de resolver los diferentes servicios de la aplicación, estos
componentes son:
Figura 2. 3 Arquitectura Lógica de la Aplicación
Fuente: Entidad Bancaria
33
� Usuarios .-Ente que interactúa directamente con la aplicación CV, en este
caso Cajeros y Supervisores.
� Capa de Presentación .-Parte de la solucion o proyecto que ofrece al
usuario un modo de interactuar con la aplicación.
� Capas empresariales .-Una vez que el proceso de usuario ha recopilado los
datos necesarios, éstos se pueden utilizar para realizar un proceso empresarial
ó de negocio.
� Capa de datos .-La mayoría de las aplicaciones y servicios necesitan
obtener acceso a un repositoriode datos en un momento determinado del
proceso empresarial.
� Orígenes de datos .-Estructura de almacenamiento de información.
� Servicios .-Programas expuestos para que las aplicaciones puedan
interactuar entre sí, ejemplo: web service.
La aplicación CV interactúa con otras aplicaciones para proveer varios servicios
al usuario final, estas son:
- Core Financiero .- Contiene la información de los clientes y es la
encargada de autorizar o no las transacciones. Además, controla el
acceso de los usuarios a la aplicación.
- Divisas.- Para obtener el valor de la cotización de las divisas la
transacción de compra o venta de divisas.
- Cubos de Información .- Toma la información de todas las
transacciones realizadas para formar el cubo de ventanillas y obtener
información gerencial.
- Tarjetas de Crédito .- Para verificar la información y el saldo a pagar de
los clientes.
- Switch Transaccional .- Para realizar las transacciones obtenidas por
concepto de recaudaciones.
2.1.4 MÓDULOS Y TRANSACCIONES DE LA APLICACIÓN CV
La aplicación CV consta de cinco módulos, compuestos por transacciones que
han sido definidas de acuerdo a las necesidades del negocio, en la Figura 2.4
se detalla estos módulos.
34
Figura 2. 4 Módulos Aplicación Cajero de Ventanillas
Fuente: Entidad Bancaria
Módulo No. Elementos Elemento
Transacciones
15
Inicializar las transacciones Pago de Cheques Depósitos Retiros Pago a Proveedores Recaudaciones Bono de Solidaridad Pago Aportes y Fondos IESS Pago de Pensiones del IESS Certificación de Cheques Ruteos de transacciones Reversos de transacciones Actualizar Libreta Cambiar Libreta Compra / Venta de Divisas
Tabla 2. 4 Elementos Módulo Transacciones
Fuente: Entidad Bancaria
35
Módulo No. Elementos Elemento
Consultas 3
Lista de Transacciones Lista de Cajeros Cuadre de Oficina
Tabla 2. 5 Elementos Módulo Consultas
Fuente: Entidad Bancaria
Módulo No. Elementos Elemento
Reportes
4
Planilla Total Efectivo Planilla Total Cheques Planilla Total Cajero Planilla Detalles Retenciones
Tabla 2. 6 Elementos Módulo Reportes
Fuente: Entidad Bancaria
Módulo No. Elementos Elemento
Control
3
Trasferencias con Bóveda Configuración de la Oficina Registro Ingreso / Egreso de Caja
Tabla 2. 7 Elementos Módulo Control
Fuente: Entidad Bancaria
Módulo No. Elementos Elemento
Herramientas 2 Firmas Calculadora
Tabla 2. 8 Elementos Módulo Herramientas
Fuente: Entidad Bancaria
2.2. ELABORACIÓN DEL PROGRAMA DE AUDITORÍA
El programa de auditoría es la estrategia que utilizará el auditor de SI para
realizar la evaluación de su asignación en particular, éste identifica el alcance,
los objetivos para lograr evidencia suficiente, competente y confiable para
obtener y sustentar las conclusiones y opiniones de auditoría.
Según COBIT los auditores de SI evalúan los sistemas de TI desde las
siguientes perspectivas:
- Seguridad (confidencialidad, integridad y disponibilidad).
- Calidad (efectividad, eficiencia, confiabilidad).
- Cumplimiento.
- Recursos Involucrados en los procesos.
36
2.2.1 ELABORACIÓN DEL PROGRAMA DE AUDITORÍA PARA LA
EVALUACIÓN DE LA APLICACIÓN WEB
Un programa de auditoría no sigue necesariamente un conjunto específico de
pasos, provee como mínimo los pasos secuenciales para obtener una
comprensión del objeto a auditar, en este caso la aplicación CV con el objetivo
de evaluar la estructura de control, probar los controles y lograr evidencia
suficiente, competente y confiable para obtener y sustentar las conclusiones y
recomendaciones.
El producto inicial y crítico del proceso de auditoría debe ser el programa de
auditoría, que es la guía para la ejecución y documentación de todos los
siguientes pasos de la auditoría.
Tabla 2. 9 Importancia del Programa de Auditoría
Fuente: Elaborado por los autores.
A continuación se muestra el desarrollo de un programa de auditoría para
aplicaciones informáticas el cual se ha desarrollado utilizando las directrices de
COBIT 4.1 y de sus objetivos de control detallados, los mismos que se
definieron previamente (Sección: 1.2.4 Análisis de los Procesos COBIT 4.1 y
Objetivos de Control para Auditoría de Aplicaciones Informáticas).
Más adelante se definirán los objetivos de control y actividades que se
utilizarán para la auditoría de la aplicación web CV.
37
Directriz de COBIT 4.1 (Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE COBIT 4.1 Y DE LOS AUTORES)
1 No Aplica No Aplica Comprensión de la aplicación.
Comprender el proceso del negocio y la forma como la aplicación lo maneja.
1.1. Relevar el proceso del negocio 1.2. Comprender los módulos de la
aplicación con sus respectivas funcionalidades.
2 DS5 - Garantizar la seguridad de los sistemas.
DS5.3 Gestión de identidad
DS5.4 Gestión de cuentas de usuario
Revisión del control de accesos y manejo de contraseñas de la aplicación.
Se han definido políticas y procedimientos de seguridad para la administración de usuarios.
La aplicación cuenta con técnicas y herramientas de seguridad lógica para restringir el acceso a los recursos de información.
2.1. Verificar la existencia de un procedimiento para la administración de usuarios que acceden a las aplicaciones.
2.2. Validar que los usuarios creados en la aplicación son los autorizados y que los ex empleados y personal de vacaciones hayan sido desactivados. 2.3. Validar los parámetros establecidos para la contraseña en la aplicación (Complejidad, longitud, históricos, caducidad, etc.) y que estén de acuerdo a las mejores prácticas y a las políticas definidas en la institución. 2.4. Verificar los inicios de sesión múltiples, accesos por URLs, tiempo de inactividad de la aplicación.
3 DS5 - Garantizar la seguridad de los sistemas. PO4 - Definir los procesos, organización y relaciones de TI.
DS5.4 Gestión de cuentas de usuario. PO4.11 Segregación de funciones.
Revisión de los perfiles de usuarios autorizados en la aplicación y la segregación de funciones.
Los perfiles de usuario cuentan con procedimientos de control aprobado por la gerencia para garantizar que son generados y asignados con base en las funciones de los cargos y el principio de segregación de tareas.
3.1. Verificar que el procedimiento de creación, asignación y mantenimiento de perfiles se cumple de acuerdo a las políticas y procedimientos de seguridad de la información de la institución.
Tabla 2. 10 Programa de Auditoría - Fuente: Elaborado por los Autores
38
Directriz de COBIT 4.1 (Proceso COBIT utilizado)
Objetivo de Control detallado de COBIT 4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS AUTORES) 4 DS5 - Garantizar la
seguridad de los sistemas
DS5.3 Gestión de identidad
Transacciones Críticas. Identificación de las Transacciones Críticas y su asignación a usuarios autorizados.
4.1. Identificar las transacciones críticas de la aplicación en conjunto con los responsables de la aplicación / módulos y validar su funcionalidad.
4.2. Identificar los perfiles y usuarios que tengan las transacciones/opciones identificadas como críticas.
4.3. Validar el principio de segregación de funciones
5 PO2 - Definir la arquitectura de información.
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores.
PO2.4 Gestión de integridad.
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores.
Revisión de los controles asociados a la salida y entrega de información.
Se han definido controles que aseguren que los datos son entregados a los usuarios en una forma consistente y segura.
5.1. Verificar que los reportes que contienen información sensible tenga controles para impedir se proceda a exportar los datos. 5.2. Revisar que la información sensible que está siendo consultada a través de la aplicación sea realizada por usuarios autorizados.
6 AC2 Recolección y Entrada de Información Fuente
AC3 Verificaciones de exactitud, totalidad, y autenticidad.
AC2 Recolección y Entrada de Información Fuente
AC3 Verificaciones de exactitud, totalidad, y autenticidad
Revisión de los controles asociados al ingreso de datos.
Existen procedimientos de control de entrada que aseguren que toda transacción que vaya a ser procesada sea recibida y registrada correcta y completamente.
6.1. Validar que exista un control de monto máximo por transacción y cuando se supere ese valor se solicite autorización de la línea de supervisión y validar todas las transacciones que requieren de autorización
6.2. Verificar los controles automatizados implementados para efectuar el registro de los datos
6.3. Verificar la existencia de un procedimiento para la modificación de las parametrizaciones del sistema y validar su cumplimiento.
Continuación Tabla 2.10 Programa de Auditoría
39
Directriz de COBIT 4.1 (Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS AUTORES) 7 DS5 Garantizar la
seguridad de los sistemas
AC6 Autenticación e integridad de transacciones
DS5.11 Intercambio de datos Sensitivos
AC6 Autenticación e integridad de transacciones
Revisión de los controles asociados al procesamiento batch.
Existen controles de procesamiento aprobados por la gerencia que aseguren la integridad y la exactitud de los datos.
7.1. Verificar si existe una protección adecuada para la información sensitiva durante la transmisión y transporte en cuanto a accesos y modificaciones no autorizadas. 7.2. Identificar las carpetas FTP y verificar que la lista de usuarios de las carpetas identificadas y sus permisos sean los autorizados. 7.3. Verificar el procedimiento cuando se detecta un error en los archivos
8 AC4 Integridad y Validez del Procesamiento
AC4 Integridad y Validez del Procesamiento
Revisión de los controles asociados al procesamiento on line.
Existen controles de procesamiento aprobados por la gerencia que aseguren la integridad y la exactitud de los datos procesados.
8.1. Identificar los controles que se utilizan en la aplicación para asegurar que los datos se procesen correctamente y sin el riesgo de duplicar o eliminar información (Anular, reversar, corregir). 8.2. Analizar los controles que se tienen en la aplicación para garantizar el registro en la base de datos de las transacciones que se ejecutan en línea 8.3. Identificar el procedimiento a seguir en caso de encontrar errores durante el procesamiento de información e impedir que estos errores afecten a la operación del sistema (rollback de la transacción).
Continuación Tabla 2.10 Programa de Auditoría
40
Directriz de COBIT 4.1 (Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS AUTORES)
9 DS5 Garantizar la seguridad de los sistemas
DS5.4 Gestión de cuentas de Usuario.
Integridad de los datos.
Revisión de la afectación directa a los datos de la base de datos de la aplicación.
9.1. Validar que el personal que puede acceder a la base de datos de la aplicación es el adecuado. 9.2. Identificar las tablas críticas de la aplicación. 9.3. Validar los permisos de los usuarios con accesos a tablas críticas de la base de datos de la aplicación.
10 DS10 Gestionar problemas
DS10.1 Identificación y clasificación de problemas
Revisión de errores y necesidades en la funcionalidad de la aplicación.
Se valida con el área usuaria cuales son los errores más comunes que se presentan en las funcionalidades de la aplicación y se revisa que necesidades funcionales no se incluyen dentro de la aplicación.
10.1. Revisar con el área usuaria los errores más comunes en las funcionalidades de la aplicación 10.2. Revisar con el área usuaria cuales son las necesidades funcionales que la aplicación no cubre.
Continuación Tabla 2.10 Programa de Auditoría
41
Directriz de COBIT 4.1 (Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE
AUDITORÍA DE COBIT 4.1 Y DE LOS AUTORES)
11
AI6 Gestionar cambios
AI7 Instalar y acreditar soluciones y cambios.
AI6.1 Estándares y procedimientos para cambios
AI6.2 Evaluación de impacto, priorización y autorización
AI6.3 Cambios de emergencia
AI6.4 Seguimiento y reporte de estado de los cambios
AI6.5 Cierre y documentación del cambio
AI7.6 Pruebas de cambios
AI7.7 Pruebas de aceptación final
AI7.8 Promoción a producción. AI2.3 Control y auditabilidad de las aplicaciones
Revisión de los cambios efectuados en la aplicación.
Las modificaciones a los sistemas de aplicación existentes se implantan adecuadamente y funcionan de acuerdo con las intenciones de la gerencia. Existen bitácoras (logs) donde se registren los accesos a información crítica en la aplicación. Además, estos registros son revisados regularmente para evaluar si el acceso y uso de dicha información fue el adecuado
11.1. Verificar la existencia de un procedimiento para la ejecución de cambios en la aplicación.
Continuación Tabla 2.10 Programa de Auditoría
42
Directriz de COBIT 4.1 (Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS AUTORES) 12
AI2 Adquirir y mantener software aplicativo
AI 2.3 Control y auditabilidad de las aplicaciones
Evaluación de los logs de auditoría de la aplicación
Los niveles de seguridad de la aplicación se activan para registrar e informar de incidentes de seguridad que no cumplan las políticas definidas por la institución; los informes generados se revisan periódicamente y se toman medidas correctivas.
12.1. Validar si la aplicación cuenta con logos transaccionales y de seguridad, si están activados y qué información almacenan.
12.2. Verificar si se realiza una revisión periódica de estos logos y la existencia de un procedimiento de las acciones a tomar en caso de encontrar novedades (formal o no)
12.3. Identificar a qué niveles se reporta la información encontrada en los logs de la aplicación
13 DS2 Gestionar los servicios de terceros
DS2.3 Gestión de riesgos de proveedores
DS2.4 Monitoreo del desempeño de proveedores
Evaluación de aspectos contractuales. Licencias en caso de aplicaciones de terceros
Existen contratos para el mantenimiento y soporte técnico de la aplicación que garanticen la disponibilidad de la aplicación en términos que garanticen la calidad del servicio a la institución
13.1. Revisar la existencia, completitud y vigencia de los contratos para la adquisición y mantenimiento de la aplicación
13.2. Validar que los contratos cuenten con cláusulas que especifiquen los niveles de servicio de la aplicación y su correspondiente monitoreo por las partes 13.3. Verificar que los contratos cuenten con cláusulas que no pongan en riesgo la disponibilidad del servicio de la aplicación ni su información 13.4. Revisar la existencia y validez de las licencias para el uso del aplicativo
Continuación Tabla 2.10 Programa de Auditoría
43
Directriz de COBIT 4.1(Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS AUTORES)
14
DS3 Gestionar el desempeño y la capacidad
DS4 Garantizar la continuidad del servicio
DS3.4 Disponibilidad de recursos de TI
DS4.2 Planes de Continuidad de TI
DS4.4 Mantenimiento del Plan de Continuidad de TI
DS4.8 Recuperación y Reanudación de los Servicios de TI
Evaluación del impacto de las contingencias y su remediación
La gerencia dispone de un estudio de evaluación de impacto en clientes y usuarios debido a fallas o caídas temporales de la aplicación, así como de un plan para la remediación de la contingencia
14.1. Verificar la existencia de procedimientos de contingencia tecnológica, operativa y su adecuada aplicación
Continuación Tabla 2.10 Programa de Auditoría
44
Directriz de COBIT 4.1 (Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS AUTORES) 15
DS4 Garantizar la continuidad del servicio
DS11 Gestionar datos
DS4.9 Almacenamiento externo de respaldos
DS11.1 Requerimientos del negocio para la gestión de datos DS11.2 Acuerdos para el almacenamiento y la conservación
DS11.3 Sistema de gestión de librería de medios
DS11.4 Eliminación
DS11.5 Respaldo y restauración
DS11.6 Requisitos de seguridad para la gestión de datos
Relevamiento de la administración de respaldos
Los respaldos obtenidos con relación a la aplicación son adecuados
15.1. Validar con el área usuaria que el período de respaldo vaya de acuerdo a las necesidades del negocio y que cumplan con lo establecido por las entidades de control.
Continuación Tabla 2.10 Programa de Auditoría
45
Directriz de COBIT 4.1 (Proceso COBIT
utilizado)
Objetivo de Control detallado de COBIT
4.1
Objetivo de Control (Definido por los
autores)
Descripción Objetivo de Control (Definido
por los autores)
Actividades de Control (DEFINIDAS EN BASE A LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS AUTORES)
16
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores
AC5 Revisión de Salidas, Reconciliación y Manejo de Errores
Cumplimiento
Revisar si los reportes y la información cumplen con todos los aspectos legales impuestos por las entidades de control.
16.1. Identificar con los responsables de la aplicación (negocio), si existen reportes que deban ser emitidos para las entidades de control y si su emisión es correcta.
Continuación Tabla 2.10 Programa de Auditoría
46
2.3. DEFINICIÓN DEL ALCANCE DEL PROGRAMA DE AUDITOR ÍA
Definir el alcance del programa de auditoría permite identificar qué objetivos de
control serán incluidos en la revisión y en base a ello emitir el informe de la auditoría.
El alcance de la auditoría está determinado de acuerdo con el objeto a auditar, el
cual está compuesto por todos los recursos informáticos (personas, equipos,
aplicaciones, capacitación, entre otros.), la información y los controles.
Para definir el alcance se ha establecido factores que permitan calificar a cada uno
de los objetivos de control establecidos para la auditoría de aplicaciones informáticas
tipo web, de tal manera que se pueda determinar si los controles cumplen con los
criterios de información establecidos por COBIT 4.1, los mismos que son: efectividad,
eficiencia, integridad, disponibilidad, confidencialidad, confiabilidad y cumplimiento.
De acuerdo a COBIT a estos criterios se los puede agrupar en factores que están
orientados a la seguridad, calidad, cumplimiento y recursos involucrados en los
procesos.
2.3.1. FACTOR 1: CRITERIOS QUE ORIENTAN A LA SEGURI DAD SEGÚN COBIT
- Confidencialidad .- Se refiere a la protección de información sensible contra
divulgación no autorizada.
- Integridad .- Se refiere a la precisión y suficiencia de la información, así como
a su validez de acuerdo con los valores y expectativas del negocio.
- Disponibilidad .- Se refiere a que la información esté disponible cuando sea
requerida por los procesos del negocio en cualquier momento. También
involucra a la protección y salvaguarda de los recursos.
47
2.3.2 FACTOR 2. CRITERIOS QUE SE FOCALIZAN EN LA CA LIDAD SEGÚN
COBIT
- Efectividad .- Se refiere a que la información relevante sea pertinente para el
proceso del negocio, así como a que su entrega sea oportuna, correcta,
consistente y de manera utilizable.
- Eficiencia .- Consiste en que la información sea generada con el óptimo (más
productivo y económico) uso de los recursos.
- Confiabilidad .- Se refiere a proporcionar la información apropiada para que la
gerencia administre la entidad y ejerza sus responsabilidades de reportes
financieros y de cumplimiento.
2.3.3 FACTOR 3. CRITERIO ORIENTADO AL CUMPLIMIENTO SEGÚN COBIT
- Cumplimiento .- Se refiere a acatar aquellas leyes, reglamentos y acuerdos
contractuales a los cuales está sujeto el proceso de negocios, es decir,
criterios de negocios impuestos externamente, así como políticas internas.
2.3.4 FACTOR 4. RECURSOS INVOLUCRADOS EN LOS PROCESOS SEGÚN
COBIT
- Aplicaciones .- Incluyen sistemas automatizados y procedimientos manuales
que procesan información.
- Información .- Son los datos en todas sus formas, de entrada, procesados y
generados por los sistemas de información.
- Infraestructura .- Es la tecnología y las instalaciones (hardware, sistemas
operativos, sistemas de administración de base de datos, redes, multimedia,
entre otros., así como el sitio donde se encuentran y el ambiente que los
soporta) que permiten el procesamiento de las aplicaciones.
- Personas .- Personal requerido para planear, organizar, adquirir, implementar,
entregar, soportar, monitorear y evaluar los sistemas y los servicios de
información. Estas pueden ser internas, por outsourcing o contratadas de
acuerdo al requerimiento del negocio.
48
Estos criterios se encuentran enlazados a cada una de las directrices de COBIT 4.1,
cada criterio de información tiene una referencia definida por COBIT 4.1, los mismos
que son: primario, secundario o en blanco ya que algunos procesos tienen mayor
impacto en la meta de TI que otros.
A continuación se define la razón por la cual los criterios pueden ser primarios,
secundarios o se encuentran en blanco, según COBIT.
- Primario .- Si definen objetivos de control que impactan directamente los
criterios de información considerados.
- Secundario .- Si definen objetivos de control que solo satisfacen una
extensión pequeña o satisfacen indirectamente al criterio de información
considerado.
- En blanco .- Podría ser aplicable. Sin embargo los requerimientos son
satisfechos de una forma más apropiada por otro criterio en este proceso y/o
en otro proceso.
El detalle de la matriz que muestra cada proceso calificado con sus criterios de
información y su referencia, se lo muestra en el Anexo 3:
Matriz_Alcance_de_Auditoría.xlsx.
Pueden existir varios criterios para definir el alcance de un programa de auditoría,
uno de ellos es presentado en la matriz descrita en el Anexo 3, que define los
criterios de COBIT4.1 que se enfocan en la seguridad, calidad, cumplimiento y los
recursos involucrados. Los objetivos de control que se pueden definir para ser
evaluados pueden ser determinados en base a las ponderaciones que se han
establecido. Por ejemplo el criterio para seleccionar estos objetivos de control
pueden ser los que hayan alcanzado una calificación de riesgo alto.
Otro de los criterios que el auditor de Sistemas puede tomar, es en base al
conocimiento de la aplicación y del entorno tecnológico que le rodea, en cuyo caso
49
los objetivos de control a ser auditados se definirán en base a la experiencia del
auditor.
Es recomendable trabajar con los dos criterios descritos anteriormente, ya que éstos
se complementan.
Para el presente trabajo se tomarán los dos criterios definidos: Objetivos de Control
con calificación de riesgo “Alto” y experiencia del auditor, en el transcurso de la
ejecución de la auditoría de los controles implementados, se elaborarán y
establecerán las observaciones resultado del proceso.
En el Capítulo 3, se incluirá en el Programa de Auditoría, los objetivos de control
resultado de los criterios definidos anteriormente.
50
CAPITULO 3. EJECUCIÓN DEL PLAN DE AUDITORÍA
En la ejecución de la auditoría se debe cumplir los objetivos planteados que se
describen en el programa de auditoría. Los objetivos de la auditoría incluyen el
aseguramiento del cumplimiento, la confidencialidad, integridad y disponibilidad de
los recursos de información y de TI.
En este capítulo se verificará el nivel de cumplimiento de los criterios de información
definidos por COBIT 4.1, para la aplicación Cajero de Ventanillas, de acuerdo a los
objetivos de control establecidos en el Capítulo 2.
Para verificar dicho cumplimiento se ha utilizado las siguientes técnicas de auditoría:
- Pruebas de cumplimiento .- Consiste en recolectar evidencia con el propósito
de probar el cumplimiento de una organización con procedimientos de control,
y determinar si estos están siendo aplicados de acuerdo a las políticas y
procedimientos de gestión determinados por la entidad. Por ejemplo: políticas
de control de cambios de programas, accesos de usuarios, entre otros.
- Pruebas sustantivas .- Consiste en recolectar evidencia para evaluar la
integridad de transacciones individuales, datos u otra información. Por
ejemplo: cálculo de intereses pagado en una muestra de cuentas de clientes.
3.1. RELEVAMIENTO Y EJECUCIÓN DE LA AUDITORÍA
Durante esta etapa el auditor debe tener como elemento principal de trabajo a la
evidencia, entendiéndose a esta como cualquier información usada por el auditor de
SI para determinar si el objeto que está siendo auditado cumple con los criterios de
información, en base a las evidencias relevantes que son definidas a criterio y
51
experiencia del auditor ó regulaciones de la entidad, se obtendrán las respectivas
conclusiones.
A continuación se describen las técnicas de recopilación de evidencia que serán
utilizadas:
- Revisión de estructuras organizacionales.
- Revisión de políticas y procedimientos estándares.
- Revisión de la documentación de la aplicación.
- Entrevista con personal involucrado.
- Observaciones de procesos y desempeño de los usuarios.
- Inspección y verificación.
Otro de los elementos utilizados en la ejecución de la auditoría son las técnicas de
muestreo, que son aplicadas cuando por factores de tiempo y costo no se puede
realizar la verificación total de todas las transacciones ó eventos en una población
definida. Según el Manual de Preparación del Examen CISA 2011.Se define a la
muestra como un subconjunto de miembros de una población utilizada para realizar
pruebas y se usa para inferir características de una población.
Las técnicas de muestreo utilizadas en Auditoría son:
- Técnicas de muestreo estadístico .- Basadas en las leyes matemáticas de la
probabilidad para calcular el tamaño de la muestra y seleccionar los objetos.
El auditor decide cuantitativamente el grado de aproximación con que la
muestra debería representar a la población. Al utilizar este tipo de muestra, la
selección de los objetos pueden ser o no representativos, pues se seleccionan
al azar. Para utilizar esta técnica de muestreo se pueden utilizar herramientas
automáticas como son: ACL – Audit Command Language (Lenguaje de
Comandos de Auditoria) e IDEA, Interactive Data Extraction and Analysis
(Software para Análisis y Extracción de Datos en forma Interactiva).
52
- Técnicas de muestreo no estadístico .- Según el Manual de Preparación al
Examen CISA 2011 , las técnicas de muestreo no estadístico son aquellas en
la cual el tamaño de la muestra y los elementos seleccionados son
determinados en base al juicio y experiencia del auditor respecto al criterio
subjetivo de cuales elementos tienen mayor importancia y riesgo.
Para la ejecución de la presente auditoría se utilizará la Técnica de Muestreo no
estadístico.
Durante la ejecución de la auditoría, el auditor de SI en base a las pruebas realizadas
en cada objetivo de control, determina si un control es efectivo o inefectivo. Un
control es efectivo cuando existe y está implementado de acuerdo a regulaciones,
políticas, mejores prácticas entre otros parámetros de control establecidos por la
entidad de tal manera que mitiguen los riesgos que se puedan presentar, Un control
es inefectivo si éste no existe, está mal implementado o está incompleto,
consecuentemente no mitiga los riesgos que se pueden presentar.
En el Anexo 4. Relevamiento y Ejecución de la Auditoría, se describe el trabajo
realizado en la auditoría de la aplicación informática, Cajero de Ventanilla, que
muestra la evaluación de los objetivos de control definidos en el Capítulo 2. Además,
se define si un objetivo de control es efectivo o inefectivo.
53
3.2. ANÁLISIS DE RIESGOS DE LAS VULNERABILIDADES
IDENTIFICADAS
Esta fase está destinada a identificar, evaluar y valorar los riesgos de las
vulnerabilidades encontradas, la frecuencia, impacto y probabilidad de ocurrencia de
los mismos.
Es importante aclarar varios conceptos que se utilizarán a partir de la presente
sección para mayor comprensión y objetividad del análisis, estos son: amenaza,
vulnerabilidad, hallazgo, riesgo, en base a estos criterios se realizará el análisis de
riesgo de las vulnerabilidades identificadas en la aplicación Cajero de Ventanillas.
AMENAZA
Evento que puede crear situaciones de incertidumbre ante la posibilidad de
ocurrencia de algún hecho dañino sobre recursos de información, tales como:
destrucción, divulgación, modificación de datos, negación de servicios.
HALLAZGO
Cualquier situación deficiente y relevante que determine el auditor mediante
procedimientos de auditoría sobre áreas críticas. Por lo tanto, abarca hechos y
asuntos que llaman la atención del auditor y que en su opinión merecen ser
comunicados a los funcionarios responsables de la entidad auditada y a otras
personas interesadas.
VULNERABILIDAD
La vulnerabilidad es una condición o conjunto de condiciones que pueden hacer que
una amenazase concrete y haga daño a los SI, se origina por una deficiencia en los
54
controles, debido a que están mal diseñado, incompletos, mal implementados ó
ausentes, cuando el auditor encuentra una vulnerabilidad se dice que existe el
hallazgo de una vulnerabilidad.
RIESGO
Según la Guía ISO/CEI 73, el riesgo se define como “la combinación de la
probabilidad de un suceso y sus consecuencias”, es el potencial de que una
amenaza dada explote las vulnerabilidades de un activo o grupo de activos,
causando pérdida o daño a los mismos.
Componentes del riesgo
- Procesos y/o activos (incluyendo todos los activos de una organización,
físicos, financieros, humanos e intangibles / información).
- Impacto.- magnitud del resultado cuando una amenaza explota una
vulnerabilidad.
- Probabilidad .- combinación de la frecuencia de ocurrencia de la amenaza
(cada cuánto ocurre la amenaza) y la exposición (cada cuánto ocurre la
actividad que contiene la amenaza).
Tipos de Riesgos
- Riesgo inherente .- es una condición que siempre está presente y puede
ocurrir debido a la naturaleza del negocio riesgo.
- Riesgo residual .- permanecen después de que se haya realizado acciones o
implementado controles para reducir el impacto y la probabilidad de un
acontecimiento adverso.
El auditor de SI debe evaluar las fortalezas y debilidades de los controles y
determinar si son efectivos o inefectivos para cumplir los objetivos de control
55
establecidos. A partir de esta definición, se pueden identificar los hallazgos de
vulnerabilidades y determinar el riesgo que éstas implican.
En la Tabla 3.1 se describe algunos ejemplos para mayor claridad a los conceptos
antes mencionados.
Amenaza Vulnerabilidad Riesgo Sustracción de información.
Incorrecta asignación de perfiles. Acceso a Información confidencial por personas no autorizadas.
Indisponibilidad de la aplicación
Ausencia de un proceso de contingencia definido para la aplicación.
Pérdida de servicios que presta la aplicación. Mala imagen ante clientes. Pérdida de clientes.
Inundación Ubicación del Centro de Datos en
el subsuelo en una zona con alto nivel de lluvias.
Pérdida total o parcial del servicio Pérdida de información.
Incendio Sistema de extinción de
incendios sin mantenimiento durante el último año.
Pérdida total del servicio Pérdida de información.
Asalto Falta de capacitación en el manejo de situaciones críticas al personal de seguridad de la entidad.
Pérdida de vidas humanas. Pérdida del servicio Pérdida de información.
Tabla 3. 1 Interrelación: Vulnerabilidad, Amenaza, Riesgo
Fuente: Elaborado por los Autores
3.2.1 MATERIALIDAD DE LOS HALLAZGOS
La materialidad de los hallazgos significa cuales de estos deben presentarse en un
reporte de auditoría, teniendo en cuenta qué información es significativa para los
distintos niveles de gerencia y el efecto en la organización en caso de que no se
realicen las acciones correctivas.
En la Tabla 3.2, se detallan los hallazgos identificados en la aplicación Cajero de
Ventanillas y los riesgos asociados.
56
ACTIVIDADES DE CONTROL
(DEFINIDAS EN BASE A LAS GUÍAS DE
AUDITORÍA DE COBIT 4.1 Y DE LOS
AUTORES)
CONCLUSIÓN HALLAZGOS DE VULNERABILIDADES RIESGOS
2.2. Validar que los usuarios creados en la aplicación son los autorizados y que los ex empleados y personal en período de vacaciones hayan sido desactivados.
Inefectivo La política "Administración de Usuarios" elaborada por el área de Seguridad de la Institución Financiera (IF), indica que: "En ambiente de Producción ningún usuario mantendrá el estado de activo, cuando el empleado propietario del mismo, se encuentre definitivamente separado de la IF", sin embargo, de la revisión a los usuarios que tienen acceso a la aplicación CV, se identificó que existen 7 personas que se encuentran en la lista de ex empleados de la IF y todavía permanecen como usuarios activos de la aplicación que tienen asignados opciones como: "Retiros y Depósitos en cuentas de clientes"
Acceso a transacciones e información confidencial por ex empleados
2.2. Validar que los usuarios creados en la aplicación son los autorizados y que los ex empleados y personal en período de vacaciones hayan sido desactivados.
Inefectivo La política "Administración de Usuarios" elaborada por el área de Seguridad de la IF, indica que: “Se generarán usuarios genéricos únicamente para identificar a los componentes o programas que realizan transacciones de batch, convivencia, entre otros y no para ser usados bajo responsabilidad de los funcionarios de la IF”, sin embargo, se identificaron que existen 25 usuarios genéricos que son utilizados por los Cajeros, para sus labores diarias.
Imposibilidad de detección de usuarios que realizaron transacciones inusuales.
4.2. Identificar los perfiles y usuarios que tengan las transacciones/opciones identificadas como críticas
Inefectivo La política "Definición de Perfiles" elaborada por el área de Seguridad de la Información de la IF, indica que: "Los responsables de las áreas deberán depurar y ratificar al menos una vez al año, los perfiles de su área'', sin embargo, de la revisión efectuada a una muestra de perfiles y transacciones críticas de la aplicación CV bajo la responsabilidad del área Call Center, se identificó a 5 usuarios que por la naturaleza de sus funciones y por el riesgo inherente no deberían tener acceso a dichas opciones por ejemplo: Recaudaciones, Cuadre de la ventanilla, Anular/Reversar. Además, de la revisión efectuada a una muestra de perfiles y transacciones críticas de la aplicación CV bajo la responsabilidad del área Operativa, identificamos opciones asignadas a 20 usuarios que por la naturaleza de sus funciones y por el riesgo inherente no deberían tener acceso a dichas opciones. Por ejemplo: Recaudaciones, Depósitos, Pago de Cheques, Retiros, Configuración de Oficinas
Acceso a información confidencial y ejecución de transacciones críticas por personal que no debería tener asignado dichas transacciones
Tabla 3. 2 Hallazgos de vulnerabilidades Identificados y Riesgos Asociados
Fuente: Elaborado por los Autores
57
ACTIVIDADES DE CONTROL
(DEFINIDAS EN BASE A LAS
GUÍAS DE AUDITORÍA DE COBIT 4.1 Y DE LOS AUTORES)
CONCLUSIÓN HALLAZGOS DE VULNERABILIDADES RIESGOS
6.2. Verificar los controles automatizados implementados para efectuar el registro de los datos
Inefectivo Existe operaciones de pago y depósito que no verifican el nombre y cuenta del cliente al momento de procesar la transacción, por lo que si el cajero de ventanilla digitó de forma incorrecta el número de la cuenta o si estuvo mal la cuenta en la papeleta de pago o depósito, la transacción se registrará con errores. De la revisión a la muestra de transacciones, se identifica que en las siguientes no se realiza la validación mencionada anteriormente: - Pago de tarjetas de crédito - Pago de Corporación que produce cosméticos.
- Procesar transacciones en cuentas incorrecta - Reclamos de los clientes por transacciones incorrectas
6.3. Verificar la existencia de un procedimiento para la modificación de las parametrizaciones del sistema y validar su cumplimiento
Inefectivo La aplicación CV para su adecuado funcionamiento utiliza ciertos parámetros como: montos sobre los cuales se solicita el ruteo para autorización de transacciones, número de retiros permitidos por día, entre otros, en la revisión identificamos que no existe un procedimiento documentado para crear o modificar los parámetros de la aplicación en el que se incluyan los pasos a seguir para realizar cambios a los parámetros, las personas que autorizan, ingresan y revisan los cambios. La aplicación CV no dispone de un log que almacene la información de los cambios a los parámetros, únicamente se cuenta con una tabla en la base de datos donde se encuentran los parámetros vigentes del aplicativo.
Cambios no autorizados a los parámetros de la aplicación Dificultad para detectar oportunamente cambios no autorizados a los parámetros
10.1. Revisar con el área usuaria los errores más comunes en las funcionalidades de la aplicación
Inefectivo En la revisión al reporte de problemas frecuentes, se identifica que existen 30 registros de problemas que se presentan con recurrencia en la aplicación CV y que fueron reportados en el primer trimestre del año 2012 por el área de tecnología de la entidad, estos son: - Servicios no disponibles en la aplicación - La aplicación no se encuentra disponible o presenta lentitud
Pérdida de la imagen de la IF ante sus clientes, por indisponibilidad de los servicios que ofrece la aplicación
Continuación Tabla 3. 2 Hallazgos de vulnerabilidades Identificados y Riesgos Asociados
58
ACTIVIDADES DE CONTROL (DEFINIDAS EN BASE A
LAS GUÍAS DE AUDITORÍA DE
COBIT 4.1 Y DE LOS
AUTORES)
CONCLUSIÓN HALLAZGOS DE VULNERABILIDADES RIESGOS
12.3. Identificar a qué niveles se reporta la información encontrada en los logs de la aplicación
Inefectivo La aplicación CV tiene activado un log en el que se registra información de las transacciones que realiza el cliente. Este log no es monitoreado periódicamente, consecuentemente no se informa las novedades registradas. Mediante la revisión periódica de estos logs podrían identificarse actividades sospechosas, por ejemplo intentos de acceso fallidos por repetidas ocasiones, transacciones seguidas por montos elevados, entre otros.
No identificación de transacciones inusuales
14.1. Verificar la existencia de procedimientos de contingencia tecnológica, operativa y su adecuada aplicación
Inefectivo La norma "JB-2005 834 Gestión de Riesgo Operativo" de la Superintendencia de Bancos y Seguros del Ecuador 4(SBS) indica que: “Todas las instituciones controladas deberán contar con procedimientos de contingencia debidamente probados. Además, los planes de contingencia deben incluir un cronograma y procedimientos de prueba y mantenimiento del plan. Se identificó que no se han realizado pruebas formales del plan de contingencia en caso de fallas en los servidores de la aplicación para garantizar la efectividad y el correcto funcionamiento del mismo.”
- Interrupción o paralización de los procesos que operan con la aplicación. - Sanciones de la entidad de control por incumplimiento de la norma
Continuación Tabla 3. 2 Hallazgos de vulnerabilidades Identificados y Riesgos Asociados
3.2.2EVALUACIÓN DE RIESGOS
Una vez que los riesgos han sido identificados es necesario valorarlos, para ello se
requiere la determinación y cálculo de los criterios de análisis de riesgo para lo cual
se puede utilizar dos métodos usados frecuentemente, estos son:
- Método cualitativo .- Son clasificaciones sencillas de significancia del riesgo
que pueden ser alto, medio ó bajo, con base en el juicio profesional del auditor
4Entidad que regula y supervisa en el Ecuador el sistema financiero, de seguros privados y de seguridad social.
59
de SI y del conocimiento del negocio. Son los más sencillos y más
comúnmente utilizados.
- Método Cuantitativo .- Usan valores numéricos o letras para describir la
significancia del riesgo en base al impacto y la probabilidad de ocurrencia de
los mismos.
Significancia del riesgo, es el grado o nivel de afectación (alto, medio o bajo) que podría
tener un riesgo en la consecución de un objetivo para la efectividad de las operaciones,
confiabilidad de la información o cumplimiento. Tabla 3. 3 Definición de Significancia de Riesgo
Fuente: Elaborado por los Autores
Para realizar el análisis y la valoración del riesgo se utilizará el Método Cuantitativo,
en el cual es necesario elaborar las escalas de probabilidad e impacto. Esto con la
finalidad de obtener una calificación del riesgo.
Para el presente trabajo se utilizará una matriz de modelo estándar para análisis de
riesgo, que puede ser utilizada para cualquier organización en la cual se esté
realizando auditoría a sus aplicaciones o procesos de negocio.
60
Tabla 3. 4 Modelo Estándar para análisis de Riesgo.
Fuente: Instituto de Auditores Internos – Auditoría Basada en Riesgos
MODELO PARA ANÁLISIS DE RIESGO ESTANDAR PARA UNA OR GANIZACIÓN Probabilidad de que algo salga mal
Im
pact
o de
l rie
sgo
Categoría
Improbable No es probable que
suceda.
Rara vez No es probable
que suceda pero es posible.
Ocasional Puede suceder algunas veces.
Probable Bastante
probable que suceda alguna
vez.
Frecuente Probable que suceda
inmediatamente o en un breve período de tiempo.
CATASTRÓFICO Puede ocasionar la suspensión del negocio por un tiempo extendido o su desaparición.
M A A E E
CRÍTICO Puede ocasionar daños personales graves, daños materiales importantes, pérdida financiera considerable y/o publicidad negativa para la organización.
B M A A E
MARGINAL Puede ocasionar daños personales menores, daños materiales, pérdida financiera y/o publicidad negativa para la organización.
B B M M A
INSIGNIFICANTE El peligro representa una amenaza mínima a la seguridad y normal funcionamiento de la organización.
B B B B M
E
Riesgo extremadamente alto
Las actividades de esta categoría contienen niveles de riesgo inaceptables, incluida la posibilidad de daños catastróficos y críticos. Las empresas deben considerar la posibilidad de eliminar o modificar las actividades que tienen una calificación "E" luego de aplicar todas las estrategias de gestión de riesgo razonables.
A
Riesgo alto Las actividades de esta categoría contienen riesgos potencialmente graves que, probablemente, pueden suceder. Se aconseja aplicar estrategias proactivas de gestión de riesgos para reducir el riesgo. Las empresas deben considerar la manera de modificar o eliminar los riesgos inaceptables.
M Riesgo moderado Las actividades de esta categoría contienen algún nivel de riesgo que probablemente no suceda. Las empresas deben considerar qué se podría hacer para gestionar el riesgo y evitar resultados negativos.
B Riesgo bajo Las actividades de esta categoría contienen un riesgo mínimo que probablemente no suceda. Las empresas pueden continuar con estas actividades de acuerdo con lo planificado.
61
En la Tabla 3.5 se muestra la significancia de los riesgos en base al impacto y la
probabilidad de las vulnerabilidades halladas durante la auditoría de la aplicación,
para ello se utilizará la información descrita en las Tablas 3.2 y 3.4.
Hallazgo de las vulnerabilidades Riesgo Impacto Probabilidad Significancia
La política "Administración de Usuarios" elaborada por el área de Seguridad de la IF, indica que: "En ambiente de Producción ningún usuario mantendrá el estado de activo, cuando el empleado propietario del mismo, se encuentre definitivamente separado de la Institución Financiera (IF)", sin embargo, de la revisión a los usuarios que tienen acceso a la aplicación CV, se identificó que existen 7 personas que se encuentran en la lista de ex empleados de la IF y todavía permanecen como usuarios activos de la aplicación que tienen asignados opciones como: "Retiros y Depósitos en cuentas de clientes"
Acceso a transacciones e información confidencial por ex empleados
Crítico
Ocasional
Alto
La política "Administración de Usuarios" elaborada por el área de Seguridad de la IF, indica que: “Se generarán usuarios genéricos únicamente para identificar a los componentes o programas que realizan transacciones de batch, convivencia, entre otros y no para ser usados bajo responsabilidad de los funcionarios de la IF”, sin embargo, se identificaron que existen 25 usuarios genéricos que son utilizados por los Cajeros, para sus labores diarias.
Imposibilidad de detección de usuarios que realizaron transacciones inusuales.
Crítico
Rara vez
Moderado
Tabla 3. 5 Análisis y Evaluación de Riesgos
Fuente: Elaborado por los Autores
62
Hallazgo de las vulnerabilidades Riesgo Impacto Probabilidad Significancia
La política "Definición de Perfiles" elaborada por el área de Seguridad de la Información de la IF, indica que: "Los responsables de las áreas deberán depurar y ratificar al menos una vez al año, los perfiles de su área'', sin embargo, de la revisión efectuada a una muestra de perfiles y transacciones críticas de la aplicación CV bajo la responsabilidad del área Call Center, se identificó a 5 usuarios que por la naturaleza de sus funciones y por el riesgo inherente no deberían tener acceso a dichas opciones por ejemplo: Recaudaciones, Cuadre de la ventanilla, Anular/Reversar
Acceso a información confidencial y ejecución de transacciones críticas por personal que no debería tener asignado dichas transacciones
Crítico
Rara vez
Moderado
La política "Definición de Perfiles", menciona que "Los responsables de las áreas deberán depurar y ratificar al menos una vez al año, los perfiles de su área'', sin embargo, de la revisión efectuada a una muestra de perfiles y transacciones críticas de la aplicación CV bajo la responsabilidad del área Operativa, identificamos opciones asignadas a 20 usuarios que por la naturaleza de sus funciones y por el riesgo inherente no deberían tener acceso a dichas opciones. Por ejemplo: Recaudaciones, Depósitos, Pago de Cheques, Retiros, Configuración de Oficinas
Acceso a información confidencial y ejecución de transacciones críticas por personal que no debería tener asignado dichas transacciones
Crítico
Rara vez
Moderado
Continuación Tabla 3.5 Análisis y Evaluación de Riesgos
63
Hallazgo de las vulnerabilidades Riesgo Impacto Probabilidad Significancia
Existe operaciones de pago y depósito que no verifican el nombre y cuenta del cliente al momento de procesar la transacción, por lo que si el cajero de ventanilla digitó de forma incorrecta el número de la cuenta o si estuvo mal la cuenta en la papeleta de pago o depósito, la transacción se registrará con errores. De la revisión a la muestra de transacciones, se identifica que en las siguientes no se realiza la validación mencionada anteriormente: - Pago de tarjetas de crédito - Pago de Corporación que produce cosméticos.
- Procesar transacciones en cuentas incorrectas - Reclamos de los clientes por transacciones incorrectas
Crítico
Ocasional
Alto
La aplicación CV para su adecuado funcionamiento utiliza parámetros como: montos sobre los cuales se solicita el ruteo para autorización de transacciones, número de retiros permitidos por día, entre otros, en la revisión se identifica que no existe un procedimiento documentado para crear o modificar los parámetros de la aplicación en el que se incluyan los pasos a seguir para realizar cambios a los parámetros, las personas que autorizan, ingresan y revisan los cambios.
Cambios no autorizados a los parámetros de la aplicación
Crítico
Rara vez
Moderado
La aplicación CV no dispone de un log que almacene la información de los cambios a los parámetros, únicamente se cuenta con una tabla en la base de datos donde se encuentran los parámetros vigentes del aplicativo.
Dificultad para detectar oportunamente cambios no autorizados a los parámetros
Marginal Probable Moderado
Continuación Tabla 3.5 Análisis y Evaluación de Riesgos
64
Hallazgo de las vulnerabilidades Riesgo Impacto Probabilidad Significancia
En la revisión al reporte de problemas frecuentes, se identifica que existen 30 registros de problemas que se presentan con recurrencia en la aplicación CV y que fueron reportados en el primer trimestre del año 2012 por el área de tecnología de la entidad, estos son: - Servicios no disponibles en la aplicación - La aplicación no se encuentra disponible o presenta lentitud
Pérdida de la imagen de la IF ante sus clientes, por indisponibilidad de los servicios que ofrece la aplicación
Crítico Ocasional Alto
La aplicación CV tiene activado un log en el que se registra información de las transacciones que realiza el cliente. Este log no es monitoreado periódicamente, consecuentemente no se informa las novedades registradas.
No identificación de transacciones inusuales
Marginal Probable Moderado
La norma "JB-2005 834 Gestión de Riesgo Operativo" de la Superintendencia de Bancos y Seguros del Ecuador (SBS) indica que: “Todas las instituciones controladas deberán contar con procedimientos de contingencia debidamente probados. Además, los planes de contingencia deben incluir un cronograma y procedimientos de prueba y mantenimiento del plan. Se identificó que no se han realizado pruebas formales del plan de contingencia en caso de fallas en los servidores de la aplicación para garantizar la efectividad y el correcto funcionamiento del mismo.”
Interrupción o paralización de los procesos que operan con la aplicación Sanciones de la entidad de control por incumplimiento de la norma
Crítico
Probable
Alto
Continuación Tabla 3.5 Análisis y Evaluación de Riesgos
65
3.3. ELABORACIÓN DEL INFORME FINAL
Previo al informe final de auditoría, se debe elaborar el borrador del mismo, que
contendrá los resultados obtenidos en el proceso de auditoría, los cuales serán
comunicados a los representantes de la entidad auditada e involucrado en el
proceso. Posterior a la revisión de este documento el mismo constituirá como base
para la elaboración del informe final de auditoría.
Según el Manual de Preparación al Examen CISA 2011, los informes de auditoría
son el producto final del trabajo de auditoría de SI. Son usados por el auditor de SI
para reportar a la gerencia sus hallazgos y recomendaciones .
De acuerdo al concepto anterior, el informe final es el resultado del proceso de
auditoría, en el cual el auditor describe a los niveles de gerencia de la entidad, los
hallazgos identificados en base a los controles inefectivos y las recomendaciones
para mitigar los riesgos asociados. No se incluirá en el informe criterios sobre los
controles efectivos.
No existe un formato exacto de un informe de auditoría, varía en cada organización
dependiendo de las políticas y procedimientos utilizados. Sin embargo un patrón
común de informe tiene la siguiente estructura y contenido:
- Identificación del informe .- Nombre identificativo.
- Identificación del cliente .- Destinatarios y personas que solicitan la auditoría.
- Identificación de la entidad auditada. - Organización/entidad/área objeto de
la auditoria.
- Normativa aplicada .- Identificar las normas legales y profesionales. Ejemplo:
COBIT 4.1, ISO 27002, entre otros.
66
- Alcance de la auditoria .- Naturaleza y extensión del trabajo.
- Periodo de la auditoria .- Definir las fechas en las cuales se inicia y termina la
auditoría.
- Limitaciones al alcance .- Detallar lo que no se realizará en la auditoría,
ejemplo: No se auditará los controles de procesamiento batch.
- Informe – Resultados – Dictamen – Opiniones y Párra fos de salvedades
en caso de ser necesarios. Se deben colocar todas las observaciones
agrupadas por objetivos principales y sus respectivas recomendaciones
resumidas, además, por cada objetivo se debe emitir una opinión.
- Respuestas del auditado .- Acciones que se van a tomar para cubrir o mitigar
los riesgos identificados.
- Plazo de implementación .- El auditado debe otorgar el plazo y las acciones
necesarias para cubrir las recomendaciones emitidas.
A continuación se presenta el informe final de la aplicación CV, en base a la
información descrita en la Tabla 3.5
67
INFORME DE AUDITORÍA DE LA APLICACIÓN CAJERO DE VEN TANILLA
Identificación del informe
01-2012-ACV Aplicación Cajero de Ventanillas
Entidad:
Institución Financiera
Aplicación Auditada Cajero de Ventanillas
Normativa utilizada
Directrices del Marco de Trabajo COBIT 4.1.
Alcance
La auditoría cubre la verificación de los siguientes controles y seguridades dela
aplicación Cajero de Ventanilla:
- Revisión de los usuarios que tienen asignado en los perfiles, transacciones
definidas como críticas.
- Verificación de los parámetros de seguridad de la contraseña de acceso.
- Verificación de controles para evitar errores o duplicación en el registro de la
información de las opciones críticas: ingreso y aprobación de transacciones,
cierre de caja, cuadres y parametrización.
- Revisión y análisis de pistas de auditoría.
- Validación de usuarios, roles y privilegios en la base de datos de la aplicación.
- Revisión del esquema de respaldos y plan de contingencia.
Periodo de la auditoría
El proceso de auditoría se realizó en el segundo trimestre del año 2012.
Limitaciones al alcance
No se presentaron limitaciones en el alcance de la auditoría.
68
Resultados
Los resultados detallados a continuación han sido desarrollados en base a los
hallazgos identificados.
Revisión de la administración de usuarios y perfile s
Se debe realizar las siguientes actividades:
- Revisión del listado de usuarios activos en la aplicación, con los perfiles y
opciones asignadas.
- Revisión de las siguientes políticas: Administración de Usuarios, Definición de
Perfiles.
- Revisión del procedimiento: Manual de Procedimientos de Mantenimiento de
Usuarios, entregados por el Departamento de Seguridad de la Información.
Observación No. 1. Usuarios correspondientes a ex empleados activos en la aplicación.
La política "Administración de Usuarios" elaborada por el área de Seguridad de la IF, indica que: "En ambiente de Producción ningún usuario mantendrá el estado de activo, cuando el empleado propietario del mismo, se encuentre definitivamente separado de la Institución Financiera (IF)", sin embargo, de la revisión a los usuarios que tienen acceso a la aplicación CV, se identificó que existen 7 personas que se encuentran en la lista de ex empleados de la IF y todavía permanecen como usuarios activos de la aplicación que tienen asignados opciones como: "Retiros y Depósitos en cuentas de clientes"
Riesgo: Acceso a transacciones e información confidencial por ex empleados.
Nivel de Riesgo: Alto. Recomendaciones: Eliminar inmediatamente a los usuarios correspondientes a ex
empleados de todos los aplicativos a los cuales tengan acceso. Cumplir con la política de "Administración de Usuarios" en lo referente a la eliminación de los usuarios correspondientes a ex empleados.
Área Responsable: Seguridad de la Información de la IF. Comentarios del auditado:
Se procederá a la eliminación de los accesos de los ex empleados
Fecha de implementación acordada:
Septiembre 30, 2012
Tabla 3. 6 Análisis de la Observación 1 - Usuarios : ex - empleados
Fuente: Elaborado por los autores
69
Observación No. 2 Uso de usuarios genéricos en ambiente de producción
La política "Administración de Usuarios" elaborada por el área de Seguridad de la IF, indica que: “Se generarán usuarios genéricos únicamente para identificar a los componentes o programas que realizan transacciones de batch, convivencia, entre otros y no para ser usados bajo responsabilidad de los funcionarios de la IF”, sin embargo, se identificaron que existen 25 usuarios genéricos que son utilizados por los Cajeros, para sus labores diarias.
Riesgo: Dificultad para identificar quién ejecutó posibles transacciones inusuales.
Nivel de Riesgo : Moderado
Recomendaciones:
Analizar inmediatamente el uso de los usuarios genéricos por parte de los empleados de la IF y considerar la posibilidad de proceder a eliminar dichos usuarios.
Área Responsable : Seguridad de la Información IF
Comentarios del auditado:
Se procederá a realizar un análisis de los usuarios genéricos utilizados y del resultado de este análisis se procederá no a la eliminación de los mismos.
Fecha de implementación acordada:
Diciembre 31, 2012
Tabla 3. 7 Análisis Observación 2 - Uso de usuarios genéricos
Fuente: Elaborado por los autores.
Observación No. 3
Usuarios sin depurar Call Center
La política "Definición de Perfiles" elaborada por el área de Seguridad de la Información de la IF, indica que: "Los responsables de las áreas deberán depurar y ratificar al menos una vez al año, los perfiles de su área'', sin embargo, de la revisión efectuada a una muestra de perfiles y transacciones críticas de la aplicación CV bajo la responsabilidad del área Call Center, se identificó a 5 usuarios que por la naturaleza de sus funciones y por el riesgo inherente no deberían tener acceso a dichas opciones por ejemplo: Recaudaciones, Cuadre de la ventanilla, Anular/Reversar.
Riesgo :
Acceso a información confidencial y ejecución de transacciones críticas por personal que no debería tener asignado dichas transacciones.
Nivel de Riesgo: Moderado
70
Recomendaciones:
Solicitar al área de Seguridad de la Información de la IF la eliminación de las opciones de la aplicación CV de los usuarios que por la naturaleza de sus funciones no deberían tener acceso a dichas opciones
Área Responsable : Call Center IF Comentarios del auditado:
Se procederá a eliminar las opciones de los perfiles y de ser el caso se procederá a eliminar los usuarios que no deban acceder a dichas opciones
Fecha de implementación acordada:
Noviembre 30, 2012
Tabla 3. 8 Análisis Observación 3 - Usuarios sin depurar Call Center.
Fuente: Elaborado por los autores.
Observación No.4 Usuarios sin depurar área Operativa
La política "Definición de Perfiles", menciona que "Los responsables de las áreas deberán depurar y ratificar al menos una vez al año, los perfiles de su área'', sin embargo, de la revisión efectuada a una muestra de perfiles y transacciones críticas de la aplicación CV bajo la responsabilidad del área Operativa, identificamos opciones asignadas a 20 usuarios que por la naturaleza de sus funciones y por el riesgo inherente no deberían tener acceso a dichas opciones. Así por ejemplo tenemos: Recaudaciones, Depósitos, Pago de Cheques, Retiros, Configuración de Oficinas
Riesgo:
Acceso a información confidencial y ejecución de transacciones críticas por personal que no debería tener asignado dichas transacciones.
Nivel de Riesgo: Moderado Recomendación:
Solicitar al área de Seguridad de la Información de la IF la eliminación de las opciones de la aplicación CV de los usuarios que por la naturaleza de sus funciones no deberían tener acceso a dichas opciones.
Área Responsable : Área Operativa IF. Comentarios del auditado:
Se solicitará la eliminación de las opciones de la aplicación de los usuarios que no requieren tener acceso.
Fecha de implementación acordada :
Diciembre 31, 2012
Tabla 3. 9Análisis Observación 1- Usuarios sin depurar área operativa.
Fuente: Elaborado por los autores
71
Revisión de los controles implementados en el ingre so de datos
Se debe realizar las siguientes actividades:
- Pruebas con los usuarios de la aplicación Cajero de Ventanilla.
- Pruebas para verificar los controles implementados para efectuar el correcto
registro de los datos.
- Verificación de la existencia de parámetros ingresados en la aplicación y su
administración de acuerdo a las políticas establecida por la IF para ello.
Observación No.5. Transacciones sin validación previa.
Existe operaciones de pago y depósito que no verifican el nombre y cuenta del cliente al momento de procesar la transacción, por lo que si el cajero de ventanilla digitó de forma incorrecta el número de la cuenta o si estuvo mal la cuenta en la papeleta de pago o depósito, la transacción se registrará con errores. De la revisión a la muestra de transacciones, se identifica que en las siguientes no se realiza la validación mencionada anteriormente: -Pago de tarjetas de crédito -Pago de Corporación que produce cosméticos.
Riesgos
- Procesar transacciones en cuentas incorrectas. - Reclamos de los clientes por transacciones incorrectas.
Nivel de Riesgo: Alto. Recomendaciones:
Solicitar al área de Tecnología de la IF realice los cambios en la aplicación CV para que el cajero de ventanilla pueda validar la cuenta y datos del cliente antes de procesar la transacciones, en la muestra se identificaron las siguientes transacciones: - Pago de tarjetas de crédito -Pago de Corporación que produce cosméticos.
Área Responsable Área Operativa IF
Comentarios del auditado:
Se generó un proyecto para mejoras del aplicativo, en el cuál se incluirán estas validaciones.
Fecha de implementación acordada:
Marzo 31, 2013
Tabla 3. 10 Análisis Observación 5- Transacciones sin validación previa.
Fuente: Elaborado por los autores
72
Revisión de los parámetros y logs de auditoría Se realizaron pruebas con los usuarios de la aplicación Cajero de Ventanilla.
Observación No.6 Procedimiento para parametrización, no documentado.
La aplicación CV para su adecuado funcionamiento utiliza ciertos parámetros como: montos sobre los cuales se solicita el ruteo para autorización de transacciones, número de retiros permitidos por día, entre otros, en la revisión se identifica que no existe un procedimiento documentado para crear o modificar los parámetros de la aplicación en el que se incluyan los pasos a seguir para realizar cambios a los parámetros, las personas que autorizan, ingresan y revisan los cambios.
Riesgo :
Cambios no autorizados a los parámetros de la aplicación.
Nivel de Riesgo: Moderado. Recomendaciones :
Definir, aprobar y difundir un procedimiento para la modificación de los parámetros de la aplicación CV de la IF que incluya lo siguiente: - Pasos a seguir para realizar cambios en los parámetros - Responsables que autorizan, ingresan y revisan los cambios para verificar que no se hayan realizado cambios no autorizados.
Área responsable: Área Operativa IF. Comentarios del auditado:
Se elaborará un procedimiento para la modificación de parámetros de la aplicación.
Fecha de implementación acordada:
Diciembre 31, 2012
Tabla 3. 11 Análisis Observación 6 - Procedimientos para parametrización, no documentado
Fuente: Elaborado por los autores
Evaluación de los logs de auditoría de la aplicació n
Se debe realizar las siguientes actividades:
- Revisión de la existencia de logs de auditoría para las principales
transacciones de la aplicación.
- Validación de la existencia de revisiones periódicas de estos logs.
73
Observación No.7 Aplicación sin log de parametrización.
La aplicación CV no dispone de un log que almacene la información de los cambios a los parámetros, únicamente se cuenta con una tabla en la base de datos donde se encuentran los parámetros vigentes del aplicativo.
Riesgo
Dificultad para detectar oportunamente cambios no autorizados a los parámetros
Nivel de Riesgo Moderado
Recomendaciones Solicitar al área de Tecnología de la IF la implementación de un log que almacene la transacción mediante la cual se realizaron las modificaciones a los parámetros de la aplicación CV - Realizar una revisión periódica a estos logs dejando las respectivas evidencias
Área Responsable Área Operativa
Comentarios del auditado:
Se solicitará al área Tecnología de la IF la implementación de un log que registre los cambios a los parámetros del aplicativo.
Fecha de implementación acordada
Diciembre 31, 2012
Tabla 3. 12 Análisis Observación 8 – Aplicación sin log de parametrización
Fuente: Elaborado por los autores
74
Observación No.8 Falta de revisión de logs
La aplicación CV tiene activado un log en el que se registra información de las transacciones que realiza el cliente. Este log no es monitoreado periódicamente, consecuentemente no se informa las novedades registradas
Riesgo
No identificación de transacciones inusuales
Nivel de Riesgo
Moderado
Recomendaciones : Realizar una revisión periódica a estos logs y registrar las respectivas evidencias de los eventos encontrados.
Área/Responsable : Área Operativa
Comentarios del auditado:
Se realizarán las revisiones de log transaccional de la aplicación cuando haya algún reclamo de los clientes o requerimiento oficial que involucre información mayor a los 15 días. Se realizará una primera revisión en el mes de octubre del 2012
Fecha de implementación acordada :
Octubre 31, 2012
Tabla 3. 13 Análisis Observación 8 - Falta de revisión de logs.
Fuente: Elaborado por los autores
Revisión de errores y necesidades en la funcionalid ad de la aplicación
Se debe realizar las siguientes actividades:
- Revisión de los reportes de problemas frecuentes presentados en la
aplicación.
- Verificación de que las soluciones presentadas para corregir los problemas
eran las efectivas.
75
Observación No.9 Problemas frecuentes de la aplicación
En la revisión al reporte de problemas frecuentes, se identifica que existen 30 registros de problemas que se presentan con recurrencia en la aplicación CV y que fueron reportados en el primer trimestre del año 2012 por el área de tecnología de la entidad, estos son: -Servicios no disponibles en la aplicación -La aplicación no se encuentra disponible o presenta lentitud
Riesgo
Pérdida de la imagen de la IF ante sus clientes, por indisponibilidad de los servicios que ofrece la aplicación
Nivel de Riesgo
Alto
Recomendaciones -
Realizar un análisis de los problemas frecuentes presentados, definir e implementar las acciones correctivas para evitar que estos problemas se sigan presentando
Área/Responsable Área de Tecnología IF Comentarios del auditado:
Se propondrá un proyecto para corregir los errores frecuentes presentados en la aplicación.
Fecha de implementación acordada
Diciembre 31, 2012
Tabla 3. 14 Análisis Observación 9 - Problemas frecuentes de la aplicación.
Fuente: Elaborado por los autores
Revisión de las contingencias
Se debe realizar las siguientes actividades:
- Revisión de los planes de contingencia tecnológicos y operativos definidos en
caso de pérdidas del servicio de la aplicación.
- Verificación si los planes de contingencia definidos son los adecuados y van
de acuerdo a las necesidades del negocio
- Verificación si los planes son probados de forma continua y si los resultados
son documentados.
76
Observación No.10 Planes de contingencia no probados
La norma "JB-2005 834 Gestión de Riesgo Operativo" de la Superintendencia de Bancos y Seguros del Ecuador (SBS) indica que: “Todas las instituciones controladas deberán contar con procedimientos de contingencia debidamente probados. Además, los planes de contingencia deben incluir un cronograma y procedimientos de prueba y mantenimiento del plan. Se identificó que no se han realizado pruebas formales del plan de contingencia en caso de fallas en los servidores de la aplicación para garantizar la efectividad y el correcto funcionamiento del mismo.”
Riesgos :
- Interrupción o paralización de los procesos que operan con la aplicación - Sanciones de la entidad de control por incumplimiento de la norma.
Nivel de Riesgo:
Alto
Recomendaciones:
Realizar pruebas del procedimiento de contingencia definido para el aplicativo CV, documentarlas y preparar informes con los resultados de las pruebas
Área/Responsable: Área de Tecnología IF
Comentarios del auditado:
Se realizará un análisis de los recursos necesarios para la ejecución de las pruebas al plan de contingencia, con el resultado de este análisis se procederá a la realización o no de las pruebas.
Fecha de implementación acordada :
Diciembre 31, 2012
Tabla 3. 15 Análisis Observación 10 - Planes de contingencia no probados
Fuente: Elaborado por los autores
77
En la siguiente tabla se resume la procedencia de cada una de las
observaciones descritas en el informe final de acuerdo al proceso de auditoría
realizado y que se detalla en el Anexo 4: Relevamiento y Ejecución de la
Auditoría.xlsx
Número de
Observación
Nombre de la Observación Directriz de COBIT
4.1
Objetivo de Control
detallado de COBIT
4.1
1 Usuarios correspondientes a ex empleados activos en la aplicación.
DS5 Garantizar la
Seguridad de los
Sistemas
DS5.3 Gestión de
Identidad.
DS5.4 Gestión de
cuentas de usuario
2 Uso de usuarios genéricos en
ambiente de producción
DS5 Garantizar la
Seguridad de los
Sistemas
DS5.3 Gestión de
Identidad.
DS5.4 Gestión de
cuentas de usuario
3
Usuarios sin depurar Call Center
DS5 Garantizar la
Seguridad de los
Sistemas
DS5.3 Gestión de
Identidad.
4 Usuarios sin depurar área
Operativa
DS5 Garantizar la
Seguridad de los
Sistemas
DS5.3 Gestión de
Identidad.
5 Transacciones sin validación previa.
AC2 Recolección y
entrada de
información fuente
AC3 Verificaciones
de exactitud,
totalidad y
autenticidad
AC2 Recolección y
entrada de
información fuente
AC3 Verificaciones
de exactitud,
totalidad y
autenticidad
6 Procedimiento para
parametrización, no
documentado.
AC2 Recolección y
entrada de
información fuente
AC2 Recolección y
entrada de
información fuente
78
AC3 Verificaciones
de exactitud,
totalidad y
autenticidad
AC3 Verificaciones
de exactitud,
totalidad y
autenticidad
7 Aplicación sin log de parametrización.
AC2 Recolección y
entrada de
información fuente
AC3 Verificaciones
de exactitud,
totalidad y
autenticidad
AC2 Recolección y
entrada de
información fuente
AC3 Verificaciones
de exactitud,
totalidad y
autenticidad
8 Falta de revisión de logs
AI2 Adquirir y
mantener software
aplicativo
AI 2.3 Control y
auditabilidad de las
aplicaciones
9 Problemas frecuentes de la aplicación
DS10 Gestionar
Problemas
DS 10.1
Identificación y
clasificación de
problemas
10 Planes de contingencia no probados
DS3 Gestionar el
desempeño y la
capacidad
DS4 Garantizar la
continuidad del
servicio
DS3.4 Disponibilidad
de recursos de TI
DS4.2 Planes de
continuidad de TI
DS4.4
Mantenimiento del
plan de continuidad
de TI
DS4.8 Recuperación
y reanudación de los
servicios de TI.
Tabla 3. 16 Procedencia de las Observaciones del Informe Final
Fuente: Elaborado por los autores
79
CAPITULO 4: CONCLUSIONES Y RECOMENDACIONES
4.1. CONCLUSIONES
- Para el desarrollo del presente trabajo fue importante la utilización del marco
de referencia COBIT4.1, que permitió evaluar los controles de la aplicación
informática, utilizada como caso de estudio en la institución financiera, con el
objetivo de ayudar a que la aplicación informática esté alineada con los
objetivos del negocio.
- Cada auditor debe ajustar los objetivos de control propuestos a la realidad de
la empresa y de la aplicación informática que se va auditar. No existe un
estándar al cual se deba regir de forma obligatoria para la ejecución de una
auditoría.
- Para la ejecución del presente trabajo fue necesario realizar varias tareas y
actividades de revisión en la institución financiera, que sustenten las
observaciones identificadas y el análisis del presente trabajo; Éstas se
detallan en el Anexo 5: Documentos Ejecución Auditoría de la Aplicación
Cajero de Ventanillas.
- Si durante la ejecución de la auditoría, el Auditor de Sistemas de Información
identifica que un control está mal diseñado, incompleto, mal implementado o
simplemente no existe, éste puede decidir incluir algunas pruebas que
permitan fundamentar la integridad del procesamiento de información, estas
pruebas son las llamadas “pruebas sustantivas”.
- En la ejecución de una Auditoría de Aplicaciones Informáticas, se debe poner
énfasis en la revisión de los usuarios internos y sus opciones asignadas a
través de los perfiles de acceso, la incorrecta asignación de éstos, es a
menudo una causa principal de problemas a nivel interno en las entidades.
80
- Durante la ejecución de la auditoría, el auditor de Sistemas de Información en
base a las pruebas realizadas en cada objetivo de control, determina si un
control es efectivo o inefectivo, en base a este último se determina los
hallazgos de vulnerabilidades que se incluirán en el informe de auditoría.
- En el informe de auditoría se reportan los hallazgos de vulnerabilidades con la
finalidad de emitir las recomendaciones necesarias para la mitigación de los
riesgos que éstas pueden presentar. Además, se pueden incluir comentarios
constructivos sobre procesos y controles efectivos y existentes.
- El informe de auditoría debe contener las respuestas y plazos de cumplimiento
dados por los representantes e involucrados de la entidad auditada, a las
recomendaciones emitidas para mitigar los riesgos de los hallazgos de
vulnerabilidades, caso contrario los riesgos identificados deben ser asumidos
por la gerencia de la entidad auditada.
- En la ejecución de la auditoría se han encontrado 10 hallazgos de los cuales
el 40 % (4) tienen asociados riesgos de significancia Alto y el 60 % (6) de
riesgo Moderado, esta información debe ser transmitida a la gerencia de la
institución financiera para su gestión en la elaboración de planes de acción
para mitigar los hallazgos de vulnerabilidades que generan mayor riesgo a la
institución.
81
4.2. RECOMENDACIONES
- El análisis realizado en el presente trabajo puede ser utilizado como base para
la auditoría de aplicaciones informáticas. Además, se puede incluir otras
directrices como las mencionadas en el Anexo 2: Interrelación de los Marcos
de Trabajo COBIT-ITIL-ISO27002 y propias de COBIT 4.1.
- Se debe tomar en cuenta el conocimiento de la organización, del proceso o de
la aplicación objeto de la auditoría, con el fin de definir de forma correcta el
programa de auditoría y establecer el tiempo que tomará la ejecución de la
misma.
- Definir de forma correcta el alcance de la auditoría, es un factor importante
para el cumplimento de la misma, pues en esta fase se identifican las
directrices de su realización.
- Se recomienda tomar en cuenta variables como el tamaño de la organización,
la cantidad de procesos a evaluar, la metodología a utilizar, conformación del
equipo auditor, entre otros, para que el resultado de la planificación sea
adecuada.
- Se debe recopilar la evidencia necesaria que justifique las novedades o
hallazgos identificados en la auditoría, sin esta evidencia, una condición
reportable u observación puede ser eliminada del informe final.
- Se debe presentar claramente los hallazgos de vulnerabilidades y los riesgos
que implican para la entidad, de tal manera que la entidad auditada asuma las
propuestas para implantar las recomendaciones como objetivos de la
organización.
82
- No se debe ignorar las debilidades de control solo porque éstas se encuentren
fuera del alcance de una revisión, si existen debilidades que el auditor ha
identificado, éstas deben ser reportadas e informadas.
- La entidad auditada debe prestar atención a los riesgos identificados, para
implementar las recomendaciones emitidas en el proceso de auditoría con la
finalidad de prevenir a la organización posibles intentos de fraude y colusión
utilizando la aplicación.
- En el proceso de auditoría, los auditores deben actuar con escepticismo
profesional y centrarse en torno a verificar la eficacia de los controles
implementados ya que la probabilidad de descubrir posibles actividades
fraudulentas aumentan; Dudar de todo hasta que demuestren lo contrario.
- Los hallazgos de vulnerabilidades de significancia BAJA pueden ser incluidos
en el informe de auditoría, no como una observación sino como una
oportunidad de mejora, o ser presentados de forma independiente a través de
un memorando.
- Se puede recomendar a la gerencia de la entidad auditada el definir un
periodo de tiempo posterior a la emisión del informe de auditoría, para realizar
la verificación al cumplimiento de las acciones correctivas acordadas por las
áreas auditadas.
- Se debe emitir recomendaciones que sean realistas y de acuerdo a los
requerimientos de la entidad auditada.
83
BIBLIOGRAFÍA
AGERS. (s.f.). Guía ISO/CEI 73. Recuperado el Julio de 2012, de Asociación Española, Gerencia de Riesgos y Seguros: http://www.agers.es/pdf/noticiasinteres/Guia_ISO-CEI_73.pdf BANDA, H. A., & CARRILLO, P. (Octubre de 2011). Curso COBIT 4.1. BETANZOS Rodriguez, A. I. (Diciembre de 2011). Auditoría y Control de Sistemas de Información en Tecnología. Recuperado el Enero de 2012, de http://www.gestiopolis.com/finanzas-contaduria-2/auditoria-control-sistemas-de-informacion-en-tecnologia.htm CRESPO, A. (Julio de 2008). ITIL V3- la versión más estratégica de este código de buenas prácticas. Recuperado el Febrero de 2012, de http://www.techweek.es/estandares/informes/1003446002901/itil-v3-version-mas-estrategica.1.html ERB, M. (s.f.). Gestión de Riesgo en la Seguridad Informática. Recuperado el Julio de 2012, de http://protejete.wordpress.com/gdr_principal/amenazas_vulnerabilidades/ GONZALO Alonso, F. (junio de 2005). Gerencia de riesgos Introducción (I/III). Recuperado el agosto de 2012, de Asociación Colegio Nacionalde Ingenieros del ICAI: www.icai.es/publicaciones/anales_get.php?id=472 ISACA. (2008). Alineando COBIT 4.1,ITIL v3, ISO/IEC 27002 en Beneficio del Negocio. Recuperado el Octubre de 2011, de http://www.isaca.org/Knowledge-Center/Research/Documents/Alineando-Cobit-4.1,-ITIL-v3-y-ISO-27002-en-beneficio-de-la-empresa-v2,7.pdf ISACA. (2011). Certified Information System Auditor-Manual de Preparación al Exámen CISA 2011 . ISACA. (2007). COBIT 4.1. Recuperado el Diciembre de 2010, de http://www.isaca.org/Knowledge-Center/cobit/Documents/cobiT4.1spanish.pdf ISACA. (2011). COBIT 5 Initiative—Work Plan Overview. Recuperado el Diciembre de 2011, de http://www.isaca.org/Knowledge-Center/cobit/Pages/COBIT-5-Initiative-Status-Update.aspx ISACA. (2009). Cobit and Application Controls – A Management Guide. Recuperado el Junio de 2011, de http://www.isaca.org/Knowledge-
84
Center/Research/ResearchDeliverables/Pages/COBIT-and-Application-Controls-A-Management-Guide.aspx ISACA. (2007). COBIT Objetivos de Control 3a Edition . ISACA. (2007). COBIT Security Baseline An Information Security Survival Kit 2nd Edition. Recuperado el Agosto de 2012, de http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Security-Baseline-An-Information-Security-Survival-Kit-2nd-Edition1.aspx ISACA. (Diciembre de 2008). IS AUDITING GUIDELINE-G14 APPLICATION SYSTEM REVIEWS. Recuperado el Diciembre de 2011, de http://www.isaca.org/Knowledge-Center/Standards/Documents/G14-AppSysRev-15Oct08.pdf ISACA. (2007). IT Assurance Guide . Recuperado el mayo de 2012, de www.itgi.org ISACA. (2007). IT Assurance Guide: Using COBIT . Recuperado el julio de 2011, de http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/IT-Assurance-Guide-Using-COBIT.aspx Resumen de COBIT 4.1. (s.f.). Recuperado el Abril de 2011, de http://auditoriasistemasucb.pbworks.com/f/ProcesosCOBIT41_ig.pdf SDI, S. D. (2009). ITIL V3 Service Management Foundation. Recuperado el Julio de 2012, de http://www.sdila.com Universidad de, Sevilla. (Octubre de 2004). Introduccion a las Aplicaciones WEB. Recuperado el Noviembre de 2011, de Departamento de Lenguaje y Sistemas Informáticos: http://www.lsi.us.es/docencia/get.php?id=352 Universidad, de. Alicante. (2006). Qué es una aplicación Web. Recuperado el Noviembre de 2011, de Departamente de Lenguaje y Sistemas: http://rua.ua.es/dspace/bitstream/10045/4412/5/03c-AplicacionesWeb.pdf
85
GLOSARIO
ASP: Es un fichero de sólo texto que contiene las secuencias de comandos, junto
con el HTML necesario.
CGI: Son programas que se ejecutan en el servidor, pueden servir como pasarela
con una aplicación o base de datos o para generar documentos html de forma
automática.
HTTP: Protocolo de la capa de aplicación, que permite el servicio de transferencia
de páginas de hipertexto entre el cliente WEB y los servidores.
IP: Protocolo de la capa de Red, que permite definir la unidad básica de
transferencia de datos y se encarga del direccionamiento de la información, para
que llegue a su destino en la red.
ISACA : Organización global sin fines de lucro que establece las pautas para los
profesionales de gobernación, control, seguridad y auditoría de información.
Proveedor de conocimiento, certificaciones, comunidad, apoyo y educación en
seguridad y aseguramiento de sistemas de información, gobierno empresarial,
administración de TI así como riesgos y cumplimiento relacionados con TI.
JSP: Segmentos de código en Java que se insertan dentro de páginas web, de
forma análoga a los ASPs.
PHP : Lenguaje cuyos programas se insertan también dentro de las páginas web, al
igual que los ASPs y JSPs.
Servlets : Programas en Java que se ejecutan de forma persistente en el servidor, y
que, por lo tanto, tienen una activación muy rápida, y una forma más simple de
hacerlo. Estos programas procesan una petición y generan la página de respuesta.
TCP: Protocolo de la Capa de Transporte, que permite dividir y ordenar la
información a transportar en paquetes de menor tamaño para su transporte y
recepción.
86
ANEXOS
Anexo 1: Directrices de auditoría de Sistemas de Información definidas por ISACA.
Anexo 2: Interrelación de los Marcos de Trabajo COBIT-ITIL-ISO27002.
Anexo 3: Matriz para Definir el Alcance de Auditoría.
Anexo 4: Relevamiento y Ejecución de la Auditoría
Anexo 5: Documentos Ejecución Auditoría de la Aplicación CV.