Sunteți pe pagina 1din 44

Auditoría de Sistemas Semestre 9 Fascículo No. 7

Tabla de contenido Contenido Análisis de riesgos Matriz de riesgo Controles en Informática Controles primarios de tecnología informática Controles de implementación Administración del desarrollo del sistema Diseño del sistema y preparación de programas Catalogación Administración de los cambios a sistemas Prueba de programas Catalogación Controles sobre la operación del computador Planificación de la carga Preparación y ejecución de trabajos Uso correcto de los archivos de datos Monitoreo de actividades Procedimientos de respaldo y recuperación Controles sobre la seguridad de los programas Controles sobre el acceso físico Segregación de funciones Controles sobre la seguridad de archivos de datos Software de controles de acceso

Acceso por los usuarios Acceso a datos en línea Acceso por los programas de producción Archivos fuera de línea Controles sobre el software de sistemas Instrumentos de control La documentación de las subetapas del desarrollo e implantación del sistema

Evaluación de controles Resumen Bibliografía recomendada Párrafo nexo Autoevaluación formativa

Análisis de riesgos

En el presente fascículo, nos ocuparemos del análisis de riesgos, estudiando temáticas como: matriz de riesgo, controles en Informática y evaluación de controles.

Indicadores de logro

Al terminar el estudio del presente fascículo, el estudiante:

Identifica los riesgos que se pueden presentar dentro de una organización y que están directamente relacionados con el área de informática.

Determina los controles que deben existir y aplicar en cada caso, para reducir, minimizar o eliminar los riesgos.

Realiza el análisis de riesgos para cada amenaza y/o escenario de riesgo y la evaluación de los controles existentes en la empresa.

Matriz de riesgo

La siguiente tarea del auditor en informática es elaborar la matriz de riesgo, cuyo objetivo principal es detectar las áreas de mayor riesgo en relación con informática y que requieren una revisión formal y oportuna.

El procedimiento de análisis y elaboración de la matriz de riesgos es un proceso que resulta del diagnóstico obtenido después de realizar las pruebas pertinentes en cada una de las áreas de trabajo o escenarios de riesgos en el área de informática. Existen varias formas de representar las matrices; algunas de ellas se limitan a exponer las áreas de riesgo, las amenazas o debilidades obtenidas, el

nivel de efectividad de los controles y, con base en estos datos, se determina el grado de exposición en que se encuentra la empresa, con el fin de adoptar los correctivos necesarios.

Para facilitar esta comprensión vamos a trabajar con la matriz que se compone de las áreas auditadas, los aspectos por evaluar, los riesgos y la probabilidad de ocurrencia de estos riesgos y las debilidades encontradas, así:

1. Es importante identificar el nivel de riesgo de cada uno de los elementos que integran la función de informática en la empresa, obtenido en el diagnóstico de la situación actual.

2. Las áreas que se analizarán varían según el tamaño y estructura de la empresa, lo que implica que el auditor tenga que evaluar productos y servicios de informática con un enfoque integral.

3. Algunos de los siguientes servicios de informática se mencionan de manera ilustrativa de tal forma que pueden incluirse otros que consideren hacen parte de la gestión del área de informática, así:

Planeación de informática

Administración de la red

Sistemas en desarrollo

Sistemas en producción o explotación

Administración del hardware y software

Soporte a usuarios

Investigación y desarrollo tecnológico

4. El auditor debe utilizar los parámetros de medición y evaluación necesarios y que estén alienados con la visión del negocio y del área de informática, para

evitar pérdidas innecesarias de tiempo en aspectos poco relevantes para la empresa.

Áreas

Aspecto o componentes por

Riesgo Clasifi

Debilidad

susceptibles de

evaluar del área

cación

auditar

del

riesgo

Administración

1.Misión y objetivos

Alto,

de informática

2. Organización

medio

3. Servicios

o bajo

4. Parámetros de medición

Dirección y

1.Seguimiento a la función

Alto,

niveles

de información por la

medio

ejecutivos

dirección

o

bajo

2. Comunicación e

integración

3. Apoyo a toma de

decisiones

Usuarios de

1.

Comunicación e

Alto,

informática

integración

medio

2. Proyectos conjuntos

3. Admón. de recursos

4. Grado de satisfacción

Control interno 1. Políticas y procedimientos

o bajo

Alto,

medio

o bajo

Ciclo de

1. Metodología

Alto,

desarrollo e

2. Técnicas

medio

implantación de 3. Herramientas

sistemas

4.

actualización

Capacitación/

Tabla 7.1 Matriz de riesgos.

o bajo

La primera columna describe el área auditada que se obtiene del plan de auditoría o plan de trabajo.

La segunda columna o aspecto a evaluar determina el escenario de trabajo del auditor para cada área a auditar.

El riesgo se obtiene a partir de las debilidades que el auditor identificó durante el proceso de análisis. Es importante determinar la probabilidad de ocurrencia del riesgo con el fin de establecer los potenciales efectos que este pueda tener cuando ocurra.

La columna de Clasificación del riesgo determina el nivel de daño o impacto causado por el riesgo, que en algunos casos se expresa en una notación de alta, media o baja criticidad o impacto del riesgo.

Los siguientes aspectos deben tenerse en cuenta para elaborar el diagnóstico de la situación actual y que ayudará a la elaboración de la matriz de riesgo:

Consideraciones para elaborar la matriz de riesgos

Es un tarea relevante y necesaria para el auditor en informática.

Los parámetros para medir el nivel de riesgos pueden variar de acuerdo con factores como la experiencia y conocimiento en la auditoría, así como en las áreas de informática.

Algunos hechos pueden indicar la existencia de riesgos relevantes.

Revisar la matriz de riesgos con el responsable de la auditoría general.

Asegurarse de contar con el soporte acerca de las debilidades o anomalías detectadas.

Actividad 7.1

Elabore la matriz de riegos de una empresa y determine las áreas de mayor impacto o criticidad para la misma. Justifique su respuesta.

Controles en informática

Los controles de Tecnología Informática (TI) son los procedimientos dentro del departamento de Sistemas, que aseguran que los programas y recursos operan apropiadamente y que se impidan cambios no autorizados. Incluyen controles sobre el diseño, implementación, seguridad, y uso de programas y archivos del computador. Estos controles consisten en una combinación de procedimientos manuales y programados.

Los controles de TI son similares a los controles de Aplicación, aunque debería notarse las siguientes diferencias:

- Los controles de TI son controles sobre el medio ambiente de Procesamiento de Datos (PD) en su totalidad. Los controles de Aplicación son controles sobre aplicaciones específicas; los controles de TI cubren todas las aplicaciones.

