Página 1

Gestión de auditoría de TI

Página 2
Guía Global de Auditoría de Tecnología
Gestión de auditoría de TI
Autor
Michael Juergens, Director, Deloitte & Touche LLP
Autor colaborador
David Maberry, gerente sénior de Deloitte & Touche LLP
Editores colaboradores
Eric Ringle, gerente sénior de Deloitte & Touche LLP
Jeffrey Fisher. Gerente Senior, Deloitte & Touche LLP
Marzo 2006
Esta guía ha sido producida y distribuida a través de
el patrocinio de Deloitte & Touche LLP.
Copyright © 2006 por el Instituto de Auditores Internos, 247 Maitland Avenue,
Altamonte Springs, Florida 32701-4201.
Todos los derechos reservados. Impreso en los Estados Unidos de América. Ninguna
parte de esta publicación puede reproducirse, almacenarse en
sistema de recuperación, o transmitido de cualquier forma y por cualquier medio:
electrónico, mecánico, fotocopiado, grabación,
o de lo contrario, sin permiso previo por escrito del editor.
El IIA publica este documento con fines informativos y educativos. Este documento
está destinado a proporcionar información,
pero no es un sustituto del asesoramiento legal o contable. El IIA no brinda dicho
asesoramiento y no ofrece ninguna garantía en cuanto a
cualquier resultado legal o contable a través de su publicación de este documento.
Cuando surgen problemas legales o de contabilidad,
la asistencia profesional debe buscarse y conservarse.

Página 3
1. Resumen para el Jefe de Auditoría Ejecutivo ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... 1
2. Introducción ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 2
3. Definir IT ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... 3
3.1 Gestión de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... 4
3.2 Infraestructura técnica ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 4
3.3 Aplicaciones ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... 4
3.4 Conexiones externas ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... 5
4. Riesgos relacionados con TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... ... 6
4.1 The Snowflake Theory ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 6
4.2 Evolución del riesgo ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... 6
4.3 Proliferación de riesgos relacionada con TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... ... ... 7
4.4 Tipos de riesgos relacionados con TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... 7
4.5 Evaluación de riesgos de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... 7
5. Definición del universo de auditoría de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... ... 10
5.1 Consejos para el CAE ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 10
5.2 Presupuestación para la auditoría de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... ... 10
6. Ejecución de auditorías de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... 12
6.1 Marcos y estándares ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... 12
6.2 Gestión de recursos de auditoría de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... 14
7. Aceleradores de auditoría de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... 17
7.1 Facilitadores de auditoría ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... 17
7.2 Probando aceleradores ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 17
8. Preguntas para el CAE ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 19
A. Apéndice A: Problemas emergentes ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... 20
A.1 Redes inalámbricas ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 20
A.2 Dispositivos móviles ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... 20
A.3 Interfaces ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... 21
A.4 Gestión de datos ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... 21
A.5 Privacidad ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 22
A.6 Segregación de deberes ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 22
A.7 Acceso de administrador ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... 23
A.8 Controles configurables ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 24
A.9 Piratería ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... 24
Otros recursos ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... 25
Acerca de los autores ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... 26
GTAG - Tabla de contenido

Página 4
1
La tecnología de la información (TI) está cambiando la naturaleza de
función de auditoría interna. A medida que surgen nuevos riesgos, nuevas auditorías
Se requieren procedimientos para manejar estos riesgos adecuadamente. Esta
guía, que fue creada para ayudar al director ejecutivo de auditoría
(CAE) planifique y administre la función de auditoría de TI de forma más efectiva
eficaz y eficientemente, cubre cómo:
Definir TI : qué áreas se deben considerar para incluir
sión en un plan de auditoría de TI? El CAE debería ser capaz de
medir su alcance de auditoría de TI planificada contra el
directrices presentadas aquí para ayudar a garantizar que el alcance
de los procedimientos de auditoría de TI es adecuado.
Evaluar el riesgo relacionado con TI : está claro que la evolución
de TI introduce nuevos riesgos en una organización. Esta
guía ayudará al CAE a comprender cómo identificar mejor
tificar y cuantificar estos riesgos relacionados con TI. Haciendo eso
ayudar a garantizar que los procedimientos y recursos de auditoría de TI sean
centrado en las áreas que representan el mayor riesgo para el
organización.
Definir el universo de auditoría de TI: los recursos de auditoría de TI son
generalmente es escaso, y las demandas de auditoría de TI son sustanciales.
Una sección sobre la definición del universo de auditoría de TI ayudará
el CAE entiende cómo construir un plan de auditoría de TI
que equilibra de manera efectiva las necesidades de auditoría de TI con recursos
restricciones
Ejecutar auditorías de TI : la proliferación y la complejidad de
TI dictamina la necesidad de nuevos procedimientos de auditoría de TI.
Es probable que la auditoría por lista de verificación o por indagación sea insuficiente
ficiente. Este libro ofrece una guía específica para el CAE
sobre cómo ejecutar procedimientos de auditoría de TI y cómo
entender qué estándares y marcos existen en
el mercado que puede soportar los procedimientos requeridos.
Administre la función de auditoría de TI - Administre la auditoría de TI
la función puede requerir nuevas técnicas de gestión
y procedimientos. Esta guía brinda consejos útiles y
técnicas para maximizar la efectividad de la TI
función de auditoría y gestión de recursos de auditoría de TI.
Abordar los problemas emergentes : las TI evolucionan rápidamente. Este evo-
lución puede introducir nuevos riesgos significativos en un
organización. El CAE de clase mundial se enfoca en la auditoría de TI
atención no solo en los componentes básicos de TI,
sino también tecnologías nuevas y emergentes. Una sección sobre
cuestiones emergentes proporcionarán información específica sobre
número de tecnologías emergentes, evaluar los riesgos
que estas tecnologías representan para una organización, y
proporcionar recomendaciones sobre cómo debe CAE
responder a estos riesgos
El enfoque de esta guía es proporcionar información pragmática
mación en inglés sencillo, con recomendaciones específicas que
un CAE puede implementar de inmediato. Mayor consideración es
dado a proporcionar preguntas que un CAE puede pedir para ayudar
entender si su función de auditoría de TI es alta
ejecutante.
GTAG - Resumen ejecutivo para el Jefe de Auditoría Ejecutivo - 1

Página 5
2
No hay duda de que TI está cambiando la naturaleza de la
función de auditoría interna. Los riesgos que enfrentan las empresas, los tipos
de las auditorías que deberían realizarse, cómo priorizar el
universo de auditoría, y cómo entregar hallazgos perspicaces son todos
problemas con los que los CAE deben lidiar. Sin una tecnología profunda
fondo económico, sin embargo, puede ser difícil encontrar
respuestas a estas y otras preguntas.
Este GTAG está diseñado para CAE y auditoría interna
personal de gestión que es responsable de la supervisión
Auditorías de TI. El propósito de la guía es ayudar a clasificar
los problemas estratégicos con respecto a la planificación, ejecución y
informando sobre auditorías de TI. Se tendrá en cuenta el
fundamentos y problemas emergentes.
La auditoría de TI es cada vez más importante, principalmente
porque las organizaciones son cada vez más dependientes
en eso. Los procesos clave están automatizados o habilitados por tecnología
gy. Es posible que un pedido de cliente ingrese a través de una Web
sitio, ser transmitido al piso del almacén, y ser enviado a
el cliente sin nadie más que el almacén
trabajador que ve o toca la orden.
A medida que las organizaciones aumentan su dependencia de TI, dos
problemas principales emergen:
• Un gran porcentaje de los controles internos clave
en la que se basa la organización es probable que sean tecnológicos
impulsado por la nología. Ejemplo: la política corporativa establece que
antes de realizar cualquier pago a un proveedor, un pago tripartito
se realiza la coincidencia. Históricamente, ese partido fue
Probablemente realizado por un empleado, que físicamente emparejado
trozos de papel, grapados y archivados. Ahora todo
las coincidencias pueden ser realizadas por la institución
sistema de planificación de recursos premio (ERP). El sistema
realiza automáticamente el partido basado en
reglas preconfiguradas y niveles de tolerancia y automatismos
icalmente publica varianzas a cuentas de varianza definidas.
Para auditar ese control de manera efectiva, un auditor debe ir
en los ajustes de configuración de ese sistema ERP y
evaluar las reglas y configuraciones Esto requiere mucho
diferente conjunto de habilidades y programa de auditoría que el histórico
proceso lo hizo. Para realizar una auditoría efectiva,
enfoque de auditoría histórica debe ser rediseñado para
abordar los nuevos riesgos. Esto requiere un enfoque en - y
comprensión de - tecnología de auditoría.
• Sistemas que carecen de integridad o tienen deficiencias de control
cias tendrán un mayor impacto en la organización de
operaciones y la preparación competitiva, por lo tanto
aumentando la necesidad de controles de TI efectivos.
Ejemplo: Considere el proceso automatizado descrito
arriba, donde entra un pedido de venta a través de un sitio web y
se transmite directamente a través del sistema ERP al
piso de almacén Ahora considere lo que sucede cuando un
el cliente ordena accidentalmente 100 palets en lugar de 100
unidades. Si la organización ha optimizado completamente su
procesos con un sistema ERP, es posible que
sistema comprobará el inventario, tenga en cuenta que 100 palets son
no disponible, actualice el cronograma de producción a
producir 100 paletas y enviarlas automáticamente
órdenes de compra de materias primas a través de datos electrónicos
Intercambio (EDI). Potencialmente, este error puede no obtener
atrapado hasta que el cliente reciba los bienes, demasiado
tarde.
Claramente, para mitigar este tipo de riesgos, las organizaciones necesitan
para ejecutar planes de TI bien diseñados que consideren estos problemas.
Desafortunadamente, la mayoría de las organizaciones solo migraron a
en entornos automatizados en los últimos 10 años o menos. Así,
Tradicionalmente, es posible que no haya habido un enfoque profundo en la auditoría
tecnología, ni fuentes profundas de liderazgo de pensamiento con respecto a
cómo auditar la tecnología. Parte de eso se debe a la rápida tasa de
Avances tecnológicos. No ha habido ningún radical
desarrollos en el proceso de emparejamiento a tres bandas en muchos años;
Sin embargo, las aplicaciones utilizadas para respaldar estos procesos
evolucionar anualmente.
Un problema adicional que a menudo surge cuando se planifica
el universo de auditoría de TI realmente está entendiendo cómo la TI
Los trols se relacionan con informes financieros, fraude y otros asuntos clave.
Esto es relativamente fácil de entender cuando evalúa
trols dentro de un sistema de aplicación (por ejemplo, la combinación de tres vías)
configuraciones discutidas arriba). Sin embargo, es mucho más difícil
al evaluar tecnologías de apoyo. Supongamos que la organización
zación mantiene una conexión a Internet, pero no tiene una
cortafuegos para proteger la red interna. Son los financieros
tergiversado? ¿Las operaciones están impactadas? Se vuelve más difícil dibujar
la correlación directa ya que la tecnología se elimina más
de las operaciones comerciales.
Dado esto, muchos CAE a menudo proporcionan menos atención de auditoría
a estas tecnologías de soporte, que pueden representar un
visión miope del riesgo de TI. El hecho del asunto es que el control
las deficiencias en las tecnologías de soporte pueden tener una mayor
impacto en la organización que los controles de TI específicos para un
proceso gle
Por ejemplo, supongamos que una organización crea
pagos electrónicos que envía a sus proveedores. Estos pagos-
se enrutan electrónicamente a cuentas bancarias basadas en
números de ruta de la cámara de compensación automática (ACH) para cada
cuenta de vendedor. Todos esos números ACH se almacenan algunos-
donde en una tabla en el sistema de base de datos de la organización. A data-
administrador de la base, o cualquier persona con el derecho de acceso a la
base de datos, simplemente podría cambiar cada entrada en esa tabla a su
o su propia ruta ACH de cuenta bancaria. La próxima vez que
organización hizo una comprobación electrónica, toda la carrera
ser depositado en la cuenta bancaria del perpetrador. Esto sería
evadir por completo toda la seguridad, el control y el seguimiento de auditoría
mecanismos que existen dentro del proceso de negocios y la
aplicación comercial, incluido el pago positivo.
En los escenarios anteriores, es fácil ver cómo un control
la deficiencia a nivel de base de datos podría tener un impacto mucho mayor
que una deficiencia con la configuración de coincidencia de tres vías. Es para
esta razón por la cual los CAE deben considerar cuidadosamente todas las capas de
el entorno de TI cuando se planifica el universo de auditoría de TI para
el año.
GTAG - Introducción - 2

Página 6
3
Uno de los desafíos iniciales que enfrenta CAE al desarrollar
el plan de auditoría de TI para el año está definiendo los límites de TI.
¿Los sistemas de correo de voz y teléfono forman parte de TI? Debería
se incluirán credenciales de instalaciones y sistemas de seguridad física?
¿Qué pasa si se subcontratan a la administración de la propiedad?
¿empresa? Estos son algunos de los problemas que enfrentan los CAE
con al tratar de determinar cómo asignar auditoría de TI
recursos.
La realidad es que TI significa diferentes cosas para diferentes
organizaciones. Incluso dos compañías en la misma industria pueden
tener entornos de TI radicalmente diferentes. Desafortunadamente,
lo que TI es, o debería ser, no está definida clara o universalmente.
Esta sección ayudará a los CAE a abordar cómo pensar
TI dentro de una organización. Reconociendo que hay un alto
cantidad de heterogeneidad en los entornos de TI, una forma de
CAE puede acercarse a la definición de TI pensando en
en capas, como un postre helado. Cada capa es diferente e importante
tant. Existen riesgos en cada capa del medio ambiente, y el
los riesgos varían mucho Hackear el sitio web corporativo, por ejemplo,
ple, es un riesgo muy diferente para la organización que el robo
la ejecución de cheques electrónicos antes mencionada.
Considera cada capa
Para que una función de auditoría de TI sea efectiva, los riesgos de cada
capa debe ser considerado y priorizado, y auditoría
los recursos deben asignarse a cada capa. Si la auditoría de TI
plan no incluye auditorías para cada capa del medio ambiente
las probabilidades son que el plan de auditoría tomado en conjunto no es
va a abordar el riesgo de TI de la organización de manera adecuada.
Cabe señalar que, en algunos casos, puede ser apropiado
priate para considerar todas las capas durante un período de tiempo (es decir,
durante varios años en forma rotativa) en lugar de cubrir
ing todas las capas dentro de un solo año. Empresas privadas o
organizaciones que no necesitan cumplir con los Estados Unidos
Ley Sarbanes-Oxley de 2002 u otras regulaciones de control o
legislación, como el seguro de depósito federal
Ley de Mejora de la Corporación, puede desear establecer un plan
que cubre el universo de TI durante un período de dos a tres
años. Los planes de rotación que se extienden más allá de tres años son
probablemente inadecuado debido a la alta tasa de cambio en la TI
ambiente.
¿Cuántos recursos se deben asignar a cada capa?
¿En qué parte de la capa deberían asignarse? Respuestas a
estas preguntas desafiantes deben ser el resultado natural
los procesos de evaluación de riesgos, combinados con los
juicio y pensamiento estratégico. Independientemente de lo específico
asignación de recursos, se deben considerar todas las capas.
¿Cuáles son las capas?
La Figura 1 a continuación es una descripción simple de un entorno de TI.
Obviamente, cada organización es diferente, pero este gráfico
debería cubrir la mayoría de los sistemas críticos para la mayoría de los
izaciones. Las capas clave a considerar son:
• Gestión de TI.
• Infraestructura técnica.
• Aplicaciones.
• Conexiones externas.
Tenga en cuenta que este gráfico no define las categorías de
el plan de auditoría de TI. Cuando se planifican auditorías de TI específicas,
pueden organizarse en categorías basadas en los
procesos, o por marcos estandarizados, etc. Este gráfico es
GTAG - Definición de IT - 3
Figura 1 - Entorno de TI

