Gestión de la Auditoría de TI

Global Technology Auditoría Guía de

gestión de la Auditoría de TI

Autor

Michael Juergens, director de Deloitte & Touche LLP

contribuyendo Autor

David Maberry, Gerente Senior de Deloitte & Touche LLP

Colaboradores de redacción

Eric Ringle, Gerente Senior de Deloitte & Touche LLP Jeffrey Fisher.

Gerente Senior de Deloitte & Touche LLP

de marzo de de 2006

Esta guía se ha producido y distribuido a través de

el patrocinio de Deloitte & Touche LLP.

Copyright © 2006 por The Institute of Internal Auditors, 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 ser reproducida, almacenada en una
sistema de recuperación o transmitida en cualquier forma por cualquier medio - electrónico, mecánico, de fotocopiado, de grabación,

o de otra manera - sin la previa autorización 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 de asesoramiento legal o contable. El IIA no proporciona este tipo de asesoramiento y no hace ninguna garantía en cuanto a

ningún resultado legales o contables a través de la publicación de este documento. Cuando surgen problemas legales o contables,

asistencia profesional se debe buscar y retenido.

GTAG - Tabla de Contenidos

1. Resumen de la Auditoría General Director ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 1

2. Introducción ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 2

3. Definición de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 3

3.1 Gestión de ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 4

3.2 Infraestructura técnica ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 4

3.3 Aplicaciones ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 4

3.4 Conexiones externas ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 5

4. Los riesgos relacionados con TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 6

4.1 La teoría del copo de nieve ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 6

4.2 Riesgo Evolución ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 6

4.3 TI-relacionados con la proliferación de riesgos ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 7

4.4 Tipos de riesgos relacionados con TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 7

4.5 Evaluación de Riesgos de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 7

5. Definición de la TI Auditoría Universo ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 10

5.1 Consejos para el CAE ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 10

5.2 Presupuesto para una auditoría de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 10

6. La ejecución de las auditorías de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 12

6.1 marcos y normas ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 12

Gestión de Recursos de TI de Auditoría 6.2 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 14

7. Aceleradores de auditoría de TI ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 17

7.1 facilitadores de auditorías ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 17

7.2 Aceleradores de prueba ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 17

8. Preguntas para el CAE ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 19

A. Apéndice A - Temas emergentes ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 20

A.1 Redes Inalámbricas ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 20

A.2 dispositivos móviles ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 20

Interfaces A.3 ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 21

A.4 Gestión de datos ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 21

A.5 privacidad ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 22

A.6 segregación de funciones ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 22

A.7 administrador de acceso ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 23

A.8 configurable Controles ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 24

A.9 la piratería ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 24 Otros recursos ... ... ... ... ... ... ...

... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... 25 Acerca de los autores ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

... ... ... ... ... ... ... ... ... ... ... 26
 GTAG - Resumen Ejecutivo de la Auditoría General Director - 1

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 de manera adecuada. Esta guía, que fue creada
para ayudar al ejecutivo de auditoría (DEA) y el plan de gestión de la función de auditoría
de TI más eficaz y eficiente, se explica cómo:

definirlo - ¿En qué áreas deben ser considerados para su inclusión en un plan de

auditoría de TI? El DEA debe ser capaz de medir su planeada alcance de la

auditoría de TI frente a las directrices que se presentan aquí para ayudar a

asegurar que el alcance de los procedimientos de auditoría que es adecuada.

Evaluar relativos a TI Riesgo - Está claro que la evolución de TI introduce

nuevos riesgos en una organización. Esta guía le ayudará a entender el CAE
cómo identificar y cuantificar mejor los riesgos relacionados con TI. Si lo
hace, ayudará a asegurar que los procedimientos de auditoría de TI y los
recursos se centra en las áreas que representan el mayor riesgo para la
organización.

Definir el universo de auditoría de TI - los recursos de auditoría de TI suelen ser

escasos, y las demandas de auditoría de TI son sustanciales. Una sección en la

definición del universo de auditoría de TI ayudará a la CAE entiende cómo

construir un plan de auditoría de TI eficaz que los saldos de auditoría de TI con las

necesidades de las limitaciones de recursos.

Ejecutar las auditorías de TI - La proliferación y la complejidad de TI dicta la

necesidad de nuevos procedimientos de auditoría de TI.

Auditoría de lista de control o por la investigación es probable que sea

insuficiente. Este libro ofrece una guía específica para el CAE en la forma de
ejecutar los procedimientos de auditoría de TI y la manera de entender lo que
existen normas y marcos en el mercado que pueden apoyar los procedimientos
requeridos.
Manejo de la función de auditoría de TI - La gestión de la función de auditoría
de TI puede requerir nuevas técnicas y procedimientos de gestión. Esta guía
proporciona consejos y técnicas útiles para maximizar la eficacia de la
función de auditoría de TI y la gestión de los recursos de auditoría de TI.

Abordar nuevas cuestiones - Se desarrolla rápidamente. Esta evolución puede

introducir nuevos riesgos importantes en una organización. El primer nivel
CAE se centra la atención en auditoría de TI no sólo los bloques de
construcción básicos de TI, sino también tecnologías nuevas y emergentes.
Una sección sobre las nuevas cuestiones proporcionará información
específica en una serie de tecnologías emergentes, evaluar los riesgos que
estas tecnologías representan para una organización, y proporcionar
recomendaciones sobre cómo el DEA debe responder a estos riesgos.

El objeto de esta guía es proporcionar información pragmática en la

llanura Inglés, con recomendaciones específicas que un CAE puede poner en
práctica de inmediato. Además se considera a proporcionar preguntas que un
CAE puede hacer para ayudar a entender si su función de auditoría de TI es
un gran intérprete.

1
GTAG - Introducción - 2
No hay duda de que está cambiando la naturaleza de la función de auditoría
interna. Las empresas se enfrentan a riesgos, los tipos de auditoría que se deben
realizar, la forma de priorizar el universo de auditoría, y la forma de entregar
resultados interesantes son todas las cuestiones con las que deben lidiar los DEA.
Sin conocimientos técnicos profundos, sin embargo, puede ser difícil encontrar
respuestas a estas y otras preguntas.
Este GTAG está diseñado para CAE y personal de gestión de auditoría interna
que se encargan de supervisar las auditorías de TI. El propósito de la guía es ayudar a
clasificar a través de los temas estratégicos relacionados con la planificación, la
realización y presentación de informes sobre las auditorías de TI. Se tendrá en cuenta
a los fundamentos, así como cuestiones emergentes.
auditoría de TI está aumentando en importancia, sobre todo porque las
organizaciones se están volviendo cada vez más dependientes de TI. Los
procesos clave son automatizados, o habilitados por la tecnología. Es posible
que una orden de venta a entrar a través de un sitio Web, se transmitirá al
suelo del almacén, y se envía al cliente sin que nadie que no sea el ver
trabajador de almacén o tocando la orden.
A medida que las organizaciones a aumentar su dependencia de TI, dos problemas
principales surgen:
• Un gran porcentaje de los controles internos clave en que se basa la
organización es probable que sea conducido por la tecnología. Ejemplo: la
política corporativa establece que antes de realizar cualquier pago a un
proveedor, se realiza un partido de tres vías. Históricamente, ese partido fue
probablemente realizada por un empleado, que corresponde físicamente trozos
de papel, ellos con grapas, y les presentó. Ahora, todos los partidos pueden
ser realizadas por planificación de recursos empresariales de la organización
del sistema (ERP). El sistema realiza automáticamente
el partido sobre la base de
mensajes preconfigurados reglas y los niveles de tolerancia y automáticamente
varianzas a las cuentas de varianza definidos. Para auditar que el control de
eficacia, un auditor debe entrar en los ajustes de configuración de ese sistema
ERP y evaluar las normas y los ajustes. Esto requiere un conjunto de
habilidades y auditoría del programa muy diferente que el proceso histórico lo
hizo. Para llevar a cabo una auditoría eficaz, el enfoque de auditoría histórica
tiene que ser re-diseñado para hacer frente a los nuevos riesgos. Esto requiere
un enfoque en - y la comprensión de - la tecnología de auditoría.
• Los sistemas que carecen de integridad o que tienen deficiencias de
control tendrán un mayor impacto en las operaciones de la
organización y la preparación competitiva, lo que aumenta la necesidad
de eficaces controles de TI.
Ejemplo: Considere el proceso automatizado descrito anteriormente, donde
una orden de venta viene en medio de un sitio web y se transmite
directamente a través del sistema ERP para el piso de la bodega.
Consideremos ahora lo que sucede cuando un cliente ordena accidentalmente
paletas 100 en lugar de 100 unidades. Si la organización ha optimizado
totalmente sus procesos con un sistema ERP, es posible que el sistema
comprobará el inventario, tenga en cuenta que las paletas 100 no están
disponibles, actualizar el programa de producción de
2
producir 100 palets, y enviar automáticamente las órdenes de compra de
materias primas a través de intercambio electrónico de datos (EDI).
Potencialmente, este error no pueden quedar atrapados hasta que el cliente
recibe la mercancía - demasiado tarde.
Es evidente que, para mitigar este tipo de riesgos, las organizaciones necesitan para
ejecutar bien diseñado planes de TI que tenga en cuenta estas cuestiones. Por desgracia,
la mayoría de las organizaciones sólo han migrado a entornos altamente automatizados en
los últimos 10 años más o menos. Por lo tanto, tradicionalmente, puede que no haya sido
un foco profundo en la tecnología de auditoría, ni las fuentes profundas de liderazgo de
pensamiento sobre la forma de auditoría de tecnología. Parte de ello se debe al rápido
ritmo de los avances tecnológicos. No ha habido ningún desarrollos radicales en el proceso
de emparejamiento de tres vías en muchos años; Sin embargo, las aplicaciones que se
utilizan para apoyar estos procesos se desarrollan anualmente.
Un problema adicional que surge con frecuencia en la planificación del universo de
auditoría de TI es realmente la comprensión de cómo los controles se relaciona con la
información financiera, fraude y otros temas clave. Esto es relativamente fácil de entender
cuando se está evaluando los controles dentro de un sistema de aplicación (por ejemplo,
las configuraciones de coincidencia de tres vías discutidas más arriba). Sin embargo, es
mucho más difícil en la evaluación de tecnologías de apoyo. Supongamos que la
organización mantiene una conexión a Internet, pero no tiene un cortafuegos para proteger
la red interna. Están representados incorrectamente los datos financieros? Se ven
afectadas las operaciones? Se hace más difícil trazar la correlación directa como la
tecnología está más alejado de la actividad comercial.
Ante esto, muchos CAE proporcionan a menudo menos atención auditoría para
estas tecnologías de apoyo, que pueden representar una visión bastante miope de los
riesgos de TI. El quid de la cuestión es que las deficiencias de control en las tecnologías de
soporte pueden tener un impacto mucho mayor en la organización de los controles de TI
específicos de un solo proceso.
Por ejemplo, vamos a suponer que una organización crea pagos electrónicos
que envía a sus proveedores. Estos pagos se enrutan electrónicamente a las cuentas
bancarias basado en cámara de compensación automatizada números (ACH) de
enrutamiento para cada cuenta de proveedor. Todos los números de ACH se
almacenan en algún lugar de una tabla en la base de datos del sistema de la
organización. Un administrador de base de datos, o cualquier persona con el derecho
de acceso a la base de datos, simplemente podrían cambiar cada entrada en la tabla
que a su propia cuenta bancaria vía ACH. La próxima vez que la organización hizo una
carrera cheque electrónico, toda la tirada sería depositado en la cuenta bancaria del
perpetrador. Esto eludir por completo todos los mecanismos de seguridad, control y
seguimiento de auditoría que existen dentro del proceso de negocio y la aplicación de
negocios - incluyendo pagos positivos.
En los casos anteriores, es fácil ver cómo una deficiencia de control a nivel de base
de datos podría tener un impacto mucho mayor que una deficiencia con las configuraciones
de coincidencia de tres vías. Es por esta razón que los DEA deben considerar
cuidadosamente todas las capas del entorno de TI en la planificación del universo de
auditoría de TI para el año.