- Los controles de Aplicación están compuestos de procedimientos manuales y procedimientos programados.

- Los controles de TI regulan el medio ambiente de PD para asegurar que los procedimientos programados continúen funcionando apropiadamente.

- Si existen debilidades en los controles de TI, no hay seguridad de que los procedimientos programados continúen trabajando apropiadamente, aún cuando no hayan sido cambiados.

Un ambiente de PD controlado en forma inapropiada, puede ocasionar la interrupción de las operaciones de la organización por la vía de:

- Múltiples reejecuciones de las aplicaciones para corregir errores, causando retrasos.

- Afectar la información usada por la Administración para operar el negocio.

- Permitir la ocurrencia de fraudes, tal como la alteración no autorizada de los registros electrónicos.

- Permitir la divulgación de secretos comerciales.

Controles primarios de tecnología informática

Los controles de TI pueden ser divididos en las siguientes siete áreas:

Ladillo Siete áreas: siete controles primarios de tecnología informática.

Controles de implementación, diseñados para asegurar que los procedimientos programados son apropiados y correctamente implantados en los programas computacionales.

Controles sobre el mantenimiento, diseñados para asegurar que los cambios a los procedimientos programados son diseñados, probados, aprobados e implementados apropiadamente.

Controles sobre operación del computador, diseñados para asegurar que los procedimientos programados son aplicados consistentemente durante todo el procesamiento de la información y que se utilizan las versiones correctas de los archivos.

Controles sobre la seguridad de programas, diseñados para asegurar que cambios no autorizados no pueden ser hechos a procedimientos programados.

Controles sobre la seguridad de archivos, diseñados para asegurar que cambios no autorizados no pueden ser efectuados a archivos de datos.

Controles sobre el software de sistemas, diseñados para asegurar que el software de sistemas es implantado correctamente y protegido contra cambios no autorizados.

Controles sobre la conversión de archivos, diseñados para asegurar que los datos, son convertidos en forma total y exacta desde un sistema antiguo a uno nuevo.

Controles de implementación

Los controles de implementación ayudan a evitar los errores en aplicaciones nuevas. Incluyen controles sobre el diseño de nuevas aplicaciones computacionales, la prueba de los programas de aplicación, y los procedimientos

para traspasar los programas aprobados a producción. Estos controles se aplican tanto a sistemas desarrollados internamente como a aquellos adquiridos a proveedores externos.

El trabajo realizado por una organización, entre el momento en que completa el estudio de factibilidad para un sistema de aplicación propuesto y el momento en que ese sistema se implanta exitosamente, es muy significativo. La traducción de los requerimientos de los usuarios partiendo de ideas generales, para arribar a una serie de programas de producción detallados e instrucciones específicas, tanto para el computador como para los departamentos usuarios, puede significar una cantidad de tiempo considerable.

Los procedimientos relacionados con el desarrollo de nuevos sistemas son los siguientes:

- Administración del desarrollo del sistema.

- Diseño de sistema y preparación de programas.

- Prueba de programas y sistemas.

- Catalogación.

Administración del desarrollo del sistema

Generalmente, los requerimientos para nuevas aplicaciones son desarrollados en el Departamento de PD por los dueños de las aplicaciones. Los informes de estudio de factibilidad, diseño general del sistema, plan de pruebas y resultados, son revisados y aprobados, usualmente, por los usuarios y por las funciones de PD que se verán afectadas por la nueva aplicación (por ejemplo: los administradores de la Base de Datos y de la Red de Comunicaciones), por el grupo de soporte técnico (en relación con la compatibilidad con el Software de

Sistemas existente), y la jefatura de programación (para dar conformidad a los programas respecto de las especificaciones, y de la compatibilidad con las otras aplicaciones). A menudo, las funciones de control de calidad y/o Auditoría interna están involucradas en este proceso.

También es necesario controlar la planificación de la implementación de los nuevos sistemas a través del uso de cartas de administración de proyectos u otro método que registre el estado de avance del proyecto. Normalmente, se efectúa el control del avance del proyecto en relación con grupos de programas o módulos.

Diseño del sistema y preparación de programas

Típicamente, los requerimientos de nuevas aplicaciones son iniciados por los usuarios, basados en necesidades, cambios en la legislación o por el deseo de incrementar la eficiencia del procesamiento.

Los usuarios y personal de PD efectúan el estudio de factibilidad, incluyendo análisis de costo-beneficio, análisis técnico para determinar los efectos sobre el hardware y software existente y análisis operacional para medir el impacto de la aplicación sobre las operaciones de la organización.

Se documenta el diseño general, incluyendo los procedimientos manuales y

programados. Se definen los puntos de control y las interfases con otros sistemas

y con el software de sistemas. Los prototipos pueden ayudar a los usuarios a

refinar sus especificaciones para la nueva aplicación. La administración de cada

unidad involucrada en el flujo de datos revisa el plan para asegurar que entienden

y están de acuerdo con él antes de que continúe el desarrollo.

Se realiza la aprobación del estudio de factibilidad, el diseño general del sistema y las especificaciones detalladas. Típicamente, las especificaciones detalladas para las nuevas aplicaciones incluyen narrativas y/o flujogramas de actividades, diagramas de flujo de la recopilación de datos, procesos de ingreso y emisión de informes para conciliación y fechas esperadas de término e implementación.

Prueba de programas y sistemas

Normalmente, las políticas de PD requieren el desarrollo de planes de prueba para todas las aplicaciones nuevas. Esas políticas especifican el nivel de detalle de la documentación del plan, partes a ser involucrados en el proceso de desarrollo del plan, y las aprobaciones que deben obtenerse.

La documentación del plan incluye la descripción de las pruebas, los datos que van a ser utilizados o la metodología para generar estos datos, y los resultados esperados de las pruebas. Generalmente, el plan de pruebas es un esfuerzo conjunto entre los usuarios y la administración de PD.

La prueba de programas y sistemas se hace normalmente en tres etapas diferentes: (1) prueba de programa, (2) prueba de sistema, y (3) prueba paralela.

1. La prueba de programa consiste en verificar la lógica de programas individuales. Los métodos principales utilizados son la prueba de escritorio y datos de prueba. La prueba de escritorio consiste en analizar la lógica de un programa y confirmar que el código del programa reúne las especificaciones de dicho programa. Cuando fuera posible, la prueba de escritorio debería ser realizada por un programador diferente al que diseñó y escribió el programa. Es probable que el programador original piense que su lógica es correcta y trate de probar que lo es, antes que realmente verificar que así