Página 7
4
diseñado para lograr que el CAE piense sobre el entorno de TI
y asegurándose de que los recursos de auditoría estén asignados a cada
capa. La organización de las auditorías específicas queda a juicio de
el CAE.
3.1 Gestión de TI
Esta capa comprende el conjunto de personas, políticas, procedimientos,
y procesos que gestionan el entorno de TI. Tecnologías
puede implementarse; por ejemplo, una organización puede implementar
SAP ERP en un entorno Unix, pero la integridad de
los sistemas y datos son altamente contingentes en tareas específicas
que el personal administrativo realiza regularmente.
Por lo tanto, esta capa incluye:
Monitoreo del sistema : el monitoreo implica identificar
transacciones que no se pudieron publicar debido a un error de procesamiento,
o identificando cuando una base de datos se corrompe.
Programación : muchas organizaciones realizan programas internos
Gramática para varios sistemas. La programación necesita
ser administrado y supervisado para que los programas con errores
no afectan la integridad de los sistemas clave.
Planificación : el departamento de TI debería estar desarrollando
planes estratégicos de TI tanto a largo como a corto plazo.
Estos deben alinearse con los de la organización y
planes a corto plazo. La ausencia de una buena estrategia de TI
planeando todo menos garantías de que TI no será compatible
los objetivos de la organización, tomados en conjunto.
Gestión de proveedores subcontratados : muchas organizaciones
subcontrata varios componentes, o todos, de la TI
entorno a un proveedor externo. En estas situaciones
ciones, gestionando la relación externalizada
es una pieza fundamental para garantizar la integridad de
entorno informático.
Gobernanza de TI : establecer un tono fuerte en la parte superior para
diseñando, construyendo y operando sistemas de TI con
integridad; comunicando esa cultura en todo el
Función de TI; supervisando el desarrollo y despliegue-
de políticas y procedimientos; y evaluando
el rendimiento son los componentes clave de la ejecución de una TI
función.
Tenga en cuenta que las auditorías de estas funciones serán similares al proceso
auditorías. El auditor de TI está mirando a personas y tareas como
opuesto a una configuración técnica del sistema. Las pruebas de los controles serán
bastante diferente y requerirá una cierta cantidad de juicio.
3.2 Infraestructura técnica
Esta capa se conoce con muchos nombres diferentes, como
controles generales de la computadora, controles generalizados o de apoyo
tecnologías. Se refiere esencialmente a los sistemas que subyacen
Miente, admite y habilita las principales aplicaciones comerciales. En
En general, esto incluye:
Sistemas Operativos - El conjunto de programas que instruyen al
sistemas informáticos sobre cómo funcionar. Ejemplos incluyen
Unix, Windows 2003 y OS / 400. Todos los programas y
los archivos eventualmente residen en algún lugar del sistema operativo
tem. Acciones realizadas en el nivel del sistema operativo
en general eludir la mayoría de la seguridad y los controles que
existir en el nivel de proceso. Por ejemplo, considere un ejecutivo
la computadora portátil de utive Si el ejecutivo quiere eliminar un correo electrónico,
él o ella iniciaría sesión en la aplicación de correo electrónico y
eliminar ese correo electrónico. El programa probablemente pregunte,
"¿Estás seguro?" Entonces, el correo electrónico eliminado sería
almacenado en una carpeta especial por un período de tiempo para que
podría ser recuperado Sin embargo, el mismo ejecutivo podría
también abra Windows Explorer y elimine todos los directorios en
el C: conducir. El efecto sería el mismo; el correo electrónico
se habría ido. En el último ejemplo, sin embargo, hay
claramente menos controles.
Bases de datos : todos los datos comerciales, críticos o no, terminan
hasta residir en algún tipo de base de datos en algún lugar de la
ambiente. Las bases de datos están compuestas de tablas
datos, que, entre otras cosas, forman el
base para todos los informes comerciales. Los ejemplos incluyen Oracle,
MS SQL Server y DB2. Acciones realizadas en el
nivel de base de datos también tienden a eludir la mayoría de los controles
que existen en el nivel del proceso: vis-à-vis el anterior
ejemplo de fraude de cuentas por pagar.
Redes : para que los datos fluyan a través de una organización,
debe tener un método de viaje, ya sea a través de un
cable, un cable de fibra óptica o un sistema inalámbrico. La red-
el trabajo consiste en componentes físicos como cables;
dispositivos que gestionan el movimiento del tráfico de red
como conmutadores, enrutadores o firewalls; y programas
que controlan el movimiento de datos. La integridad de
la red juega un papel importante para garantizar la
plenitud y precisión del negocio de la organización
datos. Por ejemplo, si un trabajador de almacén se prepara para
enviar un producto escanea con un escáner de código de barras, cómo
¿esa transacción se registra nuevamente en el
al libro mayor (G / L)? Respuesta: viaja por la red
y es procesado Pero, ¿y si no viaja por el
¿red? ¿Qué pasa si se cambia a lo largo del camino, o dis-
aparece por completo? ¿Cómo sería la organización?
¿saber?
Las auditorías de infraestructura técnica tienden a enfocarse más en la revisión
de configuración de configuración técnica que los procesos.
3.3 Aplicaciones
Las aplicaciones comerciales son programas que realizan
tareas relacionadas con las operaciones comerciales. Estos generalmente pueden ser
clasificados en dos categorías: aplicaciones transaccionales
y aplicaciones de soporte.
Aplicaciones transaccionales
Las aplicaciones transaccionales consisten principalmente de software
que procesa y registra transacciones comerciales. Ejemplos
incluye procesamiento de órdenes de venta, registro de contabilidad general,
y gestión de almacenes Aplicaciones transaccionales
GTAG - Definición de IT - 3

Página 8
5
típicamente caen en una de las siguientes categorías:
Buy Side : permite la adquisición y la cadena de suministro
procesos.
Sell Side : permite procesos de ventas y distribución.
Back Office : permite la contabilidad financiera, cuentas por pagar,
cuentas por cobrar y procesos de recursos humanos.
ERP - software integrado que hace una o más de las
encima.
Aplicaciones de soporte
Las aplicaciones de soporte son programas de software especializados que
facilitar las actividades comerciales, pero en general no procesar
actas. Los ejemplos incluyen programas de correo electrónico, fax soft-
ware, software de imágenes de documentos y software de diseño.
La mayor parte de la atención de auditoría de TI debe estar orientada
hacia aplicaciones transaccionales. Sin embargo, dependiendo de
ciertas industrias, algunas aplicaciones de soporte pueden ser altas
riesgo también Ejemplo: la empresa XYZ hace un consumidor
producto y tiene una marca altamente reconocible. Continua-
pierde dinero debido a la venta de productos defectuosos
porate piratas. Su equipo creativo diseña nuevos productos en una
paquete de software de diseño de computadora integrado. En este caso,
la compañía debe evaluar los controles en torno a este supuesto
aplicación del puerto, ya que podría representar un riesgo
la empresa si se roban nuevos diseños antes de nuevos productos
golpeando la calle.
3.4 Conexiones externas
La red corporativa no opera aisladamente. Es
seguramente conectado a muchas otras redes externas.
El Internet, por supuesto, es el que viene más fácilmente
a la mente, pero muchas veces los CAEs cometen el error de parar
ahí. De hecho, es muy probable que la red corporativa
está conectado a muchas otras redes. Por ejemplo: ¿el
organización hacer negocios a través de EDI? Si es así, la red corporativa
el trabajo probablemente esté conectado a una red de proveedor de EDI, o
quizás directamente conectado a la red de una parte comercial
ner. ¿La organización usa un almacén de terceros?
proveedores? Si es así, las dos redes probablemente estén vinculadas
juntos.
Además, a medida que las organizaciones continúan automatizando la clave
procesos, se otorga más acceso a la red corporativa a
extraños, a menudo a través de Internet. Considere, por ejemplo, el
capacidad de buscar el estado de la cuenta de una tarjeta de crédito o la
estado de envío de un paquete de FedEx. Clientes que realizan
Es probable que esas actividades entren en las internas de esas compañías
redes a través de Internet.
El problema aquí es que las redes externas no están bajo
el control de la organización y, por lo tanto, no debería ser
Confiado Toda la comunicación hacia y desde redes externas
debe estar estrechamente controlado y monitoreado. Puede ser un desafío
alargar para definir los procedimientos de auditoría de TI para abordar este riesgo,
porque la organización solo puede auditar lo que puede controlar.
Por lo tanto, es crítico auditar los puntos de entrada y salida, en una
mínimo.
GTAG - Definición de IT - 3

Página 9
6
GTAG - Riesgos relacionados con TI - 4
4.1 La teoría del copo de nieve
Cada entorno de TI es único y, en consecuencia, representa
un conjunto único de riesgos, dice la teoría del copo de nieve. Las diferencias
en entornos de TI hacen que sea cada vez más difícil
tomar un enfoque genérico o de lista de verificación para la auditoría de TI. Ser
eficaz, cada organización debe definir una auditoría de TI
acercarse y crear planes de trabajo de auditoría de TI que sean específicos de
las necesidades de ese ambiente particular.
Esto es muy diferente del financiero u operativo
áreas de auditoría, donde ciertos riesgos son endémicos para una industria determinada
intentar o el tamaño de la empresa. Considere lo siguiente: Compañía
ABC y Company XYZ son medios y entretenimiento
compañías. Ambas compañías enfrentan riesgos al calcular el máximo
entradas contables para películas que se han lanzado. Esta
proceso sería algo que la función de auditoría interna
definitivamente auditaría.
En el lado de TI, sin embargo, la Compañía ABC está utilizando
Oracle Applications como el principal sistema de negocios, ejecutándose
en Windows 2000 y usando una base de datos Oracle. Ahi esta
un sistema centralizado de Oracle. La empresa XYZ tiene una descendencia
función de TI tralizada, con cada unidad de negocio utilizando su propio
sistema en una variedad de plataformas. Cada unidad de negocio informa
en un sistema de consolidación, que la compañía tiene
de origen a un proveedor externo. Claramente, las auditorías de TI que
sería planificado y ejecutado por la Compañía ABC haría
varían mucho de los de la Compañía XYZ.
El factor de configuración
Otro factor principal en la teoría del copo de nieve es la configuración
ción. Cuando una empresa implementa una tecnología determinada, configura
ures la tecnología para apoyar sus objetivos particulares. Ahí
puede haber un alto grado de variabilidad del entorno al medio ambiente
ambiente Una compañía que usa Windows 2003 como principal
sistema operativo puede haber configurado múltiples dominios, con
relaciones de confianza entre todos los dominios. Otro puede
tener solo un dominio, usando Windows Active Directory
para administrar todo el acceso de los usuarios. Aunque ambas compañías son
usando la misma tecnología, los riesgos son muy diferentes; estafa-
en consecuencia, el rendimiento de las auditorías de TI también es muy diferente.
La configuración también afecta las aplicaciones comerciales.
La Compañía ABC y la Compañía XYZ implementaron SAP
como el sistema de negocios primario y habilitado las cuentas por pagar
proceso con SAP. La compañía ABC ha configurado SAP para
realizar una coincidencia de tres partes, precio coincidente, cantidad y
fecha. Se ha establecido por encima o por debajo de los niveles de tolerancia de $ 50 o 5
por ciento, cualquiera que sea menor. La empresa XYZ ha configurado
SAP para realizar "liquidación de recibo evaluado", donde el
el pago se genera automáticamente según lo que fue
recibido, independientemente de lo que se ordenó o facturó. No tres-
se realiza la coincidencia de caminos, y no se establecen límites de tolerancia
lished. Una vez más, aunque ambas compañías están usando SAP,
los riesgos de cada una de esas configuraciones son bastante diferentes,
y las auditorías de TI que deberían realizarse en cada compañía
ny también son diferentes.
Una matriz de variables
Otras variables que impactan en la teoría del copo de nieve son:
• Grado de centralización del sistema.
• Grado de centralización geográfica.
• Número de servidores.
• Elección de tecnologías de infraestructura.
• Grado de personalización.
• Estructura organizacional del departamento de TI.
• Versiones de tecnología específica utilizada (por ejemplo, Windows
2000 versus Windows 2003).
• Grado y método de outsourcing.
• Políticas corporativas (por ejemplo, guardar todos los correos electrónicos para
siempre
sus no guardar ningún correo electrónico).
El resultado neto de todas estas variables es la teoría del copo de nieve:
No hay dos entornos de TI iguales. Por lo tanto, es muy difícil
culto - si no imposible - para tomar un enfoque de lista de verificación para
planificación y ejecución de auditorías de TI. Cada empresa debería tener
un plan de auditoría de TI totalmente único basado en sus riesgos específicos de TI.
El desafío, por supuesto, es identificar adecuadamente el
negocios y riesgos de TI específicos para el particular de la organización
Entorno de TI. Esta es la razón por la cual el proceso de evaluación de riesgos de TI
es fundamental, tal vez incluso más que la evaluación general de riesgos
ment. Además, la evaluación de riesgos debe realizarse
por recursos bien informados, como aquellos que entienden
cómo afectará el uso de Active Directory por parte de la compañía
Auditorías de TI que deben realizarse.
4.2 Evolución del riesgo
La teoría del copo de nieve dicta que cada compañía tendrá
un perfil de riesgo exclusivo de esa organización.
Sin embargo, hay otra dimensión de riesgo que es importante
También debe tenerse en cuenta, y esa es la evolución del riesgo. Riesgo evo-
lution se basa en la Ley de Moore. La Ley de Moore, que era
inicialmente propuesto en 1965, establece que cada 18 meses, el
la densidad de datos en un circuito integrado se duplica. Que es esto
significa pragmáticamente que la tecnología está aumentando rápidamente,
que no debe sorprender a nadie
En consecuencia, el riesgo relacionado con TI no es estático. Dado el alto
crecimiento y expansión de la tecnología, los riesgos relacionados con TI
cambio - a veces dramáticamente - de año en año. Es
incluso posible tener una situación en la que el calendario de auditoría de TI fue
basado en un proceso efectivo de evaluación de riesgos de TI, pero por el
vez que se realizarán las auditorías reales, ese perfil de riesgo
evolucionado, y las auditorías de TI planificadas ya no son suficientes.
Para combatir este problema de la evolución del riesgo relacionado con la TI, el
CAE debería:
• Reconocer la naturaleza dinámica del riesgo relacionado con TI y
realizar evaluaciones independientes de riesgos de TI cada año.
• Desarrollar una comprensión del departamento de TI
planes a corto plazo para un año determinado y analizar cómo
esas iniciativas pueden afectar la evaluación de riesgos de TI.
• Comience cada auditoría de TI actual mediante la actualización de la evaluación de
riesgos.
componente de la auditoría en particular.