Uno de los retos iniciales de un CAE enfrenta al desarrollar el plan de auditoría de TI
para el año es la definición de los límites de TI. Son los sistemas de correo de voz de
teléfono y parte de ella? Deben incluirse las instalaciones de credencialización y
sistemas de seguridad física? ¿Qué pasa si se subcontrata a los que la empresa de
gestión de la propiedad? Estos son algunos de los temas que lidiar con CAES cuando
se trata de determinar cómo asignar los recursos de auditoría de TI.
La realidad es que significa cosas diferentes para diferentes
organizaciones. Incluso dos empresas en la misma industria pueden tener
radicalmente diferentes entornos de TI. Por desgracia, lo que es, o debería ser,
claramente no es ni universal definido.
Esta sección le ayudará CAE ocupa de cómo debe pensar en ello dentro de
una organización. Reconociendo que hay una gran cantidad de heterogeneidad
en los entornos de TI, de una manera un CAE puede acercarse a la definición de
la misma es por pensar en capas, como un postre helado. Cada capa es diferente
e importante. Existen riesgos en cada capa del medio ambiente, y los riesgos
varían mucho. Hackear el sitio Web de la empresa, por ejemplo, es un riesgo muy
diferente a la organización que robar el mencionado plazo de cheques
electrónicos.
Considere cada capa
Para una función de auditoría que sea eficaz, los riesgos de cada capa deben ser
considerados y priorizados, y los recursos de auditoría deberían asignarse a cada capa.
Si el plan de auditoría de TI no incluye auditorías para cada capa del medio ambiente,
más probable es que el plan de auditoría considerados en su conjunto no se va a hacer
frente a los riesgos de TI de la organización de manera adecuada.
Cabe señalar que, en algunos casos, puede ser apropiado considerar todas
las capas durante un período de tiempo (es decir,
Figura 1 - Medio ambiente IT
3
GTAG - Definición de TI - 3
durante varios años sobre una base de rotación) en lugar de cubrir todas las
capas en un solo año. Las empresas privadas u organizaciones que no
tienen que cumplir con la Ley Sarbanes-Oxley de 2002 u otras regulaciones
controles o la legislación, como la Ley de mejora de la Federal Deposit
Insurance Corporation, tal vez deseen establecer un plan que cubre el
universo de TI durante un período de dos a tres años. planes de rotación que
se extienden más allá de tres años son probablemente inadecuadas debido
a la alta tasa de cambio en el entorno de TI.
Cuántos recursos deben asignarse a cada capa? Cuando dentro de la capa
en caso de que se asignen? Las respuestas a estas preguntas difíciles deben ser
el resultado natural de los procesos de evaluación de riesgos, junto con el criterio
del auditor y el pensamiento estratégico. Independientemente de la asignación
específica de recursos, se deben considerar todas las capas.
¿Cuáles son las capas?
Figura 1 a continuación, es una representación sencilla de un entorno de TI. Obviamente,
cada organización es diferente, pero este gráfico debe cubrir la mayor parte de los sistemas
críticos para la mayoría de las organizaciones. Las capas principales a considerar son:
• Gestión de TI.
• Infraestructura técnica.
• Aplicaciones.
• Las conexiones externas.
Tenga en cuenta que este gráfico no define las categorías del plan de auditoría
de TI. Cuando se planifican las auditorías de TI específica, pueden ser organizados
en categorías basadas en procesos de la organización, o por marcos estandarizados,
etc. Este gráfico es
GTAG - Definición de TI - 3
diseñada para obtener el CAE pensando en el entorno de TI y asegurarse de
que los recursos de auditoría se asignan a cada capa. La organización de las
auditorías específicas se deja a juicio del CAE.
Gestión de TI 3.1
Esta capa comprende el conjunto de personas, políticas, procedimientos y procesos
que gestionan el entorno de TI. Las tecnologías pueden ser desplegadas - por
ejemplo, una organización puede implementar ERP SAP en un entorno Unix - pero
la integridad de los sistemas y los datos dependen en gran medida en las tareas
específicas que el personal administrativo realizan sobre una base regular. Por lo
tanto, esta capa incluye:
Supervisión del sistema - La supervisión implica la identificación de transacciones
que no lograron publicar debido a un error de procesamiento, o la identificación de
una base de datos cuando se corrompe.
Programación - Muchas organizaciones realizan programación interna para
varios sistemas. La programación debe ser gestionado y supervisado por lo
que los programas con errores no afectan a la integridad de los sistemas
clave.
Planificación - El departamento de TI debe ser el desarrollo tanto a largo plazo
como a corto plazo planes estratégicos de TI. Estos deben estar alineados
con los planes a largo y corto plazo de la organización. La ausencia de una
buena planificación estratégica de todos, pero garantiza que no va a apoyar
los objetivos de la organización, tomados en su conjunto.
Gestión de proveedores subcontratados - Muchas organizaciones
externalizan diversos componentes, o la totalidad, del entorno de TI a
un proveedor externo. En estas situaciones, la gestión de la relación de
contratación externa efectiva es una pieza fundamental de asegurar la
integridad del entorno informático.
Gobierno de TI - El establecimiento de un fuerte tono en la parte superior para el
diseño, construcción y operación de los sistemas con la integridad de la
información; comunicar que la cultura a lo largo de la función de TI; supervisar
el desarrollo y la implementación de políticas y procedimientos; y el
rendimiento de la evaluación son componentes clave de la ejecución de una
función de TI.
Tenga en cuenta que las auditorías de estas funciones será similar para procesar las
auditorías. El auditor de TI está mirando a la gente y las tareas en lugar de un ajuste del
sistema técnico. Las pruebas de controles serán bastante diferentes y requerirán una
cierta cantidad de juicio.
3.2 Infraestructura Técnica
Esta capa se conoce por muchos nombres diferentes, tales como los controles
generales de ordenador, controles generalizados, o tecnologías de apoyo. Se refiere
esencialmente a los sistemas que son la base, el soporte y permiten a las
aplicaciones de negocio principal. En general, esto incluye:
Sistemas operativos - El conjunto de programas que instruyen a los sistemas
informáticos en la forma de funcionar. Los ejemplos incluyen Unix, Windows
2003, y OS / 400. Todos los programas y
4
archivos finalmente residir en algún lugar del sistema operativo. Las acciones
realizadas a nivel del sistema operativo generalmente eluden más seguridad y
controles que existen a nivel de proceso. Por ejemplo, considere la laptop de un
ejecutivo. Si el Ejecutivo quiere eliminar un e-mail, él o ella podría iniciar sesión
en la aplicación de correo electrónico y eliminar ese correo electrónico. El
programa probablemente preguntar: “¿Seguro?” A continuación, el correo
electrónico eliminado se almacena en una carpeta especial por un período de
tiempo para que pudiera ser recuperado. Sin embargo, el mismo ejecutivo
también podría abrir el Explorador de Windows y borrar todos los directorios de
la unidad C:. El efecto sería el mismo; la dirección de correo habría
desaparecido. En el último ejemplo, sin embargo, está claro que hay menos
controles.
Bases de datos - Todos los datos de negocio, crítico o de lo contrario, termina con
domicilio en algún tipo de base de datos en algún lugar en el medio ambiente.
Las bases de datos se componen de tablas que contienen datos, que, entre
otras cosas, forman la base de todos los informes comerciales. Los ejemplos
incluyen Oracle, MS SQL Server, y DB2. Las acciones realizadas a nivel de
base de datos también tienden a eludir la mayoría de los controles que existen
a nivel de proceso - vis-à-vis el ejemplo de fraude por pagar cuentas anteriores.
redes - Para que los datos fluyen a través de una organización, debe tener
un método de viajar, si a través de un alambre, un cable de fibra óptica,
o sistema inalámbrico. La red consta de componentes físicos tales
como cables; dispositivos que gestionan el movimiento del tráfico de
red tales como conmutadores, routers o firewalls; y los programas que
controlan el movimiento de los datos. La integridad de la red juega un
papel importante en asegurar la integridad y exactitud de los datos de
negocio de la organización. Por ejemplo, si un empleado de almacén
preparar el envío de un producto escanea con un escáner de código de
barras, ¿cómo conseguir que la transacción grabada de nuevo en el
libro mayor (G / L)? Respuesta: Se desplaza a través de la red y se
procesa. Pero lo que si no viaja a través de la red? ¿Y si se cambia a lo
largo del camino, o desaparece por completo? ¿Cómo sabría la
organización?
auditorías de infraestructura técnica tienden a centrarse más en la revisión de los
parámetros de configuración que los procesos técnicos.
3.3 Aplicaciones
Las aplicaciones de negocios son programas que realizan tareas específicas relacionadas
con las operaciones de negocio. Estos por lo general se pueden clasificar en dos
categorías: las aplicaciones transaccionales y aplicaciones de apoyo.
Las aplicaciones transaccionales
aplicaciones transaccionales consisten principalmente en software que procesa
y registra las transacciones comerciales. Los ejemplos incluyen la gestión de
pedidos, registro de contabilidad general y la gestión de almacenes.
aplicaciones transaccionales
 GTAG - Definición de TI - 3

suelen caer en una de las siguientes categorías:

Comprar Side - permite procesos de la cadena de adquisición y suministro.

Lado de la venta - permite a los procesos de venta y distribución.

Back Office - permite la contabilidad financiera, cuentas por pagar, cuentas por

cobrar, y los procesos de recursos humanos.

ERP - software que hace uno o más de los anteriores integrada.

Las solicitudes de apoyo

aplicaciones de soporte están especializados programas de software que facilitan la

actividad empresarial, pero por lo general no procesar transacciones. Los ejemplos incluyen

programas de correo electrónico, software de fax, 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 a las

aplicaciones transaccionales. Sin embargo, dependiendo de ciertas industrias, algunas
aplicaciones de soporte pueden ser de alto riesgo también. Ejemplo: La empresa XYZ
hace un producto de consumo y tiene una marca muy reconocible. Se pierde
continuamente dinero debido a las imitaciones de productos que se venden por piratas
corporativos. Su equipo creativo diseña nuevos productos en un paquete integrado de
software de diseño por ordenador. En este caso, la empresa debe evaluar los controles
en torno a esta aplicación de soporte, como pudo representa un riesgo para la línea de
fondo a la empresa si los nuevos diseños son robados antes de nuevos productos que
golpean la calle.

3.4 Conexiones externas

La red de la empresa no opera en forma aislada. Que sin duda está
conectada a muchas otras redes externas. La Internet, por supuesto, es el
que más fácilmente viene a la mente, pero muchas veces los DEA cometer el
error de parar allí. De hecho, es muy probable que la red corporativa está
conectada a muchas otras redes. Por ejemplo: ¿La organización hace
negocios a través de EDI? Si es así, la red corporativa está probablemente
conectado a una red de proveedores de EDI, o tal vez conectada
directamente a la red de un socio comercial. ¿La organización utilizar
cualquier proveedor de almacenamiento de terceros? Si es así, las dos redes
tienen un origen probable juntos.

Además, como las organizaciones siguen para automatizar los procesos clave,
más acceso a la red corporativa se concede a los extranjeros, a menudo a través de
Internet. Consideremos, por ejemplo, la capacidad para buscar el estado de cuenta de
una tarjeta de crédito o el estado del envío de un paquete de FedEx. Los clientes que
realizan esas actividades son probablemente entrando en las redes internas de esas
empresas 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 deben ser de confianza. Toda la comunicación desde y
hacia redes externas debe ser estrechamente controlada y monitoreada. Puede ser un
reto para definir los procedimientos de auditoría de TI para hacer frente a este riesgo,
debido a que la organización sólo puede auditar lo que puede controlar. Por lo tanto,
es crítico para auditar los puntos de entrada y de salida, en un mínimo.

5
Los riesgos relacionados con TI - - 4 GTAG
4.1 La teoría del copo de nieve
Cada entorno de TI es único y, por lo tanto, representa un conjunto único de
riesgos, según la teoría de copo de nieve. Las diferencias en los entornos de TI
hacen cada vez más difícil tomar un enfoque genérico o lista de control de
auditoría de TI. Para que sea eficaz, cada organización debe definir un enfoque
de auditoría de TI y crear planes de trabajo de auditoría de TI que son específicos
a las necesidades de ese entorno particular.
Esto es muy diferente de las áreas de auditoría financiera u operativa,
donde ciertos riesgos son endémicas de una industria o el tamaño de la
compañía dada. Considere lo siguiente: Empresa ABC y la empresa XYZ son los
dos medios y entretenimiento. Ambas empresas se enfrentan a riesgos en el
cálculo de los asientos contables definitivos para las películas que han sido
liberados. Este proceso sería algo que la función de auditoría interna sería
definitivamente auditar.
En el lado de TI, sin embargo, la empresa ABC es el uso de las aplicaciones
de Oracle como el sistema de negocio principal, que se ejecuta en Windows 2000 y
el uso de una base de datos Oracle. Hay un sistema de Oracle centralizada. La
empresa XYZ tiene una función de TI descentralizada, 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 ha subcontratado
a un proveedor de terceros. Claramente, las auditorías de TI que se planeó y
ejecutó en la Compañía ABC podría variar enormemente de los de la empresa XYZ.
El factor de configuración
Otro factor principal en la teoría de copo de nieve es de configuración. Cuando una
empresa implementa una tecnología dada, se configura la tecnología para apoyar
sus objetivos particulares. No puede haber un alto grado de variabilidad de un
entorno a otro. Una empresa que utiliza Windows 2003 como el sistema operativo
primario puede haber configurado varios dominios, con relaciones de confianza entre
todos los dominios. Otro puede tener solamente un único dominio, utilizando
Windows Active Directory para administrar todos los accesos de usuario. A pesar de
que ambas compañías están utilizando la misma tecnología, los riesgos son muy
diferentes; en consecuencia, la realización de auditorías de TI es también muy
diferente.
Configuración también afecta a las aplicaciones de negocio. Empresa ABC
y la empresa XYZ tanto SAP implementan como el sistema de negocios principal
y permitieron el proceso de cuentas por pagar con SAP. Compañía ABC ha
configurado SAP para realizar un partido de tres vías, la igualación de precios,
cantidad y fecha. Se ha establecido sobre y debajo de los niveles de tolerancia de
$ 50 o 5 por ciento, el que sea inferior. La empresa XYZ ha configurado SAP para
realizar “autofacturación”, cuando el pago se genera automáticamente en función
de lo que fue recibido, independientemente de lo ordenado o facturado. No hay
resultados de tres vías se lleva a cabo, y no se establecen límites de tolerancia.
Una vez más, aunque ambas empresas están utilizando SAP, los riesgos de cada
una de estas configuraciones son muy diferentes, y las auditorías de TI que se
debe realizar en cada empresa también son diferentes.
6
Una matriz de variables
Otras variables que afectan a 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 las tecnologías de infraestructura.
• Grado de personalización.
• departamento de TI estructura organizativa.
• Las versiones de la tecnología específica utilizada (por ejemplo, Windows 2000 en
comparación con Windows 2003).
• Grado y forma de contratación externa.
• Las políticas institucionales (por ejemplo, ahorro de todos los correos electrónicos
siempre frente ahorrarse ningún e-mails).
El resultado neto de todas estas variables es la teoría del copo de nieve: No hay dos
entornos de TI son iguales. Por lo tanto, es muy difícil - si no imposible - adoptar un enfoque
lista de comprobación para la planificación y ejecución de las auditorías de TI. Cada
empresa debe tener un plan de auditoría de TI del todo singular en función de su específica
los riesgos de TI.
El desafío, por supuesto, es identificar adecuadamente el negocio y los
riesgos de TI específica del entorno particular de TI de la organización. Es por esto
que el proceso de evaluación de riesgos de TI es crítica, tal vez incluso más que la
evaluación general de riesgos. Además, la evaluación del riesgo debe ser realizada
por los recursos con conocimiento - como aquellos que entienden cómo el uso de
Active Directory de la empresa tendrá un impacto en las auditorías de TI que
necesita ser realizado.
4.2 Evolución de Riesgo
La teoría del copo de nieve dicta que cada empresa tendrá un perfil de riesgo que
es único para esa organización única. Sin embargo, hay otra dimensión de riesgo
que es importante tener en cuenta también, y que es la evolución del riesgo. la
evolución del riesgo se basa en la Ley de Moore. La Ley de Moore, que fue
propuesto inicialmente en 1965, establece que cada 18 meses, la densidad de
datos en un circuito integrado se duplica. Lo que esto significa es que la tecnología
pragmáticamente está aumentando rápidamente, lo que no debería ser una
sorpresa para nadie.
En consecuencia, los riesgos relacionados con TI no es estática. Dado el alto
crecimiento y la expansión de la tecnología, los riesgos relacionados con TI cambiarán - a
veces de manera espectacular - de año en año. Incluso es posible tener una situación en la
que el programa de auditoría de TI se basa en un proceso eficaz de evaluación de riesgos
de TI, pero por el momento las auditorías reales se van a realizar, que el perfil de riesgo
había evolucionado, y las auditorías de TI planeado ya no son suficientes.
Para combatir este problema de la evolución de riesgos relacionados con TI, el DEA
debe:
• Reconocer la naturaleza dinámica de los riesgos relacionados con TI y llevar a
cabo las evaluaciones de riesgos de TI independientes cada año.
• Desarrollar una comprensión de los planes a corto plazo del departamento de
TI para un año determinado y analizar cómo estas iniciativas pueden afectar a
la evaluación de riesgos de TI.
• Comience cada auditoría de TI real mediante la actualización del componente de
evaluación del riesgo de que la auditoría en particular.