sea. La prueba de escritorio se realiza normalmente en conjunción con la utilización de datos de prueba. Los datos de prueba son datos ficticios, preparados de acuerdo con las especificaciones del sistema para ser procesados por el mismo y deben ser diseñados para cubrir todas las alternativas de proceso o condiciones de error. Se deben establecer procedimientos formales para identificar y corregir cualquier error descubierto durante la prueba. Todos los resultados obtenidos con los datos de prueba deberán ser documentados y retenidos como evidencia de que dichas pruebas fueron realizadas. Los mismos datos pueden también ser utilizados para probar cambios futuros al sistema.

2. La prueba de sistema consiste en verificar que la lógica de varios programas individuales es consistente y que pueden encadenarse para formar un sistema completo que reúna los requerimientos de las especificaciones detalladas del sistema. La técnica principal utilizada es la de datos de prueba. Los resultados de la prueba deben ser cuidadosamente revisados. Los datos de prueba deben ser reprocesados y rediseñados, si fuera necesario, hasta que todos los errores de lógica sean detectados. En adición a situaciones comunes que el sistema está diseñado para manejar, las pruebas deberían también tratar el efecto de circunstancias inusuales en el sistema. Cuando fuera posible, la prueba del sistema debería ser realizada o verificada por personal diferente de aquél que fue responsable de hacer la programación detallada.

3. La prueba paralela significa operar el nuevo sistema al mismo tiempo, o en paralelo con el sistema existente. Los resultados obtenidos de este proceso dual, pueden ser verificados para identificar e investigar cualquier diferencia. Corridas en paralelo o piloto es una manera de probar la operación de un sistema completo, incluyendo todos los procedimientos de los usuarios. A diferencia de la prueba de sistema, el propósito de la prueba en paralelo o

piloto es probar la habilidad del sistema para manejar datos reales, no de prueba, y procesar grandes volúmenes de información, en vez de transacciones individuales. El nuevo sistema no debería ser aceptado en su totalidad por el departamento usuario correspondiente, ni tampoco debería ser abandonado hasta que, en la medida que sea práctico, el ciclo completo de proceso, haya sido exitosamente ejecutado en el nuevo sistema. En adición a ello, los procedimientos de recuperación la habilidad del sistema para recuperarse de una terminación anormal - deberían ser probados y documentados. Los resultados deberían ser revisados, si esto fuera posible, por personal diferente al responsable de la programación detallada.

Catalogación

La catalogación es el conjunto de procedimientos necesarios para transferir a producción aquellos programas ya probados. Los procedimientos más importantes son aquellos que aseguran que la prueba y la documentación han sido satisfactoriamente completados antes que los programas entren en producción, y que los procedimientos manuales para el sistema nuevo, o el sistema que está siendo cambiado, estén funcionando, tanto en el departamento usuario como en el departamento de PD. Esto incluye la preparación de instrucciones escritas de operación y de usuarios, revisadas y aprobadas por personal responsable de los departamentos involucrados. Debería haber un procedimiento para transferir a producción programas nuevos o cambiados, según sea el caso, incluyendo instrucciones al personal sobre los nuevos procedimientos. Cuando estos programas están en línea, la transferencia de programas aprobados que residen en bibliotecas de prueba a bibliotecas de producción u operacionales, es un procedimiento del sistema operativo.

Los procedimientos de catalogación deberán incluir puntos de control para asegurar que todos los cambios requeridos, y solamente ellos, han sido hechos a los programas.

Naturalmente, la versión ejecutable de un programa es la probada y utilizada para producción. La versión fuente también debe ser guardada, puesto que cualquier cambio autorizado posteriormente se hace sobre esta versión. Con todas estas versiones disponibles, es importante verificar que el programa fuente retenido coincide con la versión ejecutable residente en la biblioteca de producción. Existen paquetes de manejo de bibliotecas que pueden ayudar a controlar las versiones y los cambios realizados.

Otra buena práctica es recompilar programas antes de la prueba final de aceptación. Esto es esencial si se desea confiar en la comparación de versiones fuente descrita anteriormente; existen programas disponibles para verificar que un programa recompilado es idéntico a la versión ejecutable del mismo programa.

Controles sobre el mantenimiento

Los controles sobre el mantenimiento, están diseñados para asegurar que las modificaciones a los procedimientos programados están diseñadas e implementadas en forma efectiva. Cubren las mismas áreas que los controles de implementación, pero se relacionan con los cambios de programas más que con nuevas aplicaciones. Estos controles deberían asegurar que los cambios son diseñados, probados, aprobados, incorporados y actualizados apropiadamente, y que los requerimientos de cambio son manejados apropiadamente. Los procedimientos relacionados con el mantenimiento de sistemas son:

- Administración de los cambios a sistemas

- Prueba de programas

- Catalogación.

Administración de los cambios a sistemas

Los usuarios y la administración de PD siguen procedimientos específicos para requerir cambios. Por ejemplo, un individuo en cada departamento puede preparar requerimientos o reunirse con los propietarios de la aplicación y con personal de PD para discutir la necesidad de los cambios y los métodos mediante los cuales deberían ser efectuados. Un control de cambios manual o automatizado, asegura que todos los requerimientos son atendidos y que se lleva un registro del estado de avance de ellos.

Los cambios a los programas deberían ser documentados tan acabadamente como los sistemas nuevos. La documentación del sistema, de los programas, de operación y de los usuarios debería ser actualizada para reflejar todos los cambios. Una documentación inadecuada puede resultar en errores de sistema, tiempo excesivo de mantenimiento y una dependencia desmedida en personal técnico. Para asegurar que la documentación ha sido actualizada satisfactoriamente, esta es revisada y aprobada por la función de control de calidad o por los usuarios responsables de la aplicación y por la administración de PD.

Prueba de programas

Una organización bien controlada, tiene políticas que requieren el desarrollo de un plan de pruebas para cada programa sometido a cambios, y que especifica el nivel de detalle, la aprobación necesaria del plan, y quienes deberían efectuar dichas pruebas. La documentación del plan de pruebas debería incluir las pruebas a ser

ejecutadas, los resultados esperados, y cómo desarrollar los datos de prueba. Normalmente, el plan de pruebas es revisado y aprobado por los usuarios y por la administración de PD.

Dependiendo de la complejidad de los cambios y su impacto sobre el sistema de aplicación, el usuario en conjunto con la administración de PD deberían determinar la técnica de prueba apropiada: de programa, de sistema y/o paralela.