Página 10
7
GTAG - Riesgos relacionados con TI - 4
• Ser flexible con respecto al universo de auditoría de TI; lun-
itor el perfil de riesgo relacionado con TI de la organización y
dispuesto a adaptar los procedimientos de auditoría a medida que evoluciona.
4.3 Proliferación de riesgos relacionada con TI
Una tercera dimensión a considerar cuando se evalúa la TI
riesgo es el concepto de proliferación, que se refiere a la
naturaleza activa de los riesgos relacionados con TI. Suponer que la organización
ha identificado el riesgo de TI A y el riesgo de TI B. Independientemente, cada
el riesgo puede ser bajo, pero cuando los dos procesos relacionados con el riesgo
trabajan juntos, crean un riesgo de TI C que es mucho mayor que
la suma de los riesgos individuales.
Ejemplo: la empresa XYZ está ejecutando Oracle
Aplicaciones. No hay un proceso para monitorear
actividad del sistema Además, los administradores del sistema tienen todos completos
acceso al sistema Independientemente, cada uno de estos artículos representa
resiente el riesgo, pero juntos representan una situación donde
cantidad de personas que pueden hacer lo que quieran en el sistema
(aprobar facturas, cortar cheques, configurar nuevas cuentas de nómina)
sin controles de detective y saldos. En este caso, bajo
de pie los procesos de administración y monitoreo de TI,
junto con la seguridad específica del sistema, es importante
entendiendo el verdadero riesgo
Por esta razón, es importante considerar los relacionados con TI
arriesgar holísticamente, en lugar de discretamente. El CAE debería
considere el riesgo relacionado con TI a nivel empresarial, evaluando no
solo cada riesgo individual, pero también cómo los riesgos individuales
impactarse el uno al otro. Recuerde que el entorno de TI tiene
capas. Imagine que uno está tratando de tamizar arena a través de un número
de pantallas apiladas una encima de la otra. Aunque cada
pantalla tiene agujeros, las capas de pantallas evitarán cualquier
arena de llegar todo el camino. Ahora imagina eso
cada pantalla tiene un pequeño orificio en ella, alineado directamente con un
pequeño agujero en la capa debajo de él. En este caso, la arena puede caer
todo el camino a través de las pantallas sin impedimento.
El CAE de clase mundial siempre está considerando todas las capas
del entorno de TI al planificar o ejecutar TI
auditorías. Evaluar el impacto de los riesgos en una capa contra
riesgos en otras capas es muy importante cuando se realiza el
Evaluación de riesgos de TI.
4.4 Tipos de riesgos relacionados con TI
El primer paso para comprender los riesgos asociados con TI
es identificar qué puede salir mal, incluyendo:
• Disponibilidad: cuando el sistema no está disponible para su uso.
• Seguridad: cuando ocurre un acceso no autorizado a los sistemas.
• Integridad: cuando los datos son incompletos o inexactos.
• Confidencialidad: cuando la información no se mantiene en secreto.
• Eficacia: cuando el sistema no entrega un
función prevista o esperada.
• Eficiencia: cuando los sistemas causan un uso subóptimo
de recursos.
Los diversos riesgos relacionados con TI generalmente se pueden agrupar en
dos categorías principales: riesgo generalizado y riesgo específico.
Riesgo generalizado
Ciertos riesgos relacionados con TI no están limitados a un sistema específico
o proceso Estos riesgos impactan a la empresa como un todo, y
por lo tanto, se conocen como riesgos generalizados. Ejemplo:
La compañía XYZ está conectada a Internet y no
mantener un firewall ¿Qué balance de cuenta tiene ese impacto?
Potencialmente todos los saldos de cuenta o potencialmente ninguna cuenta
saldos Otro ejemplo podría ser la presencia de agua
rociadores en el centro de datos. Si esos accidentalmente se apagan y
apagar todos los servidores con agua, proceso operacional
es se vería afectado? Podría ser todos los procesos, sin proceso-
es, o cualquier cosa en el medio.
Riesgo específico
El riesgo específico, por otro lado, puede atribuirse directamente
a un proceso específico o saldo de cuenta. Considera el
ajustes de configuración de coincidencia de tres vías mencionados en el
introducción de esta guía. Si esas configuraciones están configuradas incorrectamente,
El riesgo se relacionará específicamente con las cuentas por pagar y el efectivo.
Los CAE a menudo luchan con el hecho de que los riesgos generalizados
representan riesgos mucho mayores para la empresa que los específicos
riesgos Sin embargo, es muy difícil cuantificar un riesgo generalizado.
Además, al informar una deficiencia de control relacionada con un
riesgo generalizado, es mucho más difícil vincularlo con el negocio
impacto debido a la deficiencia.
La importancia aquí es el equilibrio. El CAE debería
recuerde que los riesgos generalizados y específicos son importantes
enfoque y enfoque la atención de auditoría en ambos tipos de riesgo. Si un
la revisión del universo de auditoría de TI planificada no revela auditorías
que cubren ambos tipos de riesgo, es probable que la auditoría de TI
el universo no cubrirá los riesgos de la organización adecuadamente.
4.5 Evaluación de riesgos de TI
El auditor debe usar una tecnología apropiada de evaluación de riesgos
nique o enfoque en el desarrollo del plan general para el
asignación efectiva de recursos de auditoría de TI. La evaluación de riesgos es
una técnica utilizada para examinar las unidades auditables en la unidad de auditoría
verso y seleccione áreas para revisión que tienen el mayor riesgo
exposición. Los riesgos asociados con cada capa de TI no pueden ser
determinado al revisar los riesgos relacionados con TI de forma aislada, pero
debe considerarse en conjunto con la organización
procesos y objetivos.
Impacto frente a la verosimilitud
La evaluación del riesgo relacionado con TI también debe considerar la
impacto y probabilidad de ocurrencia. El impacto de TI se relaciona
Los eventos de riesgo a menudo son altos, particularmente para los riesgos
generalizados.
Probabilidad puede ser más difícil de determinar porque es un pre
valor de dicción (por ejemplo, ¿cuál es la probabilidad de que un hacker
irrumpir en el sitio web de la organización?). Experiencia pasada y
se pueden utilizar las mejores prácticas generales para respaldar estas estimaciones.
compañeros. El producto del impacto y la probabilidad ayuda a definir
la gravedad del riesgo, que proporciona una base para comparar
y priorizar los riesgos relacionados con TI.

Página 11
8
Considere la empresa XYZ, que ha implementado
Windows 2003. ¿Debería ser auditado como parte de la edición de este año?
¿Auditorías de TI? La respuesta, como muchas otras respuestas con respecto a TI,
es "Depende". En este caso, hay múltiples factores
impactando la decisión. La consideración clave es el riesgo de
el negocio y el impacto que tiene la tecnología en el funcionamiento
aciones de la organización. Si la única aplicación que se ejecuta en
Windows 2003 es la aplicación que actualiza los códigos postales
cuando la oficina postal los cambia, entonces claramente la tecnología
tiene muy poco impacto en la integridad general de la organización
operaciones de nización En consecuencia, sería un desperdicio de
Recursos de auditoría de TI para molestar a la auditoría de este sistema.
Por el contrario, si el sistema de cadena de suministro primario de la organización
tems se ejecutan en Windows 2003, entonces la tecnología definitivamente
impacta el logro de los objetivos de la organización
y debe incluirse en el plan de auditoría de TI.
Muchas veces, sin embargo, las respuestas no son tan auto
evidente. Es por esta razón que una función efectiva de auditoría de TI
depende en gran medida del rendimiento de una TI robusta
Evaluación de riesgos. La evaluación de riesgos de TI ayuda a abordar el
problemas planteados por la teoría del copo de nieve y permite a las organizaciones
para determinar qué áreas requieren atención de auditoría.
Evaluaciones de riesgos tradicionales a un lado
Es importante tener en cuenta que la evaluación de riesgos tradicional
los procesos y actividades pueden no ser compatibles con un riesgo efectivo de TI
evaluación. Estos procesos y tareas deberían ser reingeniería
para abordar las necesidades de una evaluación de riesgos de TI ade-
Quately. Específicamente, la mayoría de los procesos de evaluación de riesgos
heredados
son altamente basados en entrevistas. Las entrevistas por sí solas son probablemente
insuficientes
ficiente para evaluar el riesgo de TI, porque una buena parte del riesgo de TI es
basado en cómo la tecnología se configura específicamente en el
organización. Además, una buena parte del riesgo en el área de TI es
dictado por cuestiones emergentes. Por ejemplo, asumir un hacker
descubre un nuevo defecto en Windows 2003 y crea una herramienta que
explota este defecto Microsoft identifica el problema y las versiones
un parche que elimina el defecto. Un auditor de TI probablemente
necesidad de comprender la información sobre qué parches tienen
sido instalado antes de que pudieran evaluar adecuadamente la verdadera
riesgo alrededor de esa tecnología.
Riesgo estático frente a dinámico
En la Sección 4.4, se tuvo en cuenta el concepto
de riesgo generalizado versus específico. Entendiendo ésos
la dinámica es importante. Sin embargo, al realizar una TI
evaluación de riesgos, también es importante considerar estática versus
riesgo dinámico
Riesgo estático: el riesgo estático no cambia de un año a otro
año y generalmente es impulsado por la industria dentro
que la organización opera Por ejemplo,
La compañía XYZ es un minorista en línea de libros y tiene
riesgo asociado con sus servidores web que ejecutan la línea
sistema de pedidos. Si esos servidores caen, la compañía
la corriente de ingresos de ny se apaga hasta que los servidores
vuelve a subir.
Al evaluar el riesgo estático, consulta y entrevista
las técnicas son, en muchos casos, adecuadas. Además, estos
las evaluaciones tienden a necesitar una pequeña actualización cada año,
basado en nuevas condiciones, pero generalmente es cierto año
despues del año. A menos que la empresa XYZ decida salir de
el negocio del libro en línea y abrir un ladrillo y
solución de mortero, los servidores web continuarán siendo
un área de alto riesgo.
Riesgo dinámico: el riesgo dinámico es el riesgo constante
cambiando. Tiende a ser menos impulsado por la industria y
más impulsado por la evolución de la tecnología (recuerde
Ley de Moore de Berke). El descubrimiento de un nuevo defecto en
Windows 2003 es un gran ejemplo de riesgo dinámico.
La evaluación de riesgos del año pasado no habría identificado
ese riesgo; no existía en ese momento. Riesgo dinámico también
afecta cómo debe ser el proceso de evaluación de riesgos de TI
conducido. En este caso, el proceso de evaluación de riesgos de TI
debe centrarse en el proceso que la gestión de TI
ha implementado para monitorear parches y medir su
implementación oportuna.
Los asuntos legales y regulatorios también son muy dinámicos
riesgos Estos problemas afectan todas las áreas del negocio,
pero dada la evolución de la tecnología, hay lejos
mayores nuevos problemas legales y regulatorios relacionados con
tecnología que surge cada año. Considere, por ejemplo,
todas las nuevas reglas y regulaciones relacionadas con
la privacidad de la información del consumidor que ha sido
promulgado en el pasado reciente.
Evaluar el riesgo de TI dinámico
Al realizar una evaluación de riesgo de TI dinámico, consulta
los procedimientos solos son probablemente insuficientes. Hay dos
pasos clave que deben tomarse: descubrimiento y análisis.
Discovery : el descubrimiento es el proceso de determinar
qué tecnologías se han implementado, cómo
se han configurado, y qué procesos de negocio
ellos apoyan y se alinean con. En muchos casos, las herramientas son
usado para apoyar el proceso de descubrimiento. Por ejemplo, un
organización con una función de TI descentralizada puede no
saber cuántos servidores y versiones de sistemas operativos
Los sistemas están en uso en toda la empresa. Un descubrimiento de red
y la herramienta de mapeo podría ayudar a recopilar estos datos rápidamente
y con precisión.
Análisis - El análisis se basa en la evaluación de los datos
una vez que ha sido recolectado Una vez más, esto sería
probablemente no sea conducido a través de procedimientos de investigación, pero
basarse más en el auditor de TI que analiza los cobros
datos ed contra los problemas emergentes y las nuevas tecnologías
riesgos
Otro concepto que emerge en la fase de análisis es
el concepto de dependencia de riesgo. Este concepto fue tocado
anteriormente utilizando una analogía de tamizar arena a través de una pila de
pantallas (Sección 4.3 Proliferación de riesgos relacionada con TI). Si hay
un agujero en cada pantalla, luego la arena podría caerse hasta el final
GTAG - Riesgos relacionados con TI - 4

Pagina 12
9
a través de ellos. Esta es la esencia de la dependencia del riesgo. los
impacto de un riesgo dado puede depender de la presencia de otro
riesgos Por ejemplo, la empresa XYZ no ha segregado el
red corporativa y está utilizando una serie de redes inalámbricas
trabajos. El equipo de ingeniería colabora electrónicamente
documentos de diseño para nuevos productos. En este caso, el negocio
el riesgo es que un competidor podría sentarse afuera con una antena
y recopilar información sobre nuevos diseños de productos. Este riesgo es
creado por la combinación de diseño de red, proceso
diseño y nueva tecnología, y cada riesgo depende de
la existencia de los otros dos riesgos. El riesgo total es mayor
que la suma de cada riesgo individual.
Es por esta razón que muchas organizaciones utilizan un
estrategia de defensa ", que proporciona múltiples capas de
seguridad y control Es importante que durante el análisis
proceso, el CAE evalúa el diseño y la eficacia de
todas las capas de defensa antes de concluir sobre el impacto de
un riesgo o debilidad de TI.
Evaluación robusta de riesgos de TI
Ante estos problemas, el DEA debe planificar en consecuencia y
garantizar que el proceso de evaluación de riesgos de TI:
• Se realiza en profundidad todos los años y no es solo una
actualización del año anterior.
• Considera todas las capas del entorno de TI.
• Considera los riesgos estáticos y dinámicos.
• No se basa estrictamente en entrevistas, sino que usa otras dis-
técnicas de covery
• Se complementa con el nivel apropiado de análisis
después del descubrimiento.
• Es realizado por el personal apropiado.
Esta última viñeta es una que puede presentar uno de los desafíos más grandes
a los CAE, porque TI es un término muy amplio y comprende
es muchas capas. Las habilidades requeridas para entender cada capa
son dramáticamente diferentes. Un especialista en redes con profundo
habilidades técnicas tiene un conjunto de habilidades muy diferente de un SAP
especialista en aplicaciones con habilidades técnicas profundas. Actuar
una evaluación de riesgos de TI efectiva, especialistas que entienden todo
las capas del entorno de TI deben estar involucradas. Estos son
raramente, si alguna vez, evidente en una sola persona. ¿Qué es mucho más?
es probable que sea un equipo de especialistas en auditoría de TI con habilidades en
todo
todas las capas tendrán que estar involucradas. Este equipo también tendrá
para trabajar juntos de cerca a través del proceso, principalmente
debido a la cuestión de la dependencia del riesgo.
GTAG - Riesgos relacionados con TI - 4

Página 13
Una vez que la evaluación de riesgos de TI se ha realizado con el
nivel apropiado de precisión, el siguiente paso es determinar
qué auditorías de TI deben realizarse. Si la evaluación de riesgos de TI
se realizó con eficacia, la organización debería
tener una idea razonable de los riesgos de TI existentes. Sin embargo, esto
también plantea una serie de desafíos, entre ellos el menos importante
definir auditorías de TI.
En el ejemplo anterior (página 8), la empresa tenía
identificado un riesgo comercial de transmitir un producto importante
información de diseño fuera de la organización. Qué auditoría
debe realizarse para abordar este riesgo? ¿Debería una auditoría de
redes inalámbricas se realizan; una auditoría de los archivos de red
tecture y diseño; o una revisión de la aplicación del electrón
ic aplicación de diseño? Y si las auditorías se dividen en eso
moda, las probabilidades son que el informe de los resultados de la auditoría
estar relacionado con las configuraciones técnicas para cada tecnología individual
ogy. Está bien, pero el comité de auditoría probablemente no le importe
sobre ajustes técnicos detallados y probablemente quiera IT
los hallazgos de la auditoría deben estar relacionados con los asuntos comerciales.
En consecuencia, la forma en que se definen las auditorías de TI
juega un papel importante en la eficacia general de la auditoría de TI
función. Esto se ve agravado por la necesidad de la auditoría de TI
función para integrarse con el proceso / operacional / financiero
auditores y los procedimientos que están realizando, particular-
en entornos con grandes aplicaciones ERP integradas,
donde hay un alto número de controles clave del proceso
con los sistemas.
Aunque no hay una forma correcta de definir auditorías de TI, hay
son ciertamente grados de error. Por ejemplo, muchos CAE
cometer el error de determinar una auditoría de "controles generales de TI".
Esto es tan amplio que casi no tiene sentido, especialmente en un
gran organización. ¿Están incluidos los interruptores telefónicos? Cómo
sobre la configuración de escritorio? Controles ambientales en el
¿centro de datos? Todas las anteriores? Si es así, la auditoría requerirá una
cantidad sustancial de tiempo para completar.
5.1 Consejos para el CAE
El desafío es proporcionar el nivel correcto de granularidad en
la definición del universo de auditoría de TI para hacerlo efectivo
tivo y eficiente. Esto será diferente para cada auditoría de TI
función (una extensión de la teoría del copo de nieve), pero algunos
Las consideraciones para el CAE al definir las auditorías de TI son:
• Usar definiciones demasiado amplias para las auditorías de TI (por ejemplo, TI
controles generales) casi garantizará que haya
ser un alcance lento en los procedimientos de auditoría . Además,
también puede haber una brecha entre lo que la administración
piensa que está siendo auditado y los verdaderos procedimientos de auditoría
siendo realizado. Por ejemplo, la empresa XYZ implementa
SAP para los procesos de contabilidad financiera. La cosa
la función de auditoría realiza una revisión posterior a la implementación
de cuentas configurables controles pagables, pero lo llama
una "revisión posterior a la implementación de SAP". Después de
auditoría, la compañía tiene un problema importante con el SAP
configuración de seguridad del usuario. Es probable que el comité de auditoría
pregunte por qué eso no fue capturado en la implementación de SAP
revisión de la tación. Esta respuesta es que no fue evaluada.
Pero la nomenclatura de la auditoría fue engañosa.
Con esto en mente, los CAE deben asegurarse de que
la definición de cada auditoría de TI es justa y precisa
descripción de lo que se está revisando.
• El universo de auditoría para el año debería tocar todos
las capas en el entorno de TI. Aunque cada TI
el ambiente es diferente, las capas tienden a ser
mismo. Si el plan de auditoría de TI no incluye alguna revisión
para cada una de las capas, las probabilidades son que el plan, como
completo, es deficiente.
• Las auditorías de TI deberían estructurarse de tal manera que
proporcionar informes efectivos y lógicos . Solicitud
las revisiones, por ejemplo, rara vez son óptimamente efectivas
cuando se dividen de forma independiente (por ejemplo, un Oracle
revisión de cuentas por pagar). Las aplicaciones deben ser inte-
derivado de un proceso de ejecución e informe con
auditorías de proceso / operacionales / financieras. Auditorías de TI de perva-
Algunas tecnologías (por ejemplo, redes, procesos, etc.) tienden a
ser más efectivo cuando se audita en el nivel de la empresa.
En otras palabras, no realice una auditoría de red en el
Instalación de Pittsburgh y otra auditoría de red en el
Instalación de Phoenix. Realice una auditoría de red empresarial.
La geografía importa menos que el proceso.
• Las auditorías de TI deben cubrir los riesgos apropiados. En muchos
casos, los presupuestos de auditoría de TI se determinan antes de la TI
la evaluación de riesgos se realiza. Esto conduce inevitablemente a
una de dos situaciones:
1. Un número inadecuado de horas de auditoría es
distribuido en demasiadas auditorías, lo que resulta en
consistentemente auditorías de TI de baja calidad porque
no hay suficiente tiempo para hacer ninguno de ellos
correctamente.
2. Las auditorías que deben realizarse no son
realizado porque el presupuesto no permite
para que se realicen
La planificación y presupuestación de la auditoría de TI debe ser un resultado del
Proceso de evaluación de riesgos de TI, no realizado antes de la evaluación de riesgos
de TI.
ment. Además, la evaluación de riesgos de TI debe considerarse en el
contexto de la evaluación de riesgos para la empresa en su conjunto. Eso
bien puede ser que en una organización particular, el entorno de TI
el presente representa tanto riesgo para la compañía que todo
Los procedimientos de auditoría realizados para el año deben ser de auditoría de TI
cedures - una situación hiperbólica para estar seguro, pero no inviable.
5.2 Presupuestación para la auditoría de TI
Uno de los errores más comunes que comete un AED al definir
el universo de auditoría de TI está subestimando la cantidad de tiempo
requerido para hacer una auditoría de TI. El problema, en muchos casos, es el
teoría del copo de nieve. Ejemplo: la compañía ABC está ejecutando un
aplicación financiera en un AS / 400. El auditor de TI quiere
evaluar la seguridad alrededor del AS / 400, y él o ella gasta
100 horas realizando la revisión. La compañía XYZ también se ejecuta
una aplicación similar en un AS / 400. ¿Debería la revisión
tomar la misma cantidad de tiempo?
10
GTAG - Definición del universo de auditoría de TI - 5