• Sea flexible con respecto al universo de auditoría de TI; monitorear el perfil de
riesgo relacionados con la TI de la organización y estar dispuestos a adaptar los
procedimientos de auditoría a medida que evoluciona.
4.3 proliferación de riesgos relacionados con TI
riesgos relacionados con TI Una tercera dimensión a tener en cuenta cuando se evalúa es
el concepto de la proliferación, que se refiere a la naturaleza aditiva de los riesgos
relacionados con TI. Suponga que la organización ha identificado riesgos de TI A y los
riesgos de TI B. Independientemente, cada riesgo puede ser baja, pero cuando los dos
procesos relacionados con el riesgo trabajan juntos, crean riesgos de TI C, que es mucho
mayor que la suma de los riesgos individuales.
Ejemplo: La empresa XYZ es corriendo Oracle
Aplicaciones. No hay un proceso en el lugar para la actividad del sistema de
vigilancia. Además, los administradores del sistema tienen acceso total al sistema.
Independientemente, cada uno de estos elementos representa riesgo, pero en
conjunto representan una situación en la que un número de personas que pueden
hacer lo que quieran en el sistema (aprobar las facturas, cheques cortar, crear
nuevas cuentas de nómina) sin verificación de detective y contrapesos. En este caso,
la comprensión de la gestión de TI y procesos de monitoreo, junto con la seguridad
específica del sistema, es importante para entender el verdadero riesgo.
Por esta razón, es importante tener en cuenta los riesgos relacionados con TI de
manera integral, en lugar de forma discreta. El DEA debe tener en cuenta los riesgos
relacionados con TI a nivel de empresa, no solo la evaluación de cada riesgo individual,
sino también cómo los riesgos individuales impactar entre sí. Recuerde que el entorno de
TI tiene capas. Imaginemos que uno está tratando de tamizar la arena a través de una
serie de pantallas apiladas una encima de la otra. Aunque cada pantalla tiene agujeros en
ella, las capas de pantallas evitarán cualquier arena de conseguir todo el camino a través.
Ahora imaginar que cada pantalla tiene un pequeño agujero en él, directamente alineado
con un pequeño agujero en la capa debajo de ella. En este caso, la arena puede caer
todo el camino a través de las pantallas y sin impedimento.
El primer nivel CAE está siempre considerando todas las capas del entorno
de TI en la planificación o ejecución de las auditorías de TI. Evaluar el impacto de
los riesgos en una capa contra los riesgos a otras capas es muy importante a la
hora de realizar la evaluación de riesgos de TI.
4.4 Tipos de riesgos relacionados con TI
El primer paso en la comprensión de los riesgos asociados a ella es identificar lo
que puede salir mal, incluyendo:
• Disponibilidad - cuando el sistema no está disponible para su uso.
• Seguridad - cuando se produce el acceso no autorizado a los sistemas.
• Integridad - cuando los datos son incompletos o inexactos.
• Confidencialidad - no cuando la información se mantiene en secreto.
• Eficacia - cuando el sistema no proporciona una función
prevista o esperada.
• Eficiencia - cuando los sistemas causan una utilización subóptima de los recursos.
Los diversos riesgos relacionados con TI en general, se pueden agrupar en dos categorías
principales: riesgo omnipresente y el riesgo específico.
7
Los riesgos relacionados con TI - - 4 GTAG
Riesgo generalizado
Ciertos riesgos relacionados con TI no se limitan a un sistema o proceso específico.
Estos riesgos afectan a la empresa en su conjunto, y por lo tanto se hace referencia a
los riesgos como generalizada. Ejemplo: La empresa XYZ está conectado a la Internet
y no mantiene un servidor de seguridad. ¿Qué balance hace de cuenta que el
impacto? Potencialmente todos los saldos de cuenta o potencialmente no hay saldos
de las cuentas. Otro ejemplo podría ser la presencia de rociadores de agua en el
centro de datos. Si aquellos accidentalmente se apagan y apagar todos los servidores
con el agua, que los procesos operativos se verían afectados? Podría ser todos los
procesos, no hay procesos, o cualquier otra cosa.
Riesgos específicos
El riesgo específico, por otro lado, se puede atribuir directamente a un proceso
específico o saldo de la cuenta. Tenga en cuenta los ajustes de configuración
partido de tres vías mencionadas en la introducción de esta guía. Si esos valores se
establecen de forma incorrecta, el riesgo se refieren específicamente a pagar y
efectivo.
CAE menudo luchan con el hecho de que los riesgos generalizados representan
riesgos mucho mayores para la empresa que los riesgos específicos. Sin embargo, es muy
difícil de cuantificar un riesgo omnipresente. Por otra parte, al informar de una deficiencia
de control relacionada con un riesgo omnipresente, es mucho más difícil para vincularlo con
el impacto de negocios debido a la deficiencia.
Lo importante aquí es el equilibrio. El DEA debe recordar que los riesgos tanto
generalizadas y específicas son importantes y centrar la atención de auditoría en
ambos tipos de riesgo. Si una revisión del universo de auditoría de TI planeado no
revela las auditorías que cubren ambos tipos de riesgo, es probable que el universo de
auditoría de TI no cubrirá los riesgos de la organización de manera adecuada.
4.5 Evaluación de Riesgos de TI
El auditor debe utilizar una técnica o método de evaluación de riesgos adecuada en el
desarrollo del plan general para la asignación eficaz de los recursos de auditoría de TI.
La evaluación de riesgos es una técnica utilizada para examinar unidades auditables en
el universo de auditoría y seleccionar las áreas de revisión que tienen la mayor
exposición al riesgo. Los riesgos asociados con cada capa de TI no pueden determinarse
mediante la revisión de los riesgos relacionados con TI en aislamiento, pero deben ser
consideradas en conjunción con los procesos y los objetivos de la organización.
Impacto Versus Verosimilitud
La evaluación de los riesgos relacionados con TI también debe considerar el impacto y
probabilidad de ocurrencia. El impacto de los riesgos relacionados con TI es a menudo alta,
sobre todo con respecto a riesgos generalizados. Probabilidad puede ser más difícil de
determinar debido a que es un valor de predicción (por ejemplo, ¿Cuál es la probabilidad
de que un hacker se romperá en el sitio web de la organización?). La experiencia del
pasado y las mejores prácticas generales pueden ser utilizados para apoyar estas
estimaciones. El producto del impacto y la probabilidad ayuda a definir la gravedad del
riesgo, lo que proporciona una base para comparar y priorizar los riesgos relacionados con
TI.
Los riesgos relacionados con TI - - 4 GTAG
Considere la empresa XYZ, que ha implementado Windows 2003.
Si esto se auditada como parte de las auditorías de TI de este año? La
respuesta, al igual que muchas otras respuestas con respecto a IT, es
“depende”. En este caso, hay varios factores que influyen en la
decisión. La consideración clave es el riesgo para el negocio y el
impacto que la tecnología tiene sobre las operaciones 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 en la oficina de
correos los cambia, entonces es claro que la tecnología tiene muy
poco impacto en la integridad general de operaciones de la
organización. En consecuencia, sería un desperdicio de los recursos
de auditoría de TI a molestar auditoría este sistema. Por el contrario, si
los sistemas de distribución primaria de la organización se ejecutan en
Windows 2003,
Muchas veces, sin embargo, las respuestas no son tan evidentes. Es por esta
razón que una función de auditoría de TI efectiva depende de la realización de una
evaluación de riesgos de TI robusta altamente. La evaluación de riesgos de TI ayuda
a abordar las cuestiones planteadas por la teoría copo de nieve y permite a las
organizaciones para determinar qué áreas requieren atención auditoría.
Las evaluaciones de riesgo tradicionales Aparte
Es importante tener en cuenta que los procesos y actividades de
evaluación de riesgo tradicionales pueden no admitir una evaluación eficaz
de los riesgos de TI. Estos procesos y tareas deben ser rediseñados para
hacer frente a las necesidades de una evaluación de riesgos de TI de
manera adecuada. En concreto, la mayoría de los procesos de evaluación
de riesgo legado son altamente basado entrevista. Entrevistas por sí solas
son propensos insuficiente para evaluar los riesgos de TI, ya que una
buena parte de los riesgos de TI se basa en cómo la tecnología está
configurado específicamente a la organización. Por otra parte, una buena
parte del riesgo en el ámbito de TI está dictada por cuestiones emergentes.
Por ejemplo, supongamos que un hacker descubre una nueva falla en
Windows 2003 y construye una herramienta que explota esta falla.
Microsoft identifica el problema y libera un parche que elimina la falla.
Estática versus dinámica del riesgo
En la Sección 4.4, se tuvo en cuenta el concepto de riesgo generalizada frente
específica. La comprensión de estas dinámicas es importante. Sin embargo, cuando
se realiza una evaluación de riesgos de TI, también es importante tener en cuenta
estática frente a dinámica del riesgo.
Riesgo estático - riesgo estático no cambia de un año a otro y por lo
general es impulsado por la industria en el que opera la organización.
Por ejemplo, la empresa XYZ es una tienda online de libros y ha
riesgo asociado con sus servidores Web que se ejecutan el sistema
de pedidos en línea. Si esos servidores bajan, fuente de ingresos de
la compañía se apaga hasta que los servidores volverá a subir de
nuevo.
8
Al evaluar las técnicas de riesgos, investigación y entrevista estáticas
son, en muchos casos, adecuada. Además, estas evaluaciones tienden a
necesitar un poco de actualización cada año, basado en las nuevas
condiciones, pero por lo general ser cierto año tras año. A no ser que la
empresa XYZ decide salir del negocio de los libros en línea y abrir una
solución de ladrillo andmortar, los servidores web seguirá siendo un área de
alto riesgo.
Riesgo dinámico - Dinámica del riesgo es el riesgo que está cambiando
constantemente. Tiende a ser menos impulsada por la industria y más
impulsado por la evolución de la tecnología (recuerde la Ley de Moore). El
descubrimiento de un nuevo defecto en Windows 2003 es un gran ejemplo de un
riesgo dinámico. evaluación de riesgos del año pasado no habría identificado
que el riesgo; que no existía en ese momento. dinámica del riesgo también
afecta a la forma en el proceso de evaluación de riesgos de TI debe llevarse a
cabo. En este caso, el proceso de evaluación de riesgos de TI debe centrarse en
el proceso de administración de TI que tiene en el lugar para controlar y medir
los parches de su implementación oportuna.
cuestiones legales y reglamentarias son también grandes riesgos
dinámicos. Estos problemas afectan a todas las áreas del negocio, pero
teniendo en cuenta la evolución de la tecnología, hay mucho mayores nuevas
cuestiones legales y reglamentarias relativas a la tecnología que se presentan
cada año. Consideremos, por ejemplo, todas las nuevas normas y reglamentos
relacionados con la privacidad de la información al consumidor que se han
promulgado en el pasado reciente.
Evaluación del riesgo Dynamic IT
Al realizar una evaluación de riesgos de TI dinámica, los procedimientos de investigación
por sí solos son probablemente insuficiente. Hay dos pasos clave que deben ser tomados:
descubrimiento y análisis.
Descubrimiento - La detección es el proceso de determinar qué tecnologías se
han desplegado, la forma en que se han configurado, y qué procesos de
negocio que soportan y alinean con. n muchos casos, las herramientas se
utilizan para apoyar el proceso de descubrimiento. Por ejemplo, una
organización con una función de TI descentralizada puede no saber cuántos
servidores y versiones de sistemas operativos están en uso en toda la
empresa. Un descubrimiento de red y herramienta de mapeo podrían
ayudar a reunir estos datos con rapidez y precisión.
Análisis - El análisis se basa en la evaluación de los datos una vez que se ha
recogido. Una vez más, esto probablemente no ser conducido a través de los
procedimientos de investigación, pero sería más basado en el auditor de TI
analizar los datos recogidos contra los nuevos problemas y nuevos riesgos
tecnológicos.
Otro concepto que surge en la fase de análisis es el concepto de dependencia
riesgo. Este concepto fue tocado en la anterior utilizando una analogía de arena
tamizado a través de un montón de pantallas (Sección 4.3 relacionados con las TI
proliferación de riesgos). Si hay un agujero en cada pantalla, luego la arena podría caer
hasta el final
 Los riesgos relacionados con TI - - 4 GTAG

a través de ellos. Esta es la esencia de la dependencia riesgo. El impacto de un

riesgo dado puede depender de la presencia de otros riesgos. Por ejemplo, la
empresa XYZ no ha segregado la red corporativa y está utilizando una serie de
redes inalámbricas. El equipo de ingeniería colabora electrónicamente en los
documentos de diseño de nuevos productos. En este caso, el riesgo del negocio
es que un competidor podría sentar fuera con una antena y reunir información
sobre nuevos diseños de productos. Este riesgo es creado por la combinación
de diseño de redes, diseño de procesos, y las nuevas tecnologías, 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 una estrategia de

“capas de defensa”, que proporciona varios niveles de seguridad y control. Es
importante que durante el proceso de análisis, el CAE evalúa el diseño y la
eficacia de todos los niveles de defensa antes de concluir sobre el impacto de
un riesgo de TI o debilidad.

Evaluación de Riesgos de TI robusta

Teniendo en cuenta estas cuestiones, el DEA debe planificar en consecuencia y asegurar

que el proceso de evaluación de riesgos de TI:

• Es realizado en profundidad todos los años y no es sólo una actualización del

año anterior.
• Considera todas las capas del entorno de TI.
• Considera los riesgos tanto estáticas como dinámicas.

• No es estrictamente sobre la base de entrevistas, pero utiliza otras técnicas de

descubrimiento.

• Se complementa con el nivel apropiado de análisis después de

descubrimiento.
• Se lleva a cabo por el personal apropiado. Este último punto es el que puede

plantear uno de los retos más grandes a los DEA, porque es un término muy amplio y

comprende muchas capas. Las habilidades necesarias para comprender cada capa son

dramáticamente diferentes. Un especialista en redes con profundos conocimientos técnicos

tiene una habilidad muy diferente establecer que un especialista en aplicaciones SAP con
conocimientos técnicos profundos. Para llevar a cabo una evaluación eficaz de los riesgos

de TI, especialistas que entienden todas las capas del entorno de TI necesitan estar

involucrados. Estos son rara vez, o nunca, evidente en una sola persona. Lo que es mucho

más probable es que tendrá que estar involucrado un equipo de especialistas en auditoría

de TI con conocimientos en todas las capas. Este equipo también tendrá que trabajar en

estrecha colaboración con el proceso, principalmente debido a la cuestión de la

dependencia riesgo.

9
GTAG - Definición de la Auditoría de TI Universo - 5
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 llevó a cabo de manera efectiva, la organización debe
tener una idea razonable de lo que los riesgos de TI existe. Sin embargo, esto también
plantea una serie de retos, no menos importante de los cuales es la definición de las
auditorías de TI.
En el ejemplo anterior (página 8), la compañía había identificado un riesgo para
el negocio de transmitir información importante de diseño de producto fuera de la
organización. Lo que de auditoría se debe realizar para hacer frente a este riesgo? Si
se realiza una auditoría de redes inalámbricas; una auditoría de la arquitectura y
diseño de la red; o un revisión de la solicitud de la aplicación de diseño electrónico? Y
si las auditorías se rompen de esa manera, lo más probable es que la notificación de
resultados de la auditoría estará relacionada con los ajustes técnicos para cada
tecnología individual. Eso está bien, pero el comité de auditoría probable que no se
preocupa acerca de los ajustes técnicos detallados y probablemente quiere auditoría
de TI hallazgos a estar vinculados a los temas de negocios.
En consecuencia, la forma en que se definen las auditorías de TI juega un
papel importante en la eficacia global de la función de auditoría de TI. Esto se ve
agravado por la necesidad de la función de auditoría de TI para integrarse con los
procesos / auditores financieros / operacionales y los procedimientos que están
realizando, especialmente en entornos con grandes aplicaciones ERP integrados,
donde un gran número de controles de procesos clave están contenidos en los
sistemas .
Aunque no hay una manera correcta para definir las auditorías de TI, sin duda hay
grados de mal. Por ejemplo, muchos CAE cometen el error de la determinación del
alcance de una auditoría “controles generales de TI”. Esto es tan amplia que es casi sin
sentido, sobre todo en una gran organización. Se incluyen conmutadores telefónicos?
¿Qué hay de configuración de escritorio? Los controles ambientales en el centro de
datos? Todas las anteriores? Si es así, la auditoría requerirá una cantidad considerable
de tiempo para completar.
5.1 Consejos para el CAE
El reto es proporcionar el nivel adecuado de granularidad en la definición del universo
de auditoría de TI con el fin de hacer más eficaz y eficiente. Esto será diferente para
cada función de auditoría de TI (una extensión de la teoría de copo de nieve), pero
algunas consideraciones para el CAE cuando se definen las auditorías de TI son:
• El uso de demasiado amplias definiciones para auditorías de TI (por ejemplo,
los controles generales) casi garantizar que no habrá arrastramiento del
alcance de los procedimientos de auditoría. Por otra parte, también puede
haber una brecha entre lo que la administración piensa está siendo auditados y los
verdaderos procedimientos de auditoría que se realiza. Por ejemplo, la empresa
XYZ implementa SAP para los procesos de contabilidad financiera. La función de
auditoría que realiza una revisión posterior a la ejecución de las cuentas a pagar
los controles configurables, pero lo llama un “examen de la aplicación SAP
puesto.” Después de la auditoría, la empresa tiene un gran problema con la
configuración de seguridad del usuario de SAP. El comité de auditoría es probable
que preguntar por qué no fue capturado en el SAP posterior aplica-
10
opinión tación. Esta respuesta es que no se evaluó. Pero la
nomenclatura de la auditoría estaba engañando. Con esto en mente,
los DEA debe asegurarse de que la definición de cada auditoría de TI
es una descripción justa y precisa de lo que se está revisando.
• El universo de auditoría para el año debe tocar en todas las capas
en el entorno de TI. Aunque cada entorno es diferente, las capas
tienden a ser el mismo. Si el plan de auditoría de TI no incluye algunas
reseña de cada una de las capas, las probabilidades son que el plan, en
su conjunto, es deficiente.
• auditorías de TI deben estar estructurados de tal manera que se
proporcione para la presentación de informes eficaz y lógica. exámenes de
la aplicación, por ejemplo, rara vez son plenamente eficaces cuando se rompen
de forma independiente (por ejemplo, un Oracle cuentas por pagar opinión). Las
solicitudes deben ser integrados de una ejecución y presentación de informes a
los procesos / auditorías operacionales / financieras. auditorías de TI de
tecnologías de difusión (por ejemplo, redes, procesos, etc.) tienden a ser más
eficaces cuando auditado a nivel de empresa. En otras palabras, no realice una
auditoría de la red en las instalaciones de Pittsburgh y otra auditoría de red en la
instalación de Phoenix. Lleve a cabo una auditoría de red de la empresa.
Geografía importa menos que proceso.
• auditorías de TI deben cubrir los riesgos apropiados. En muchos casos, los
presupuestos de auditoría se determinan antes de realizar la evaluación de
riesgos de TI. Esto conduce inevitablemente a una de las dos situtions:
1. Un número insuficiente de horas de auditoría se extiende sobre
demasiadas auditorías, lo que resulta en la mala calidad
consistentemente las auditorías de TI porque no hay tiempo
suficiente para hacer cualquiera de ellos correctamente.
2. Las auditorías que se debe realizar no se realizan debido a que el
presupuesto no permite para que puedan llevarse a cabo. TI planificación de la
auditoría y el presupuesto deben ser un resultado del proceso de evaluación de
riesgos de TI, no se realiza antes de la evaluación de riesgos de TI. Además, la
evaluación de riesgos de TI debe ser considerada en el contexto de la evaluación del
riesgo para la empresa en su conjunto. Es muy posible que en una organización en
particular, el entorno de TI presenta tanto riesgo para la compañía que todos los
procedimientos de auditoría interna para el año deben ser los procedimientos de
auditoría de TI - una situación hiperbólica para estar seguro, pero no inviable.
5.2 Presupuesto para una auditoría de TI
Uno de los errores comunes de un CAE hace al definir el universo de auditoría de
TI está subestimando la cantidad de tiempo necesario para hacer una auditoría de
TI. El problema, en muchos casos, es la teoría de copo de nieve. Ejemplo:
Empresa ABC se está ejecutando una aplicación de finanzas en un AS / 400. El
auditor de TI quiere evaluar la seguridad en todo el AS / 400, y él o ella pasa 100
horas de realizar la revisión. Company XYZ también se está ejecutando una
aplicación similar en un AS / 400. Si de la revisión tomar la misma cantidad de
tiempo?
 GTAG - Definición de la Auditoría de TI Universo - 5