Observación La mayoría de los cambios requieren de la prueba de programas y la prueba de sistemas. Generalmente, la transferencia de programas probados es la misma para la implementación de sistemas nuevos como para las subsecuentes mantenciones.

Controles sobre la operación del computador

Los controles sobre la operación del computador están diseñados para asegurar que los sistemas continúen funcionando consistentemente, de acuerdo con lo planeado. Incluyen controles sobre el uso de los datos apropiados, programas y otros recursos, y la ejecución apropiada de esta función por parte de los operadores, particularmente cuando ocurre un problema.

Usualmente, el departamento de operaciones del computador controla el funcionamiento del hardware y software en el día-a-día. En muchas organizaciones, esto es asistido por un departamento de control de la producción. Operaciones del computador es responsable por la ejecución física de las aplicaciones (montar cintas, imprimir los informes y tomar decisiones acerca del hardware, tales como discontinuar el uso de un dispositivo cuando presenta una

falla). Control de producción es responsable por la preparación de trabajos y la planificación de la carga. Los controles sobre la operación del computador están descritos a continuación.

Planificación

La planificación vincula los trabajos a ser ejecutados con los archivos de datos a ser utilizados. En muchas instalaciones, se utiliza software de planificación para implementar los procesos sobre una base predeterminada (por ejemplo: todos los días a las tres de la tarde, o los días 15 y último de cada mes). Otras instalaciones usan un esquema de planificación manual. En cualquiera de estos casos, la planificación de los procesos es aprobada por los usuarios y por la jefatura de operaciones, cuando se implementa un sistema.

Normalmente, control de la producción o la jefatura de operaciones requiere de aprobaciones escritas de los usuarios para ejecutar trabajos en una secuencia distinta a la planificada. Los usuarios deben entregar requerimientos escritos para la planificación de trabajos que no están considerados en la planificación normal, tales como actualizaciones periódicas a ciertos archivos, o procedimientos de fin de año.

La administración de PD utiliza bitácoras (manuales o automáticas) para monitorear la adherencia de los operadores a la planificación aprobada. Esas bitácoras informan los trabajos ejecutados, los tiempos de inicio y fin del trabajo y cualquier condición anormal ocurrida durante la ejecución del trabajo. Cuando ocurre una condición anormal, el operador prepara un formulario de descripción de problemas para la posterior investigación y la autorización de la reejecución.

Si las aplicaciones en operación son en línea, la planificación sólo es relevante para aquellos procesos de tipo batch, tales como los procesos de fin de día, de respaldo y de inicio de actividades del día. Las consideraciones de control se asocian a si los trabajos se ejecutan en el punto, tiempo y secuencia apropiada.

Preparación de trabajos

Preparación de trabajos es el nombre normalmente dado a la preparación de una aplicación para su proceso. Se deben definir y cargar los programas y archivos de datos del sistema, se debe especificar la secuencia de eventos, y los dispositivos deben ser asignados.

Observación La preparación de trabajos es importante para los controles sobre operación del computador, debido a que ayuda a asegurar que el lenguaje de control de trabajos y sus parámetros están apropiadamente preparados y que los archivos correctos sean utilizados.

La manera más común de asegurar que el lenguaje de control de trabajos y los parámetros que están siendo utilizados son los apropiados, es mantener instrucciones escritas previamente aprobadas. Existe también la necesidad de verificar que los comandos y los parámetros utilizados se corresponden con dichas instrucciones. Esto debería ser revisado y aprobado por personal responsable. Las instrucciones de preparación de trabajos deberían cubrir todas las aplicaciones y el sistema operativo. Ellos deberían incluir, donde fuera apropiado, el flujo del proceso, información relacionada con la preparación de equipos

periféricos y archivos, lenguaje de control de trabajos (JCL) y parámetros de ejecución.

En muchos casos, los controles de actualización y mantenimiento, descritos como controles de aplicación, aseguran que los archivos correctos están siendo utilizados. Sin embargo, aún son necesarios controles específicos sobre la utilización de los archivos correctos. Esto es particularmente verdadero, para aquellos archivos que contienen tablas que son utilizadas durante un proceso (por ejemplo, la lista de números cuando se utilizan chequeos de secuencia).

Puede haber controles manuales sobre los archivos de datos, desde el momento en que son retirados de la biblioteca física hasta la preparación del trabajo. El sistema operativo puede también asegurar que los archivos correctos están siendo utilizados. Cuando el sistema operativo, está utilizado como una técnica de control, cada archivo asignado a un dispositivo incluye un registro, cabecera conteniendo información tal como el nombre del archivo y el número de la versión del mismo. Cuando el archivo es preparado para el proceso, los detalles de dicho registro son verificados. Cualquier intervención por parte del operador sobre estos controles debería ser revisada y aprobada.

Uso correcto de los archivos de datos

En muchos casos, los controles sobre la actualización y sobre el mantenimiento, descritos como controles de aplicación, aseguran que se utilizan los archivos de datos correctos. Sin embargo, aún son necesarios controles específicos sobre el uso de datos correctos. Esto es particularmente cierto en archivos que contienen tablas que son requeridas en el procesamiento (por ejemplo: la lista de números cuando se utiliza chequeo de la secuencia numérica).

Típicamente, los controles sobre los archivos de datos requieren que éstos tengan un rótulo (label) interno único, que es leído por el software de sistemas y chequeado por el computador contra la información contenida en un sistema de control de cintas. Los correspondientes rótulos externos son puestos a los dispositivos de almacenamiento removibles, para que sean leídos por los cintotecarios y operadores en el momento de asignar dichos archivos al procesamiento.

Monitoreo de actividades

El funcionamiento del computador y sus operaciones está, normalmente, controlado por procedimientos manuales y programados. Las funciones manuales están, generalmente, restringidas a las acciones requeridas o solicitadas por dichos programas especiales. La consideración principal de control en este caso es que el sistema operativo utilizado es confiable y que los procedimientos manuales no lo son, puesto que por error o por otras razones, se puede interferir o afectar el proceso normal del computador.

Procedimientos de recuperación y respaldo

Deberían existir procedimientos de respaldo. En el evento de una falla del computador, el proceso de recuperación de programas de producción, sistema operativo o archivos, no debería introducir ningún cambio erróneo dentro del sistema. Algunas de las principales técnicas que pueden ser utilizadas son:

Esto es

aplicable a los programas cancelados antes de su término normal y evita la

La facilidad para recomenzar en un estado intermedio del proceso.

necesidad de reprocesar todo el trabajo.

Un sistema para copiar y almacenar independientemente archivos maestros y las transacciones respectivas. Esto hace posible recuperar cualquier archivo perdido o dañado durante la interrupción del trabajo.