Página 14
La respuesta, por supuesto, es que depende. Si la compañía
ABC tiene 100 usuarios y la Compañía XYZ tiene 1000 usuarios,
puede ser más apropiado suponer que tomaría 10
veces más tiempo para la Compañía XYZ, si la auditoría debe evaluar todo
usuarios. Si el enfoque de auditoría es simplemente evaluar el acceso
derechos de una muestra de 10 usuarios, entonces las auditorías podrían tomar el
misma cantidad de tiempo, pero ofrecería diferentes niveles de
garantía.
Ese ejemplo ilustra el peligro de estimar TI
presupuestos de auditoría. Es fácilmente posible juzgar mal el esfuerzo
requerido por órdenes de magnitud, que generalmente no se ve en
el lado operacional o financiero de la casa de auditoría. Aquellos
las estimaciones pueden ser incorrectas, pero no por órdenes de magnitud.
Otro ejemplo podría ser la auditoría de un sistema SAP.
Una revisión de seguridad de un sistema SAP con dos producciones
los clientes tardarán el doble que una revisión de seguridad de un SAP
sistema con un cliente de producción. Ay de los CAE
quien estimó el presupuesto sin entender completamente el
Entorno de TI (consulte la sección de evaluación de riesgos de TI). Si
Se generaron estimaciones sin saber cuántos
clientes de producción, las estimaciones presupuestarias podrían ser
significativamente incorrecto.
¿Cómo debe un CAE resolver este problema? Ciertamente, uno cru-
elemento funcional es comprender el entorno de TI, que
debería evolucionar naturalmente desde la realización de un riesgo de TI adecuado
evaluación. Otro componente crítico es la estimación precisa
apareamiento el tiempo requerido para realizar tareas de auditoría de TI. Cierto
Las tareas de auditoría de TI, como la revisión de una configuración, pueden
hacerse de manera rápida y eficiente. Otras tareas, como la auditoría
una arquitectura de seguridad de usuario complicada, puede llevar una
cantidad total de tiempo Tácticamente, un CAE debería desafiar al
las estimaciones presupuestarias de las auditorías planificadas garantizan que haya
suficiente
la planificación final se ha realizado para justificar una estimación y garantizar
que el personal de auditoría de TI y la gerencia estén de acuerdo con la estimación.
Tenga en cuenta que bajo muy pocas circunstancias puede una auditoría de TI
de menos de 80 horas para cualquier tecnología.
GTAG - Definición del universo de auditoría de TI - 5
11

Página 15
El proceso para ejecutar una auditoría de TI es, en teoría, no
diferente del proceso para ejecutar una auditoría operacional.
El auditor planifica la auditoría, identifica y documenta
trols, prueba el diseño y la efectividad operativa de
trols, concluye e informa. Porque la mayoría de los CAE son
familiarizado con este proceso general, no estará cubierto en
detalle en este GTAG. Sin embargo, hay ciertos elementos
de una auditoría de TI que varía un poco de la tradición
al auditorías. Por lo tanto, esta sección identificará algunos de esos
áreas y proporcionar CAE con cierta perspectiva e ideas sobre
cómo manejarlos. Ver Figura 2, Proceso de Auditoría
Descripción general, a continuación.
6.1 Marcos y estándares
Un desafío al que se enfrentan los auditores cuando ejecuta una auditoría de TI es
sabiendo contra qué auditar. Muchas organizaciones no tienen
líneas de base de control de TI completamente desarrolladas para todas las aplicaciones
y
tecnologías. La rápida evolución de la tecnología desearía
hacer que las líneas base sean inútiles después de un corto período de tiempo.
La teoría del copo de nieve dicta que cada entorno de TI
el es diferente Sin embargo, esto no resta valor al
concepto de objetivos de control. Objetivos de control, por definición
ción, debería permanecer más o menos constante desde el entorno
al medio ambiente. Considere el objetivo de que todos los negocios críticos
Los datos y programas deben estar respaldados y recuperados
poder. Ahora, cada entorno puede hacer eso de manera muy diferente;
las copias de seguridad pueden ser manuales o automáticas, o una herramienta puede ser
usado. Podrían ser solo incrementales, o puede haber
copias de seguridad completas de todo. Las copias de seguridad se pueden hacer todos
los días,
semanal, mensual, etc. El almacenamiento de copias de seguridad podría estar en el sitio
en
una caja fuerte a prueba de fuego, fuera del sitio en otra instalación de la compañía, o
fuera
de origen a un tercero. El método utilizado por la organización
la gestión de copias de seguridad sin duda tendría un impacto en la auditoría
procedimientos y el presupuesto para la auditoría, pero el control
el objetivo no cambiaría Dado esto, un CAE debe ser
capaz de comenzar con un conjunto de objetivos de control de TI, y aunque
no proporcionaría una especificidad del 100 por ciento a ese particular
entorno lar, seleccione un marco apropiado.
COSO y COBIT
¿Dónde puede un CAE encontrar un conjunto completo de control de TI?
objetivos? El Comité de Organizaciones Patrocinadoras de la
Treadway Commission (COSO) Internal Control-Integrated
Framework y Enterprise Risk Management - Integrado
Los marcos son excelentes fuentes de información, pero no son
enfocado en TI. Además, TI ha evolucionado mucho desde 1992,
cuando se publicó el marco COSO inicial, que
hace que los objetivos de control de COSO IT sean menos efectivos en
envejecimiento de las tecnologías actuales. Un entorno de control basado en COSO
se debe aumentar con un control de TI más detallado
objetivos para evaluar el entorno de control de TI de manera efectiva. UN
número de opciones disponibles para esto.
Un marco de control de TI es Objetivos de control para
Información y tecnología relacionada (COBIT), que fue origi-
finalmente publicado por el Gobierno de Tecnología de la Información
Instituto en 1994, con el apoyo de la Información
Asociación de Auditoría y Control de Sistemas (ISACA). Versión
4.0 de COBIT fue lanzado en noviembre de 2005. COBIT no es
pretende competir con los marcos COSO, pero puede
ser utilizado para complementarlos aumentándolos con más
objetivos de control robustos específicos de TI. COBIT 4.0 contiene
214 objetivos detallados de control de TI organizados alrededor de 34 IT
procesos. Claramente, COBIT proporciona un enfoque más detallado
que el control interno de COSO o los marcos de ERM, que
proporcionar un buen punto de partida para identificar objetivos de control
información relevante para el ambiente que se audita.
Políticas, estándares y procedimientos
Un marco como COBIT ofrece un conjunto generalmente aceptado
de los objetivos de control de TI que ayudan a la gerencia a
Alize un enfoque para medir y administrar el riesgo de TI.
La gerencia generalmente usaría ese marco para guiar
el desarrollo de un conjunto completo de políticas de TI,
normas y procedimientos.
Por ejemplo, un marco funcional de control de TI
típicamente incluyen un objetivo de control para asegurar la información
sistemas de acceso no autorizado. Una organización podría
lograr este objetivo mediante la definición de una política que especifica
12
GTAG - Ejecución de auditorías de TI - 6
Figura 2 - Descripción general del proceso de auditoría

Página 16
13
GTAG - Ejecución de auditorías de TI - 6
que un usuario único debe tener acceso a todos los sistemas de producción
ID y contraseña. Esta política se vería aumentada por una
estándar organizacional que define el ID y la contraseña
requisitos (por ejemplo, los ID son la primera letra del primer usuario
nombre, seguido de su apellido; las contraseñas deben ser al menos
ocho caracteres de largo y contienen una mezcla de letras y otros
caracteres; etc.). Tal estándar sería entonces aumentado
por procedimientos que definirían cómo se implementan las normas
mencionada plataforma por plataforma y especificaría
la "evidencia de control" creada y retenida a través del éxito
realización del procedimiento. Este enfoque en cascada de
marco de control a la política, estándar y procedimientos es el
esencia de garantizar que los controles de TI se correspondan efectivamente con
el negocio y el entorno de control de la empresa.
Supongamos que en el ejemplo anterior, la organización tiene
no se define un estándar que proporcione detalles sobre la contraseña
longitud, etc. En ese caso, el CAE enfrentará algunos desafíos
para determinar qué auditar y, con frecuencia, terminará
participó en un debate con la administración de TI sobre lo que
tiene un control suficiente. Que es más seguro: una contraseña
con una longitud mínima de seis caracteres que vence cada 30
días, o una contraseña con una longitud mínima de ocho caracteres
que expira cada 90 días? A menudo se hacen referencias a
"Mejores prácticas", pero un vínculo específico no siempre se dibuja.
En ausencia de estándares de control de TI específicos de la organización
Por supuesto, hay varios mercados públicos e industrias
normas de control. Estos pueden ayudar a respaldar los procedimientos de auditoría de
TI
ofreciendo un conjunto de recomendaciones de "mejores prácticas" donde
los detalles específicos están establecidos (por ejemplo, la contraseña debe ser al menos
ocho caracteres y se debe configurar para que caduque cada 60 días). Un
El auditor de TI puede usar estos estándares como referencia para auditar
en contra. Esto también es útil cuando se reportan deficiencias, ya que
elimina la subjetividad de la deficiencia. Comparar
"La seguridad de la contraseña se puede mejorar" con "Contraseñas no
cumplir con los estándares de seguridad de la información ISO27001 ".
Obviamente, la segunda redacción provocará menos debate.
El desafío con el uso de estándares públicos para auditar
contra es que hay muchos estándares diferentes, y
no siempre recomiendo lo mismo El propósito de esto
GTAG no debe debatir los méritos de varios estándares, pero
simplemente para alentar al CAE a considerar apoyar las auditorías de TI
mediante el uso de un estándar, cualquiera que sea el estándar que más
sentido para la organización y es aceptable para la gestión de TI
ment. En la mayoría de los casos, un estándar se relaciona con un elemento muy
específico
del entorno de TI, como la seguridad o la personalización
desarrollo del programa. En la mayoría de los casos, el CAE no está en una
posición para dictar el estándar específico utilizado por la organización
ción. Esta decisión debe tomarla el personal de TI o ejecutivo
agement. Si un estándar ya ha sido acordado y
implementado, el CAE debe identificar esa norma y auditar
En contra. El CAE también tiene la obligación de evaluar el exceso de
toda la suficiencia de los estándares elegidos por la administración de TI para
asegurarse de que respondan al perfil de riesgo de la organización,
requisitos comerciales y requisitos reglamentarios.
Seis fuentes para estándares
Algunos estándares para consideración son:
ISO27001 / ISO17799 - La Internacional
Organización para la Estandarización publicó esto
seguridad genérica reconocida internacionalmente
ty estándar, que comenzó como un estándar británico
(BS7799), evolucionado a un estándar ISO (ISO17799),
y ahora se conoce como ISO27001. Contiene generalmente
mejores prácticas aceptadas en materia de seguridad de la información
gestión y es útil como referencia para que los auditores de TI
auditoría contra. http://www.iso.org
Integración del Modelo de Madurez de Capacidades - Carnegie
Instituto de Ingeniería de Software de la Universidad de Mellon
(SEI) ha publicado Modelos de Madurez de Capacidades
(CMM) para varios procesos dentro de una organización,
principalmente relacionado con el despliegue de software.
Los ejemplos incluyen Systems Engineering CMM y
Software de adquisición de CMM. Estas MMC proporcionan una
modelo para construir procesos controlados sostenibles
dentro de una organización y son útiles para los auditores de TI
realizar auditorías de procesos de desarrollo de sistemas. En
2005, el SEI integró las CMM existentes en el
Integración del Modelo de Madurez de Capacidades (CMMI).
http://www.sei.cmu.edu/cmmi/general/general.html
Instituto Nacional de Estándares y Tecnología
(NIST) - El Centro de Recursos de Seguridad Informática es
una división de NIST que proporciona una amplia
serie de publicaciones que ofrecen información detallada
en temas de control de seguridad de la información. Publicación de muestra
cationes incluyen especificaciones biométricas de datos para personal
Verificación de identidad y orientación para proteger Microsoft
XP para profesionales de TI . Estos estándares, imprescindibles
para cualquier auditor de TI que trabaje en el sector público o en
la industria aeroespacial y de defensa, proporcionan la mejor práctica
también se pueden usar en otras industrias.
http://csrc.nist.gov/publications/nistpubs/index.html
SysAdmin, Auditoría, Red, Seguridad (SANS)
Institute - Una de las fuentes de información más confiables
Educación y formación en materia de seguridad en el mundo
(y con mucho, el más grande), el SANS Institute publica
numerosos documentos sobre diversos aspectos de la seguridad para
varias tecnologías. Las publicaciones SANS proporcionan una
número de requisitos específicos que un auditor de TI puede
auditoría contra. http://www.sans.org/aboutsans.php
La biblioteca de infraestructura de TI (ITIL) - Compatible con
el Instituto Británico de Estándares, ITIL ofrece el mejor
prácticas para apoyar los servicios de TI. Publicaciones de ITIL
se centran en apoyar la gestión de TI
servicios. Como tal, son una valiosa herramienta de apoyo para
un auditor interno que realiza cualquier auditoría de TI
capa de gestión. http://www.itil.co.uk/
Estándares específicos del proveedor : muchos proveedores de tecnología
emite pautas de seguridad y control para la tecnología
ellos producen. SAP, por ejemplo, emite un volumen de tres