La respuesta, por supuesto, es que depende. Si la empresa ABC tiene 100

usuarios y de la compañía XYZ tiene 1000 usuarios, puede ser más apropiado asumir
que tomaría 10 veces más larga para la empresa XYZ, si la auditoría debe evaluar
todos los usuarios. Si el enfoque de auditoría es evaluar únicamente los derechos de
acceso de una muestra de 10 usuarios, a continuación, las auditorías podrían tomar la
misma cantidad de tiempo, sino que ofrecen diferentes niveles de garantía.

Ese ejemplo ilustra el peligro de la estimación de los presupuestos de TI de

auditoría. Es fácilmente posible calcular mal el esfuerzo requerido en órdenes de
magnitud, que no se ve generalmente en la parte operativa o financiera de la casa de
auditoría. Estas estimaciones pueden estar equivocados, pero no por órdenes de
magnitud.
Otro ejemplo podría ser la auditoría de un sistema SAP. Una revisión de la
seguridad de un sistema SAP con dos clientes de producción tendrá dos veces más
que una revisión de seguridad de un sistema SAP con un cliente de producción. Ay
betides la CAE, que estima el presupuesto sin entender completamente el entorno
de TI (consulte la sección de evaluación de riesgos de TI). Si las estimaciones se
habían generado sin saber cómo había muchos clientes de producción, las
estimaciones presupuestarias podrían ser significativamente incorrecta.

¿Cómo debería un CAE abordar esta cuestión? Sin duda un elemento fundamental

es la comprensión del entorno de TI, que debe evolucionar de forma natural a partir de la

realización de una evaluación adecuada de riesgos de TI. Otro componente crítico es

estimar con precisión el tiempo necesario para realizar las tareas de TI de auditoría. Ciertas

tareas de auditoría de TI, tales como la revisión de un valor de configuración, se pueden

realizar de forma rápida y eficiente. Otras tareas, como la auditoría de una arquitectura de

seguridad de usuario complicada, pueden consumir una cantidad importante de tiempo.

Tácticamente, un DEA debe desafiar a un proyecto de presupuesto auditorías planificadas,

asegurar que la planificación frontend ha hecho lo suficiente para justificar una estimación,

y asegurar que el personal y la gestión de auditoría de TI están de acuerdo con la

estimación. Tenga cuidado que en muy pocas circunstancias puede una auditoría de TI de

menos de 80 horas es eficaz para cualquier tecnología.

11
GTAG - La ejecución de las auditorías de TI - 6
El proceso de la ejecución de una auditoría de TI es, en teoría, no es diferente que
el proceso de la ejecución de una auditoría operativa. El auditor planea la auditoría,
identifica y controles de documentos, prueba el diseño y la efectividad operativa de
los controles, concluye, y los informes. Debido a que la mayoría de los DEA están
familiarizados con este proceso general, no se trata en detalle en este GTAG. Sin
embargo, hay ciertos elementos de una auditoría de TI que varían ligeramente de
las auditorías más tradicional. Por lo tanto, esta sección identificará algunas de
esas áreas y proporcionar los DEA con un poco de perspectiva e ideas sobre cómo
manejarlos. Véase la Figura 2, Descripción general del proceso de auditoría, a
continuación.
6.1 marcos y normas
Un desafío que enfrentan los auditores durante la ejecución de una auditoría de TI es saber
qué auditar en contra. Muchas organizaciones no se han desarrollado completamente las
líneas de base de control de TI para todas las aplicaciones y tecnologías. La rápida
evolución de la tecnología probablemente haría que cualquier líneas de base inútiles
después de un corto período de tiempo.
La teoría del copo de nieve dicta que cada entorno es diferente. Sin embargo,
esto no va en detrimento del concepto de objetivos de control. Los objetivos de control,
por definición, deben permanecer más o menos constante desde un entorno a otro.
Considere el objetivo de que todos los datos y programas críticos de negocio deben ser
respaldados y recuperable. Ahora, cada entorno puede hacer eso de manera muy
diferente; copias de seguridad podrían ser manual, o automática, o una herramienta
puede ser utilizada. Podrían ser incrementales solamente, o puede haber copias de
seguridad completas de todo. Las copias de seguridad se podrían hacer a diario,
semanal, mensual, etc. 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 empresa,
o subcontratado a un tercero. El método utilizado por la organización para gestionar las
copias de seguridad sin duda afectar los procedimientos de auditoría y el presupuesto
para la auditoría, pero el objetivo de control no cambiaría. Teniendo en cuenta esto, un
DEA debe ser capaz de comenzar con un conjunto de objetivos de control de TI, y
aunque no proporcionaría el 100 por ciento de especificidad a ese entorno concreto,
seleccione un marco adecuado.
Figura 2 - Auditoría Descripción del Proceso
12
COSO y COBIT
Donde puede encontrar una CAE un amplio conjunto de objetivos de
control de TI? El COSO de (COSO de) Marco Integrado de Control Interno
y Enterprise Risk Management - Marco Integrado son excelentes fuentes
de información, pero no se centran en TI. Además, se ha evolucionado
mucho desde 1992, cuando se publicó el primer marco COSO, lo que
hace que los objetivos de control de TI COSO menos eficaz en el manejo
de las tecnologías de hoy en día. Un entorno de control basado en COSO
debe ser aumentado con objetivos más detallados de control de TI para
evaluar el entorno de control de manera eficaz. Un número de opciones
están disponibles para esto.
Un marco de control de TI es Objetivos de control para tecnologías de
la información y relacionadas ( COBIT), que fue publicado originalmente por la
tecnología de la información de Gobierno Institute en 1994, con el apoyo de
Auditoría y de control de asociación Sistemas de Información (ISACA).
Versión
4.0 de COBIT fue lanzado en noviembre de 2005. COBIT no pretende competir con
los marcos de COSO, pero se puede utilizar para complementar ellos aumentando
con los objetivos de control de TI-específica más robustas. COBIT 4.0 contiene 214
objetivos de control detalladas de TI organizados alrededor de 34 procesos de TI.
Claramente, COBIT proporciona un enfoque más detallado que los marcos de control
o de ERM internos de COSO, que proporcionan un buen punto de partida para la
identificación de objetivos de control relevantes para el medio ambiente que está
siendo auditada.
Políticas, normas y procedimientos
Un marco como COBIT ofrece un conjunto generalmente aceptada de los
objetivos de control de TI que ayuda a la gestión de conceptualizar un
enfoque para la medición y gestión de riesgos de TI. Gestión general sería
utilizar ese marco para guiar el desarrollo de un amplio conjunto de políticas
de TI, normas y procedimientos.
Por ejemplo, un marco de control de TI funcional incluiría típicamente un
objetivo de control en la obtención de los sistemas de información del acceso no
autorizado. Una organización puede lograr este objetivo mediante la definición de
una política que especifica