Procedimientos similares al anterior, para asegurar que las copias de las instrucciones de operación, ejecución, y otros documentos claves están disponibles en caso que los originales se pierdan.

Instrucciones formales escritas para la recuperación del proceso o su transferencia a otra instalación.

Controles sobre la seguridad de los programas

Los controles sobre seguridad de programas están diseñados para asegurar que cambios no autorizados no pueden ser hechos a programas de producción. Dichos controles aseguran que los únicos cambios son aquellos hechos a través de los procedimientos normales de cambios de programas. La seguridad de programas es preocupación especial para el auditor cuando un cambio no autorizado en un programa particular podría beneficiar a la persona que realiza el cambio (por ejemplo, un cambio hecho en un sistema que procesa salarios y pagos en efectivo podría resultar en que se realicen pagos no autorizados). A continuación se detallan los procedimientos relacionados con la seguridad sobre los programas.

Software de control de acceso

Una organización puede usar software de sistemas (por ejemplo: opciones del sistema operativo, paquetes de seguridad, paquetes de administración de bibliotecas de programas, software de comunicaciones) para restringir el acceso a

las bibliotecas de programas o a programas específicos en bibliotecas de producción. Generalmente, las técnicas de control usadas incluyen:

- Códigos de identificación de usuarios y passwords.

- Opciones de menú restringidos.

- Niveles de acceso restringido a los usuarios (acceso sólo de lectura).

- Capacidades de los medios de input/output restringidas.

En los sistemas computacionales de hoy en día, los programas pueden ser accedidos y alterados en una gran variedad de formas. La mayoría de las organizaciones usan software de control de acceso para restringir, tanto el acceso a procesos en línea, como a los procesos en batch. El acceso no sólo es restringido a programas específicos o bibliotecas, sino también a:

- Bibliotecas de procedimientos.

- Archivos del software de control de acceso.

- Bibliotecas del software de sistemas.

- Archivos de bitácoras.

Una seguridad de acceso completa, requiere que todos los usuarios estén registrados por el sistema y que sean monitoreados por la función de administración de la seguridad, de modo independiente. Los problemas (por ejemplo: desactivación de usuarios o denegar el acceso) son identificados y se efectúa un seguimiento oportuno. Las acciones privilegiadas (por ejemplo:

definición de nuevos usuarios, cambios a los privilegios de los usuarios, cambios en la definición de los recursos y a las reglas de acceso y sobrepasar la seguridad) también son registradas e investigadas en forma oportuna por el administrador de la seguridad. Son preferibles las revisiones diarias o semanales de los registros, pero las revisiones mensuales pueden ser adecuadas para un

volumen bajo de actividades. seguridad son:

Típicamente, las funciones del administrador de la

Mantener controles apropiados sobre el diseño y mantenimiento de las identificaciones de los usuarios (user ID) y sus passwords, y asegurar que las user ID's y passwords no pueden ser obtenidas por personal no autorizado.

Mantener y definir las reglas de acceso de los usuarios autorizados.

Controlar, distribuir y corregir las tablas de password.

Revocar inmediatamente las user ID's y passwords de los usuarios que dejan de pertenecer a la organización o que han sido trasladados.

Todos los controles de acceso necesitan usuarios con privilegios especiales para la administración y otras tareas importantes, tales como:

Establecer y cambiar las user ID's.

Resetear los passwords u otros códigos secretos.

Sobrepasar los controles de acceso (atributos de acceso irrestricto).

Cambiar el estado del sistema de seguridad y las opciones del software de control de acceso.

Controles sobre el acceso físico

El control físico, junto con el software de control de acceso, proveen control extenso sobre los programas. Los procedimientos de control de interés incluyen:

Restricción de acceso físico a los terminales o el acceso privilegiado a terminales y usuarios específicos. Por ejemplo, en una bodega, restringiendo el acceso al terminal para registrar el stock físico y reforzar la limitación de tiempo para el uso de la terminal.

Restricción de acceso a la sala del computador (vía tarjetas magnéticas o claves de números en la puerta).

Restricción al acceso de los listados de los programas.

Control y restricción al acceso de los respaldos de los programas y su documentación.

Segregación de funciones

Con la suficiente capacidad técnica y el conocimiento detallado de su contenido, los usuarios podrían sobrepasar la seguridad y hacer cambios a programas en producción. La protección contra esta posibilidad, normalmente se incrementó con una apropiada segregación de funciones. Cuando las funciones son separadas, los usuarios no pueden obtener un conocimiento detallado de los programas; por otro lado, aquellos responsables del desarrollo y mantenimiento de los programas, no pueden tener acceso irrestricto a los programas de producción. Es importante mantener esta segregación de funciones en todo momento, aún fuera de las horas normales de trabajo.

Controles sobre la seguridad de archivos de datos

Los controles sobre la seguridad de archivos aseguran que no se pueden efectuar cambios no autorizados sobre los archivos de datos. La necesidad de controles de seguridad sobre archivos de datos es normalmente mayor para archivos maestros que para archivos de transacciones. Esto es así, porque no todos los campos de datos críticos de los archivos maestros están sujetos a los procedimientos regulares de verificación y reconciliación. Cualquier verificación cíclica de archivos de datos podría no ser hecha lo suficientemente a menudo para proveer la oportuna identificación de cambios no autorizados.

Los controles sobre archivos de datos son también importantes desde un punto de vista operativo. Consideraciones operativas incluyen proteger los datos de ser borrados o destruidos, ya sea accidental o intencionalmente, y contra robos y uso no autorizado.

Software de controles de acceso

Una amenaza particular para los datos es el acceso irrestricto, que permite que los datos sean cambiados sin autorización previa. En sistemas en lote, donde los archivos de datos han sido cargados para la ejecución de un programa específico, el problema está limitado a controlar la acción de los operadores durante esa ejecución en particular. Los sistemas en línea y tiempo real requieren: una combinación de técnicas de control, incluyendo la restricción a los caminos de acceso del sistema y al rango de actividades permitidas a los usuarios. Los sistemas de conexión telefónica requieren altos niveles de seguridad debido a los peligros de acceso por personal no autorizado. El nivel apropiado de los controles de acceso está determinado por la sensibilidad de los datos, la división de funciones de los usuarios, y los recursos disponibles.

Acceso por los usuarios

Los procedimientos de control diseñados para proteger archivos de datos contra accesos no autorizados por parte de usuarios del sistema, son similares a aquellos ya descritos para programas. Estos procedimientos, que normalmente pueden ser llevados a cabo al mismo tiempo que aquellos para los programas, incluyen funciones del Sistema operativo tales como paquetes de control de bibliotecas, programas de seguridad delsistema operativo, palabras claves, programas de comunicaciones y sistemas de manejo de base de datos.