Página 17
guía de seguridad que brinda recomendaciones detalladas
para asegurar y controlar la aplicación SAP ERP.
Estos estándares lanzados por los proveedores a menudo no toman
consideraciones de seguridad y control al mismo nivel
que tal vez una publicación de NIST podría, pero
proporcionar un buen comienzo. También pueden ayudar a limitar el debate
alrededor de los hallazgos (por ejemplo, "las restricciones de contraseña de SAP son
no establecido de acuerdo con el proveedor documentado
requerimientos de seguridad"). Los CAE deben verificar con el
vendedores de sistemas de misión crítica para ver si son específicos
estandares estan disponibles En muchos casos, el vendedor puede
no haber lanzado nada, sino el grupo de usuarios asociado
con esa tecnología (p. ej., SAP de las Américas)
Grupo de usuarios).
6.2 Gestión de recursos de auditoría de TI
Los recursos asignados para ejecutar auditorías planificadas juegan un
rol ical en la eficiencia y efectividad de las auditorías. ESO
abarca una amplia gama de tecnología: el conjunto de habilidades
necesario para auditar una configuración de firewall es muy diferente
del conjunto de habilidades necesarias para auditar cuentas por pagar de tres vías
emparejar tablas de configuración en aplicaciones de Oracle. Es critico
ical para unir las habilidades necesarias para realizar una TI en particular
auditoría con el auditor de TI apropiado.
Uno de los retos a los que se enfrentan los DEA es identificar,
contratación y retención de profesionales de auditoría de TI competentes.
Inevitablemente, cualquier discusión sobre este tema se fusionará
la cuestión de contratar a una persona de TI y enseñarle a esa persona cómo
auditar versus contratar un auditor y enseñarle TI.
No hay una solución perfecta, y siempre habrá excepciones
ciones, pero direccionalmente, el DEA debe considerar que no TI
el auditor podrá hacer todas las auditorías de TI. Por lo tanto, cualquier auditoría de TI
función tendrá que tener algunos auditores de TI más alineados
con aplicaciones y algunos auditores de TI más alineados con
tecnologías de infraestructura. En términos de contratación de auditores de TI
quién estará más alineado con las aplicaciones, generalmente es
más eficaz para encontrar personas financieras, de proceso o de auditoría y
enséñales una aplicación particular. En términos de aprovisionamiento de TI
auditores que estarán más alineados con la infraestructura de auditoría
tecnologías, generalmente es más efectivo contratar TI
personas y enséñales a auditar. En consecuencia, un CAE
que tiene un gran conocimiento de la unidad de auditoría de TI actual
verso y los conjuntos de habilidades de auditoría de TI actuales en el personal deben ser
capaz de enfocar sus esfuerzos de reclutamiento en consecuencia.
Estrategia de retención del auditor de TI
Una vez que los auditores de TI han sido contratados, el siguiente desafío clave es
retencion. Los auditores de TI tienden a ser más móviles que los tradicionales.
auditores internacionales debido a la falta actual de auditores de TI capacitados
en el mercado Una forma de que un CAE aborde este problema
es para mejorar la compensación. En muchos casos, los presupuestos no
permitir esto; por lo tanto, el CAE puede necesitar ser creativo
al idear una estrategia de retención.
Muchos auditores de TI están motivados por la exposición a la tecnología
ogy. Disfrutan jugando con tecnologías nuevas y emocionantes.
A continuación hay algunas áreas en las que el CAE puede admitir la retención
metas al aprovechar el deseo del auditor de TI de tecnología
exposición:
Certificaciones : hay una cantidad de tecnología
certificaciones disponibles Estos incluyen técnicos
certificaciones, como varias certificaciones en Cisco
enrutadores y tecnologías de bases de datos, y certificación en
módulos específicos de SAP. ISACA ofrece un certificado
Certificación de Auditor de Sistemas de Información (CISA). ITIL
La certificación de la Fundación proporciona una comprensión básica
de los diversos procesos ITIL para la gestión del servicio
y entrega del servicio. Esta es una necesidad para los auditores de TI
revisar los departamentos de TI usando procesos ITIL.
El CAE puede querer considerar bonos que son
vinculado a certificaciones específicas de "habilidades técnicas", es decir, una TI
auditor recibe una bonificación por convertirse en Cisco
Certified Network Associate (CCNA). Esto permite
la organización para proporcionar una compensación adicional
sin aumentar los salarios base. Además, muchos certifi-
cationes toman un poco de tiempo para lograr, lo que
asegura que un auditor de TI se mantendrá al menos la longitud
del tiempo requerido para obtener la certificación. Una palabra para el sabio,
Sin embargo, a veces los auditores de TI lo recopilarán
certificaciones para salir de la función de auditoría. Es
necesario para examinar cuidadosamente las certificaciones
el auditor de TI desea buscar y asegurarse de que
Aquellos que se ajustan al universo de auditoría de TI programado.
Rotación : considere un programa de rotación entre las TI
departamento y la función de auditoría de TI. Esto puede ayudar
aumentar la capacidad de auditoría de TI, así como fortalecer la auditoría
relaciones con el departamento de TI. Ser consciente de
preocupaciones potenciales de independencia al implementar esto
tipo de estrategia Además, asegúrese de que la función de auditoría de TI
ción puede proporcionar cierta experiencia de auditoría al empleado
TI "rota".
Educación continua : los auditores de TI necesitarán más capacitación
que auditores de proceso o operativos. Allí tienen
han sido relativamente pocos saltos cuánticos en combinaciones de tres vías
en los últimos 10 años, pero ciertamente
han sido grandes avances en TI. Para que los auditores de TI se queden
al corriente, necesitan ser entrenados temprano y a menudo. los
CAE debe reconocer esto y construir una estrategia de entrenamiento
para el departamento que considera las necesidades del
Auditores de TI Se debe considerar desarrollar
experiencia en una amplia gama de temas importantes. Esta
puede lograrse asignando ciertos auditores de TI a
convertirse en expertos en la materia en una tecnología determinada
(por ejemplo, un auditor de TI es el especialista de Microsoft, otro
es el especialista en bases de datos, y un tercero es el especialista en SAP
cialista). Esto proporcionará mejores auditorías que si todo IT
los auditores están entrenados en todas las materias. Sin embargo, requiere
más diligencia y planificación al construir una TI
plan de capacitación de auditoría para el año.
Grupos de usuarios : la mayoría de los proveedores de tecnología mantienen un
grupo de usuarios, que consiste en clientes que usan el
14
GTAG - Ejecución de auditorías de TI - 6

Página 18
15
GTAG - Ejecución de auditorías de TI - 6
tecnología y se reúnen para compartir ideas, preocupaciones,
y con suerte influir en los desarrollos futuros de la
tecnología. Aunque tradicionalmente los grupos de usuarios tienen
sido el dominio de profesionales de TI y negocios
usuarios, en muchos casos, estos grupos pueden ser valiosos para
el auditor de TI también. Los usuarios de SAP de las Américas
Grupo, por ejemplo, mantiene un subgrupo que es
se centró en la seguridad y los controles. Los auditores de TI deberían
buscar los grupos de usuarios para las tecnologías críticas
utilizado por la organización y únete a ellos. En muchos
casos, no puede haber un costo adicional para el organismo
ización. La mayoría de los grupos de usuarios son gestionados por la empresa;
todos los empleados de la compañía son bienvenidos a unirse.
Personal Adecuado
Muchas funciones de auditoría de TI tienen restricciones presupuestarias
evitar que mantengan un personal con el rango de TI
habilidades de auditoría necesarias para auditar el universo de auditoría de TI de manera
efectiva.
La organización no esperaría que el departamento de TI
operar sin la experiencia del personal en los sistemas operativos,
bases, redes y sistemas de aplicaciones. Sin embargo, a veces
espera que la función de auditoría de TI funcione sin suficiente
recursos. Inevitablemente, esto lleva a la auditoría por lista de verificación y
utilizando técnicas de indagación como la principal fuente de evidencia de auditoría
dence. Como se indica a lo largo de este documento, para una TI
función de auditoría para que sea efectiva, un plan de auditoría específico debe ser
impulsado por una sólida evaluación de riesgos y respaldado con auditoría
procedimientos que están diseñados específicamente para los matices de
ese ambiente particular. El CAE debe justificar el
necesidad presupuestaria de respaldar una gama de conjuntos de habilidades de
auditoría de TI para
la alta dirección y el comité de auditoría.
Una razón principal para que el CAE defienda suficientes
recursos proviene del Párrafo 140 del US Public
Estándar de Auditoría de la Junta de Supervisión Contable de la Compañía
No. 2, una auditoría del control interno sobre el financiero
Informes realizados en conjunción con una auditoría de
Estados financieros, que dice:
"... la siguiente [circunstancia] debe ser considerada
como al menos una deficiencia significativa y como un fuerte indicio
cator que una debilidad material en el control interno
sobre informes financieros existe ... La auditoría interna
función o la función de evaluación de riesgos es ineficaz
en una compañía para la cual dicha función necesita ser
eficaz para que la empresa tenga un seguimiento efectivo
componente de evaluación o evaluación de riesgos, como por ejemplo
empresas grandes o altamente complejas ".
La ausencia o presencia limitada de una auditoría interna de TI
función en una organización con un entorno de TI grande o complejo
ambiente podría presentar una situación en la cual la organización
El auditor externo de la empresa podría concluir que el Párrafo 140
puede solicitar.
En algunas circunstancias, el CAE puede querer explorar el
posibilidad de co-sourcing de parte o la totalidad de la función de auditoría de TI.
La mayoría de los CAE entienden los pros y los contras del co-sourcing; esta
La guía no está destinada a ser una introducción. Sin embargo, las CAE gen-
pelean con cuánto co-fuente y qué auditorías TI
para co-fuente. La mezcla óptima varía de organización a
organización (la teoría del copo de nieve se aplica nuevamente), pero CAE
puede ser útil comparar su organización con el
datos siguientes del Instituto de Auditores Internos (IIA)
Informe de la Red de Información de Auditoría Global 2004 (GAIN):
• 39 por ciento de todos los servicios de auditoría interna comprados son
Auditoría de TI relacionada.
• Porcentaje de trabajo de auditoría de TI subcontratado:
- 8.1 por ciento de las organizaciones subcontratan 100
por ciento de su trabajo de auditoría de TI.
- 7.1 por ciento de las organizaciones tercerizan la mayoría
de su trabajo de auditoría de TI.
- 8.3 por ciento de las organizaciones tercerizan entre
25 por ciento y 50 por ciento de su auditoría de TI
trabajo.
- 33.1 por ciento de las organizaciones subcontratan a "algunos"
de su trabajo de auditoría de TI.
- 41.6 por ciento de las organizaciones no subcontratan
cualquiera de sus trabajos de auditoría de TI.
• Estrategia para los próximos tres años:
- 18.9 por ciento de las organizaciones planean aumentar
su tercerización de auditoría de TI.
- 64.9 por ciento de las organizaciones no planean cambios
a su cantidad de outsourcing de auditoría de TI.
- 13.3 por ciento de las organizaciones planean disminuir
su tercerización de auditoría de TI.
Las sugerencias adicionales con respecto al co-sourcing incluyen:
Co-fuente de las auditorías técnicas : en este caso, "técnica-
"auditorías cal" se refiere a las auditorías que se realizan en el
infraestructura técnica y capas de aplicación de
Entorno de TI. En general, estas auditorías requieren una
un nivel mucho más alto de conocimientos técnicos específicos,
que es más probable que se encuentre en el mercado
que internamente Las auditorías de TI de la capa de gestión son
mucho más centrado en los procesos de TI (por ejemplo, sistemas
desarrollo) y por lo tanto requieren menos profundidad
habilidades técnicas.
Considere usar dos proveedores : puede ser útil
mantener contratos con un proveedor primario de
servicios de origen, así como un proveedor secundario. En cier-
En algunos casos, una empresa puede tener un conflicto de intereses en un
auditoría potencial por alguna razón; puede ser útil
tener un proveedor de respaldo esperando y listo para intervenir. A
advertencia: el proveedor principal debe realizar
al menos el 80 por ciento de las actividades de copropiedad.
Cualquier cosa menos que eso y la caída en la eficiencia
(por ejemplo, el doble de reuniones y un aumento de la administración)
sobrecarga general) superará los beneficios. Para asegurar
que los proveedores aprendan el negocio de la organización
bien y tratar a la organización como un cliente importante,
no se deben usar más de dos empresas. Si la firma ABC

Página 19
proporciona la mayoría o todos los servicios de auditoría de TI a un
organización, tendrá una relación diferente con
la organización que si la Firma ABC es una de dos o
tres empresas que proporcionan el 30 por ciento de la auditoría de TI
servicios a la organización.
Co-fuente Auditorías distribuidas a nivel mundial - La mayoría de las empresas
mantener empleados en todas las principales regiones del mundo, y
muchas empresas operan en diferentes estructuras de precios para
recursos locales. Por lo tanto, si una organización quería
auditar sus operaciones en Kuala Lumpur, puede ser capaz de
utilizar una empresa con recursos locales de Malasia a un precio reducido
costo, en lugar de enviar recursos a Malasia. los
Una excepción a esta recomendación es cuando el
carta de auditoría interna dicta que la auditoría interna
función proporcionar una cierta cantidad de consulta
servicios a las unidades de negocios alrededor de los controles. De tal
un caso, puede ser más útil tener una auditoría de equipo
en todo el mundo para que las mejores prácticas internas puedan ser
observado por el equipo y compartido entre las unidades de negocio.
dieciséis
GTAG - Ejecución de auditorías de TI - 6

Página 20
GTAG - Aceleradores de auditoría de TI - 7
17
Como se señaló anteriormente, los presupuestos de auditoría de TI pueden ser difíciles
de estimar
y administrar Los CAE deben buscar oportunidades para usar
aceleradores: herramientas y / o técnicas que ayudan a respaldar el
procedimientos que los auditores de TI realizarán, para aumentar
eficiencia y efectividad de la auditoría. Los CAE pueden usar un
acelerador para hacer la misma auditoría en menos tiempo o hacer más
procedimientos detallados de auditoría en la misma cantidad de tiempo.
Muchos aceleradores de auditoría requieren una inversión, por lo que
CAE debe considerar cuidadosamente los costos / beneficios de cualquier solución
antes de invertir en un acelerador. Aceleradores de auditoría
se puede dividir en dos categorías generales: facilitadores de auditoría,
que ayudan a respaldar la gestión general de la auditoría
(por ejemplo, una herramienta electrónica de gestión de trabajo) y pruebas
aceleradores, herramientas que automatizan el rendimiento de la auditoría
pruebas (por ejemplo, herramientas de análisis de datos).
7.1 Facilitadores de auditoría
Papeles electrónicos
Aunque no es específico solo para auditorías de TI, papel de trabajo electrónico
la administración puede ser muy útil. Estas soluciones brindan
gestión tradi- cional y retención de documentos de trabajo, auditoría
flujo de trabajo, seguimiento de versiones, firma electrónica, etc. Hay
un número de proveedores en el mercado que ofrecen estas herramientas.
Es importante considerar la funcionalidad de la herramienta. por
ejemplo, ¿puede admitir múltiples auditorías simultáneas? Antes de
implementar cualquier herramienta, los requisitos funcionales de auditoría
debe ser definido. Quizás más importante, sin embargo, es el
contenido que se proporciona con la herramienta. ¿Contiene sug-
¿Procedimientos de auditoría o actividades de control gestados? Los CAE verán
simplemente necesita personalizar cualquier base de conocimiento incluida
con la herramienta, pero puede proporcionar una ventaja significativa.
Software de gestión de proyectos
No necesariamente para la auditoría, gestión del proyecto
el software planifica los planes de trabajo, asigna la responsabilidad de
tareas, rastrea los hitos del proyecto y los entregables, y puede ser
utilizado por la función de auditoría de TI para proporcionar con-
tencia y presentación de informes en las auditorías de TI. Gestión de proyectos soft-
ware es utilizado actualmente por el 35 por ciento de la encuesta GAIN 2004
encuestados.
Software de diagrama de flujo
Software que puede documentar gráficamente los flujos de transacciones
puntos de control y pasos clave del proceso es muy útil, casi
necesario - al documentar recorridos de proceso, par-
especialmente para fines de cumplimiento de Sarbanes-Oxley. Almacenamiento
la documentación del proceso gráfico admite electrónicamente el
facilidad de actualizar diagramas de flujo a medida que los procesos cambian y
proporciona
para un fácil almacenamiento y uso compartido. El software Flowcharting es
recientemente utilizado por el 59 por ciento de los encuestados GAIN 2004.
Software de seguimiento de problemas abiertos
Este software permite el seguimiento de problemas de auditoría pendientes
o deficiencias y a menudo se integra con el documento man-
software, especialmente aquellos diseñados para Sarbanes-
Objetivos de cumplimiento de Oxley. La funcionalidad generalmente incluye
la capacidad de asignar responsabilidades para procedimientos de remediación
duros, asignar fechas de vencimiento y entregables, y rastrear e informar
en progreso. El software de seguimiento abierto de problemas es utilizado actualmente
por
47 por ciento de los encuestados GAIN 2004.
Sitio web del Departamento de Auditoría
Varios departamentos de auditoría han establecido departamentos
tal sitios web. Generalmente se basan en intranet, pero pueden ser
Basado en Internet. Las soluciones basadas en Internet ofrecen intercambio global
de información en todas las organizaciones, pero aumenta la confidencialidad
preocupaciones Cualquier tipo de solución proporciona una auditoría interna
función con la capacidad de tener intercambio de información central
y comunicación. Estas soluciones pueden ser desarrolladas a medida
oped o comprado de proveedores. Web del departamento de auditoría
los sitios son utilizados actualmente por el 42 por ciento de la encuesta GAIN 2004
encuestados.
7.2 Prueba de aceleradores
Los aceleradores de prueba pueden automatizar la auditoría que consume mucho tiempo
tareas, como revisar grandes poblaciones de datos. También,
usar una herramienta para realizar procedimientos de auditoría ayuda a establecer
Sistencia. Por ejemplo, si se usa una herramienta para evaluar la seguridad del servidor
configuración del servidor, todos los servidores probados con esa herramienta serán
evaluados a lo largo de las mismas líneas de base. Realizando estos procedimientos
dures manualmente permite un grado de interpretación en el
parte del auditor de TI. Por último, el uso de herramientas permite a las audiencias de TI
para probar toda una población de datos, en lugar de solo una
muestra de transacciones. Esto proporciona un mucho más alto
grado de aseguramiento de la auditoría.
Los CAE deben tener en cuenta las siguientes consideraciones
con respecto a los aceleradores de auditoría de TI:
• Las herramientas cuestan dinero. El CAE debe estar seguro de que
los beneficios superan los costos antes de embarcarse en cualquier
implementación de la herramienta.
• Los auditores de TI necesitarán ser entrenados en el nuevo
herramienta. No es raro que una herramienta no se use en un
departamento de auditoría interna porque nadie sabe cómo
para usarlo Esto reduce claramente el retorno de la inversión
de cualquier herramienta.
• La herramienta también necesitará soporte, administración de parches,
y actualizaciones Dependiendo de la herramienta, puede requerir una
servidor independiente también. Por esta razón, cualquier herramienta
la selección debe ser administrada con el departamento de TI
asistencia.
• En algunos casos, administración de TI o servicio de terceros
los proveedores pueden no permitir que las herramientas accedan a la producción
entorno de trabajo directamente. Cualquier uso de herramientas y / o
las secuencias de comandos deben discutirse a fondo con, y
aprobado por, la administración de TI y ser probado completamente antes
desplegando
Software de análisis de datos
Estas herramientas permiten a un auditor de TI realizar estadísticas sólidas
análisis de grandes conjuntos de datos. También se pueden usar para apoyar