que todos los sistemas de producción deben tener acceso a un ID de usuario y
una contraseña única. Esta política sería entonces ser ampliada por un estándar
de organización que define los requisitos de identificación y contraseña (por
ejemplo, ID son la primera letra del nombre del usuario, seguido por su apellido;
contraseñas deben tener al menos ocho caracteres y contener una mezcla de
letras y otros caracteres; etc.). Tal norma sería entonces por aumentada por
procedimientos que definirían cómo se implementan las normas sobre una base de
plataforma por plataforma y se especifique la “evidencia de control”, creado y
mantenido a través de un desempeño exitoso del procedimiento. Este enfoque en
cascada del marco de control de la política, estándar y procedimientos es la
esencia de asegurar que los controles de TI corresponden efectivamente a la
empresa y el entorno de control de la empresa.
Supongamos que en el ejemplo anterior, la organización no ha definido un
estándar que proporciona detalles alrededor de longitud de la contraseña, etc. En
ese caso, el CAE se enfrentará a algunos retos en la determinación de qué auditar
contra, y será a menudo terminan ocupada en un debate con la administración de TI
sobre lo que constituye un control suficiente. ¿Qué es más seguro: una contraseña
con una longitud mínima de seis caracteres que caduca cada 30 días o una
contraseña con una longitud mínima de ocho caracteres que expira cada 90 días? A
menudo hay referencias a las “mejores prácticas”, sino un enlace específico no
siempre se dibuja.
En ausencia de normas de control de TI específicos de la organización, existen
varios estándares del mercado público y el control de la industria de TI. Estos pueden
ayudar a los procedimientos de auditoría de soporte de TI, ofreciendo una serie de
recomendaciones de “mejores prácticas”, donde se presentan los detalles específicos (por
ejemplo, contraseña debe tener al menos ocho caracteres y debe estar a punto de expirar
cada 60 días). Un auditor de TI puede utilizar estas normas como base de referencia para
auditar contra. Esto también es útil cuando se informa deficiencias, ya que lleva a cabo la
subjetividad de la deficiencia. Comparar “La seguridad de contraseña se puede mejorar”
con “Las contraseñas no son conformes con las normas de seguridad de la información
ISO27001.” Obviamente, la segunda redacción invitará a menos debate.
El reto con el uso de estándares públicos para auditar en contra
es que hay una gran cantidad de diferentes normas, y no siempre lo
recomiendo lo mismo. El propósito de este GTAG no es debatir los
méritos de las diversas normas, sino simplemente para fomentar la
CAE a considerar el apoyo a las auditorías de TI mediante el uso de
un estándar - lo que estándar tiene más sentido para la organización
y es aceptable para la administración de TI. En la mayoría de los
casos, un estándar se refiere a un elemento muy específica del
entorno de TI, tales como programa personalizado de seguridad o
desarrollo. En la mayoría de los casos, el CAE no está en
condiciones de dictar la norma específica utilizada por la
organización. Esta decisión debe ser tomada por ella o la dirección
ejecutiva. Si una norma ya ha sido acordada y desplegado, el DEA
debe identificar a esa norma y de auditoría en contra de ella.
13
GTAG - La ejecución de las auditorías de TI - 6
Seis Fuentes de Normas
Algunas normas para su consideración son:
ISO27001 / ISO17799 - El internacional
Organización de Normalización publicó este estándar de seguridad de la
información genérica reconocido internacionalmente, que comenzó como
una norma británica (BS 7799), se convirtió en un estándar ISO (ISO
17799), y ahora se conoce como ISO 27001. Contiene generalmente
aceptado las mejores prácticas en la gestión de seguridad de la
información, y es útil como referencia para los auditores de TI para auditar
contra. http://www.iso.org
Capability Maturity Model Integration - Instituto de Ingeniería de Software de
la Universidad Carnegie Mellon (SEI) ha publicado Modelos de Madurez de
Capacidad (CMM) para diversos procesos dentro de una organización,
principalmente relacionados con el despliegue de software. Los ejemplos
incluyen Ingeniería de Sistemas de Adquisición de Software CMM y CMM.
Estos MMC proporcionan un modelo para la construcción de procesos
controlados sostenibles dentro de una organización y son útiles a los
auditores la realización de auditorías de los procesos de desarrollo de
sistemas. En
2005, el SEI CMM integrado los existentes en el Modelo de Madurez
de Capacidades de Integración (CMMI).
http://www.sei.cmu.edu/cmmi/general/general.html
Instituto Nacional de Estándares y Tecnología
(NIST) - El Centro de Recursos para la seguridad informática es una división del
NIST que proporciona una amplia serie de publicaciones que ofrecen
información detallada sobre los temas de información de control de seguridad.
publicaciones de muestra incluyen Biométrica Especificación de datos para
verificación de identidad personal y Orientación para la seguridad del Microsoft
XP para profesionales de TI. Estas normas, una herramienta imprescindible para
cualquier auditor de TI que trabajan en el sector público o en la industria
aeroespacial y de defensa, proporcionar las mejores prácticas que pueden ser
utilizados en otras industrias también.
http://csrc.nist.gov/publications/nistpubs/index.html
SysAdmin, Audit, Network, Security (SANS)
Instituto - Una de las fuentes más confiables para la educación seguridad
de la información y la formación en el mundo (y por mucho, el más grande),
el Instituto SANS publica numerosos documentos sobre diversos aspectos
de la seguridad de las distintas tecnologías. SANS publicaciones ofrecen
una serie de requisitos específicos que un auditor de TI puede auditar en
contra. http://www.sans.org/aboutsans.php
La biblioteca de infraestructura de TI (ITIL) - Con el apoyo de la British
Standards Institute, ITIL proporciona las mejores prácticas para apoyar
los servicios de TI. publicaciones de ITIL se centran en el apoyo a la
gestión de servicios de TI. Como tales, son una herramienta valiosa para
el apoyo de un auditor interno la realización de auditorías de la capa de
gestión de TI. http://www.itil.co.uk/
Normas específicas del proveedor - Muchos proveedores de tecnología de
seguridad y control de emitir directrices para la tecnología que producen. SAP,
por ejemplo, emite un tres volúmenes
GTAG - La ejecución de las auditorías de TI - 6
Guía de seguridad que ofrece recomendaciones detalladas para asegurar y
controlar la aplicación SAP ERP. Estas normas de proveedores-lanzan con
frecuencia no se toman las consideraciones de seguridad y control al mismo
nivel que quizás una publicación NIST podría, sino que proporcionan un buen
comienzo. También pueden ayudar a limitar el debate en torno a los resultados
(por ejemplo, “restricciones de contraseña SAP no se fijan de acuerdo con los
requisitos de seguridad de los proveedores documentado”). CAE deben
consultar con los proveedores de sistemas de misión crítica para ver si las
normas específicas están disponibles. En muchos casos, el vendedor no
puede haber lanzado nada, pero el grupo de usuario asociado a que la
tecnología tiene (por ejemplo, Grupo de Usuarios de SAP Americas').
Gestión de Recursos de TI de Auditoría 6.2
Los recursos asignados para ejecutar auditorías planificadas juegan un papel crítico en la
eficiencia y eficacia de las auditorías. Abarca una amplia gama de tecnología - el conjunto
de habilidades necesarias para auditar una configuración de cortafuegos es muy diferente
del conjunto de habilidades necesarias para auditar las cuentas de las tablas de
configuración partido de tres vías a pagar en las aplicaciones de Oracle. Es fundamental
para que coincida con las habilidades necesarias para llevar a cabo una auditoría de TI
particular con el auditor de TI adecuada.
Uno de los desafíos que enfrentan los DEA de hoy es la identificación, contratación y
retención de los profesionales de auditoría de TI competente. Inevitablemente, cualquier
discusión sobre este tema va a unirse en torno a la cuestión de la contratación de una
persona de TI y la enseñanza de esa persona cómo auditar frente a la contratación de un
auditor y él o ella enseñanza de TI. No hay una solución perfecta, y siempre habrá
excepciones, pero direccionalmente, el DEA debe tener en cuenta que ningún auditor de TI
será capaz de hacer todas las auditorías de TI. Por lo tanto, cualquier función de auditoría
de TI tendrá que tener algunos auditores de TI más alineadas con las aplicaciones y
algunos auditores de TI más alineadas con las tecnologías de infraestructura. En términos
de abastecimiento de los auditores de TI que serán más alineada con las aplicaciones, por
lo general es más eficaz para encontrar, proceso, o personas de auditoría financiera y
darles una aplicación particular. En cuanto a los auditores de abastecimiento de TI que será
más alineados con las tecnologías de infraestructura de auditoría, por lo general es más
efectivo para contratar personal de TI y les enseñan cómo auditar. En consecuencia, un
CAE que tiene una sólida comprensión del universo de auditoría de TI actual y los actuales
conjuntos de habilidades de TI de auditoría sobre el personal debe ser capaz de enfocar
sus esfuerzos de reclutamiento en consecuencia.
TI estrategias de retención de Auditor
Una vez que los auditores de TI se han contratado, el siguiente reto clave es la retención.
Los auditores de TI tienden a ser más móviles que los auditores tradicionales debido a la
actual falta de auditores de TI cualificados en el mercado. Una forma de CAE para hacer
frente a este problema es mejorar la compensación. En muchos casos, los presupuestos no
permiten esto; Por lo tanto, en la evaluación puede tener que ser creativos a la elaboración
de una estrategia de retención.
Muchos auditores de TI están motivados por la exposición a la tecnología. Ellos
disfrutan jugando con las tecnologías nuevas y excitantes.
14
A continuación se presentan algunas áreas en las que el CAE puede apoyar objetivos de
retención mediante el aprovechamiento de la voluntad del auditor de TI para la exposición a
la tecnología:
certificaciones - Hay una serie de certificaciones tecnológicas disponibles. Estos
incluyen certificaciones técnicas - tales como diversas certificaciones en los
routers de Cisco y tecnologías de bases de datos - y certificación de módulos
específicos de SAP. ISACA ofrece una certificación Certified Information
Systems Auditor (CISA). Certificación de Fundamentos de ITIL proporciona
una comprensión básica de los diversos procesos de ITIL para la gestión de
servicios y la prestación de servicios. Esta es una necesidad para los
auditores de TI revisar los departamentos de TI que utilizan procesos de ITIL.
El CAE puede considerar bonificaciones que están vinculados a las
certificaciones específicas “habilidades calientes” - es decir, un auditor de TI
recibe un bono para convertirse en un Cisco Certified Network Associate
(CCNA). Esto permite que la organización para proporcionar compensación
adicional sin aumentar los salarios base. Por otra parte, muchas
certificaciones toman un poco de tiempo para llevar a cabo, lo que garantiza
que un auditor de TI se mantendrá al menos la longitud de tiempo necesario
para obtener la certificación. Una palabra al sabio, sin embargo, a veces los
auditores de TI estará recolectando las certificaciones para salir de la función
de auditoría. Es necesario examinar cuidadosamente lo que sea
certificaciones del auditor de TI desea seguir y asegurarse de que los encajar
dentro de los previsto auditoría de TI universo.
Rotación - Considere un programa de rotación entre el departamento de TI y la
función de auditoría de TI. Esto puede ayudar a aumentar la capacidad de
auditoría de TI, así como fortalecer las relaciones de auditoría con el
departamento de TI. Ser conscientes de los posibles problemas de independencia
al implementar este tipo de estrategia. Además, asegúrese de que la función de
auditoría de TI puede proporcionar una cierta experiencia de auditoría a las TI
desplegados “rotatees.”
Educación continua - Los auditores de TI necesitarán más entrenamiento
que proceso o los auditores operacionales. Ha habido relativamente
pocos saltos cuánticos en los procesos coincidentes de tres vías en los
últimos 10 años, pero ciertamente ha habido grandes avances en TI. Para
los auditores de TI para estar al tanto, necesitan ser entrenados temprano
y con frecuencia. El DEA debe reconocer esto y construir una estrategia
de capacitación para el departamento que tiene en cuenta las
necesidades de los auditores de TI. Debería considerarse la posibilidad
de desarrollar experiencia en una amplia gama de temas importantes.
Esto se puede lograr mediante la asignación de ciertos auditores de TI
para convertirse en expertos en la materia en una tecnología dada (por
ejemplo, un auditor de TI es el especialista Microsoft, otro es el
especialista en la base de datos, y una tercera es el especialista SAP).
Esto permitirá un mejor auditorías que si todos los auditores de TI están
capacitados en todas las materias. Sin embargo,
Grupos de Usuarios - La mayoría de los proveedores de tecnología mantienen un
grupo de usuarios, que se compone de los clientes que utilizan la

tecnología y se reúnen para compartir ideas, inquietudes, y es de esperar
influir en el desarrollo futuro de la tecnología. Aunque tradicionalmente los
grupos de usuarios han sido el dominio de los profesionales de TI y usuarios
de negocios, en muchos casos, estos grupos pueden ser valiosos para el
auditor de TI también. Las Américas de Usuarios de SAP Group, por
ejemplo, mantiene un subgrupo que se centra en la seguridad y los
controles. Los auditores de TI deben buscar a los grupos de usuarios de las
tecnologías críticos usados ​por la organización y unirse a ellos. En muchos
casos, puede que no haya coste incremental de la organizació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.
el personal adecuado
Muchas de las funciones de auditoría de TI tienen limitaciones
presupuestarias que les impiden mantener un personal con la gama de
habilidades de auditoría de TI necesarios para auditar el universo de
auditoría de manera eficaz. La organización no esperaría que el
departamento de TI para operar sin experiencia en el personal en los
sistemas operativos, bases de datos, redes y sistemas de aplicación. Sin
embargo, a veces se espera que la función de auditoría de TI para operar sin
recursos suficientes. Inevitablemente, esto lleva a la auditoría mediante
técnicas de investigación utilizando la lista de verificación y como la principal
fuente de evidencia de auditoría. Como se indica en este documento, para
una función de auditoría que sea eficaz, un plan específico de auditoría debe
ser impulsada por una evaluación del riesgo sólida y respaldada con los
procedimientos de auditoría que están diseñados específicamente para los
matices de ese entorno particular.
Una razón principal para el CAE para defender los recursos
suficientes desprende del apartado 140 del Estándar de Auditoría de la
Junta de Supervisión Public Company Accounting Nº 2, Auditoría del
control interno sobre la información financiera se realiza en conjunto con
la auditoría de estados financieros, que establece:
“... la siguiente [circunstancias] debe considerarse al menos una
deficiencia significativa y como un fuerte indicador de que existe una
debilidad material en el control interno sobre la información financiera ...
La función de auditoría interna o la función de la evaluación de riesgos
no es efectivo para una empresa para la que tales una función debe ser
eficaz para que la empresa tiene un control efectivo o componente de la
evaluación de riesgos, como para las empresas muy grandes o muy
complejos “.
La ausencia o la presencia limitada de una función de auditoría interna IT
en una organización con un entorno de TI grande o complejo podrían presentar
una situación en la que el auditor externo de la organización podría concluir que
el artículo 140 se pueden aplicar.
En algunas circunstancias, el CAE puede querer explorar la posibilidad de
co-sourcing parte o la totalidad de la función de auditoría de TI. La mayoría de los DEA
entender los pros y los contras de co-sourcing; esta
15
GTAG - La ejecución de las auditorías de TI - 6
guía no pretende ser un manual sobre ella. Sin embargo, los DEA generalmente
luchan con la cantidad de co-fuente y lo que audita a co-fuente. La combinación
óptima varía de una organización a otra (la teoría del copo de nieve se aplica de
nuevo), pero CAE puede encontrar útil para evaluar su organización frente a los
siguientes datos del Instituto de Auditores Internos 2004 Red Global de
Información de Auditoría (GAIN) informe (del IIA):
• 39 por ciento de todos los servicios de auditoría interna son comprados auditoría
de TI relacionados.
• Porcentaje de trabajo de auditoría de TI externalizados:
- 8.1 por ciento de las organizaciones externalizar el 100 por ciento
de su trabajo de auditoría de TI.
- 7.1 por ciento de las organizaciones externalizar la mayor parte de
su trabajo de auditoría de TI.
- 8.3 por ciento de las organizaciones externalizar entre 25 por ciento y
50 por ciento de su trabajo de auditoría de TI.
- 33.1 por ciento de las organizaciones externalizar “algunos” de sus
trabajos de auditoría de TI.
- 41,6 por ciento de las organizaciones sin encargar 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 incrementar la
contratación externa de auditoría de TI.
- 64,9 por ciento de las organizaciones planean ningún cambio en su
cantidad de externalización de TI de auditoría.
- 13.3 por ciento de las organizaciones planean disminuir su
externalización de auditoría de TI.
sugerencias adicionales con respecto al co-sourcing incluyen:
Co-fuente las auditorías técnicas - En este caso, “auditorías técnicas” se
refiere a las auditorías que se realizan en las capas de infraestructura y
aplicaciones técnicas del entorno de TI. En general, estas auditorías
requieren un nivel mucho más alto de experiencia técnica específica, que
es más probable que se encuentre en el mercado que internamente.
auditorías de TI de la capa de gestión son mucho más centrado en los
procesos de TI (por ejemplo, el desarrollo de sistemas) y por lo tanto
requieren menos en profundidad las habilidades técnicas.
Considere el uso de dos proveedores - Puede ser útil para mantener los
contratos con un proveedor principal de servicios cosourced así como un
proveedor secundario. En ciertos casos, una empresa puede tener conflicto
de intereses en un potencial de auditoría por alguna razón; puede ser útil
tener una espera proveedor de copia de seguridad y listo para entrar en una
palabra de precaución:. el proveedor primario debe realizar por lo menos 80
por ciento de las actividades co-origen. Cualquier cosa menor que y la caída
de la eficiencia (por ejemplo, el doble de reuniones y aumento de gastos
generales administrativos) serán mayores que los beneficios. Para asegurar
que los proveedores aprenden bien empresarial de la organización y tratar la
organización como un cliente importante, no más de dos firmas deben ser
utilizados. Si la Empresa ABC
GTAG - La ejecución de las auditorías de TI - 6

proporciona la mayor parte o la totalidad de los servicios de auditoría de TI a una

organización, que tendrá una relación diferente con la organización que si la
empresa ABC es uno de los dos o tres empresas que proporcionan el 30 por
ciento de los servicios de auditoría de TI de la organización.

Co-fuente distribuida a nivel mundial auditorías - La mayoría de las empresas

mantienen los empleados en todas las principales regiones del mundo, y
muchas empresas operan en diferentes estructuras de precios para los recursos
locales. Por lo tanto, si una organización quiere auditar sus operaciones en
Kuala Lumpur, puede ser capaz de utilizar una firma con recursos locales de
Malasia a un costo reducido, en lugar de enviar los recursos a Malasia. La única
excepción a esta recomendación es cuando el estatuto de auditoría interna dicta
que la función de auditoría interna proporciona una cierta cantidad de servicios
de consulta a las unidades de negocio alrededor de los controles. En tal caso,
puede ser más útil tener una auditoría de equipo en todo el mundo por lo que las
mejores prácticas internas pueden ser observados por el equipo y se reparten
entre las unidades de negocio.

dieciséis

Como se señaló anteriormente, los presupuestos de auditoría pueden ser difíciles de
calcular y gestionar. CAE deben buscar oportunidades de utilizar aceleradores -
herramientas y / o técnicas que ayudan a apoyar los procedimientos de auditores de TI
se presentará - para aumentar la eficiencia y la eficacia de la auditoría. CAE pueden
utilizar un acelerador para hacer lo mismo de auditoría en menos tiempo o
procedimientos de auditoría más detallados en la misma cantidad de tiempo.
Muchos aceleradores de auditoría requieren una inversión, por lo que la DEA debe
considerar cuidadosamente los costos / beneficios de cualquier solución antes de invertir en
un acelerador. aceleradores de auditoría pueden ser divididos en dos categorías generales:
Los facilitadores de auditoría, que ayudan a apoyar la gestión global de la auditoría (por
ejemplo, una herramienta de gestión de papeles de trabajo electrónico), y prueba de
aceleradores, herramientas que automatizan el rendimiento de las pruebas de auditoría
(por ejemplo, herramientas de análisis de datos).
7.1 facilitadores de auditorías
Workpapers electrónicos
Aunque no es específico de solo audita, la gestión electrónica de papeles de trabajo puede
ser muy útil. Estas soluciones proporcionan una gestión centralizada y la retención de los
documentos de trabajo, flujo de trabajo de auditoría, el seguimiento de versiones, señal
electrónica apagado, etc Hay una serie de proveedores en el mercado que ofrecen estas
herramientas. Es importante tener en cuenta la funcionalidad de la herramienta. Por
ejemplo, puede apoyar auditorías simultáneas múltiples? Antes de implementar cualquier
herramienta, se deben definir los requisitos funcionales de auditoría. Tal vez lo más
importante, sin embargo, es el contenido que se proporciona con la herramienta.
¿Contiene procedimientos de auditoría sugeridos o actividades de control? CAE sin duda
tendrá que personalizar cualquiera que sea la base de conocimientos se incluye con la
herramienta, pero puede proporcionar una ventaja significativa.
Software de Gestión de Proyectos
No necesariamente específica a la auditoría, los horarios de software de gestión de
proyectos planes de trabajo, asigna la responsabilidad de las tareas, las pistas hitos y
entregables del proyecto, y puede ser utilizado por la función de auditoría de TI para
proporcionar consistencia adicional y presentación de informes de auditorías de TI.
software de gestión de proyectos es utilizado actualmente por 35 por ciento de los
encuestados 2004 GANANCIA.
Software Diagramas de Flujo
Software que puede documentar gráficamente los flujos de transacciones, puntos de
control, y los pasos clave del proceso es muy útil - casi necesario - cuando el proceso de
documentar tutoriales, en particular para fines de cumplimiento Sarbanes-Oxley. El
almacenamiento de la documentación de procesos gráfica compatible electrónicamente la
facilidad de diagramas de flujo actualización, según los procesos de cambio y proporciona
para facilitar el almacenamiento y la distribución. Diagramas de Flujo de software es
utilizado actualmente por 59 por ciento de los 2004 encuestados GAIN.
Software de seguimiento abierta Edición
Este software permite el seguimiento de las cuestiones de auditoría pendientes o
deficiencias y, a menudo se integra con el software de gestión de documentos,
especialmente los diseñados para Sarbanes
17
GTAG - Auditoría de TI Aceleradores - 7
fines de cumplimiento Oxley. Funcionalidad típicamente incluye la posibilidad de asignar la
responsabilidad de los procedimientos de remediación, asignar fechas de vencimiento y
entregables, y realizar un seguimiento e informar sobre los progresos. software de
seguimiento de tema abierto es utilizado actualmente por 47 por ciento de los encuestados
2004 GANANCIA.
Sitio web del Departamento de Auditoría
Un número de departamentos de auditoría han establecido sitios Web departamentales.
Estos son generalmente basados ​en la intranet, pero puede ser a través de Internet.
soluciones basadas en Internet ofrecen intercambio mundial de información a través de las
organizaciones, pero plantean problemas de confidencialidad. Cualquier tipo de solución
proporciona una función de auditoría interna con la capacidad de tener el centro de
intercambio de información y la comunicación. Estas soluciones pueden ser desarrolladas
de forma personalizada o comprados a proveedores. Los sitios web de departamentos de
auditoría se utilizan actualmente en un 42 por ciento de los 2004 encuestados GAIN.
7.2 Aceleradores de prueba
aceleradores de prueba pueden automatizar las tareas de auditoría que requieren mucho
tiempo, tales como la revisión de las poblaciones grandes de datos. Además, el uso de una
herramienta para llevar a cabo procedimientos de auditoría ayuda a establecer la
coherencia. Por ejemplo, si se utiliza una herramienta para evaluar la configuración de
seguridad del servidor, todos los servidores probados con esa herramienta serán evaluados
a lo largo de las mismas líneas de base. La realización de estos procedimientos permite
manualmente para un grado de interpretación por parte del auditor de TI. Por último, el uso
de herramientas permite a los auditores de TI para poner a prueba toda una población de
datos, en lugar de sólo una muestra de transacciones. Esto proporciona un grado mucho
más alto de garantía de auditoría.
CAE deben tener en cuenta las siguientes consideraciones con respecto a ella
aceleradores de auditoría:
• Herramientas cuestan dinero. El DEA debe estar seguro de que los beneficios
superan los costos antes de iniciar cualquier aplicación de herramientas.
• Los auditores de TI tendrán que ser entrenados en la nueva herramienta. No es
raro que una herramienta se encuentra sin utilizar en un departamento de
auditoría interna porque no se sabe cómo usarlo. Esto reduce claramente el
retorno de la inversión de cualquier herramienta.
• La herramienta también necesitará apoyo, administración de parches y
actualizaciones. Dependiendo de la herramienta, se puede requerir un servidor
independiente también. Por esta razón, cualquier selección de la herramienta
debe ser gestionado con la ayuda del departamento de TI.
• En algunos casos, los proveedores de servicios de gestión o de terceros pueden
no permitir el acceso a las herramientas del entorno de producción directa.
Cualquier uso de herramientas y / o secuencias de comandos debe ser discutido a
fondo con, y aprobado por la administración de TI y ser probado completamente
antes de implementar.
Software de Análisis de Datos
Estas herramientas permiten a un auditor de TI para llevar a cabo el análisis estadístico
robusto de grandes conjuntos de datos. También pueden ser utilizados para apoyar
GTAG - Auditoría de TI Aceleradores - 7

proceso o auditorías operacionales (por ejemplo, cuentas a pagar críticas de fraude), y revisar el plan de uso de cualquiera de estas herramientas con el oficial de

que pueden soportar muchos tipos de pruebas, como el análisis de Benford, el muestreo seguridad y coordinar las pruebas con la administración de TI para asegurar la

acumulativo, etc. Una consideración cuando se utiliza una herramienta de análisis de sincronización de prueba no tendrá impacto en el procesamiento de la producción.

datos es que puede ser difícil de extraer los datos de la fuente original. Es crítico que En algunos casos, los administradores de oficiales o sistemas de seguridad que ya

pueden realizar procedimientos de auditoría para garantizar la integridad y exactitud de se pueden ejecutar algunas de estas herramientas de forma regular como parte de

los datos fuente. Algunos de los proveedores clave en este ámbito son: los procesos de gestión de sistemas. Si es así, los resultados pueden ser capaces

de aprovechar para apoyar las auditorías de TI, si se diseña y se ejecuta

correctamente. Una lista de las 75 principales herramientas se puede obtener en

• ACL: http://www.acl.com/Default.aspx?bhcp=1 www.insecure.com.

• Idea: http://www.audimation.com/product_feat_ benefits.cfm

Herramientas de análisis de seguridad de las aplicaciones - Si una organización

• Monarch: http://monarch.datawatch.com/ está utilizando cualquier aplicación empresarial integrada grande (como un sistema

• SAS: http://www.sas.com/ ERP como SAP u Oracle), muchos de los principales controles internos son altamente

dependientes de la seguridad. Por ejemplo, tal vez la empresa XYZ tiene una política

Herramientas de Análisis de Seguridad corporativa que todos los cheques de más de $ 10.000 requieren aprobación de la

Estos son un amplio conjunto de herramientas que pueden revisar una gran población de administración antes de emitir. Eso es sin duda un buen control. Ahora, supongamos

dispositivos y / o usuarios e identificar los riesgos de seguridad. Hay muchos tipos que la empresa XYZ ha configurado su sistema de Oracle para que cualquier cheque

diferentes de herramientas de análisis de seguridad, pero en general se pueden clasificar creado más de $ 10.000 automáticamente se coloca en una cola de espera para alguien

de la siguiente manera: que aprobar y liberación. Este ejemplo es otro uso de los controles de TI sólida para

Herramientas de análisis de red - Estas herramientas consisten en programas de apoyar las políticas corporativas. Ahora, supongamos que todos los usuarios del

software que se pueden ejecutar en una red y obtener información acerca de la red. sistema de Oracle tienen acceso total al sistema. Obviamente, cualquier usuario podría

Los piratas informáticos se utilizan normalmente una de estas herramientas en la entrar en la cola de espera y aprobar y liberar el cheque. Es por esta razón que la

parte delantera de un ataque para determinar lo que la red parecía. Los auditores seguridad a nivel de aplicación debe estar bien diseñada y construida en conjunto con

de TI pueden utilizar estas herramientas para una variedad de procedimientos de los procesos y controles de la aplicación. Además, este es un ejemplo de qué cualquier

auditoría, incluyendo: tipo de auditoría (financiera, proceso, operacional, o IT) en un entorno de gran

aplicación integrada necesita incluir un componente de seguridad del usuario para ser

• Verificar la exactitud de los diagramas de red mediante la eficaz. Por desgracia, la construcción de la funcionalidad para apoyar auditorías de

asignación de la red corporativa. seguridad usuario de la aplicación no es necesariamente una prioridad para muchos

• La identificación de los dispositivos de red clave que pueden justificar la vendedores, que tienden a centrarse más operacionalmente. En consecuencia, a

atención de auditoría adicional. menudo es muy engorroso y requiere mucho tiempo para llevar a cabo auditorías de

• La recopilación de información acerca de lo que está permitido el tráfico a seguridad de usuario de la aplicación. Estas auditorías pueden acelerarse mediante el

través de una red (lo que apoyaría directamente el proceso de evaluación uso de una herramienta de análisis de seguridad de aplicaciones, muchas de las cuales

de riesgos de TI). Una lista de las 75 principales herramientas se puede tienden a ser especializada para diversos sistemas de aplicación (PeopleSoft, SAP, u

obtener en www.insecure.com. Oracle) y analizar la seguridad del usuario contra las reglas preconfiguradas. Estas

herramientas también pueden evaluar la separación de funciones dentro de la

Herramientas de piratería - La mayoría de las tecnologías tienen una serie de aplicación. El DEA debe tener en cuenta que la mayoría de estas herramientas vienen

vulnerabilidades estándar, tales como la existencia de identificaciones y contraseñas con un conjunto de reglas preconfiguradas o “mejores prácticas”.

por defecto o ajustes por defecto cuando la tecnología se instala fuera de la caja. Vendedor-promocionado Debido a la teoría de copo de nieve, tendrá que ir

herramientas de hacking prevén un método automatizado de la comprobación de acompañada de un proyecto de fondo para crear cualquier aplicación de una de estas

estas vulnerabilidades estándar. Estas herramientas pueden ser dirigidos contra el herramientas un conjunto de reglas que es relevante para esa organización en

cortafuegos, servidores, redes y sistemas operativos. Muchas de ellas ofrecen para particular. De no hacerlo, dará lugar a informes de auditoría que contienen una serie de

plug-and-go de uso; el auditor de TI se enchufa en un rango de lo que quiere la cualquiera de los falsos positivos o falsos negativos. Algunos proveedores clave en este

herramienta para buscar, hojas, y regresa en unas pocas horas o al día siguiente. ámbito son: tendrá que ir acompañada de un proyecto de fondo para crear un conjunto

Para entonces, la herramienta ha desarrollado un informe de todas las de reglas que es relevante para esa organización en particular cualquier aplicación de

vulnerabilidades identificadas en ese rango. una de estas herramientas. De no hacerlo, dará lugar a informes de auditoría que

contienen una serie de cualquiera de los falsos positivos o falsos negativos. Algunos

proveedores clave en este ámbito son: tendrá que ir acompañada de un proyecto de

Estas herramientas son importantes para un auditor de TI para funcionar por varias fondo para crear un conjunto de reglas que es relevante para esa organización en

razones, no menos importante de los cuales es que estas son las herramientas que particular cualquier aplicación de una de estas herramientas. De no hacerlo, dará lugar a informes de auditor

un hacker podría utilizar para montar un ataque contra la organización. La • Approva: http://www.approva.net/
organización debe tener al menos la misma información que un hacker tendría. Es • LogicalApps: http://www.logicalapps.com/
importante tener en cuenta que algunas de estas herramientas son potencialmente • Virsa: http://www.virsa.com/
peligrosos para funcionar, ya que pueden afectar la integridad de los sistemas que • Software Q: http://www.qsoftware.com/index.htm
está escaneando. El auditor de TI debe • Soluciones de Control Internacional:
http://www.csi4sap.com/en/home/

18
 GTAG - Preguntas para el CAE - 8

auditoría que ha existido durante muchos años. Sin embargo, está en constante evolución papeles de trabajo de auditoría de TI revisa la calidad y la adecuación?

y cambio. En consecuencia, el CAE debe adaptarse y evolucionar continuamente el

enfoque de auditoría de TI y el universo de auditoría de TI para llevar a cabo
procedimientos de auditoría de TI que son necesarios para satisfacer los requisitos de
cumplimiento de manera adecuada y ayudar a gestionar el riesgo global del negocio de la
organización.
Aunque esta guía no tiene todas las soluciones y, en algunos casos, puede
plantear más preguntas que respuestas, espero que el CAE se puede utilizar como
una herramienta para ayudar con esta evolución. Las siguientes preguntas se
proporcionan para ayudar a los CAE que consideren estas cuestiones en el contexto
de su organización:
• Se ha establecido una estrategia de capacitación para los auditores
de TI? ¿Considera todas las capas del entorno de TI?
• Son problemas de TI y los riesgos evaluados cada año para determinar la
relevancia dentro de la organización emergente? ¿Cómo identifica la
organización de estas cuestiones emergentes?
• Ha referenciado la función de auditoría de la función de auditoría de TI con
las mejores prácticas de la industria? Fue la encuesta GAIN u otros
repositorios de datos utilizadas para facilitar esto?

• la organización ha definido claramente lo que significa en su organización en • Hacer todas las auditorías de proceso contienen procedimientos que evalúan los

particular? Se áreas del jefe oficial de información de responsabilidad valores de configuración de aplicaciones para las aplicaciones que automatizan

documentados? ¿El enfoque de auditoría de TI debe tener en cuenta todas los procesos? ¿Cómo están coordinadas entre los recursos de auditoría (en

esas áreas en la evaluación de riesgos y la definición del universo de comparación con el proceso de TI)?

auditoría de TI?

• ¿Tiene la función de auditoría realizar una evaluación eficaz de los riesgos de

TI al año? Son especialistas con conocimientos en tecnologías de
infraestructura, sistemas de aplicación, y todo lo que los procesos
involucrados en esa evaluación?
• ¿La evaluación de riesgos de TI en cuenta la arquitectura
tecnológica específica y la configuración empleada por esa
organización?
• ¿Cómo son los riesgos de TI cuantificado? Son tanto impacto y probabilidad
de ocurrencia estimada? ¿Qué parámetros de la industria y las mejores
prácticas se utilizan para apoyar estas estimaciones?

• ¿Tiene previsto el universo de auditoría de TI para las auditorías en cada

capa del entorno de TI? ¿Si no, porque no? ¿Hay circunstancias especiales
que se aplican, o es la sub-óptimo plan de auditoría de TI?

• ¿Cómo son los presupuestos para las auditorías de TI estima? Fue lo

suficientemente informaciones recogidas en la parte delantera de la auditoría

para apoyar una estimación precisa? Fue la configuración específica de la

tecnología considerada?

• ¿Cómo se definen los procedimientos de auditoría de TI? Son desarrollados

internamente por el entorno específico de la organización, o se utilizan listas
de control del mercado?
• la organización ha implementado o no un marco de control de TI o
normas? ¿De ser asi, cuales? Si no es así, se han establecido
internamente seguridad y control de líneas de base? Si no es así, se ha
recomendado el CAE la implementación de un marco de control de TI y
las líneas de base de seguridad y control como parte de la auditoría de la
gestión y la administración de TI?

• Son las herramientas usadas para acelerar las auditorías de TI (por ejemplo,

aceleradores de prueba o facilitadores)? ¿Si no, porque no? Si es así, ¿se han

probado completamente y aprobado por la administración de TI?

• ¿Cómo se audita atendido? Son especialistas utilizan para diversas

tecnologías (por ejemplo, aplicaciones frente a las tecnologías de
infraestructura)? ¿Si no, porque no? Como son

19
GTAG - Apéndice A - Temas emergentes
La Ley de Moore predice la evolución continua de la tecnología. Este apéndice
cubre algunas tecnologías emergentes de los cuales los DEA deben tener en
cuenta, y el impacto potencial sobre la organización y la función de auditoría de TI.
De ninguna manera se trata de una lista exhaustiva de todas las tecnologías
emergentes, pero es indicativo de algunos de los problemas más prevalentes en el
mercado.
Estas cuestiones serán sin duda variar de un entorno a otro (la teoría del
copo de nieve) y pueden presentar mayor o menor riesgo en función de los
procesos de la industria, tecnología, o de negocios. Los temas, junto con sus
riesgos y recomendaciones, se presentan en ningún orden en particular, sino
que están diseñados para obtener CAE pensando en su entorno y si
actualmente programado procedimientos de auditoría evaluará estos temas.
A.1 Redes Inalámbricas
Las redes inalámbricas están proliferando en todas las organizaciones, porque son
útiles y pueden apoyar directamente a los objetivos de negocio. Sin embargo,
también son fáciles de instalar (como cualquier persona que ha establecido una red
doméstica inalámbrica probablemente puede dar fe) y proporcionar un punto de
entrada potencial en la red corporativa. CAE deben preocuparse tanto con la
seguridad de las redes inalámbricas que están autorizadas por la organización, así
como las redes inalámbricas sin escrúpulos que los usuarios han establecido sin
autorización.
Riesgos de la red inalámbrica
Intrusión - Las redes inalámbricas pueden permitir la entrada no autorizada
a la red corporativa.
escuchas ilegales - Las redes inalámbricas pueden permitir que personas no
autorizadas tengan acceso 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 usar esa sesión
para acceder a la red corporativa.
Radio Frequency Management (RF) - La red inalámbrica puede enviar
transmisiones en zonas no deseadas, que pueden tener otros impactos.
Por ejemplo, los hospitales pueden tener equipos que reacciona mal a las
transmisiones de radio de onda y por lo tanto no deben ser expuestos a
las redes inalámbricas.
Recomendaciones para redes inalámbricas
Realizar una auditoría de red inalámbrica completa que incluye los dos
componentes siguientes:
• La organización más probable es que tiene redes inalámbricas que
han sido aprobados y ejecutados por una razón de negocio
específico. La función de TI debe evaluar estas redes y ayudar a
asegurarse de que están protegidos y controlados de acuerdo con
los objetivos de gestión.
• La organización puede tener redes inalámbricas no autorizadas que los
usuarios han establecidos. La función de auditoría de TI debe realizar
procedimientos para detectar si alguno de
20
existen estas redes y tomar las medidas apropiadas. Esto es más difícil de
garantizar que las redes están asegurados y controlados y es probable que
implicaría un auditor de TI ir físicamente a través de ubicaciones de
unidades de negocio con una antena, tratando de detectar la presencia de
dispositivos inalámbricos.
Como mínimo, el auditor de TI debe obtener y revisar una lista de todas
las redes inalámbricas aprobados por la organización. políticas y procedimientos
corporativos deben ser establecidos para las redes inalámbricas y deben
proporcionar directrices para la seguridad y control de estas redes, incluyendo el
uso de la encriptación de datos y autenticación a la red inalámbrica. El auditor
de TI debe revisar la configuración de las redes inalámbricas conocidas para
asegurar el cumplimiento con las políticas y procedimientos desarrollados. El
auditor de TI también debe detectar las redes inalámbricas no autorizadas y
tomar las acciones correctivas apropiadas.
Dispositivos móviles A.2
La mayoría de las organizaciones han reconocido el valor de los dispositivos
inalámbricos, como Blackberrys, asistentes digitales personales (PDA), teléfonos
inteligentes, o unidades TELXON y han proliferado estos dispositivos para apoyar los
objetivos de negocio. Sin embargo, no todas las organizaciones han comprendido el
riesgo de utilizar estos dispositivos.
Los riesgos de dispositivos móviles
Muchos de estos dispositivos almacenan datos comerciales críticos en el propio
dispositivo. Si el dispositivo no está configurado de una manera segura, la
confidencialidad de estos datos puede verse afectado si el dispositivo se pierde o es
robado. Además, la transmisión de datos al dispositivo en sí mismo no puede ser seguro,
potencialmente comprometer la confidencialidad o la integridad de los datos. Debido a
que estos dispositivos son a menudo utilizados por la alta dirección, esto podría ser la
compañía. Además, estos dispositivos pueden permitir el acceso remoto a redes
corporativas, y en el caso de TELXON o dispositivos similares, pueden intiate el
procesamiento de transacciones. Consideremos, por ejemplo, una empresa de
distribución de bebidas que equipa a los conductores de ruta con los dispositivos
inalámbricos que se utilizan para reservar las transacciones de inventario ya que
entregar producto para cada cliente.
Recomendaciones para dispositivos móviles
El auditor de TI debe revisar gestión de dispositivos móviles. Como
mínimo, se debe tener en cuenta:
aprovisionamiento - El proceso para un usuario para procurar un dispositivo.
Normalización - se estandarizan los dispositivos?
Configuración de seguridad - ¿Qué políticas y procedimientos se han establecido
para la definición de las líneas de base para los dispositivos de seguridad?
Transmisión de datos - ¿Cómo se controla la transmisión de datos?
El acceso a las redes corporativas - Haz dispositivos proporcionan el acceso a
la red corporativa? Si es así, ¿cómo es que controlaba?
 GTAG - Apéndice A - Temas emergentes
Perdidos o dispositivos robados - ¿Cómo sería la empresa identificar los
dispositivos perdidos o robados y terminar el servicio a ellos?
Interface Software - Si estos dispositivos inician las transacciones de negocios,
¿cómo es que la información interconectado en las aplicaciones corporativas?
A.3 Interfaces
entornos de TI complejos a menudo requieren complejas interfaces para integrar sus
aplicaciones críticas de negocio. Incluso los grandes entornos integrados ERP a
menudo requieren complicadas interfaces a otras aplicaciones distribuidas, al igual que
los sistemas de Internet. Estas interfaces pueden ser habilitadas con la tecnología de
middleware, que actúa como un punto central de comunicación y coordinación para las
interfaces. A pesar de que las interfaces y middleware juegan un papel importante en el
procesamiento de extremo a extremo de las transacciones, que en muchos casos no
están incluidos en los planes de auditoría. Esto puede deberse a que las interfaces son
difíciles de clasificar. Son similares en función a una infraestructura o tecnología de
apoyo, sin embargo, son aplicaciones de software que en realidad puede procesar
transacciones.
Los riesgos de interfaz
Interfaces y middleware en particular, son un eslabón crítico en el procesamiento de
extremo a extremo de las transacciones. Como mínimo, se mueven los datos de un
sistema a otro. En un máximo, que pueden ser responsables de la transformación de
los datos, la realización de algún cálculo o la modificación de los datos en función de
algún algoritmo. Las interfaces también pueden suponer un punto único de fallo a la
organización. Considere la empresa XYZ, que se ejecuta en un sistema ERP para la
consolidación financiera. Las unidades de negocio distribuidas todas las interfaces
de mantener una variedad de sistemas dispares hasta el sistema central de la
empresa. Hay aproximadamente 200 de estas interfaces, todos corriendo a través de
un único servidor de middleware y aplicaciones. Ese servidor middleware se detiene
repentinamente de funcionar. Esto tendría un impacto sustancial en las operaciones
de la empresa.
Recomendaciones para Interfaces
El DEA debe garantizar la evaluación de riesgos de TI y el universo de auditoría
considera interfaces y middleware. Los temas específicos que se deben considerar
son:
El uso de software de gestión de interfaces - ¿El software transforma los
datos o simplemente moverlo de un sitio a otro?
interfaz de identificadores - El software de interfaz probablemente necesite acceso a
los sistemas de a / desde la que se está moviendo datos. ¿Cómo se administra
este acceso? Se utilizan identificadores genéricos? ¿Qué acceso se conceden
estas identificaciones, y quién tiene acceso a utilizar estos ID?
Directorios de interfaz - ¿Todos los datos se movieron a través de una única
interfaz de directorio? ¿Quién tiene acceso a ese directorio? ¿Cómo se
asegura y controla? Por ejemplo, hace un empleado de una de las unidades
de negocios disponen de acceso al directorio para cargar un archivo de
transacción
21
¿tratamiento? Si es así, ¿el directorio también contiene datos utilizados en las
transferencias bancarias o pagos electrónicos salientes? ¿Cómo es el empleado
restringida a partir de estos conjuntos de datos? Es potencialmente
entremezclados datos?
Tipos de interfaz - ¿Qué tipos de interfaces se utilizan? Están en tiempo real
o por lotes orientado? ¿Qué operaciones se apoyan? ¿Es que inician el
tratamiento de otras transacciones (por ejemplo interconectado órdenes
de venta que inician el envío de mercancías).
Gestión de datos A.4
Las organizaciones están automatizando cada vez más los procesos de negocio y
funciones. Al mismo tiempo, el costo de almacenamiento de datos es cada vez más barato
y más barato. Incluso los ordenadores personales de hoy pueden tener unidades de disco
duro de 250 GB que almacenan datos o más, mucho más que incluso los grandes
servidores podrían almacenar hace cinco años. Estos problemas han dado lugar a la
proliferación de las grandes soluciones de almacenamiento de datos corporativos. No es
raro que una organización de tamaño medio para almacenar y gestionar terabytes de datos
empresariales. A medida que las organizaciones comienzan a manejar estas grandes
repositorios de datos, surgen muchos problemas.
Gestión de datos de Riesgos
La falta de gestión repositorios de datos, o redes de área de almacenamiento (SAN),
puede resultar en la pérdida de la disponibilidad de los datos críticos de negocio. Las
organizaciones deben garantizar que la integridad de estas soluciones de almacenamiento
se mantiene adecuadamente. Sin embargo, puede ser difícil de realizar copias de
seguridad, o reorganizar una red de almacenamiento de datos que contiene seis terabytes
de datos empresariales. tecnologías de gestión y mantenimiento de nuevos deben
desplegarse, y nuevos procesos de gestión deben ser definidas. Por otra parte, el
crecimiento de almacenamiento de datos también coincide con la promulgación de
muchas nuevas leyes, estatutos y regulaciones con respecto a la gestión de datos. Por lo
tanto, los requisitos de gestión de datos de una organización también deben cumplir con
numerosos nuevos requisitos legales e industriales.
Recomendaciones para la Gestión de Datos
Realizar una revisión exhaustiva de gestión de datos. Como mínimo,
se debe tener en cuenta:
Clasificación de datos - ¿La organización ha pasado a través de un ejercicio
de clasificación de datos? ¿Qué tipos de categorías de datos se han
establecido, y cuáles fueron los criterios para organizar los datos en esas
categorías?
Propiedad de los datos - ¿La organización ha asignado formalmente la propiedad de
los datos a los propietarios de datos específicos? Se han documentado las
responsabilidades de estos propietarios de los datos?
Retención de datos - ¿Se ha desarrollado una estrategia de retención de datos?
Incluso grandes soluciones de almacenamiento de datos pueden llenarse,
momento en el que la organización necesita o eliminar datos o mover los datos
a alguna otra solución de almacenamiento, tales como archivarlo. ¿Cuál es la
política de archivo / retención actual? ¿Cómo afecta esto o apoyar los objetivos
de la organización? Si una necesidades de auditoría
GTAG - Apéndice A - Temas emergentes
a realizar, serán los datos allí para auditar? ¿O se han archivado
o eliminado? Si se ha archivado, que puede ser recuperado
fácilmente?
Archivado y retención Herramientas - Si una estrategia de retención de datos se ha
definido, puede requerir herramientas de apoyo que, como software de archivo, o
el archivo de medios. Estas herramientas pueden necesitar ser examinado para
evaluar la eficacia con que se están realizando los procedimientos requeridos.
Gestión de datos - ¿Cómo se gestionan los datos? ¿Cuáles son los diario /
semanal / otras tareas que se deben realizar para ayudar a garantizar la
integridad de los datos? Que realiza esas tareas, y cómo se
procedurized?
A.5 privacidad
privacidad de los datos y de los derechos del consumidor son temas muy visibles en
la actualidad. Un gran número de leyes de protección de datos con la que las
grandes empresas deben cumplir haber sido promulgar. En algunos casos, estas
leyes pueden tener sustancialmente diferentes requisitos, incluso hasta el punto de
la incompatibilidad entre sí. Por ejemplo, una gran organización que hace negocios
en Europa y América del Norte está sujeto a la Directiva de Privacidad de la UE
sobre protección de datos, protección de información personal de Canadá y el Acta
de Documentos Electrónicos
2000, cualquier número de regulaciones a nivel estatal de los Estados Unidos, y tal
vez los requisitos específicos de la industria, como el de la Ley Gramm-Leach-Bliley
de 1999. Estos Ley de 1996 Portabilidad del Seguro de Salud y o son todos
diferentes. Si una organización quiere poner un sitio web que ofrece juegos o medios
de comunicación que los niños puedan acceder, necesitan estar al tanto de las leyes
de protección de datos protección de los niños también.
Los riesgos de privacidad
El incumplimiento de ciertas leyes de privacidad podría resultar en multas y / o
penales. Además, podría haber un impacto significativo en el valor de marca.
Considere un fabricante de cereales que pone juegos que promueven su cereal
en el sitio web corporativo. Un número de niños que se registra en el sitio y
jugar a los juegos. Un hacker continuación compromete la lista de usuarios
registrados, que contiene alguna información de identificación personal sobre
los niños que están registrados en el sitio. El periodico de Wall Street a
continuación, publica una historia sobre cómo la compañía de cereales dejar
información personal de los niños se escapan a través de 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 sería un impacto positivo en el valor de
los accionistas.
Recomendaciones para la Privacidad
Realizar una auditoría de privacidad. Como mínimo, la organización debería
considerar:
¿Qué leyes de privacidad se aplican a la Organización - ¿Ha identificado
la organización todas las diversas leyes, reglamentos y estatutos con los
que debe cumplir?
La responsabilidad de Privacidad - ¿Se ha creado un papel director de
privacidad? ¿Cuáles son las responsabilidades de ese
22
¿papel? ¿Cuál es el papel de consejero general con respecto a la privacidad?
Policias y procedimientos - ¿Se han establecido políticas y
procedimientos para crear, almacenar y gestionar los datos de negocio?
¿Cómo están implementados, y cómo garantizar el cumplimiento de la
organización?
Las tareas de cumplimiento - se realizan las tareas de cumplimiento Lo
específicos? ¿La organización requiere cifrado de datos? Si es así, ¿qué
métodos se utilizan? Se metodologías de desarrollo Web actualizados para
incluir elementos tales como las políticas de opt-in?
A.6 segregación de funciones
A medida que las organizaciones a integrar sus entornos en las aplicaciones más grandes
y complejas, la separación de funciones es menor en función del puesto de trabajo y mucho
más en función de lo que las transacciones que el usuario puede realizar en el sistema. En
consecuencia, la segregación apropiada de funciones depende en gran medida de
seguridad de nivel de aplicación.
Al mismo tiempo, sin embargo, la seguridad a nivel de aplicación es cada vez
más complejo y requiere un mayor nivel de experiencia para administrar
adecuadamente. Como resultado, muchas organizaciones están experimentando
deficiencias relacionadas con la separación de funciones. Por último, la complejidad de
la seguridad a nivel de aplicación hace que sea más difícil para auditar la separación
de funciones con eficacia y eficiencia.
La segregación de Riesgos servicio
inadecuada segregación de funciones podría exponer a la organización para el robo,
fraude o uso no autorizado de los recursos de información. Por otra parte, las deficiencias
en la separación de funciones podrían afectar el cumplimiento de la ley Sarbanes-Oxley
de manera adversa. Un número de las debilidades materiales en el control interno
declarado por las empresas que cotizan en bolsa en 2004 estaban relacionados con la
separación de funciones.
Recomendaciones para la segregación de funciones
Realizar una segregación de funciones de auditoría, que debe incluir:
La comprensión de cómo segregación de funciones es el Ser
Gestionados y controlados - ¿Qué procesos, personas y herramientas se
utilizan para apoyar la gestión de la separación de funciones?
Definición de conflictos - ¿La organización ha desarrollado una lista completa de
todas las funciones de trabajo que se consideran incompatibles? ¿Cómo se ha
modificado la lista de ubicaciones de unidades de negocio que tienen un personal
significativamente más pequeño? Quien participó en el desarrollo de la lista?
Fueron todas las partes interesadas clave que participan en el establecimiento y
aprobación de los conflictos?
La determinación de las deficiencias específicas - ¿La organización ha utilizado la
lista de conflictos para identificar cualquiera de las funciones de seguridad
específicas, o individuos específicos que se les ha concedido acceso que presenta
una violación de la separación de funciones? Es una herramienta que se utiliza
para facilitar este proceso? Si es así, ¿cómo se ha configurado la herramienta?
¿El proceso de la herramienta y controlar los conflictos en tiempo real?
 GTAG - Apéndice A - Temas emergentes
Asignación de Responsabilidad - ¿La organización ha asignado
formalmente la responsabilidad de gestionar y controlar la separación de
funciones a un papel individual o trabajo específico? Si es así, ¿qué
tareas Qué implica esta responsabilidad, y cuál es el plazo de ejecución?
Se han establecido políticas y procedimientos para guiar este papel?
Realización de un análisis de varias aplicaciones - ¿Se han establecido
instrumentos, políticas y procedimientos para gestionar el análisis de
segregación de funciones entre aplicaciones? Ejemplo: La empresa XYZ
es el uso de SAP para la contabilidad financiera y de recursos humanos
PeopleSoft. Un usuario tiene acceso a ambos sistemas, y el acceso
combinado crea una segregación de deberes conflicto. Análisis de o bien
el sistema SAP o el sistema PeopleSoft no revelaría el conflicto. Sólo un
análisis de la aplicación transversal de ambos sistemas revelaría el
conflicto.
Acceso Administrativo A.7
personal de la administración de sistemas generalmente se otorgan altos niveles de
acceso a los recursos de TI. Esto se explica de distancia, ya que se supone que son
los administradores que necesitan este acceso para realizar su trabajo.
Los riesgos acceso administrativo
Los usuarios con acceso de nivel administrativo potencialmente pueden realizar muchas
funciones más allá de sus responsabilidades fundamentales de trabajo. Un usuario con
acceso completo a una aplicación de negocios, por ejemplo, podría potencialmente crear
una factura, recibir los bienes, y un cheque. Este mismo usuario administrativo también
podría eliminar todos los registros de seguimiento de auditoría. Un usuario con acceso
administrativo a la base de datos podría apropiarse indebidamente de toda la ejecución de
pago electrónico.
A medida que las organizaciones continúan automatizar e integrar sus
entornos de TI, la contabilidad administrativa corre el riesgo de aumento. Un
administrador de sistemas con acceso ilimitado a un sistema SAP de alcance total
tiene mucha más potencia que un administrador de sistemas con acceso ilimitado a
un sistema de almacén. El no restringir el acceso administrativo adecuada es una
exposición significativa, y para las empresas que cotizan en bolsa podría afectar
Sarbanes-Oxley Sección 404 la opinión de su auditor externo. Para las empresas
que subcontratan parte o la totalidad del entorno de TI, este riesgo es aún mayor
por dos razones:
• En muchos casos, el proveedor externo puede servir a múltiples
organizaciones con un gran equipo. Por lo general, esto significa que en lugar
de un equipo de cinco administradores que apoyan una organización, puede
haber un equipo de 25 administradores que apoyan colectivamente cinco
organizaciones. Si es así, los 25 administradores probable que se les
concederá un importante nivel de acceso.
• Los acuerdos contractuales no obstante, siempre es un riesgo
mayor cuando alguien que no es un empleado de la organización
tiene acceso administrativo a los sistemas.
23
Recomendaciones para el acceso administrativo
En todos los entornos, se requiere acceso administrativo para operar los sistemas.
Sin embargo, la función de auditoría de TI debe ayudar a asegurar que los
administradores de sistemas sólo tienen acceso a los datos y funciones necesarias
para llevar a cabo las responsabilidades del trabajo. Tenga en cuenta que esto no
incluye las transacciones funcionales. Los administradores de sistemas que nunca,
como parte de sus obligaciones de trabajo, publicar una transacción para el G / L,
un cheque, o mantener un registro maestro de proveedores. Como tales, no deben
tener acceso para realizar estas transacciones. Otro argumento típico es que los
administradores necesitan acceso funcional a solucionar. Sin embargo, la mayoría
de solución de problemas y las pruebas deben realizarse en el entorno de prueba,
no en la producción. Si el entorno de prueba no es una representación adecuada
de la producción, que indica una falla en el proceso de desarrollo de sistemas,
El auditor de TI también debe considerar:
Acceso división - Dividir el acceso para realizar una función para que dos
personas se necesitan para llevar a cabo la función.
identificadores genéricos - En ciertos casos, un equipo administrativo esté
compartiendo una ID administrativo. El auditor de TI revisar un informe de
acceso sólo vería un solo usuario, pero la realidad puede ser que varios
usuarios están utilizando ese ID. Esto aumenta el riesgo porque ahora la pista
de auditoría se ve comprometida.
Número de personas con acceso de administrador - Acceso a funciones
administrativas debe limitarse a un número pequeño de sólo los
administradores. No todo el mundo en el departamento de TI necesita
acceso administrativo.
Gestión de pista de auditoría - Teniendo en cuenta que los usuarios administrativos
tienen un alto nivel de acceso a los sistemas, uno de los únicos controles de
mitigación disponibles es el examen periódico independiente de pistas de
auditoría. Esta revisión puede ser realizada por personal de auditoría de TI o por
otros recursos independientes (por ejemplo, un director de TI en otra función de
TI). Es fundamental asegurarse de que, si es posible, los sistemas de personal
administrativo no pueden borrar los datos de seguimiento de auditoría. Este paso
a menudo se puede realizar ya sea a través de la configuración de seguridad o
sistemas.
El uso de identificadores de firecall - firecall identificaciones y contraseñas
también se pueden utilizar para ayudar a mitigar el riesgo de conceder
acceso administrativo. Un ID firecall es una cuenta establecida con acceso
de administrador. Esta cuenta está cerrada con llave, y la contraseña es
conocida sólo por una persona independiente dentro de la organización.
Cuando surge una situación de emergencia, el personal de apoyo que
recupera la contraseña para el ID de firecall, y esta recuperación se registra.
La persona de apoyo utiliza el ID para realizar las tareas requeridas y
devuelve el ID de la persona independiente, que entonces bloquea la
cuenta. Hay algunas herramientas nuevas disponibles en el mercado hoy en
día que automatizan este proceso.
GTAG - Apéndice A - Temas emergentes
Los controles configurables A.8
Como se discutió en la introducción de este GTAG, muchos de los controles clave
de hoy son, o configurados en las aplicaciones empresariales de base tecnológica.
Considere el ejemplo partido de tres vías automatizado explorado en la introducción.
La funcionalidad de este proceso de comparación está controlado por una serie de
ajustes configurables dentro de la aplicación (por ejemplo, niveles de tolerancia, el
tipo de partido por cantidad o valor, qué hacer con las transacciones que fallan el
partido, lo que explica las variaciones de reserva a, etc.) .
En muchos casos, estos controles configurables son los controles primarios
que gestionan y controlan el procesamiento de transacciones a través de un
proceso dado. Sin embargo, estos controles se pasan por alto cuando se realiza
una auditoría de proceso.
Controles configurables Riesgos
Si no se consideran los controles de aplicación configurables cuando se realiza una
auditoría del proceso puede dar lugar a la ineficacia de los procedimientos de auditoría o
conclusiones de la auditoría inexactas. Además, a menudo es mucho más rápido para
revisar un entorno configurado en línea que realizar y revisar una muestra de 60
transacciones. Por lo tanto, el hecho de centrarse en los controles configurables también
puede dar lugar a procedimientos de auditoría ineficientes.
Recomendaciones para los controles configurables
La evaluación de los controles configurables no deben llevarse a cabo como una auditoría
de TI independiente. Por el contrario, todas las auditorías orientadas a los procesos deben
evaluar las opciones configurables que controlan ese proceso en particular como parte de
la auditoría general. Esto puede suponer un problema de coordinación porque los auditores
de TI probablemente tendrá que trabajar mano a mano con los auditores de proceso para
determinar qué ajustes son importantes y para llevar a cabo los procedimientos de auditoría
técnicas requeridas.
El DEA debe revisar el plan de auditoría para todas las auditorías de proceso
planificado. Si el plan no incluye ninguna pruebas de controles configurables, que debe
ser impugnada para determinar por qué no se están revisando los controles
configurables. El hecho de que no están siendo revisados ​no es necesariamente una
debilidad; puede haber cualquier número de razones válidas por las que los controles
configurables no son relevantes para esa auditoría en particular.
Si los controles configurables son relevantes para una auditoría de proceso en
particular, es importante considerar cómo se llevarán a cabo las pruebas de estos
controles. Al entrar en una tabla de configuración y evaluación de la configuración requiere
un conjunto de habilidades muy diferente a la revisión de una muestra de 60 transacciones.
CAE eficaces elaborar un plan de auditoría que utiliza el conjunto de habilidades
adecuadas en los lugares correctos. Para las auditorías de proceso, esto puede significar
que los procedimientos de auditoría de coordinación entre múltiples auditores sobre una
única auditoría. Este tipo de coordinación puede crear algunos problemas 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 en la actualidad que nunca. A
medida que las organizaciones a automatizar sus empresas, más activos se convierten a
formato digital. La gestión digital de
24
activos pueden ser, por ciertas empresas, ser más crítico para el éxito de la
compañía de proteger los activos físicos. La Internet ha creado una red de
distribución global que permite una distribución rápida y anónima de los
activos digitales pirateados.
Los riesgos de piratería
A medida que el valor de los activos digitales aumenta, el riesgo asociado con la piratería
también aumenta.
Ciertas organizaciones e industrias ver la piratería como uno de los mayores riesgos
que enfrentan hoy en día. Obviamente, los recientes combates entre la industria
discográfica y los diversos sitios de intercambio de música Napster digitales (por
ejemplo) son sólo un ejemplo de esto.
El impacto monetario directo de la piratería es difícil de cuantificar, pero muchas
organizaciones estiman que la piratería tiene un impacto línea de fondo 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 debe incluir:
Inventario de todos los activos digitales mantenida por el
Organización - ¿Tiene la organización una lista actualizada de todos
los activos digitales y sus respectivas ubicaciones físicas y lógicas?
Clasificación - ¿La organización ha pasado por un proceso de clasificación de
activos digitales? Si es así, ¿qué criterios se utilizaron para el ejercicio? Lo
que los estratos se definieron?
Almacenamiento - ¿Dónde se almacenan los activos digitales? ¿Cómo se
almacenan? Se mantienen las copias de seguridad adecuados? Si las copias de
seguridad se almacenan en otro lugar, ¿cómo están aseguradas y controladas?
Cifrado de datos - Son los activos digitales sujetos a las tecnologías de
encriptación? Si es así, que las tecnologías? ¿Los métodos de cifrado
tienen sentido para estos tipos de activos?
El acceso administrativo y de terceros - Si están asegurados activos digitales, lo que
otras personas tienen acceso a esos? Ejemplo: La empresa XYZ está haciendo su
última película de éxito del verano. Se ha gastado $ 200 millones de dólares en el
desarrollo y comercialización. La película se almacena en forma digital en grandes
servidores de edición, como cualquier empresa prudente haría. Estos datos son
una copia de seguridad fuera del sitio y la almacena. Una de las personas en la
cadena de almacenamiento (por ejemplo, el conductor o fuera de las instalaciones
gestor de almacenamiento) realiza una copia de la copia de seguridad y libera la
película sin terminar en Internet varias semanas antes de su lanzamiento de
teatro, lo que resulta en una taquilla bruta reducida de manera significativa para
que en particular película. Por desgracia, todo el fiasco es el resultado del deseo
inicial para tener un buen control de TI (por ejemplo, copias de seguridad). Esta
paradoja obliga al auditor de TI a considerar nuevas formas de seguridad y control
de los bits y bytes.
Transporte y Transmisión - Las mismas cuestiones que se aplicaban
anteriormente también se aplican al transporte y transmisión de activos
digitales. Ciertamente, cualquier cifrar
 GTAG - Apéndice A - Temas emergentes

archivo digital enviado a través de correo electrónico está expuesta y Software y Grupos de usuarios
potencialmente podría ser explotada. Ha desarrollado la organización políticas dominio
• Las público. de
herramientas

y procedimientos eficaces que proporcionan para el transporte y / o transmisión - Business Software Alliance promueve un mundo digital seguro
de activos digitales? y legal -
http://www.bsa.org/usa/antipiracy/Free-SoftwareAudit-Tools.cfm
Otros recursos
Organizaciones profesionales - Auditnet ® es una red de recursos disponibles para los auditores -
http://www.auditnet.org
• Sistemas de Información de Auditoría y Control Association (ISACA) -
www.isaca.org
- Ofrece las designaciones Certificado de Sistemas de Auditor • Grupos de Usuarios.

(CISA) y el Certificado de Sistemas de Información (CISM). - Usuarios de SAP Americas Group - www.asug.com
- Grupo de Usuarios Oracle Independiente - www.ioug.org
• Instituto de Auditores Internos (IIA) - www.theiia.org - Quest International User Group (para
- Ofrece la designación Certified Internal Auditor PeopleSoft / JD Edwards) -
(CIA). http://www.questdirect.org
- ofertas ITAudit, un boletín electrónico gratuito que incluye una - SQL Server todo el mundo Users Group -
biblioteca de referencia. http://www.sswug.org
• Asociación de Seguridad de Sistemas de Información (ISSA) - www.issa.org - directorio de Yahoo de grupos de usuarios -
http://dir.yahoo.com/Computers_and_Internet/ Organizaciones /
- Apoya los sistemas de información certificados de seguridad. User_Groups

- ISC2 administra el proceso de certificación, pero no es una

organización profesional en sí mismo.
• Instituto Americano de Contadores Públicos Certificados (AICPA) -
www.aicpa.org
- Patrocinadores Certificado designación de Contador Público
(CPA).

Sitios web útiles

• http://www.csoonline.com
- Ofrece recursos útiles, incluyendo artículos de seguridad, para los ejecutivos

de seguridad.

• http://www.whatis.com
- Grande para las definiciones de tecnología rápidos y enlaces rápidos a

otros sitios de TI.

• http://csrc.nist.gov
- Centro de Investigación de la seguridad informática, patrocinado por el
Instituto Nacional de Estándares y Tecnología.

• http://www.cyberpartnership.org
- La Alianza Nacional de Seguridad Cibernética, una asociación
pública-privada establecida para desarrollar estrategias y programas
compartidos para asegurar mejor y mejorar la infraestructura de información
de Estados Unidos.
• http://www.infosecuritymag.com/
- revista de seguridad de la información que cubre temas de seguridad
oportunas.

• http://www.itgi.org
- Existe para ayudar a los líderes empresariales en su responsabilidad
para que tenga éxito en apoyar la misión y las metas de la empresa.

25
GTAG - Acerca de los autores

Michael Juergens, autor principal, tiene más de 15 años de experiencia
profesional y ha estado con Deloitte desde 1996. En la actualidad es el líder de
la práctica de Garantía de Control de Deloitte para la región del Pacífico
Suroeste. Juergens se especializa en la evaluación de los controles de
tecnología de la información. Es un orador reconocido a nivel nacional en los
controles internos y ha hablado a muchos públicos, incluyendo el IIA, ISACA,
América Usuarios de SAP Group, MIS Training Institute, y los asistentes de
numerosos congresos nacionales e internacionales. Se sienta en el Comité de
Conferencias Profesional del IIA y supervisa todos los cursos de formación de
auditoría de TI ofrecidos por el IIA. Juergens actualmente se desempeña como
controles internos ventaja principal de una serie de grandes compañías
multinacionales. En ese sentido, ha supervisado la entrega de numerosos
y proporciona servicios a los clientes que operan en todo el mundo. Ringle se
especializa en sistemas de información y auditorías de procesos de negocio y las
evaluaciones, gestión de proyectos, y la Sección 404 de Sarbanes-Oxley
evaluaciones. Él ha ayudado a muchos clientes en la preparación, y con éxito la
implementación, los procesos de evaluación de Sarbanes-Oxley. Ringle se
graduó de la Universidad del Estado de Michigan con una licenciatura y un MBA
en la contabilidad. Él es un Contador Público Certificado (CPA), Certified
Information Tecnología Profesional (CITP), e Información Certified Systems
Auditor (CISA).
Los revisores

proyectos de control interno, proyectos de preparación SarbanesOxley, y
auditorías de certificación. Juergens tiene una licenciatura en economía de la
Universidad de California en Irvine, y un MBA de la Universidad de California en
Irvine.
David Maberry, contribuyendo autor, es un alto directivo de Auditoría de
Deloitte y la práctica de Enterprise Risk Services Aseguramiento de control en Los
Ángeles. Tiene una amplia experiencia en la gestión de riesgos, cumplimiento y
auditoría interna, con especializaciones en las evaluaciones de cumplimiento de
Sarbanes-Oxley, evaluación de riesgos de TI, opiniones previas y posteriores a la
implementación y auditorías técnicas en una variedad de sistemas y plataformas.
experiencia operativa significativa de Maberry proporciona una capacidad única
para analizar los procesos en prácticamente cualquier entorno y proporcionar el
máximo beneficio. Antes de unirse a Deloitte, trabajó durante más de 11 años en
posiciones avanzadas de gestión operativa en la industria del cuidado de la salud.
Actualmente soporta múltiples Maberry Fortuna 500 empresas en sus estrategias de
cumplimiento de auditoría y evaluación de negocios.
El Comité de Tecnología Avanzada IIA, IIA afiliados globales,
Instituto Americano de Contadores Públicos, Center for Internet
Security, Universidad Carnegie-Mellon Software Engineering
Institute, Sistema de informacion
Asociación de Seguridad, IT Process Institute, Asociación Nacional de
Directores Corporativos, y SANS Institute unió al proceso de revisión. Las
siguientes personas y organizaciones proporcionaron valiosos
comentarios a esta guía:
- American Institute of Certified Cuentas Públicas
- El Instituto de Auditores Internos en Australia
- El Instituto de Auditores Internos de Estados Kindom
- Christopher Fox - PricewaterhouseCoopers, EE.UU.
- David Bentley - Consultor, Reino Unido
- EW Sean Ballington - PricewaterhouseCoopers, EE.UU.
- Jay R Taylor - General Motors Corp., EE.UU.
- Larry Brown - El Options Clearing Corporation, EE.UU.
- Lars Erik Fjortoft - Deloitte, Noruega
- Lily Bi - El Instituto de Auditores Internos
- Stig J. Sunde - Oficina del Auditor General de Noruega

Jeff Fisher, editor y colaborador, es un alto directivo de Deloitte y Touche

práctica de Auditoría y Servicios de Riesgo Empresarial. Fisher ha estado con la
firma de más de ocho años y sirve como el director del proyecto y en un papel de
aseguramiento de la calidad técnica de algunos de los mayores clientes de Deloitte.
Se ha especializado en información de las auditorías de seguridad de sistemas y
evaluaciones, gestión de proyectos, y la sección 404 evaluaciones de
Sarbanes-Oxley. Fisher ha ayudado a muchos de los clientes de Deloitte en la
preparación, y con éxito la implementación, los procesos de evaluación de
Sarbanes-Oxley sobre una base global. Fisher se graduó de la Universidad Estatal
de Ferris con una

BS en los sistemas de contabilidad y de información de la computadora. Él es un

Certified Information Systems Security Professional (CISSP) y un auditor
certificado de Sistemas de Información (CISA).

Eric Ringle, editor y colaborador, es un alto directivo de Deloitte y Touche

LLP de Auditoría y la práctica de Servicios de Riesgo Empresarial. Cuenta con
más de 11 años de experiencia

26
Gestión de la Auditoría de TI

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 de manera adecuada. El
propósito de la guía es ayudar a los directores ejecutivos de auditoría y gerentes de auditoría interna responsables de
supervisar las auditorías de TI ordenar a través de los temas estratégicos que participan en la planificación, el rendimiento y la
presentación de informes de las auditorías de TI. Se toman en consideración los fundamentos de auditoría de TI y los nuevos
problemas.

¿Cuál es GTAG?

Elaborado por el Instituto de Auditores Internos, cada una Guía de Auditoría de Tecnología Global (GTAG) está
escrito en lenguaje simple negocio para solucionar un problema puntual relacionado con la gestión de tecnología de
la información, control y seguridad. La serie GTAG sirve como un recurso listo para ejecutivos de auditoría sobre
los diferentes riesgos asociados con la tecnología y las prácticas recomendadas. Las siguientes guías se publicaron
en 2005.

Guía 1: Controles de Tecnología de la Información

Guía 2: El cambio y la gestión de parches Controles: Crítica para

El éxito de la organización

Guía 3: Auditoría Continua: implicancias para el aseguramiento, monitoreo y

Evaluación de riesgos

Consulte el sitio Web de tecnología IIA en www.theiia.org/technology

Número de pedido: 1012

Miembro IIA US $ 25 US $ 30
No miembro IIA Evento US $
22.50

ISBN 0-89413-590-2

www.theiia.org