Acceso a datos en línea

En situaciones donde los datos son capturados a través de un terminal, como es el caso de sistemas en línea y tiempo real, es esencial proteger contra la captura de información no autorizada, que se utilizará posteriormente en el proceso de actualización. La captura de datos inválidos puede ser hecha para archivos de transacciones o archivos maestros. Normalmente transacciones con datos inválidos son introducidas al sistema para alterar el efecto de una transacción que ya se encuentra en el archivo. Por ejemplo, una nota de crédito ficticia que está apareada a una factura dentro del archivo, alteraría el estado de dicha factura. Datos inválidos dentro de un archivo maestro pueden consistir de un registro completo, tal como la cuenta de un proveedor ficticio, o un campo de datos, tal como la tasa de pago o la tasa de interés.

Cuando los archivos de datos están en línea, debería haber una combinación apropiada de opciones del sistema operativo, que permita restringir terminales a ciertos programas, transacciones, o archivos. Solamente personal autorizado debería tener acceso a archivos, ya sea para obtener información o introducir cambios.

Acceso por los programas en producción

En adición a los controles de acceso de usuarios y de terminales, deberían establecerse procedimientos para restringir el acceso a los datos por diversos programas. El acceso a los datos puede ser restringido por medio de paquetes de seguridad, a través de los cuales se puede definir qué datos pueden ser procesados y con qué opciones, ya sea de lectura o actualización. Es posible producir informes, generados por dichos paquetes, de todos los accesos permitidos a los diferentes programas. Dichos informes deberían ser revisados e investigados si fuera necesario.

Archivos fuera de línea

Los archivos residentes fuera de línea están protegidos contra cambios mientras no estén cargados en el computador, pero pueden ser removidos, posiblemente con propósitos no autorizados. Esto puede ocurrir cuando los archivos no están físicamente protegidos y/o su manejo no está apropiadamente controlado. Las características de control deberían proteger contra el traslado no autorizado o destrucción de archivos, incluyendo aquellos almacenados en sitios remotos para utilización en caso de desastre.

Seguridad física

Para proteger archivos fuera de línea contra accesos no autorizados, debería existir un área de almacenamiento bajo llave. Debería estar alejada de donde reside el computador y, preferiblemente, supervisado por un bibliotecario responsable de la entrega, recepción y seguridad de todos los archivos. Los accesos de dicha biblioteca deberían ser restringidos solamente a personal autorizado para retirar o devolver archivos.

Es necesario que existan procedimientos para asegurar que los archivos sean utilizados solamente para procesos autorizados. Esto significa que se deberían preparar calendarios de proceso que especifiquen en detalle los archivos que son requeridos para el proceso. Dichos calendarios deberían prepararse para todas las aplicaciones y ser aprobados por personal responsable. Debería requerirse autorización específica para remover archivos a sitios remotos o a otro computador.

Controles sobre el software de sistemas

Los controles sobre el software de sistemas asegura que el software de sistemas es implementado, mantenido y protegido de cambios no autorizados en forma apropiada. Los programas del sistema operativo son importantes para el auditor puesto que ayudan a controlar, tanto los programas que procesan información, como los archivos de datos. Muchos de los controles de TI, tales como la seguridad de archivos de datos y programas, dependen del software de sistemas.

El software de sistemas que puede ser relevante para controlar incluye programas relacionados con:

Catalogación

Informe de trabajos procesados

Manejo de archivos

Comunicaciones de datos

Informe de operaciones

Preparación de archivos

Seguridad de acceso

Registro de bibliotecas

Base de datos

A continuación se detallan los controles sobre el software de sistemas.

Implementación

Los controles requeridos para la implantación exitosa del software de sistemas son, esencialmente, similares a aquellos requeridos para la implantación de programas de aplicación, excepto que este trabajo es efectuado por personal de soporte técnico y por los programadores de aplicación.

Todo software de sistemas provisto por un proveedor debería estar sujeto a la revisión y aprobación por una persona con el conocimiento suficiente para determinar el impacto de dichos programas en los sistemas existentes y los procedimientos en operación. Dicha persona debería ser capaz de determinar si dichos programas satisfacen las necesidades y objetivos de la compañía. Esta revisión debería abarcar, tanto el sistema operativo básico, como las diferentes opciones disponibles.

Cuando el nuevo software de sistemas tiene una interfase directa con programas de aplicación es imperativo que los nuevos programas sean probados con programas de aplicación ya estables. Así, si ocurren anomalías, ellas pueden ser identificadas como resultantes del nuevo software de sistemas.

Las instrucciones y otra documentación del software de sistemas y las distintas opciones provistas deberían ser revisadas por personal técnicamente competente. Dicho personal debería asegurarse que la documentación describe apropiadamente los procedimientos necesarios para utilizar y operar correctamente el software de sistemas.

El uso de programas del software de sistemas debería ser restringido a usuarios autorizados. Por ejemplo, el grupo de soporte técnico puede necesitar algunos

programas de servicio que no deberían estar disponibles a operadores o a usuarios.

Mantenimiento

El software de sistemas es modificado periódicamente por el vendedor quien introduce nuevos programas o mejoras a los programas existentes. Estas mejoras o nuevos programas deben ser probados para asegurar que éste opera de acuerdo con el ambiente de la organización.

En muchas organizaciones, no hay experiencia técnica ni herramientas para efectuar correcciones al software de sistemas. En esas circunstancias, el riesgo de modificaciones no autorizadas es mínimo. En el caso de que exista experiencia técnica y herramientas, la organización debería establecer controles similares a aquellos sobre los programas de aplicación. Normalmente, las organizaciones aplican segregación de funciones, para prevenir que personal de soporte técnico obtenga un entendimiento detallado de las aplicaciones procesadas y de los controles sobre los archivos claves y sobre las transacciones de aquellas aplicaciones. Finalmente, el trabajo del personal de soporte técnico debería ser supervisado en forma muy cercana por la jefatura de soporte técnico.

Controles sobre la conversión de archivos

Los controles sobre la conversión de archivos apuntan a la conversión de los archivos existentes a los nuevos archivos de datos de una aplicación nueva. Ellos están diseñados para asegurar que el proceso de conversión no causó errores en los archivos de datos.

Instrumentos de control

Los elementos e instrumentos de control a utilizar en forma individual o en forma conjunta son:

- Documentación de las etapas del desarrollo e Implantación de sistemas.