Página 21
GTAG - Aceleradores de auditoría de TI - 7
18
auditorías de proceso o operativas (p. ej. fraude de cuentas por pagar)
revisiones), y pueden soportar muchos tipos de pruebas, como
El análisis de Benford, el muestreo acumulativo, etc. Una consideración
Cuando se utiliza una herramienta de análisis de datos es que puede ser difícil
para extraer los datos de la fuente original. Es crítico que
procedimientos de auditoría para garantizar la integridad y
precisión de los datos de origen. Algunos de los vendedores clave en este
arena son:
• ACL: http://www.acl.com/Default.aspx?bhcp=1
• Idea: http://www.audimation.com/product_feat_
benefits.cfm
• Monarch: http://monarch.datawatch.com/
• SAS: http://www.sas.com/
Herramientas de análisis de seguridad
Se trata de un amplio conjunto de herramientas que pueden revisar una gran cantidad de
población.
ción de dispositivos y / o usuarios e identificar exposiciones de seguridad.
Hay muchos tipos diferentes de herramientas de análisis de seguridad, pero
en general, se pueden clasificar de la siguiente manera:
Herramientas de análisis de red : estas herramientas consisten en soft-
ware programas que se pueden ejecutar en una red y reunir
información sobre la red. Los piratas informáticos suelen
use una de estas herramientas en el frente de un ataque a
determinar cómo se veía la red Los auditores de TI pueden
use estas herramientas para una variedad de procedimientos de auditoría, incluyendo
En g:
• Verificar la precisión de los diagramas de red por
mapeo de la red corporativa.
• Identificación de dispositivos de red clave que pueden justificar
atención adicional de auditoría.
• Recopilación de información sobre qué tráfico es
permitido a través de una red (lo que haría directamente
apoyar el proceso de evaluación de riesgos de TI).
Se puede obtener una lista de las 75 mejores herramientas en
www.insecure.com.
Herramientas de piratería : la mayoría de las tecnologías tienen varias
vulnerabilidades estándar, como la existencia de
ID y contraseñas predeterminadas o configuraciones predeterminadas cuando
la tecnología está instalada fuera de la caja. Hackear herramientas
proporcionar un método automatizado para verificar estos
vulnerabilidades estándar. Tales herramientas pueden ser dirigidas
contra firewalls, servidores, redes y sistemas operativos
Tems. Muchos proporcionan el uso plug-and-go; la audiencia de TI
tor plugs en un rango de lo que quiere que la herramienta busque
para, se va, y regresa en unas pocas horas, o la próxima
día. Para entonces, la herramienta ha desarrollado un informe de todas las
vulnerabilidades
nerabilidades identificadas en ese rango.
Estas herramientas son importantes para que un auditor de TI se postule
varias razones, una de las cuales es que estas son
las herramientas que un hacker usaría para montar un ataque
contra la organización. La organización debería al menos
tener la misma información que un hacker tendría. Sus
importante tener en cuenta que algunas de estas herramientas son potencialmente
peligroso para correr, porque pueden afectar la integridad
de los sistemas que están escaneando. El auditor de TI debería
revise el uso planeado de cualquiera de estas herramientas con el
oficial de seguridad y coordinar las pruebas con el personal de TI
para garantizar que el momento de las pruebas no afecte
procesamiento de producción. En algunos casos, el oficial de seguridad
o los administradores de sistemas ya pueden estar ejecutando algunos de
estas herramientas de forma regular como parte del personal de sistemas
procesos de gestión Si es así, los resultados pueden ser
aprovechado para respaldar las auditorías de TI, si está diseñado adecuadamente y
ejecutado. Se puede obtener una lista de las 75 mejores herramientas en
www.insecure.com.
Herramientas de análisis de seguridad de aplicaciones : si una organización
está usando cualquier aplicación comercial integrada grande
(como un sistema ERP como SAP u Oracle), muchos de
los controles internos clave dependen en gran medida de la seguridad.
Por ejemplo, tal vez la Compañía XYZ tiene una política corporativa
helado que todos los controles de más de $ 10,000 requieren gestión
aprobación antes de emitir. Eso es ciertamente un buen control.
Ahora, suponga que la empresa XYZ ha configurado su
Sistema Oracle para que cualquier cheque creado sobre $ 10,000
se coloca automáticamente en una cola de espera para alguien
para aprobar y liberar Este ejemplo es otro uso sólido
de los controles de TI para respaldar las políticas corporativas. Ahora, supongamos
que todos los usuarios en el sistema Oracle tengan acceso completo a la
sistema. Obviamente, cualquier usuario podría entrar en la explotación
hacer cola y aprobar y liberar el cheque. Es por esto
razón por la cual la seguridad del nivel de la aplicación debe estar bien
diseñado y construido en conjunto con la aplicación
procesos y controles. Además, este es un ejemplo de por qué
cualquier tipo de auditoría (financiera, de proceso, operacional o de TI)
en un gran entorno de aplicaciones integradas necesita
incluir un componente de seguridad del usuario para que sea efectivo.
Lamentablemente, la construcción de la funcionalidad para apoyar la aplicación
las auditorías de seguridad del usuario no son necesariamente una prioridad para
muchos ven-
dors, que tienden a estar más centrados en las operaciones.
En consecuencia, a menudo es extremadamente engorroso y
suming para realizar auditorías de seguridad del usuario de la aplicación. Estas
las auditorías pueden acelerarse mediante el uso de una aplicación de seguridad
herramienta de análisis, muchos de los cuales tienden a ser especializados para diversos
sistemas de aplicación (PeopleSoft, SAP u Oracle) y analizar
la seguridad del usuario contra las reglas preconfiguradas. Estas herramientas también
pueden
evaluar la segregación de deberes dentro de la aplicación. los
CAE debe saber que la mayoría de estas herramientas vienen con un conjunto
de las reglas preconfiguradas o de las "mejores prácticas" promocionadas por los
vendedores.
la teoría del copo de nieve, cualquier implementación de una de estas herramientas
deberá ir acompañado de un proyecto sustantivo para crear
un conjunto de reglas que es relevante para esa organización en particular.
De lo contrario, se generarán informes de auditoría que contienen un número
de falsos positivos o falsos negativos.
Algunos vendedores clave en este campo son:
• Approva: http://www.approva.net/
• LogicalApps: http://www.logicalapps.com/
• Virsa: http://www.virsa.com/
• Software Q: http://www.qsoftware.com/index.htm
• Control Solutions International:
http://www.csi4sap.com/en/home/

Página 22
La auditoría de TI ha existido por muchos años. Sin embargo lo és
en constante evolución y cambio. En consecuencia, el CAE
debe adaptar y evolucionar continuamente el enfoque de auditoría de TI
y el universo de auditoría de TI para realizar procedimientos de auditoría de TI
que son necesarios para cumplir con los requisitos de
y ayudar a administrar el riesgo comercial general de
la organización.
Aunque esta guía no tiene todas las soluciones y,
en algunos casos, puede generar más preguntas de las que responde,
con suerte, el CAE puede usarlo como una herramienta para ayudar con este evo-
lution Las siguientes preguntas se proporcionan para ayudar a los CAE
ya que consideran estos problemas en el contexto de su organización
ción:
• ¿Ha definido claramente la organización qué significa TI?
en su organización particular? Son los principales
las áreas de responsabilidad del oficial de mación documentadas?
¿El enfoque de auditoría de TI considera todos aquellos
áreas al evaluar el riesgo y definir la auditoría de TI
¿universo?
• ¿La función de auditoría desempeña un riesgo efectivo de TI?
evaluación anual? Son especialistas conocedores
en tecnologías de infraestructura, sistemas de aplicaciones,
y TI procesa a todos los involucrados en esa evaluación?
• ¿La evaluación de riesgos de TI considera el
arquitectura y configuración tecnológica
empleado por esa organización?
• ¿Cómo se cuantifican los riesgos de TI? Son impacto y
probabilidad de ocurrencia estimada? Qué industria
los puntos de referencia y las mejores prácticas se utilizan para apoyar
estas estimaciones?
• ¿El universo de auditoría de TI planifica auditorías en cada
capa del entorno de TI? ¿Si no, porque no? Son
hay circunstancias especiales que se aplican, o es el IT
plan de auditoría subóptimo?
• ¿Cómo se estiman los presupuestos para las auditorías de TI? Estaba
suficiente información reunida en el frente de la
auditoría para apoyar una estimación precisa? Fue el
configuración específica de la tecnología considerada?
• ¿Cómo se definen los procedimientos de auditoría de TI? Son ellos
desarrollado internamente para el específico de la organización
ambiente, o se utilizan listas de verificación de mercado?
• ¿Ha implementado la organización algún control de TI?
marcos o estándares? ¿De ser asi, cuales? Si no,
tener líneas de base de seguridad y control establecidas
¿internamente? Si no, el CAE recomendó el
implementación de un marco de control de TI y
líneas de base de seguridad y control como parte de la auditoría de
Gobierno y gestión de TI
• ¿Se utilizan herramientas para acelerar las auditorías de TI (por ejemplo, pruebas
aceleradores o facilitadores) ¿Si no, porque no? Si
Entonces, ¿han sido probados completamente y aprobados por TI?
¿administración?
• ¿Cómo se integran las auditorías de TI? Son especialistas usados para
varias tecnologías (por ejemplo, aplicaciones versus
tecnologías de estructura)? ¿Si no, porque no? Como son
Los documentos de auditoría de TI revisados por calidad y
¿adecuación?
• Se ha establecido una estrategia de entrenamiento para TI
auditores? ¿Considera todas las capas de la TI?
¿ambiente?
• Los problemas y riesgos emergentes de TI son evaluados cada año
para determinar la relevancia dentro de la organización?
¿Cómo identifica la organización estos emergentes?
¿cuestiones?
• ¿La función de auditoría ha comparado la auditoría de TI?
función contra las mejores prácticas de la industria? Fue el
Encuesta GAIN u otros repositorios de datos utilizados para
facilitar esto?
• ¿Todas las auditorías de procesos contienen procedimientos que evalúan
configuración de la aplicación para las aplicaciones
que automatizan los procesos? ¿Cómo se coordinan estos
entre los recursos de auditoría (proceso versus TI)?
19
GTAG - Preguntas para el CAE - 8

Página 23
La Ley de Moore predice la evolución continua de la tecnología
gy. Este apéndice cubre algunas tecnologías emergentes de
qué CAE deben tener en cuenta, y el impacto potencial en
la organización y la función de auditoría de TI. De ninguna manera es
esta es una lista completa de todas las tecnologías emergentes, pero
es indicativo de algunos de los problemas más frecuentes en el
mercado.
Estos problemas ciertamente variarán de un entorno a
medio ambiente (la teoría del copo de nieve) y puede presentar
mayor o menor riesgo según la industria, la tecnología o
Procesos de negocios. Los problemas, junto con sus riesgos y
ommendations, se presentan en un orden particular, pero son
diseñado para lograr que los CAE piensen sobre su entorno y
si los procedimientos de auditoría de TI actualmente programados evaluarán
comió estos problemas
A.1 Redes inalámbricas
Las redes inalámbricas están proliferando en toda la organización
ciones, porque son útiles y pueden apoyar negocios
objetivos directamente. Sin embargo, también son fáciles de configurar (como
cualquier persona que haya configurado una red inalámbrica doméstica puede hacer
atestiguan) y proporcionan un posible punto de entrada a la cor-
red de Porate. Los CAE deberían preocuparse tanto por el
seguridad de las redes inalámbricas que están autorizadas por el
organización, así como redes inalámbricas deshonestas que los usuarios
han establecido sin autorización.
Riesgos de red inalámbrica
Intrusión : las redes inalámbricas pueden permitir el acceso no autorizado
entrada en la red corporativa.
Escuchas ilegales - Las redes inalámbricas pueden permitir no autorizados por
personal calificado para acceder a información confidencial que
se transmite a través de redes inalámbricas.
Secuestro - Un usuario no autorizado puede secuestrar la sesión
de un usuario autorizado conectado a una red inalámbrica
y use esa sesión para acceder a la red corporativa.
Gestión de radiofrecuencia (RF) : la red inalámbrica
el trabajo puede enviar transmisiones a áreas no deseadas,
que puede tener otros impactos. Por ejemplo, hospitales
puede tener un equipo que reacciona mal a la onda de radio
transmisiones y por lo tanto no deberían estar expuestos a
Conexiones inalámbricas.
Recomendaciones para redes inalámbricas
Realice una auditoría de red inalámbrica completa que incluya
siguiendo dos componentes:
• Es muy probable que la organización tenga redes inalámbricas
que han sido aprobados e implementados para una
Razón comercial científica. La función de TI debe evaluar
estas redes y ayudan a garantizar que estén aseguradas
y controlado de acuerdo con la gestión
objetivos.
• La organización puede tener una conexión inalámbrica no aprobada
redes que los usuarios han establecido. La auditoría de TI
la función debe realizar procedimientos para detectar si alguno de
estas redes existen y toman las medidas apropiadas. Esta
es más difícil que asegurar que las redes sean
asegurado y controlado y es probable que implique una TI
auditor pasando físicamente por la locación de la unidad de negocios
con una antena, tratando de detectar la presencia de
Dispositivos inalambricos.
Como mínimo, el auditor de TI debe obtener y revisar
una lista de todas las redes inalámbricas aprobadas por la organización
ción. Se deben establecer políticas y procedimientos corporativos
para redes inalámbricas y debe proporcionar directrices
para asegurar y controlar estas redes, incluido el
uso de encriptación de datos y autenticación a la red inalámbrica
red. El auditor de TI debe revisar la configuración de
las redes inalámbricas conocidas para garantizar el cumplimiento de
políticas y procedimientos desarrollados. El auditor de TI debería
detectar redes inalámbricas no aprobadas y tomar
comió acción correctiva.
A.2 Dispositivos móviles
La mayoría de las organizaciones han reconocido el valor de la tecnología inalámbrica
dispositivos como Blackberrys, Personal Digital Assistants
(PDA), teléfonos inteligentes o unidades TELXON y tienen prolifer-
estos dispositivos para respaldar los objetivos comerciales. Sin embargo,
no todas las organizaciones han comprendido el riesgo de usar estas
dispositivos.
Riesgos de dispositivos móviles
Muchos de estos dispositivos almacenan datos comerciales críticos en el
dispositivo en sí. Si el dispositivo no está configurado de manera segura
ion, la confidencialidad de estos datos puede verse afectada si
dispositivo se pierde o es robado. Además, la transmisión de datos a la
el dispositivo en sí mismo puede no ser seguro, potencialmente comprometedor
la confidencialidad o integridad de esos datos. Porque estos
dispositivos son a menudo utilizados por la alta dirección, esto podría ser
empresa. Además, estos dispositivos pueden permitir control remoto
acceso a redes corporativas, y en el caso de TELXON
dispositivos similares, pueden iniciar el procesamiento de
comportamiento. Considere, por ejemplo, un servicio de distribución de bebidas
empresa que equipa los controladores de ruta con dispositivos inalámbricos que son
utilizado para reservar transacciones de inventario a medida que entregan el producto
a cada cliente
Recomendaciones para dispositivos móviles
El auditor de TI debe revisar la administración de dispositivos móviles.
Como mínimo, se debe considerar:
Aprovisionamiento : el proceso para que un usuario adquiera un dispositivo.
Estandarización : ¿Los dispositivos están estandarizados?
Configuración de seguridad : qué políticas y procedimientos
se han establecido para definir las líneas de base de seguridad
para dispositivos?
Transmisión de datos : ¿cómo se controla la transmisión de datos?
Acceso a redes corporativas : ¿los dispositivos proporcionan
acceso a la red corporativa? Si es así, ¿cómo es eso?
¿revisado?
20
GTAG - Apéndice A - Cuestiones emergentes