- Reuniones de revisión técnica.

- Benchmarking o pruebas del sistema.

- Formularios de control.

La

sistema

documentación de las subetapas del desarrollo e implantación del

La primera información que debe servir de base para efectuar un análisis sobre el control del sistema lo constituye la documentación generada en las diferentes fases de desarrollo e implantación del sistema.

La documentación debe leerse detenidamente con la finalidad de:

Comprender la concepción del sistema.

Planificar el contenido de las reuniones de revisión técnica.

Determinar los vacíos o carencias de información.

Elaborar los cuestionarios de consultas.

Efectuar el control del Sistema, con un conocimiento sólido del mismo.

Observación El técnico que efectúe el control del sistema debe tomar conocimiento completo de la documentación escrita existente, de tal forma que se reduzca el tiempo del proceso de Auditoría del sistema y se brinden resultados en corto plazo.

Reuniones de revisión técnica

Un aspecto fundamental para efectuar un buen control del sistema son las Entrevistas de Revisión Técnica, ya que la documentación, en la mayoría de los casos, es muy escasa y deficiente y, generalmente, cubre sólo una parte de la información y las entrevistas permiten complementar la información técnica y recabar opiniones sobre deficiencias del sistema.

Las reuniones de Revisión Técnica, deben estar debidamente planificadas y contar con formularios de los temas y consultas a tratar, para evitar olvidar cualquier aspecto fundamental para el análisis y la investigación. Las reuniones de Revisión Técnica deben efectuarse con todas las personas que participaron en el desarrollo e implantación del sistema, así como los que operan y utilizan el sistema.

Deben efectuarse reuniones de Revisión Técnica con cada participante en forma separada para lograr información y opiniones libres e independientes de cada uno de ellos; después de las reuniones individuales puede efectuarse una reunión global para determinar las conclusiones de consenso.

Ladillo En las entrevistas de revisión técnica deben consultarse los factores que limitaron el desarrollo, implantación, operación y uso del sistema, así como las deficiencias, aspectos de confiabilidad y seguridad, en función de cada persona.

Las Entrevistas de Revisión Técnica deben efectuarse con la o las siguientes personas que llevaron o llevan a cabo las siguientes funciones: el Analista de

Sistemas, el Programador, el Implementador, los Operadores del Sistema, los Usuarios Operativos que utilizan el Sistema, los Usuarios que utilizan la información para la toma de decisiones.

Benchmark o pruebas del sistema

Instrumento vital para evaluar la confiabilidad del Sistema, es lo que se denomina Benchmark o Pruebas del Sistema. No basta con evaluar el sistema tomando conocimiento de su documentación y sosteniendo reuniones de revisión técnica con el personal involucrado; lo fundamental, que demuestra la buena funcionalidad y confiabilidad del sistema es efectuar procesos de prueba simulando situaciones extremas de tal forma que se pueda determinar si el sistema responde a lo especificado y es confiable produciendo resultados correctos en los tiempos esperados.

Es por eso que se debe realizar Benchmark o procesos de prueba especiales tales como: prueba de carga máxima, prueba de almacenamiento, prueba de tiempo de ejecución, prueba de recuperación.

Formularios de control

Para efectos de registrar y controlar preventivamente el desarrollo e implantación del Sistema o evaluarlo posteriormente, es necesario utilizar formularios denominados de control, cuya explicación se indica a continuación.

Control de cronograma del proyecto

Para efectos de controlar o evaluar el cumplimiento de los plazos y la duración de las etapas del sistema y por razones de sencillez se recomienda utilizar el

diagrama de GANTT, debiendo en el mismo cuadro registrar lo planeado y lo ejecutado con dos símbolos diferentes. Se recomienda que se utilicen herramientas computarizadas de formulación y control de proyectos que permiten utilizar el PERT-PCM.

Control de documentación de sistemas

Este formulario permite verificar la aplicación de la metodología de desarrollo e implantación de sistemas, mediante el registro de la documentación que se debe haber generado para cada etapa. Deber contarse con la firma de conformidad del usuario de la documentación que éste deba aprobar.

Control técnico del análisis

Para verificar que el control del análisis se haya efectuado adecuadamente, se debe utilizar el Formulario de Registro de Técnicas Utilizadas y se deben realizar estudios de gabinete de la documentación generada, así como efectuar reuniones de revisión técnica, conjuntamente con el personal de analistas del proyecto. En caso de verificarse la falta de aplicación de las técnicas o errores en el trabajo de análisis, éstas se registrarán en un acta, para que sean superadas.

Es mejor efectuar el control, en forma permanente, apenas se finaliza una etapa y antes de proceder a la próxima, pues hacerlo en forma posterior, es más costoso y requiere de mayor tiempo, teniendo mayores implicaciones.

Las técnicas que se deben haber utilizado son:

- Entrevistas.

- Diagrama de Flujo de Datos (D.F.D).

- Modelación de Datos.

- Diagrama de Estructura de Datos (D.E.D).

- Historia de Vida de la Entidad (H.E.V).

- Análisis de Costo/Beneficio (A.C.B).

- Prototipeo.

Control técnico del diseño

Para verificar que el Control Técnico del Diseño se ha efectuado adecuadamente, se debe utilizar el Formulario de Registro de Técnicas Diseño y se deben realizar estudios de gabinete de la documentación generada, así como efectuar reuniones de revisión técnica, conjuntamente con el personal de analistas del proyecto. Como en el control anterior, en caso de verificarse la falta de aplicación de las técnicas o errores en el trabajo de diseño, éstas se registrarán en un acta, para que sean superadas. También es mejor efectuar el control en forma permanente, apenas se finaliza una etapa y antes de proceder a la próxima.

Las técnicas que se deben haber utilizado son:

- Diseño Estructurado.

- Diagrama de Estructura de Cuadros.

- Optimización del Diseño Físico.

- Diseño de Pruebas.

- Prototipeo.

Actividad 7.2

Elabore un cuadro en el cual, para cada riesgo o amenaza exista el control respectivo y el nivel de cobertura del control.

Evaluación de controles

Definición de la metodología CRMR:

La traducción más adecuada para CRMR, es evaluación de la gestión de recursos informáticos. En cualquier caso, esta terminología quiere destacar la posibilidad de realizar una evaluación de eficiencia de utilización de los recursos por medio del management. Una revisión de esta naturaleza no tiene en sí misma el grado de profundidad de una Auditoría informática global, pero proporciona soluciones más rápidas a problemas concretos y notorios.

Ladillo CRMR: sigla de computer resource management review.