Página 24
21
GTAG - Apéndice A - Cuestiones emergentes
Dispositivos perdidos o robados : ¿cómo se identificaría la empresa?
tificar los dispositivos perdidos o robados y terminar el servicio a
¿ellos?
Software de interfaz : si estos dispositivos inician un negocio
transacciones, ¿cómo se interconecta esa información con
las aplicaciones corporativas?
A.3 Interfaces
Los entornos de TI complejos a menudo requieren interfaces complejas
para integrar sus aplicaciones comerciales críticas. Incluso grande
entornos de ERP integrados a menudo requieren complicados
interfaces con otras aplicaciones distribuidas, como sistemas de Internet
Tems. Estas interfaces pueden habilitarse con middleware
tecnología, que actúa como un punto central de comunicación
y coordinación para interfaces. Aunque las interfaces y
middleware juega un papel importante en el procesamiento de extremo a extremo
de las transacciones, en muchos casos no están incluidas en la auditoría
planes. Esto puede deberse a que las interfaces son difíciles de clasificar.
Son similares en función a una infraestructura, o soporte-
tecnología, sin embargo, son aplicaciones de software que pueden
en realidad procesa transacciones.
Riesgos de interfaz
Las interfaces, y el middleware en particular, son un enlace crítico en
el procesamiento de transacciones de extremo a extremo. A lo mínimo,
mueven datos de un sistema a otro. Como máximo,
ellos pueden ser responsables de transformar los datos, realizar
Cálculo o modificación de los datos en función de
algoritmo. Las interfaces también pueden presentar un único punto de falla
a la organización. Considere la empresa XYZ, que es
ejecutando un sistema ERP para la consolidación financiera. El dis-
las unidades de negocio tributadas mantienen interfaces de una variedad
de sistemas dispares hasta el sistema corporativo central.
Hay aproximadamente 200 de estas interfaces, todas corriendo
a través de un solo servidor de middleware y aplicación. Ese
el servidor de middleware deja de funcionar de repente. Esto sería
tener un impacto sustancial en las operaciones de la compañía.
Recomendaciones para interfaces
El CAE debe garantizar la evaluación y auditoría de riesgos de TI
universo considera interfaces y middleware. Artículos específicos
eso debe ser considerado son:
Uso de software para gestionar interfaces : ¿el
el software transforma los datos o simplemente lo mueve del lugar
¿poner?
ID de interfaz: el software de interfaz probablemente necesitará
acceso a los sistemas hacia / desde el cual se mueve
datos. ¿Cómo se maneja este acceso? Son identificadores genéricos
¿usado? ¿Qué acceso se otorgan estas identificaciones y quién tiene
acceso para usar estos ID?
Directorios de interfaz : ¿se mueven todos los datos a través de un
solo directorio de interfaz? Quién tiene acceso a eso
¿directorio? ¿Cómo está asegurado y controlado? por
ejemplo, ¿tiene un empleado en una de las unidades de negocio
acceder al directorio para cargar un archivo para la transacción
¿tratamiento? Si es así, ¿el directorio también contiene datos?
utilizado en transferencias electrónicas o pagos electrónicos salientes
ments? ¿Cómo se restringe el empleado de estos conjuntos de datos?
¿Los datos se mezclan potencialmente?
Tipos de interfaz : ¿qué tipos de interfaces se utilizan? Son
¿están orientados en tiempo real o por lotes? Qué transacciones
¿apoyan? ¿Inician el procesamiento de
otras transacciones (p. ej., órdenes de ventas intercomunicadas)
ing el envío de mercancías).
A.4 Gestión de datos
Las organizaciones están automatizando más y más negocios
procesos y funciones. Al mismo tiempo, el costo de los datos
el almacenamiento es cada vez más barato y más barato. Incluso hoy en día
las computadoras personales pueden tener discos duros que almacenan 250 GB o
más datos, mucho más de lo que incluso los grandes servidores podrían almacenar
hace cinco años. Estos problemas han llevado a la proliferación de
grandes soluciones de almacenamiento de datos corporativos. No es poco común
para una organización de tamaño medio para almacenar y administrar terabytes de
datos comerciales A medida que las organizaciones comienzan a manejar estos grandes
repositorios de datos, surgen muchos problemas.
Riesgos de gestión de datos
Error al administrar los repositorios de datos o las redes de área de almacenamiento
(SANS), puede ocasionar la pérdida de información comercial crítica
capacidad. Las organizaciones deben garantizar que la integridad de estos
las soluciones de almacenamiento se mantienen adecuadamente. Sin embargo, puede
ser difícil hacer una copia de seguridad, o reorganizar una red de almacenamiento de
datos
que contiene seis terabytes de datos comerciales. Nueva gestión
las tecnologías de mantenimiento y mantenimiento deben desplegarse, y
Se deben definir nuevos procesos de gestión. Por otra parte, el
el crecimiento en el almacenamiento de datos también coincide con la promulgación
de muchas leyes, estatutos y reglamentos nuevos sobre la
gestión de datos. Por lo tanto, la gestión de datos
requisitos de una organización también deben cumplir con
nuevos requisitos legales y de industria.
Recomendaciones para la gestión de datos
Realice una revisión exhaustiva de la administración de datos. En un mini-
mamá, se debe considerar:
Clasificación de datos : ¿la organización ha pasado?
un ejercicio de clasificación de datos? Qué tipos de datos
categorías se han establecido, y ¿cuál fue el
criterios para organizar los datos en esas categorías?
Propiedad de los datos : tiene la organización formalmente
¿propiedad de datos asignada a propietarios de datos específicos?
Tienen las responsabilidades de estos propietarios de datos
documentado?
Retención de datos : se ha implementado una estrategia de retención de datos
¿desarrollado? Incluso grandes soluciones de almacenamiento de datos pueden llenar
arriba, en qué punto la organización necesita
eliminar datos o mover datos a otro almacenamiento
solución, como archivarlo. Cuál es el actual
política de archivo / retención? ¿Cómo afecta esto o
apoyar los objetivos de la organización? Si una auditoría necesita

Página 25
para ser realizado, ¿los datos estarán allí para auditar? O
¿Habrá sido archivado o eliminado? Si ha sido
archivado, ¿se puede recuperar fácilmente?
Herramientas de archivo y retención : si es una retención de datos
estrategia se ha definido, puede requerir herramientas para
portarlo, como software de archivo o archivar medios.
Estas herramientas pueden necesitar ser auditadas para evaluar cómo
efectivamente están llevando a cabo los procedimientos requeridos.
Gestión de datos : ¿cómo se gestionan los datos? Qué son
las tareas diarias / semanales / otras que deben realizarse
para ayudar a garantizar la integridad de los datos? Quién realiza
esas tareas, y ¿cómo son procesadas?
A.5 Privacidad
La privacidad de los datos y los derechos del consumidor son temas altamente visibles
hoy. Una gran cantidad de leyes de privacidad de datos con las cuales
las empresas deben cumplir han sido promulgadas. En algunos
casos, estas leyes pueden tener requisitos sustancialmente diferentes
hasta el punto de incompatibilidad con uno y otro
er. Por ejemplo, una gran organización que hace negocios en
Europa y América del Norte están sujetos a la privacidad de la UE
Directiva sobre protección de datos, Personal de Canadá
Ley de Protección de Datos y Documentos Electrónicos de
2000, cualquier cantidad de reglamentaciones estatales de los Estados Unidos, y
requisitos específicos de la industria, tales como la salud de los EE. UU.
Ley de Portabilidad y Responsabilidad de Seguros de 1996 o la
Ley Gramm-Leach-Bliley de 1999. Todos estos son diferentes. Si
una organización quiere poner un sitio web que proporciona
juegos o medios a los que los niños pueden acceder, deben ser
conocedor de las leyes de privacidad de datos de protección infantil también.
Riesgos de privacidad
El incumplimiento de ciertas leyes de privacidad podría resultar en
multas y / o enjuiciamiento criminal. Además, podría haber
ser un impacto significativo para el valor de marca. Considera un cereal
fabricante que pone los juegos promoviendo su cereal en el
web corporativa. Una cantidad de niños se registra en el sitio
y juega los juegos. Un hacker luego compromete la lista de
usuarios registrados, que contiene algunos identificables personalmente
información sobre los niños que están registrados en el
sitio. El Wall Street Journal luego publica una historia sobre cómo
la compañía de cereales permitió que la información de identificación personal
sobre la fuga de niños en Internet. ¿Cuál sería el
impacto de esa situación? Es difícil cuantificar el impacto
en la organización, pero es probable que el resultado no
tener un impacto positivo en el valor para el accionista.
Recomendaciones para la privacidad
Realice una auditoría de privacidad. Como mínimo, la organización
Debería considerar:
Qué leyes de privacidad se aplican a la organización : tiene
la organización identificó todas las diversas leyes, reglamentos
ciones y estatutos con los que debe cumplir?
Responsabilidad por la privacidad : tiene un jefe de privacidad
rol creado? Cuáles son las responsabilidades de eso
¿papel? Cuál es el papel del abogado general con respecto
a la privacidad?
Políticas y procedimientos : tener políticas y procedimientos
sido establecido para crear, almacenar y administrar
datos comerciales? ¿Cómo se implementan estos y cómo?
¿la organización asegura el cumplimiento?
Tareas de cumplimiento : qué tareas específicas de cumplimiento son
realizado? ¿La organización requiere cifrado de datos?
¿verdad? Si es así, ¿qué métodos se usan? ¿Se está desarrollando la web?
metodologías actualizadas para incluir elementos tales como
¿Políticas opt-in?
A.6 Segregación de deberes
A medida que las organizaciones integran sus entornos en más grandes,
aplicaciones más complejas, la segregación de funciones es menor
función del puesto de trabajo y más una función de qué transacciones
el usuario puede realizar en el sistema. En consecuencia,
La segregación de tareas depende en gran medida de la aplicación
nivel de seguridad
Al mismo tiempo, sin embargo, la seguridad del nivel de la aplicación es
cada vez más complejo y requiere un mayor nivel
de experiencia para administrar apropiadamente. Como resultado, muchos
organizaciones están experimentando deficiencias relacionadas con la segregación
gación de deberes. Por último, la complejidad del nivel de aplicación
la seguridad hace que sea más difícil auditar la segregación de deberes
Efectivo y eficiente.
Segregación de riesgos de trabajo
La segregación inadecuada de deberes podría exponer a la organización
robo, fraude o uso no autorizado de información
recursos. Por otra parte, deficiencias en la segregación de deberes
podría afectar negativamente el cumplimiento de Sarbanes-Oxley. UN
número de debilidades materiales en el control interno
informado por las empresas que cotizan en bolsa en 2004 se relacionaron
a la segregación de deberes.
Recomendaciones para la segregación de tareas
Realice una auditoría de segregación de funciones, que debe incluir:
Entender cómo se está segregando los deberes
Administrado y controlado : qué procesos, personas y
herramientas se utilizan para apoyar la gestión de la segregación de
deberes?
Definición de Conflictos - ¿Ha desarrollado la organización un
lista exhaustiva de todas las funciones de trabajo que se consideran
¿incompatible? ¿Cómo se ha modificado esta lista para los negocios?
ubicaciones de unidades que tienen un personal significativamente más pequeño? Quien
estuvo involucrado en el desarrollo de la lista? Todos eran intereses clave
titular involucrado en el establecimiento y aprobación de conflictos?
Determinación de deficiencias específicas - Tiene la organización
utilizó la lista de conflictos para identificar cualquier seguridad específica
roles, o individuos específicos a quienes se les ha otorgado acceso
que presenta una violación de la segregación de deberes? Es una herramienta
siendo utilizado para facilitar este proceso? Si es así, ¿cómo ha sido la herramienta?
sido configurado? ¿La herramienta procesa y monitorea
Flicts en tiempo real?
22
GTAG - Apéndice A - Cuestiones emergentes

Página 26
23
GTAG - Apéndice A - Cuestiones emergentes
Asignar Responsabilidad - ¿Ha formalizado la organización
responsabilidad asignada para administrar y controlar
segregación de deberes a un individuo o trabajo específico
¿papel? Si es así, ¿qué tareas implica esta responsabilidad?
y ¿cuál es el período de rendimiento? Tener políticas
y procedimientos establecidos para guiar este rol?
Realizar un análisis de aplicación cruzada : tener herramientas,
políticas y procedimientos establecidos para administrar
analizando la segregación de tareas entre las aplicaciones?
Ejemplo: la empresa XYZ está utilizando SAP para fines financieros
contabilidad y PeopleSoft para recursos humanos. UN
el usuario tiene acceso a ambos sistemas, y la combinación
el acceso crea un conflicto de segregación de deberes. Análisis
del sistema SAP o del sistema PeopleSoft
no revelaría el conflicto Solo una aplicación cruzada
el análisis de ambos sistemas revelaría el conflicto.
A.7 Acceso Administrativo
El personal de administración de sistemas generalmente recibe altas
niveles de acceso a los recursos de TI. Esto es explicado
porque se presume que son administradores que necesitan
este acceso para realizar su trabajo.
Riesgos de acceso administrativo
Los usuarios con acceso de nivel administrativo pueden potencialmente
formar muchas funciones más allá de su trabajo principal
responsabilidades. Un usuario con pleno acceso a una aplicación comercial
ción, por ejemplo, potencialmente podría crear una factura,
recibir bienes y cortar un cheque. Esta misma administración
el usuario también podría eliminar todos los registros de seguimiento de auditoría. Un
usuario con
el acceso administrativo a la base de datos podría apropiarse indebidamente
la ejecución completa del pago electrónico.
A medida que las organizaciones continúan automatizando e integrando
sus entornos de TI, los riesgos contables administrativos
incrementar. Un administrador de sistemas con acceso ilimitado a un
el sistema SAP de alcance completo tiene mucha más potencia que un sistema
administrador con acceso ilimitado a un sistema de depósito.
El hecho de no restringir adecuadamente el acceso administrativo es un significado
icant exposición, y para las empresas que cotizan en bolsa podría
impactar la Sección 404 de Sarbanes-Oxley del auditor externo
opinión. Para las empresas que subcontratan algunas o todas las TI
medio ambiente, este riesgo es aún mayor por dos razones:
• En muchos casos, el proveedor subcontratado puede servir mul-
tiple organizaciones con un gran equipo. Por lo general, esto
significa que en lugar de un equipo de cinco administradores
apoyando una organización, puede haber un equipo de 25
administradores que apoyan colectivamente a cinco organizaciones
ciones. Si es así, probablemente se otorgarán los 25 administradores
un nivel significativo de acceso.
• A pesar de los acuerdos contractuales, es
siempre un mayor riesgo cuando alguien que no es un
empleado de la organización tiene acceso administrativo
a los sistemas.
Recomendaciones para acceso administrativo
En cada entorno, se requiere acceso administrativo para
operar los sistemas. Sin embargo, la función de auditoría de TI debería
ayudar a garantizar que los administradores de sistemas solo tengan acceso a
datos y funciones requeridos para realizar las responsabilidades del trabajo.
Tenga en cuenta que esto no incluye las transacciones funcionales.
Los administradores de sistemas nunca, como parte de su trabajo
deberes, publicar una transacción en el L / M, cortar un cheque o
contiene un registro maestro de proveedor. Como tal, no deberían tener
acceso para realizar estas transacciones. Otro argumento típico
es que los administradores necesitan un acceso funcional a
bleshoot. Sin embargo, la mayoría de los problemas y pruebas deben
hacerse en el entorno de prueba, no en producción. Si el
entorno de prueba no es una representación adecuada de pro-
ducción, que indica un defecto en el desarrollo de sistemas
proceso, no una necesidad de un mayor acceso a la producción.
El auditor de TI también debe considerar:
Dividir acceso - Dividir el acceso para realizar una función
para que se necesiten dos personas para realizar el
función.
ID genéricos : en ciertos casos, un equipo administrativo
puede estar compartiendo una identificación administrativa. El auditor de TI
revisar un informe de acceso solo vería un solo usuario,
pero la realidad puede ser que múltiples usuarios están usando
esa identificación. Esto aumenta el riesgo porque ahora la auditoría
el sendero está comprometido.
Número de personas con acceso de administrador : acceso
a las funciones administrativas debería limitarse a
pequeña cantidad de administradores solamente. No todos en
el departamento de TI necesita acceso administrativo.
Auditoría de gestión de senderos : dado que administrativa
los usuarios tienen un alto nivel de acceso a los sistemas, uno de
los únicos controles mitigantes disponibles son los periódicos
revisión independiente de pistas de auditoría. Esta revisión puede ser
realizado por el personal de auditoría de TI o por otros
recursos (por ejemplo, un director de TI en otra función de TI)
ción) Es fundamental asegurarse de que, si es posible, los sistemas
el personal administrativo no puede eliminar la pista de auditoría
datos. Este paso a menudo se puede realizar a través de
seguridad o configuración de sistemas.
Uso de identificadores Firecall: los ID y contraseñas Firecall también pueden
ser utilizado para ayudar a mitigar el riesgo de otorgar
acceso trative Una identificación Firecall es una cuenta configurada con
acceso de nivel de administrador. Esta cuenta se mantiene
bloqueado, y la contraseña es conocida solo por un
persona pendiente dentro de la organización. Cuando un
emerge situación de emergencia, el personal de soporte de TI
recupera la contraseña para la identificación Firecall, y esto
la recuperación se registra. La persona de soporte usa la ID para
realizar las tareas requeridas y devuelve la ID a la
persona independiente, que luego bloquea la cuenta.
Hay algunas herramientas nuevas disponibles en el mercado
hoy que automatizan este proceso.