Supuestos de aplicación

En función de la definición dada, la metodología abreviada CRMR es aplicable más a deficiencias organizativas y gerenciales que a problemas de tipo técnico, pero no cubre cualquier área de un Centro de Procesos de Datos.

El método CRMR puede aplicarse cuando se producen algunas de las situaciones que se citan:

Se detecta una mala respuesta a las peticiones y necesidades de los usuarios.

Los resultados del Centro de Procesos de Datos no están a disposición de los usuarios en el momento oportuno.

Se genera con alguna frecuencia información errónea por fallos de datos o proceso.

Existen sobrecargas frecuentes de capacidad de proceso.

Existen costes excesivos de proceso en el Centro de Proceso de Datos.

Efectivamente, son éstas y no otras las situaciones que el auditor informático encuentra con mayor frecuencia. Aunque pueden existir factores técnicos que causen las debilidades descritas, hay que convenir en la mayor incidencia de fallos de gestión.

Áreas de aplicación

Las áreas en las cuales puede ser aplicado el método CRMR se corresponden con las sujetas a las condiciones de aplicación señaladas en punto anterior:

Gestión de datos.

Control de operaciones.

Control y utilización de recursos materiales y humanos.

Interfaces y relaciones con usuarios.

Planificación.

Organización y administración.

Ciertamente, el CRMR no es adecuado para evaluar la procedencia de adquisición de nuevos equipos (Capacity Planning) o para revisar muy a fondo los caminos críticos o las holguras de un Proyecto complejo.

Objetivos

CRMR tiene como objetivo fundamental evaluar el grado de bondad o ineficiencia de los procedimientos y métodos de gestión que se observan en un Centro de

Proceso de Datos. Las recomendaciones que se emitan como resultado de la aplicación del CRMR, tendrán como finalidad algunas de las que se relacionan:

Identificar y fijas responsabilidades.

Mejorar la flexibilidad de realización de actividades.

Aumentar la productividad.

Disminuir costos.

Mejorar los métodos y procedimientos de Dirección.

Alcance

Se fijarán los límites que abarcará el CRMR, antes de comenzar el trabajo. Se establecen tres clases:

Reducido. El resultado consiste en señalar las áreas de actuación con potencialidad inmediata de obtención de beneficios.

Medio. En este caso, el CRMR ya establece conclusiones y recomendaciones, tal y como se hace en la Auditoría informática ordinaria.

Amplio. El CRMR incluye planes de acción, aportando técnicas de implementación de las recomendaciones, a la par que desarrolla las conclusiones.

Información necesaria para la evaluación del CRMR

Se determinan, en este punto, los requisitos necesarios para que esta simbiosis de Auditoría y consultoría pueda llevarse a cabo con éxito.

El trabajo de campo del CRMR ha de realizarse completamente integrado en la estructura del Centro de Proceso de Datos del cliente, y con los recursos de éste. No debe olvidarse que se están evaluando actividades desde el punto

de vista gerencial. El contacto permanente del auditor con el trabajo ordinario del Centro de Proceso de Datos permite a aquél determinar el tipo de esquema organizativo que se sigue.

Se deberá cumplir un detallado programa de trabajo por tareas. Todo trabajo habrá de ser descompuesto en tareas. Cada una de ellas se someterá a los siguientes temas:

- Identificación de la tarea.

- Descripción de la tarea.

- Descripción de la función de dirección cuando la tarea se realiza incorrectamente.

- Descripción de ventajas, sugerencias y beneficios que puede originar un cambio o modificación de tarea.

- Test para la evaluación de la práctica directiva en relación con la tarea.

- Posibilidades de agrupación de tareas.

- Ajustes en función de las peculiaridades de un departamento concreto.

- Registro de resultados, conclusiones y recomendaciones.

El auditor-consultor recabará determinada información necesaria del cliente. El cliente es el que facilita la información que el auditor contrastará con su trabajo de campo.

Se exhibe a continuación una Checklist completa de los datos necesarios para confeccionar el CRMR:

Datos de mantenimiento preventivo de hardware.

Informes de anomalías de los sistemas.

Procedimientos estándar de actualización.

Procedimientos de emergencia.

Monitorización de los sistemas.

Informes del rendimiento de los sistemas.

Mantenimiento de las librerías de programas.

Gestión de espacio en disco.

Documentación de entrega de aplicaciones a explotación.

Documentación de alta de cadenas en explotación.

Utilización de CPU, canales y discos.

Datos de paginación de los sistemas.

Volumen total y libre de almacenamiento.

Ocupación media de disco.

Manuales de procedimientos de explotación.

Observación Esta información cubre ampliamente el espectro del CRMR y permite ejercer el seguimiento de las recomendaciones realizadas.

Actividad 7.3

Elabore una guía de trabajo para evaluar los controles aplicando la metodología CRMR en el área de informática de una empresa.

Resumen

El proceso de evaluación de controles implica un análisis detenido y cuidadoso de todas las actividades que se desarrollan en el área de Informática o alrededor del uso de la tecnología informática. La metodología de CRMR o Evaluación de la gestión de recursos informáticos responde a la necesidad de evaluar toda la

gestión de los recursos y tecnología informática utilizada en una organización, de una manera estructurada y sistemática, en las áreas de Gestión de Datos, Control de Operaciones, Control y utilización de recursos materiales y humanos, Interfaces y relaciones con usuarios, Planificación, Organización y administración. El CRMR permite evaluar el grado de trabajo o ineficiencia de los procedimientos y métodos de gestión que se observan en un Centro de cómputo o proceso de Datos.

Bibliografía recomendada

Hernández

CECSA, 2000.

Hernández, Enrique.

Auditoría en Informática. México: Editorial

Piettini, G., Emilio del Peso. Auditoría Informática, un enfoque práctico. México:

Editorial Alfaomega, segunda edición, 2001.

Nexo

En el próximo fascículo estudairemos un caso Práctico de Auditoría de Seguridad Informática,Ciclo de Seguridad, para proporcionar una visión más desarrollada y amplia de la función auditora.

Autoevaluación formativa

1. ¿Qué significa análisis de riesgos para una empresa?

2. ¿Cuáles son los componentes de una matriz de análisis de riesgos?

3. Defina 10 controles de informática y determine la importancia de cada uno de estos para la empresa.

4. ¿Por qué los controles deben evaluarse frente al beneficio que se recibe en la Empresa?

5. ¿Para qué se utiliza la metodología de CRMR en Auditoría?

6. Describa las áreas de aplicación de la metodología.

7. ¿Cuáles son los datos necesarios para el trabajo de CRMR?