Página 27
GTAG - Apéndice A - Cuestiones emergentes
24
A.8 Controles configurables
Como se discutió en la introducción a este GTAG, muchos de
los controles clave de hoy están basados en la tecnología o configurados en
aplicaciones de negocios. Considere el sistema de tres vías automatizado
ejemplo de coincidencia explorado en la Introducción. La función-
La calidad de este proceso de coincidencia está controlada por varios
configuraciones configurables dentro de la aplicación (por ejemplo, tolerancia
niveles, tipo de coincidencia por cantidad o valor, qué hacer con
transacciones que no coinciden, qué cuentas hay que reservar
ances a, etc.).
En muchos casos, estos controles configurables son los principales
mary controles que administran y controlan el procesamiento de
transacciones a través de un proceso determinado. Sin embargo, estos
Los controles a menudo se pasan por alto al realizar una auditoría de proceso.
Controles configurables Riesgos
No considerar controles configurables de la aplicación cuando
realizar una auditoría de proceso puede resultar en una auditoría ineficaz
procedimientos o conclusiones de auditoría inexactas. Además, es
a menudo mucho más rápido para revisar una configuración configurada en línea
que realizar y revisar una muestra de 60 transacciones.
Por lo tanto, la falta de enfoque en controles configurables también puede
dar lugar a procedimientos de auditoría ineficientes.
Recomendaciones para controles configurables
La evaluación de los controles configurables no debe realizarse como
una auditoría de TI independiente. Por el contrario, todas las auditorías orientadas a
procesos
debe evaluar las configuraciones configurables que controlan
proceso particular como parte de la auditoría general. Esto puede suponer
un desafío de coordinación porque los auditores de TI probablemente necesitarán
para trabajar de la mano con los auditores de procesos para determinar
qué configuraciones son importantes y para realizar el requerimiento
procedimientos de auditoría técnica.
El CAE debe revisar el plan de auditoría para todos los planes
procesar auditorías. Si el plan no incluye pruebas de con-
controles figurables, se debe desafiar a determinar por qué
no se están revisando controles configurables. El hecho de que
no están siendo revisados, no es necesariamente una debilidad;
puede haber una cantidad de razones válidas por las que se puede configurar
los controles no son relevantes para esa auditoría en particular.
Si los controles configurables son relevantes para un particular
auditoría de procesos, es importante considerar cómo las pruebas de estos
se realizarán controles Entrando en una tabla de configuración
y la evaluación de la configuración requiere un conjunto de habilidades muy diferente
que revisar una muestra de 60 transacciones. CAE efectivos
elaborar un plan de auditoría que utilice los conjuntos de habilidades correctas en el
derecho
lugares. Para las auditorías de proceso, esto puede significar coordinar la auditoría
procedimientos entre múltiples auditores en una sola auditoría. Esta
tipo de coordinación puede crear algunos desafíos logísticos,
pero debería resultar en una mejor auditoría.
A.9 Piratería
Las actividades de piratería informática son más frecuentes hoy en día, entonces
alguna vez antes. A medida que las organizaciones automatizan sus empresas,
más activos se convierten a forma digital. Gestión digital
los activos pueden, para ciertas compañías, ser más críticos para el
éxito de la compañía que proteger los activos físicos. los
Internet ha creado una red de distribución global que
digital rápido y anónimo de pirateado digital
bienes.
Riesgos de piratería
A medida que aumenta el valor de los activos digitales, el riesgo asociado
con la piratería también aumenta.
Ciertas organizaciones e industrias ven la piratería como una de
los mayores riesgos que enfrentan hoy. Obviamente, el bate reciente
entre la industria discográfica y los diversos medios digitales
sitios de intercambio de música (por ejemplo, Napster) son solo un ejemplo de
esta.
El impacto monetario directo de la piratería es difícil de cuantificar
fy, pero muchas organizaciones estiman que la piratería tiene
impacto de línea de decenas, si no cientos, de millones de dólares.
Recomendaciones para la piratería
Realizar una auditoría de gestión de activos digitales, que debería
incluir:
Inventario de todos los activos digitales mantenidos por
Organización - ¿La organización tiene una corriente
lista de todos los activos digitales y sus respectivos archivos físicos
y lugares lógicos?
Clasificación - ¿Ha pasado la organización por una excavación?
¿Ejercicio de clasificación de activos italianos? Si es así, ¿qué criterio?
fueron utilizados para el ejercicio? ¿Qué estratos se definieron?
Almacenamiento : ¿Dónde se almacenan los activos digitales? Cómo son
almacenado? ¿Se guardan las copias de seguridad adecuadas? Si las copias de seguridad
son
almacenados en otro lugar, ¿cómo están asegurados y con-
Trolled?
Cifrado de datos : ¿los activos digitales están sujetos a encriptación?
tecnologías de la información? Si es así, ¿qué tecnologías? Hacer el
Los métodos de encriptación tienen sentido para esos tipos de
¿bienes?
Acceso administrativo y de terceros : si los activos digitales
están asegurados, ¿qué otras personas tienen acceso a esos?
Ejemplo: la empresa XYZ está haciendo su último verano
película superventas. Ha gastado $ 200 millones en desarrollo
Opción y marketing. La película está almacenada en digital
formar en grandes servidores de edición, como cualquier empresa prudente
haría. Esta información está respaldada y almacenada fuera del sitio.
Una de las personas en la cadena de almacenamiento (por ejemplo, el conductor
o administrador de almacenamiento fuera del sitio) toma una copia de la copia de
seguridad
y lanza la película inacabada en Internet varias veces
semanas antes de su lanzamiento en el teatro, lo que resulta en
taquilla significativamente reducida en bruto para ese particular
película. Desafortunadamente, todo el fiasco es el resultado de
el deseo inicial de tener buenos controles de TI (por ejemplo,
UPS). Esta paradoja obliga al auditor de TI a considerar
nuevas formas de asegurar y controlar bits y bytes.
Transporte y transmisión : los mismos problemas que
aplicados anteriormente también se aplican al transporte y transporte
misión de los activos digitales. Ciertamente, cualquier descifrado

Página 28
archivo digital enviado por correo electrónico está expuesto y potencialmente
podría ser explotado Ha desarrollado la organización
políticas y procedimientos sólidos que brindan
transporte y / o transmisión de activos digitales?
Otros recursos
Organizaciones profesionales
• Asociación de Auditoría y Control de Sistemas de Información
(ISACA) - www.isaca.org
- Ofrece el Auditor Certificado de Sistemas de Información
(CISA) y Sistemas de Información Certificados
Designaciones de Gerentes (CISM).
• Instituto de Auditores Internos (IIA) - www.theiia.org
- Ofrece el Auditor Interno Certificado (CIA)
designacion.
- Ofrece ITAudit , un boletín electrónico gratuito que
incluye una biblioteca de referencia.
• Asociación de Seguridad de Sistemas de Información (AISS) -
www.issa.org
- Admite seguridad de sistemas de información certificados
Profesionales.
- ISC2 administra el proceso de certificación, pero es
no es una organización profesional en sí misma.
• Instituto Americano de Contadores Públicos Certificados
(AICPA) - www.aicpa.org
- Patrocina Contador Público Certificado (CPA)
designacion.
Sitios web útiles
• http://www.csoonline.com
- Ofrece recursos útiles, incluidos artículos de seguridad,
para ejecutivos de seguridad.
• http://www.whatis.com
- Ideal para definiciones de tecnología rápida y rápida
enlaces a otros sitios de TI.
• http://csrc.nist.gov
- Centro de Investigación de Seguridad Informática, patrocinado por
el Instituto Nacional de Estándares y
Tecnología.
• http://www.cyberpartnership.org
- La Asociación Nacional de Seguridad Cibernética, una
asociación público-privada establecida para desarrollar
estrategias y programas compartidos para asegurar y
mejorar la infraestructura de información de Estados Unidos.
• http://www.infosecuritymag.com/
- Revista de seguridad de la información que cubre oportunamente
temas de seguridad
• http://www.itgi.org
- Existe para ayudar a los líderes empresariales en su responsabilidad
capacidad para hacer que la TI tenga éxito al apoyar
la misión y los objetivos de la empresa.
Software y grupos de usuarios
• Herramientas de freeware.
- Business Software Alliance promueve una caja fuerte y
mundo digital legal -
http://www.bsa.org/usa/antipiracy/Free-Software-
Audit-Tools.cfm
- AuditNet es una red de recursos disponibles para
®

auditores
http://www.auditnet.org
• Grupos de Usuarios.
- Grupo de usuarios de SAP de América - www.asug.com
- Grupo Independiente de Usuarios de Oracle - www.ioug.org
- Quest International User Group (para
PeopleSoft / JD Edwards) -
http://www.questdirect.org
- Grupo de usuarios de SQL Server Worldwide -
http://www.sswug.org
- Directorio de Yahoo de grupos de usuarios -
http://dir.yahoo.com/Computers_and_Internet/
Organizaciones / User_Groups
25
GTAG - Apéndice A - Cuestiones emergentes

Página 29
26
Michael Juergens , autor principal, tiene más de 15
años de experiencia profesional y ha estado con Deloitte
desde 1996. Actualmente se desempeña como líder de Deloitte
Práctica de Control de Control para la región del Pacífico Sudoeste.
Juergens se especializa en evaluación de tecnología de la información
controles. Él es un orador nacionalmente reconocido en el ámbito interno
controles y ha hablado a muchas audiencias, incluido The
IIA, ISACA, Grupo de Usuarios de SAP de las Américas, Capacitación MIS
Instituto, y asistentes a numerosos eventos nacionales e internacio-
conferencias internacionales. Él se sienta en el profesional de IIA
Comité de Conferencias y supervisa todo el entrenamiento de auditoría de TI
cursos ofrecidos por el IIA. Juergens actualmente sirve como
el principal principal de controles internos para una serie de grandes
Compañías multinacionales. En ese sentido, él ha supervisado
la entrega de numerosos proyectos de control interno, Sarbanes-
Proyectos de preparación de Oxley y auditorías de certificación. Juergens tiene
una licenciatura en economía de la Universidad de California
Irvine, y un MBA de la Universidad de California
Irvine.
David Maberry , autor contribuyente, es un gerente sénior
er en Deloitte's Audit and Enterprise Risk Services Control
Práctica de aseguramiento en Los Ángeles. Él tiene una amplia experiencia
la gestión del riesgo, el cumplimiento y la auditoría interna.
ing, con especializaciones en cumplimiento Sarbanes-Oxley
evaluaciones, evaluaciones de riesgo de TI, implementación previa y posterior
revisiones y auditorías técnicas sobre una variedad de sistemas y
plataformas. Importante experiencia operativa de Maberry
ofrece una capacidad única para analizar procesos en prácticamente cualquier
ambiente y proporcionar el máximo beneficio. Antes de unirse
Deloitte, trabajó durante más de 11 años en avanzado
puestos de gestión operativa en la industria de la asistencia sanitaria
tratar. Maberry actualmente admite múltiples compañías Fortune 500
nies en su cumplimiento de auditoría y evaluación comercial
estrategias.
Jeff Fisher , editor colaborador, es un alto directivo en
Servicios de auditoría y riesgo empresarial de Deloitte and Touche
práctica. Fisher ha estado con la firma por más de ocho
años y se desempeña como gerente de proyecto y en una
papel de garantía de calidad para algunos de los clientes más grandes de Deloitte.
Se especializa en auditorías de seguridad de sistemas de información y
evaluaciones, gestión de proyectos y Sarbanes-Oxley
Sección 404 evaluaciones. Fisher ha ayudado a muchos de
Los clientes de Deloitte se preparan y ejecutan con éxito
menting, los procesos de evaluación de Sarbanes-Oxley en
base. Fisher se graduó de la Universidad Estatal de Ferris con un
BS en contabilidad y sistemas de información de la computadora. Él es
un profesional certificado en seguridad de sistemas de información
(CISSP) y un Auditor Certificado de Sistemas de Información
(CISA).
Eric Ringle , editor colaborador, es un alto directivo en
Auditoría y riesgo empresarial de Deloitte and Touche LLP
Práctica de servicios. Él tiene más de 11 años de experiencia
y proporciona servicios a clientes que operan en todo el mundo.
Ringle se especializa en sistemas de información y negocios
auditorías y evaluaciones de procesos, gestión de proyectos y
Evaluaciones de la Sección 404 de Sarbanes-Oxley. Él ha ayudado
muchos clientes en la preparación y la implementación exitosa-
ing, procesos de evaluación Sarbanes-Oxley. Ringle graduado
de la Universidad Estatal de Michigan con una licenciatura y un MBA en
contabilidad. Es Contador Público Certificado (CPA),
Certified Information Technology Professional (CITP), y
Auditor Certificado de Sistemas de Información (CISA).
Revisores
El IIA Advanced Technology Committee, IIA global affil-
iates, Instituto Americano de Contadores Públicos Certificados,
Centro de Seguridad de Internet, Universidad Carnegie-Mellon
Software Engineering Institute, Sistema de información
Asociación de Seguridad, IT Process Institute, National
Asociación de Directores Corporativos, y SANS Institute
se unió al proceso de revisión. Las siguientes personas y
las organizaciones proporcionaron valiosos comentarios a esta guía:
- Instituto Americano de Cuentas Públicas Certificadas
- El Instituto de Auditores Internos en Australia
- El Instituto de Auditores Internos en United Kindom
- Christopher Fox - PricewaterhouseCoopers, EE. UU.
- David Bentley - Consultor, Reino Unido
- EW Sean Ballington - PricewaterhouseCoopers,
Estados Unidos
- Jay R Taylor - General Motors Corp., EE. UU.
- Larry Brown - The Options Clearing Corporation,
Estados Unidos
- Lars Erik Fjortoft - Deloitte, Noruega
- Lily Bi - El Instituto de Auditores Internos
- Stig J. Sunde - Oficina del Auditor General de Noruega
GTAG - Sobre los autores

Página 30
www.theiia.org
Gestión de auditoría de TI
La tecnología de la información (TI) está cambiando la naturaleza de la función de
auditoría interna.
A medida que surgen nuevos riesgos, se requieren nuevos procedimientos de auditoría
para gestionar estos riesgos.
adecuadamente. El propósito de la guía es ayudar a los ejecutivos principales de
auditoría e internos
Los gerentes de auditoría responsables de supervisar las auditorías de TI clasifican a
través de
problemas involucrados durante la planificación, el rendimiento y el informe de las
auditorías de TI.
Se tienen en cuenta los fundamentos de la auditoría de TI y los problemas emergentes.
¿Qué es GTAG?
Preparado por el Instituto de Auditores Internos, cada Auditoría Global de Tecnología
La Guía (GTAG) está escrita en un lenguaje comercial sencillo para abordar una
problema oportuna relacionado con la gestión, el control y la seguridad de la tecnología
de la información.
La serie GTAG sirve como un recurso listo para los ejecutivos principales de auditoría
en diferentes
riesgos asociados a la tecnología y prácticas recomendadas. Las siguientes guías fueron
publicado en 2005.
Guía 1: Controles de tecnología de la información
Guía 2: Controles de cambio y gestión de parches: crítico para
Éxito organizacional
Guía 3: Auditoría continua: implicaciones para asegurar, monitorear y
Evaluación de riesgos
Consulte el sitio web de tecnología IIA en www.theiia.org/technology
Número de pedido: 1012
Miembro de IIA US $ 25
No miembro US $ 30
Evento IIA US $ 22.50
ISBN 0-89413-590-2

Texto original
– Information security magazine that covers timely
Sugiere una traducción mejor