AUDITORIA EN SISTEMAS

Ing. Jorge H. Cassi

CONTENIDO

MODULO 1: Conceptos Bsicos sobre Auditora Informtica

1. Concepto sobre Auditora, Consultora y Control Interno 2. Auditora: tipo y clases 3. Etapas del Proceso de Auditora: Etapa de Planeamiento (estratgico y detallado), Etapa de Ejecucin y Etapa de Conclusin. 4. Riesgo de Auditora: Riesgo Inherente, Riesgo de Control y Riesgo de Deteccin. 5. Informe de Auditora: Objetivos de los Papeles de Trabajo, Preparacin, Contenido y Estructura General.

MODULO 2: Auditora de Componentes Informticos

1. Marco Jurdico de la Auditora Informtica 2. Auditora de Proyectos Etapa de Anlisis Etapa de Diseo Etapa de Construccin Etapa de Implantacin Etapa de Mantenimiento 3. Auditora de Aplicaciones 4. Auditora de Base de Datos 5. Auditora de Redes 6. Auditora de la Seguridad

Bibliografa: 1. Piattini - Del Peso, AUDITORA INFORMATICA, Ediciones RA-MA, Ao 1998. 2. Slosse, C. A. ,AUDITORIA: UN NUEVO ENFOQUE EMPRESARIAL, Ediciones Macchi, Ao 1993.

AUDITORIA. CONCEPTO Conceptualmente la auditora es la actividad consistente en la emisin de una opinin profesional sobre si el objeto sometido a anlisis presenta adecuadamente la realidad que pretende reflejar y/o cumple las condiciones que le han sido prescritas. Podemos descomponer este concepto en los elementos fundamentales que a continuacin se especifican: 1) Contenido: una opinin 2) Condicin: profesional 3) Justificacin: sustentada en determinados procedimientos 4) Objeto: una determinada informacin obtenida en un cierto soporte 5) Finalidad: determinar si presenta adecuadamente la realidad o sta responde a las expectativas que le son atribuidas. En todo caso es una funcin que se acomete a posteriori, en relacin con actividades ya realizadas, sobre las que hay que emitir una opinin.

CLASES DE AUDITORA Los elementos 4 y 5 distinguen de qu clase o tipo de auditora se trata. El objeto sometido a estudio, sea cual sea su soporte, por una parte, y la finalidad con que se realiza el estudio, definen el tipo de auditora de que se trata, por ejemplo: Auditoras operativas (operacional) Auditoras informticas Auditoras de economa y eficiencia Auditora de efectividad Etc.

TIPOS DE AUDITORIA Auditora interna: Pertenece a la organizacin y es un rgano independiente de otros sectores que tiene como objeto la revisin de desempeo. La auditora interna es un mecanismo de control selectivo e separados de los engranajes de control interno habituales que hacen a la operatoria de la empresa. Auditora externa: No pertenece a la organizacin. Su objetivo es brindar a travs de especialistas un servicio que implique el examen de informacin, operaciones, procedimientos, actividades, proyecciones, etc. que necesiten de un juicio profesional.

CONSULTORA. CONCEPTO La consultora consiste en dar asesoramiento o consejo sobre lo que se ha de hacer o cmo llevar adecuadamente una determinada actividad para obtener los fines deseados. Los elementos de la consultora podran resumirse en: 1) Contenido: dar asesoramiento o consejo 2) Condicin: de carcter especializado 3) Justificacin: en base a un examen o anlisis 4) Objeto: la actividad o cuestin sometida a consideracin 5) Finalidad: establecer la manera de llevarla a cabo adecuadamente Es una funcin a priori con el fin de determinar cmo llevar a cabo una funcin o actividad de forma que obtenga los resultados pretendidos. La auditoria verifica a posteriori si estas condiciones, una vez realizada esta funcin o actividad, se cumplen y los resultados pretendidos se obtienen realmente.

CLASES DE CONSULTORA A ttulo ilustrativo podramos enunciar los siguientes: Financiera, asesoramiento Procedimientos administrativos Informtica, asesoramiento Diseo e implantacin Aplicaciones Desarrollo Planes de Contingencia Etc. Especialmente el elemento definido como "contenido" (1) distingue claramente la auditora de la consultora. Dependiendo de que su contenido sea opinar sobre unos resultados vs. dar asesoramiento o consejo en relacin con una actividad a desarrollar, se tratar de auditora o consultora. Esta distincin nos resultar importante cuando queramos delimitar las funciones. Se observa sin embargo que las definiciones de la auditora tienden a englobar el concepto de consultora.

CONTROL INTERNO Y AUDITORA INFORMATICOS Se puede definir el control interno como cualquier actividad o accin realizada manual y/o automticamente para prevenir, corregir errores o irregularidades que puedan afectar al funcionamiento de un sistema para conseguir sus objetivos. Los controles cuando se diseen, desarrollen e implanten han de ser al menos completos, simples, fiables, revisables, adecuados y rentables. Respecto a esto ultimo habr que analizar el coste-riesgo de su implantacin.

Control Interno Informtico Controla diariamente que todas las actividades de sistemas de informacin sean realizadas cumpliendo los procedimientos, estndares y normas fijados por la Direccin de la Organizacin y/o la Direccin de Informtica, as como los requerimientos legales. La misin del Control Interno Informtico es asegurarse de que las medidas que se obtienen de los mecanismos implantados por cada responsable sean correctas y vlidas. Control Interno Informtico suele ser un rgano staff de la Direccin del Departamento de Informtica y est dotado de las personas y medios materiales proporcionados a los cometidos que se le encomienden. Como principales objetivos podemos indicar los siguientes: Controlar que todas las actividades se realizan cumpliendo los procedimientos y normas fijados, evaluar su bondad y asegurarse del cumplimiento de las normas legales. Asesorar sobre el conocimiento de las normas. Colaborar y apoyar el trabajo de Auditora Informtica, as como de las auditoras externas al Grupo. Definir, implantar y ejecutar mecanismos y controles para comprobar el logro de los grados adecuados del servicio informtico. Realizar en los diferentes sistemas (centrales, departamentales, redes locales, PCs, etc.) y entornos informticos (produccin, desarrollo o pruebas) el control de las diferentes actividades operativas sobre: o El cumplimiento de procedimiento, normas y controles dictados. Merece resaltarse la vigilancia sobre el control de cambios y versiones del software.

o o o o o

Controles sobre la produccin diaria. Controles sobre la calidad y eficiencia del desarrollo y mantenimiento del software y del servicio informtico. Controles en las redes de comunicaciones. Controles sobre el software de base. Controles en los sistemas microinformticos.

La seguridad informtica (su responsabilidad puede estar asignada a control interno o bien pueda asignrsele la responsabilidad de control dual de la misma cuando est encargada a otro rgano): o Usuarios, responsables y perfiles de uso de archivos y bases de datos. o Normas de seguridad. o Control de informacin clasificada o Control dual de la seguridad informtica. Licencias y relaciones contractuales con terceros. Asesorar y transmitir cultura sobre el riesgo informtico.

Auditora Informtica La Auditoria Informtica es el proceso de recoger, agrupar y evaluar evidencias para determinar si un sistema informatizado salvaguarda los activos, mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la organizacin y utiliza eficientemente los recursos. De este modo la auditora informtica sustenta y confirma la consecucin de los objetivos tradicionales de la auditora: Objetivos de proteccin de activos e integridad de datos. Objetivos de gestin que abarcan, no solamente los de proteccin de activos sino tambin los de eficacia y eficiencia. El auditor evala y comprueba en determinados momentos del tiempo los controles y procedimientos informticos ms complejos, desarrollando y aplicando tcnicas mecanizadas de auditora, incluyendo el uso del software. En muchos casos, ya no es posible verificar manualmente los procedimientos informatizados que resumen, calculan y clasifican datos, por lo que se deber emplear software de auditora y otras tcnicas asistidas por ordenador. El auditor es responsable de revisar e informar a la Direccin de la Organizacin sobre el diseo y el funcionamiento de los controles implantados y sobre la fiabilidad de la informacin suministrada. Se pueden establecer tres grupos de funciones a realizar por un auditor informtico: Participar en las revisiones durante y despus del diseo, realizacin, implantacin y explotacin de aplicaciones informticas, as como en las fases anlogas de realizacin de cambios importantes. Revisar y juzgar los controles implantados en los sistemas informticos para verificar su adecuacin a las rdenes e instrucciones de la Direccin, requisitos legales, proteccin de confidencialidad y cobertura ante errores y fraudes. Revisar y juzgar el nivel de eficacia, utilidad, fiabilidad y seguridad de los equipos e informacin.

Control interno y auditora informticos: campos anlogos Muchos controles internos fueron una vez auditores. De hecho, muchos de los actuales responsables de Control Interno Informtico recibieron formacin en seguridad informtica tras su paso por la formacin en auditora. Numerosos auditores se pasan al campo de Control lnterno Informtico debido a la similitud de los objetivos profesionales de control y auditora, campos anlogos que propician una transicin natural. Aunque ambas figuras tienen objetivos comunes, existen diferencias que convienen enfatizar:

CONTROL INTERNO INFORMATICO SIMILITUDES

AUDITOR INFORMATICO

DIFERENCIAS

Personal interno Conocimientos especializados en Tecnologa de la Informacin. Verificacin del cumplimiento de controles internos, normativa y procedimientos establecidos por la Direccin de Informtica y la Direccin General para los sistemas de informacin. Anlisis de los controles en el Anlisis de un momento da a da. informtico determinado. Informa a la Direccin del Informa a la Direccin General Departamento de Informtica. de la Organizacin. Slo personal interno. Personal interno y/o externo El alcance de sus funciones es Tiene cobertura sobre todos nicamente sobre el los componentes de los Departamento de Informtica sistemas de informacin de la Organizacin

SISTEMA DE CONTROL INTERNO INFORMTICO Histricamente, los objetivos de los controles informticos se han clasificado en las siguientes categoras: Controles preventivos: para tratar de evitar el hecho, como un software de seguridad que impida los accesos no autorizados al sistema. Controles detectivos: cuando fallan los preventivos para tratar de conocer cuanto antes el evento. Por ejemplo, el registro de intentos de acceso no autorizados, el registro de la actividad diaria para detectar errores u omisiones, etc. Controles correctivos: facilitan la vuelta a la normalidad cuando se han producido incidencias. Por ejemplo, la recuperacin de un fichero daado a partir de las copias de seguridad. Como el concepto de controles se origin en la profesin de auditora, resulta importante conocer la relacin que existe entre los mtodos de control, los objetivos de control y los objetivos de auditora. Se trata de un tema difcil por el hecho de que histricamente, cada mtodo de control ha estado asociado unvocamente con un objetivo de control (por ejemplo, la seguridad de ficheros de datos se consegua sencillamente manteniendo la sala de ordenadores cerrada con llave). Sin embargo, a medida que los sistemas informticos se han vuelto ms complejos, los controles informticos han evolucionado hasta convertirse en procesos integrados en los que se atenan las diferencias entre las categoras tradicionales de controles informticos. Por ejemplo, en los actuales sistemas informticos puede resultar difcil ver la diferencia entre seguridad de los programas, de los datos y objetivos de control del software del sistema, porque el mismo grupo de mtodos de control satisface casi totalmente los tres objetivos de control.

Implantacin de un sistema de controles internos informticos Los controles pueden implantarse a varios niveles diferentes. La evaluacin de los controles de la Tecnologa de la Informacin exige analizar diversos elementos interdependientes. Por ello es importante llegar a conocer bien la configuracin del sistema, con el objeto de identificar los elementos, productos y herramientas que existen para saber dnde pueden implantarse los controles, as como para identificar posibles riesgos. Para llegar a conocer la configuracin del sistema es necesario documentar los detalles de la red, as como los distintos niveles de control y elementos relacionados:

Entorno de red: esquema de la red, descripcin de la configuracin hardware de comunicaciones, descripcin del software que se utiliza como acceso a las telecomunicaciones, control de red, situacin general de los ordenadores de entornos de base que soportan aplicaciones crticas y consideraciones relativas a la seguridad de la red. Configuracin del ordenador base: configuracin del soporte fsico, entorno del sistema operativo, software con particiones, entornos (pruebas y real), bibliotecas de programas y conjunto de datos. Entorno de aplicaciones: procesos de transacciones, sistemas de gestin de bases de datos y entornos de procesos distribuidos. Productos y herramientas: software para desarrollo de programas, software de gestin de bibliotecas y para operaciones automticas. Seguridad del ordenador base: identificar y verificar usuarios, control de acceso, registro e informacin, integridad del sistema, controles de supervisin, etc.

Para la implantacin de un sistema de controles internos informticos habr que definir: Gestin de sistemas de informacin: polticas, pautas y normas tcnicas que sirvan de base para el diseo y la implantacin de los sistemas de informacin y de los controles correspondientes. Administracin de sistemas: controles sobre la actividad dc los centros de datos y otras funciones de apoyo al sistema, incluyendo la administracin de las redes. Seguridad: incluye las tres clases de controles fundamentales implantados en el software del sistema, integridad del sistema, confidencialidad (control de acceso) y disponibilidad. Gestin del cambio: separacin de las pruebas y la produccin a nivel de software y controles de procedimientos para la migracin de programas software aprobados y probados. La creacin de un sistema de control informtico es una responsabilidad de la Gerencia y un punto destacable de la poltica en el entorno informtico. A continuacin se indican algunos controles internos (no todos los que deberan definirse) para sistemas de informacin, agrupados por secciones funcionales, y que seran los que Control Interno Informtico y Auditora Informtica deberan verificar para determinar su cumplimiento y validez:

1. Controles generales organizativos Polticas: debern servir de base para la planificacin, control y evaluacin por la Direccin de las actividades del Departamento de Informtica. Planificacin: o Plan Estratgico de Informacin, realizado por los rganos de la Alta Direccin de la Empresa donde se definen los procesos corporativos y se considera el uso de las diversas tecnologas de informacin as como las amenazas y oportunidades de su uso o de su ausencia. o Plan Informtico, realizado por el Departamento de Informtica, determina los caminos precisos para cubrir las necesidades de la Empresa plasmndolas en proyectos informticos. o Plan General de Seguridad (fsica y lgica), que garantice la confidencialidad, integridad y disponibilidad de la informacin. o Plan de emergencia ante desastres, que garantice la disponibilidad de los sistemas ante eventos. Estndares: que regulen la adquisicin de recursos, el diseo, desarrollo y modificacin y explotacin de sistemas. Procedimientos: que describan la forma y las responsabilidades de ejecutoria para regular las relaciones entre el Departamento de Informtica y los departamentos usuarios. Organizar el Departamento de Informtica en un nivel suficientemente superior de estructura organizativa como para asegurar su independencia de los departamentos usuarios. Descripcin de las funciones y responsabilidades dentro del Departamento con una clara separacin de las mismas. Polticas de personal: seleccin, plan de formacin, plan de vacaciones y evaluacin y promocin.

Designar oficialmente la figura dc Control Interno Informtico y de Auditora Informtica (estas dos figuras se nombrarn internamente en base al tamao del Departamento de Informtica).

2. Controles de desarrollo, adquisicin y mantenimiento de sistemas de informacin Para que permitan alcanzar la eficacia del sistema, economa y eficiencia, integridad de los datos, proteccin de los recursos y cumplimiento con las leyes y regulaciones. Metodologa del ciclo de vida del desarrollo de sistemas: su empleo podr garantizar a la alta Direccin que se alcanzarn los objetivos definidos para el sistema. Estos son algunos controles que deben existir en la metodologa: o La alta Direccin debe publicar una normativa sobre el uso de metodologa de ciclo de vida del desarrollo de sistemas y revisar sta peridicamente. o La metodologa debe establecer los papeles y responsabilidades de las distintas reas del Departamento de Informtica y de los usuarios, as como la composicin y responsabilidades del equipo del proyecto. o Las especificaciones del nuevo sistema deben ser definidas por los usuarios y quedar escritas y aprobadas antes de que comience el proceso de desarrollo. o Debe establecerse un estudio tecnolgico de viabilidad en el cual se formulen formas alternativas de alcanzar los objetivos del proyecto acompaadas de un anlisis costebeneficio de cada alternativa. o Cuando se seleccione una alternativa debe realizarse el plan director del proyecto. En dicho plan deber existir una metodologa de control de costes. o Procedimientos para la definicin y documentacin de especificaciones de: diseo de entrada, de salida, de ficheros, de procesos, de programas, de controles de seguridad, de pistas de auditora, etc. o Plan de validacin, verificacin y pruebas. o Estndares de prueba de programas, de prueba de sistemas. o Plan de conversin: prueba de aceptacin final. o Los procedimientos de adquisicin de software debern seguir las polticas de adquisicin de la Organizacin y dichos productos debieran ser probados y revisados antes de pagar por ellos y ponerlos en uso. o La contratacin de programas de servicios de programacin a medida ha de estar justificada mediante una peticin escrita de un director de proyecto. Debern prepararse manuales de operacin y mantenimiento como parte de todo proyecto de desarrollo o modificacin de sistemas de informacin, as como manuales de usuario. Explotacin y mantenimiento: el establecimiento de controles asegurara que los datos se tratan de forma congruente y exacta y que el contenido de sistemas slo ser modificado mediante autorizacin adecuada. Estos son algunos de los controles que se deben implantar: o Procedimientos de control de explotacin. o Sistema de contabilidad para asignar a usuarios los costes asociados con la explotacin de un sistema de informacin. o Procedimientos para realizar un seguimiento y control de los cambios de un sistema de informacin.

3. Controles de explotacin de sistemas de informacin Planificacin y Gestin de recursos: definir el presupuesto operativo del Departamento, Plan de adquisicin de equipos y gestin de la capacidad de los equipos. Controles para usar de manera efectiva los recursos en ordenadores: o Calendario de carga de trabajo. o Programacin de personal. o Mantenimiento preventivo del material. o Gestin de problemas y cambios. o Procedimientos de facturacin a usuarios. o Sistema de gestin de la biblioteca de soportes.

Procedimientos de seleccin del software del sistema, de instalacin, de mantenimiento, de seguridad y control de cambios. Seguridad fsica y lgica: o Definir un grupo de seguridad de la informacin, sien do una de sus funciones la administracin y gestin del software de seguridad, revisar peridicamente los informes de violaciones y actividad de seguridad para identificar y resolver incidentes. o Controles fsicos para asegurar que el acceso a las instalaciones del Departamento de Informtica queda restringido a las personas autorizadas. o Las personas externas a la Organizacin debern ser acompaadas por un miembro de la plantilla cuando tengan que entrar en las instalaciones. o Instalacin de medidas de proteccin contra el fuego. o Formacin y concientizacin en procedimientos de seguridad y evacuacin del edificio. o Control de acceso restringido a los ordenadores mediante la asignacin de un identificador de usuario con palabra clave personal e intransferible. o Normas que regulen el acceso a los recursos informticos. o Existencia de un plan de contingencias para el respaldo de recursos dc ordenador crticos y para la recuperacin de los servicios del Departamento Informtico despus de una interrupcin imprevista de los mismos.

4. Controles en aplicaciones Cada aplicacin debe llevar controles incorporados para garantizar la entrada, actualizacin, validez y mantenimiento completos y exactos de los datos. Las cuestiones ms importantes en el control de los datos son: Control de entrada de datos: procedimientos de conversin y de entrada, validacin y correccin de datos. Controles de tratamientos de datos para asegurar que no se dan de alta, modifican o borran datos no autorizados para garantizar la integridad de los mismos mediante procesos no autorizados. Controles de salidas de datos: sobre el cuadre y reconciliacin de salidas, procedimientos de distribucin de salidas, de gestin de errores en las salidas, etc.

5. Controles especficos de ciertas tecnologas Controles en Sistemas de Gestin de Bases de Datos: o El software de gestin de bases de datos para prever el acceso a, la estructuracin de, y el control sobre los datos compartidos, deber instalarse y mantenerse de modo tal que asegure la integridad del software, las bases de datos y las instrucciones de control que definen el entorno. o Que estn definidas las responsabilidades sobre la planificacin, organizacin, dotacin y control de los activos de datos, es decir, un administrador de datos. o Que existen procedimientos para la descripcin y los cambios de datos as como para el mantenimiento del diccionario de datos. o Controles sobre el acceso a datos y de concurrencia. o Controles para minimizar fallos, recuperar el entorno de las bases de datos hasta el punto de la cada y minimizar cl tiempo necesario para la recuperacin. o Controles para asegurar la integridad de los datos: programas de utilidad para comprobar los enlaces fsicos -punteros- asociados a los datos, registros de control para mantener los balances transitorios de transacciones para su posterior cuadre con totales generados por el usuario o por otros sistemas. Controles en informtica distribuida y redes: o Planes adecuados de implantacin, conversin y pruebas de aceptacin para la red. o Existencia de un grupo de control de red. o Controles para asegurar la compatibilidad de conjunto de datos entre aplicaciones cuando la red es distribuida. o Procedimientos que definan las medidas y controles de seguridad a ser usados en la red de informtica en conexin con la distribucin del contenido de bases de datos entre los departamentos que usan la red.

o o o o o o o o o o o o o o o o

Que se identifican todos los conjuntos de datos sensibles de la red y que se han determinado las especificaciones para su seguridad. Existencia dc inventario de todos los activos de la red. Procedimientos de respaldo del hardware y del software de la red. Existencia de mantenimiento preventivo de todos los activos. Que existen controles que verifican que todos los mensajes de salida se validan de forma rutinaria para asegurar que contienen direcciones de destino validas. Controles de seguridad lgica: control de acceso a la red, establecimiento de perfiles de usuario. Procedimientos de cifrado de informacin sensible que se transmite a travs de la red. Procedimientos automticos para resolver cierres del sistema. Monitorizacin para medir la eficiencia de la red. Disear el trazado fsico y las medidas de seguridad de las lneas de comunicacin local dentro de la organizacin. Detectar la correcta o mala recepcin de mensajes. Identificar los mensajes por una clave individual de usuario, por terminal, y por el nmero de secuencia del mensaje. Revisar los contratos de mantenimiento y el tiempo medio de servicio acordados con el proveedor con objeto de obtener una cifra de control constante. Determinar si el equipo multiplexor/concentrador/procesador frontal remoto tiene lgica redundante y poder de respaldo con realimentacin automtica para el caso de que falle. Asegurarse de que haya procedimientos de recuperacin y reinicio. Asegurarse de que existan pistas de auditora que puedan usarse en la reconstruccin de los archivos de datos y de las transacciones de los diversos terminales. Debe existir la capacidad de rastrear los datos entre la terminal y el usuario. Considerar circuitos de conmutacin que usen rutas alternativas para diferentes paquetes de informacin provenientes del mismo mensaje; esto ofrece una forma de seguridad en caso de alguien intercepte los mensajes.

Controles sobre ordenadores personales y redes de rea local: o Polticas de adquisicin y utilizacin. o Normativas y procedimientos de desarrollo y adquisicin de software de aplicaciones. o Procedimientos de control del software contratado bajo licencia. o Controles de acceso a redes, mediante palabra clave, a travs de ordenadores personales. o Revisiones peridicas del uso de los ordenadores personales. o Polticas que contemplen la seleccin, adquisicin e instalacin de redes de rea local. o Procedimientos de seguridad fsica y lgica. o Departamento que realice la gestin y soporte tcnico de la red. o Controles para evitar modificar la configuracin de una red. o Recoger informacin detallada sobre los Minis existentes: Arquitectura (CPUs. Discos, Memoria, Streamers, Terminales, etc.), Conectividad (LAN, MINI TO HOST, etc.), software (sistema operativo, utilidades, lenguajes, aplicaciones, etc.), Servicios soportados. o Inventario actualizado de todas las aplicaciones de la Entidad. o Poltica referente a la organizacin y utilizacin de los discos duros de los equipos, as como para la nomenclatura de los ficheros que contienen, y verificar que contiene al menos: obligatoriedad de etiquetar el disco duro con el nmero de serie del equipo, Creacin de un subdirectorio por usuario en el que se almacenarn todos sus ficheros privados, as como creacin de un subdirectorio pblico que contendr todas las aplicaciones de uso comn para los distintos usuarios. o Implantar herramientas de gestin de la red con el fin de valorar su rendimiento, planificacin y control. o Procedimientos de control de los file-transfer que se realizan y de controles de acceso para los equipos con posibilidades de comunicacin. o Polticas que obliguen a la desconexin de los equipos de las lneas de comunicacin cuando no se est haciendo uso de ellas. o Adoptar los procedimientos de control y gestin adecuados para la integridad, privacidad, confidencialidad y seguridad de la informacin contenida en redes de rea local. o Cuando exista conexin PC-Host, comprobar que opera bajo los controles necesarios para evitar la carga/extraccin de datos de forma no autorizada. o Contratos de mantenimiento (tanto preventivo como correctivo o detectivo).

o o o o

o o o o o

Cuando en las acciones de mantenimiento se requiera la accin de terceros o la salida de los equipos de los lmites de la oficina, se debern establecer procedimientos para evitar la divulgacin de informacin confidencial o sensible. Mantener un registro documental de las acciones de mantenimiento realizadas, incluyendo la descripcin del problema y la solucin dada al mismo. Los ordenadores debern estar conectados a equipos de continuidad (UPSs, grupo, etc.). Proteccin contra incendios, inundaciones o electricidad esttica. Control de acceso fsico a los recursos microinformticos: Llaves de PCs. reas restringidas. Ubicacin de impresoras (propias y de red). Prevencin de robos de dispositivos. Autorizacin para desplazamientos de equipos. Acceso fsico fuera de horario normal. Control de acceso fsico a los datos y aplicaciones: almacenamiento de disquetes con copias de backup u otra informacin o aplicacin, procedimientos de destruccin de datos e informes confidenciales, identificacin de disquetes/cintas, inventario completo de disquetes almacenados, almacenamiento de documentacin. En los ordenadores en que se procesen aplicaciones o datos sensibles instalar protectores de oscilacin de lnea elctrica y sistemas de alimentacin ininterrumpida. Implantar en la red local productos de seguridad as como herramientas y utilidades de seguridad. Adecuada identificacin de usuarios en cuanto a las siguientes operaciones: altas, bajas y modificaciones, cambios de password, explotacin del log del sistema. Controlar las conexiones remotas in/out (CAL): Modems, Gateways, Mapper. Procedimientos para la instalacin o modificacin de software y establecer que la direccin es consciente del riesgo de virus informticos y otros software maliciosos, as como de fraude por modificaciones no autorizadas de software y daos. Controles para evitar la introduccin de un sistema operativo a travs de disquete que pudiera vulnerar el sistema de seguridad establecido.

EL PROCESO DE AUDITORIA La secuencia de pasos que implica llevar a cabo una auditoria puede variar segn diferentes circunstancias. No obstante ello, usualmente se verifican tres etapas esenciales: planificacin, ejecucin y conclusin. Estas tres etapas implican que la auditoria es un proceso secuencial con un punto de partida y otro de terminacin. En el caso de las auditorias recurrentes (exmenes efectuados por un mismo profesional durante varios ejercicios) se verifica una estrecha relacin entre la finalizacin de una auditoria y el inicio de la auditoria del periodo siguiente: la terminacin de la auditoria de un ao naturalmente conduce y proporciona el ingreso a la etapa de planificacin de la auditoria del ao prximo, ya que el conocimiento obtenido de la auditoria de cada ao se acumula y es aprovechado por las auditorias siguientes. Tambin sucede que los lmites de cada etapa no son tajantes ni excluyentes. Si bien la etapa de planificacin pretende establecer todos los procedimientos de auditoria que se aplicarn puede ser necesaria la modificacin de la planificacin efectuada durante su desarrollo, cambiando el alcance o la naturaleza de las pruebas a efectuar en etapas sucesivas. Asimismo, durante la planificacin y a efectos de darle validez a la informacin que le suministren al auditor sobre los principales procedimientos y sistemas de la empresa, se deberan efectuar pruebas de transacciones (seguir algunas operaciones desde el principio hasta el final del circuito administrativo que ellas recorren) a efectos de verificar la validez de la informacin que le fuera suministrada sobre el conocimiento del sistema, y a la vez, probar la efectividad del funcionamiento de los controles instituidos en el circuito, en especial aquellos que el auditor prevea que pueden resultarle de utilidad al momento de definir la naturaleza, el alcance y la oportunidad de los procedimientos a aplicar. De acuerdo con lo expuesto, resulta fcil apreciar que de hecho, y a pesar de estar efectuando la planificacin, se estn aplicando algunos procedimientos de auditoria que usualmente integran la etapa de ejecucin.

ETAPAS DEL PROCESO DE AUDITORIA

Las etapas del proceso de auditoria pueden sintetizarse de acuerdo con el siguiente detalle:

ETAPA PLANIFICACION EJECUCION

OBJETIVO Predeterminar procedimientos

CONCLUSION

RESULTADO Memorando de planificacin y programas de trabajo Obtener elementos de juicios, a Evidencias documentadas en travs de la aplicacin de los papeles de trabajo procedimientos planificados Emitir un juicio basado en la Informe del auditor evidencia de auditora obtenida en la etapa de ejecucin

En general se puede afirmar que los objetivos primordiales de cada una de las etapas en las que ha sido dividido el proceso de auditoria son los siguientes: Planificacin: El objetivo ltimo de esta etapa es la determinacin del enfoque de auditoria a aplicar y su consecuencia inmediata, la seleccin de los procedimientos particulares a ejecutar. Esto se ver reflejado en un memorando de planificacin que documenta las consideraciones analizadas durante toda la etapa, como asimismo los respectivos programas detallados de trabajo que indican de qu forma, en qu momento y con qu alcance se ejecutarn los procedimientos seleccionados. Ejecucin: Su finalidad ser la de cumplimentar los procedimientos planificados para obtener elementos de juicio vlidos y suficientes para sustentar una opinin. Todos esos elementos de juicio se traducirn en papeles de trabajo que constituyen la documentacin y evidencian el examen realizado. Es de destacar que en esta etapa no slo se realizarn los procedimientos previstos en la etapa de planificacin, sino tambin todas aquellas pruebas alternativas que deban efectuarse reemplazando o complementando a las

originalmente planificadas, ya sea por dificultades propias de la empresa, de los sistemas, del resultado de los procedimientos realizados o por eficiencia en el examen. Conclusin: En esta etapa se evalan todas las evidencias obtenidas durante la etapa de ejecucin que deben permitir formar un juicio o una opinin, emitiendo el respectivo informe del auditor. Habiendo definido en forma global los objetivos de cada una de las etapas que integran el proceso de auditoria, seguidamente se analizarn las caractersticas principales de cada una de ellas.

ETAPA DE PLANIFICACION Ante cualquier actividad que realice el hombre, antes de ejecutarla, y aun inconscientemente, piensa en cmo efectuada. Cuanto mayores la posibilidad de razonamiento, mayor ser su intencin de planificar la actividad a realizar. Ello lleva implcitos dos objetivos: Que la actividad resulte efectiva, permitiendo llegar al cumplimiento de los objetivos propuestos; Que la actividad resulte eficiente, es decir, que asegurada la efectividad, la misma se alcance utilizando los recursos estrictamente necesarios. Como conclusin podemos decir que el objetivo consiste en determinar qu procedimientos de auditoria corresponder realizar y cmo y cundo se ejecutarn. La planificacin de una auditoria comienza con la obtencin de informacin necesaria para definir la estrategia a emplear y culmina con la definicin detallada de las tareas a realizar en la etapa de ejecucin, cuyo resultado ser evaluado en la etapa de conclusin. Las organizaciones que sern objeto de un examen de auditoria podrn operar en diferentes actividades y negocios, estarn expuestas a diferentes riesgos y a diversos contactos con entidades de distinta ndole, todo lo cual conformar el ambiente en el que la empresa desarrolla sus actividades. En funcin de estos condicionantes desarrollar los sistemas de informacin que mejor se adapten a sus necesidades. Por lo tanto, es necesario predeterminar el enfoque de auditoria para recoger las particularidades de esas organizaciones. La planificacin incluye diversos procedimientos ms relacionados con una lgica conceptual que con la tcnica de auditora. Los mismos pueden sintetizarse en el siguiente grfico:

Inherentes Negocio Riesgos Unid. Operativas Componentes De Control Afirmaciones Sistema de Control Enfoque de Cumplimiento Enfoque Sustantivo Procedimientos Pruebas Analticas

Si alguien pretende dar una opinin de un ente, y a su vez stos reflejen una actividad o un negocio, resulta necesario que esta persona obtenga un conocimiento profundo de su actividad principal. Se entiende por negocio a la actividad principal objeto de la existencia del ente. El conocimiento del negocio implica comprender con profundidad las caractersticas salientes de dicha actividad, por

ejemplo cul es la principal fuente de ingresos y recursos, cules son los aspectos estratgicos y clave para conseguirlos, qu riesgos del contexto lo afectan, cules son los sistemas de Informacin de que dispone para reflejar las operaciones, etc. Habiendo conocido las principales caractersticas de la actividad, se est en condiciones de definir las unidades operativas en las cuales resultar til dividir a una entidad, a efectos de la revisin. Se entiende por unidades operativas a todas aquellas actividades del negocio que, por tener caractersticas distintivas, son susceptibles de ser consideradas con criterios y procedimientos de auditoria propios, por ejemplo actividades de fabricacin de productos totalmente dismiles. Determinadas las unidades operativas, se deben definir los componentes que las forman. Estos componentes estn vinculados con lo que se quiere revisar o examinar. Pueden ser sistemas o circuitos administrativos entre otros. De esta forma, s se hubiera definido a diferentes plantas de produccin como unidades operativas distintas, los sistemas que conforman la produccin podran ser los componentes a analizar. El paso siguiente consistir en definirlas afirmaciones ms Importantes que incluyen los componentes y cuya validez deber probarse en el transcurso de la auditoria. La validez de las afirmaciones debe ser confirmada mediante la ejecucin de los procedimientos de auditoria. Los procedimientos surgen de determinar el enfoque de auditoria, esto es la combinacin ms adecuada entre pruebas analticas de cumplimiento y sustantivas. Esa combinacin se obtiene del anlisis de los riesgos de auditoria vinculados con los componentes, las afirmaciones a ser verificadas, el sistema de control vigente y la eficiencia en el proceso de auditoria (es decir la combinacin que demande menor cantidad de recursos). El riesgo de auditora es la susceptibilidad a la existencia de errores o Irregularidades. Es de gran importancia que el auditor tenga una adecuada comprensin de cmo los riesgos se vinculan con cada componente ya que esto es la clave de la determinacin del enfoque de auditoria a aplicar. Definido el enfoque para cada componente, se determinan los procedimientos de auditoria especficos que se aplicarn a efectos de verificar la validez de las afirmaciones. Los procedimientos planificados deben detallarse en programas de trabajo que expliciten en forma pormenorizada los pasos a seguir.

Etapas del proceso de planificacin Como proceso, la planificacin puede dividirse en dos etapas o momentos distintos. En el primero de ellos se define cul ser la estrategia a seguir en base al conocimiento e informacin mantenida del ente a auditar, se la denomina planificacin estratgica. En el segundo momento, luego de definir la estrategia global, se discriminan para cada uno de los distintos componentes cules son los procedimientos a realizar para completar esa estrategia y se detalla cmo se llevarn a cabo: se la denomina planificacin detallada. La planificacin estratgica brinda una visin desde arriba" englobando toda la auditoria en su conjunto. La planificacin detallada, "desde abajo", trabaja con cada estrategia definida y determina cmo ejecutarla. La planificacin estratgica, como primera etapa del proceso dc planificacin, rene el conocimiento acumulado del ente, la informacin adicional obtenida como consecuencia de un primer acercamiento a las actividades ocurridas en el periodo a auditar y resume este conocimiento en la definicin de decisiones preliminares para cada componente. En la planificacin detallada se trabaja cada componente en particular, en forma separada del resto de los componentes. Consiste en concentrar los esfuerzos de auditoria en las reas de mayor riesgo y en particular, en lo que se denominan afirmaciones.

El resultado de la etapa de planificacin detallada se documentar a travs de lo que se llama programa de trabajo que Incluye cada uno de los procedimientos a aplicar para cada componente y en cada visita de auditoria con indicacin del alcance y pasos a seguir. Los siguientes tem resumen los conceptos antes enunciados sobre planificacin detallada: Definicin de afirmaciones Seleccin de procedimientos de auditoria Preparacin de programas de trabajo

ETAPA DE EJECUCION En esta etapa se desarrolla el plan de auditora, es decir se llevan a cabo los procedimientos planificados en la etapa anterior. El propsito de la de ejecucin es obtener suficiente satisfaccin de auditoria sobre la cual se puede sustentar el Informe del auditor. La satisfaccin de auditora se obtiene mediante la ejecucin de los procedimientos previamente definidos y adecuadamente documentados. A pesas de lo detallada que haya sido la planificacin de la auditoria el plan puede ser modificado a medida que progresa el trabajo. Por ejemplo, se pueden descubrir factores de riesgo adicionales relativos a los sistemas y negocios que requieran que se cambie el alcance y la naturaleza del trabajo previamente definido. Cuando fuera necesario realizar un cambio significativo al plan aprobado, ste debe documentarse adecuadamente.

ETAPA DE CONCLUSION La etapa de conclusin une los resultados del trabajo realizado en cada unidad operativa y en cada componente. El objetivo es analizar los hallazgos de auditoria de cada unidad y componente de auditoria y obtener una conclusin general constituye la esencia del informe del auditor Como parte de la etapa de conclusin, los mximos responsables del equipo de auditoria deben revisar crticamente el trabajo realizado. El objetivo de la revisin es asegurarse de que el plan de auditoria haya sido efectivamente aplicado y determinar si los hallazgos de auditoria han sido correctamente evaluados y si los objetivos fueron alcanzados, La evaluacin de la evidencia de auditoria debe considerar si la informacin y los parmetros sobre los cuales se bas el plan de auditoria continan siendo apropiados y, por consiguiente, si se ha obtenido suficiente satisfaccin de auditoria. En especial se debe considerar si: La evidencia obtenida es tan importante y confiable como se esperaba. La naturaleza y nivel de las excepciones estn de acuerdo con lo que se esperaba en el momento en que la auditoria fue planificada. La evidencia debe ser evaluada en, trminos de su suficiencia. Importancia y confiabilidad, y la naturaleza y nivel de las excepciones de auditoria identificadas. Tambin se debe considerar si dicha evidencia contradice alguna de las decisiones tomadas durante la planificacin.

RIESGO DE AUDITORIA Excepto en contadas ocasiones el auditor puede estar en condiciones de emitir un juicio tcnico con absoluta certeza sobre la validez de las afirmaciones. Esta falta de certeza genera el concepto de riesgo de auditoria. La labor del auditor se concentrar entonces en ejecutar tareas y procedimientos tendientes a reducir ese riesgo a un nivel aceptacin. El riesgo de auditoria puede definirse como la posibilidad de emitir un informe de auditoria incorrecto por no haber detectado errores o irregularidades significativas que modificaran el sentido de la opinin vertida en el informe. El riesgo de auditoria esta compuesto por distintas situaciones o hechos que, analizados en forma separada, ayudan a evaluar el nivel de riesgo existente en un trabajo en particular y determinar de qu manera es posible reducirlo a niveles aceptables. Bajo este anlisis, el riesgo global de auditoria es el resultado de la conjuncin de: Aspectos aplicables exclusivamente al negocio o actividad del ente, independientemente de los sistemas de control desarrollados, lo que se denomina riesgo inherente. Aspectos atribuibles a los sistemas de control, incluyendo auditoria interna, lo que se denomina riesgo de control. Aspectos originados en la naturaleza, alcance y oportunidad de los procedimientos de auditoria de un trabajo en particular, lo que se denomina riesgo de deteccin. Las dos primeras categoras de riesgo se encuentran fuera de control por parte del auditor y son propias de los sistemas y negocios del ente. En cambio, el nesgo de deteccin est directamente relacionado con la labor del auditor. En primer lugar, se identifica el riesgo global de que existan errores o Irregularidades no detectados por los procedimientos de auditoria y que en definitiva lleven a emitir un informe de auditora incorrecto. En segundo lugar, se evala el riesgo de auditoria especifico para cada componente en particular. La identificacin de los distintos riesgo, su clasificacin y evaluacin permiten concentrar la labor de auditoria en las reas de mayor riesgo. El riesgo de auditoria se reduce en la medida en que se obtenga evidencia de auditoria que respalde la validez de las afirmaciones. No obstante, cualquiera sea el grado de obtencin de validez para estas afirmaciones es inevitable que exista algn grado de riesgo. El trabajo del auditor ser entonces reducirlo a un nivel tal donde la existencia de errores o Irregularidades sea lo suficientemente baja como para no interferir en su opinin global

Categora de riegos de auditora Las mismas son: Riesgo Inherente Riesgo de control Riesgo de deteccin La comprensin de cada una de ellas ayudar al auditor a evaluar el nivel de riesgo existente en una auditoria en su conjunto y en cada componente en particular, para poder determinar cul es el enfoque de auditoria apropiado a cada situacin individual.

RIESGO INHERENTE El riesgo Inherente es la susceptibilidad de la existencia de errores o irregularidades significativas, antes de considerar la efectividad de los sistemas de control.

El riesgo Inherente est totalmente fiera de control por parte del auditor. Difcilmente se puedan tomar acciones que tiendan a eliminarlo por que es propio de la operatoria del ente. Entre los factores que determinan la existencia de un riesgo inherente se pueden mencionan: La naturaleza del negocio del ente: el tipo de operaciones que se realizan y el riesgo propio de esas operaciones: la naturaleza de sus productos y volumen de transacciones. El riesgo Inherente que tiene la situacin econmica financiera del ente. La organizacin gerencial y sus recursos humanos y materiales: la Integridad de la gerencia y la calidad de los recursos que el ente posee. La predisposicin de los niveles gerenciales a establecer adecuados y formales sistemas de control, su nivel tcnico y la capacidad de mostrarla en el personal clave.

RIESGO DE CONTROL El riesgo de control es el riesgo de que los sistemas de control estn Incapacitados para detectar o evitar errores o irregularidades significativas en forma oportuna. Este tipo de riesgo tambin est fuera del control de los auditores, pero eso s, las recomendaciones resultantes del anlisis y evaluacin de los sistemas de Informacin y de control que se realicen van a ayudar a mejorar los niveles de riesgo en la medida en que se adopten tales recomendaciones. Los factores que determinan el riesgo de control estn presentes en el sistema de informacin y control. La tarea de evaluacin del riesgo de control est ntimamente relacionada con el anlisis de estos sistemas. La existencia de puntos dbiles de control implicara a priori la existencia de factores que incrementan el riesgo de control y al contrario, puntos fuertes de control serian factores que reducen el nivel de este riesgo.

RIESGO DE DETECCION El riesgo de deteccin es el riesgo de que los procedimientos de auditoria seleccionados no detecten errores o irregularidades existentes. A diferencia de los dos riesgos mencionados anteriormente, el riesgo de deteccin es totalmente controlable por la labor del auditor y depende exclusivamente de la forma en que se diseen y lleven a cabo los procedimientos de auditoria. Al igual que el riesgo de control la existencia de altos niveles de riesgo inherente, el riesgo de deteccin es la ltima y nica posibilidad de mitigar altos niveles de riesgos inherentes y de control. Los factores que determinan el riesgo de deteccin estn relacionados con: La ineficacia de un procedimiento de auditora aplicado. La mala aplicacin de un procedimiento de auditoria, resulte ste eficaz o no. Problemas de definicin de alcance y oportunidad en un procedimiento de auditoria, hayan sido bien o mal aplicado. El auditor no examina el 100% de las transacciones de un ente, sino que se basa en el trabajo realizado sobre una muestra y extiende esos resultados al universo de las transacciones. La mala determinacin del tamao de la muestra puede llevar a conclusiones errneas sobre el universo de esas operaciones.

EVALUACION DEL RIESGO DE AUDITORIA La evaluacin del riesgo de auditoria es el proceso por el cual, a partir del anlisis de la existencia e intensidad de los factores de riesgo, se mide el nivel de riesgo presente en cada caso. El nivel del riesgo de auditora suele medirse en cuatro grados posibles: Mnimo Bajo Medio Alto En algunas circunstancias quiz resulte poco clara esta clasificacin, por lo que muchas veces la evaluacin del nivel de riesgo se limita a determinar un riesgo alto o bajo. La tarea de evaluacin est presente en dos momentos de la planificacin de auditoria. Planificacin estratgica: en esta etapa se evala el riesgo global de auditoria y se evala el riesgo inherente y de control de cada componente en particular. Planificacin detallada: En esta etapa se evala el riesgo Inherente y de control especfico para cada afirmacin en particular, dentro de cada componente. La evaluacin del nivel de riesgo es un proceso totalmente subjetivo y depende exclusivamente del criterio, capacidad y experiencia del auditor. Adems, es la base para la determinacin del enfoque de auditoria a aplicar y la cantidad de satisfaccin de auditoria a obtener. Por lo tanto, debe ser un proceso cuidadoso y realizado por quienes posean la mayor capacidad y experiencia en un equipo de trabajo. No obstante ser un proceso subjetivo, hay formas de tratar de estandarizar o disminuir esa subjetividad. En ese sentido, se tratan de medir tres elementos que combinados, son herramientas a utilizar en el proceso de evaluacin del nivel de riesgo. Esos elementos son: La significatividad del componente. La existencia de factores de riesgo y su importancia relativa. La probabilidad de ocurrencia de errores o irregularidades bsicamente obtenida del conocimiento y la experiencia anterior de ese ente. Un nivel de riesgo mnimo estara conformado cuando en un componente poco significativo no existan factores de riesgo y donde la probabilidad de ocurrencia de errores o irregularidades sea remota. Cuando en un componente significativo existan factores de riesgo pero no demasiado importantes y la probabilidad de existencia de errores o irregularidades sea baja -Improbable-, ese componente tendr una evaluacin de riesgo bajo. Un componente claramente significativo, donde existen varios factores de riesgo y es posible que se presenten errores o irregularidades. Ser un riesgo medio. Por ltimo, un componente tendr un nivel de riesgo alto cuando sea claramente significativo, con varios factores de riesgo, algunos de ellos muy importantes y donde sea totalmente probable que existan errores o irregularidades.

La tabla siguiente esquematiza estos conceptos: NIVEL DE RIESGO SIGNIFICATIVIDAD FACTORES DE RIESGO PROBROBABILIDAD DE OCURRENCIA DE ERRORES Remota Improbable Posible Probable

MNIMO BAJO MEDIO ALTO

No significativo Significativo Muy significativo Muy significativo

No existen Existen algunos pero pocos importantes Existen algunos Existen varios y son importantes

Relaciones entre riesgos

(+)

Cantidad de evidencia necesaria Evidencia de auditora necesaria (-) Alto Mnimo Riesgo Inherente

(+)

Confianza derivada de los controles (-) Mnimo Alto Riesgo de Control

(+)

1
Riesgo Inherente

3
(-) (-) Riesgo de Control

(+)

Caso 1: Alto riesgo inherente; mnimo riesgo de control: corresponde aplicar pruebas de cumplimiento (por el riesgo de control) que brinden suficiente satisfaccin de auditoria (por el riesgo inherente) Caso 2: Alta riesgo inherente y de control: Corresponde aplicar pruebas sustantivas (por control)con un alcance extenso (por el riesgo inherente) Caso 3: Mnimo riesgo inherente y de control: como ambos riesgos son mnimos, es decir, la probabilidad de ocurrencia de errores es remota, no corresponde asignar demasiados esfuerzos de auditoria a este caso. Seguramente ser suficiente la aplicacin de algn procedimiento analtico global. Caso 4: Mnimo riesgo inherente y alto riesgo de control: No es necesario aplicar extensas pruebas (por el riesgo inherente) pero, como existen problemas de control, ser oportuno practicar algn procedimiento sustantivo tendiente a reducir el riesgo del rea que presente el problema.

INFORME DE AUDITORIA Vamos a tratar de fijar la prctica de la Auditoria Informtica en funcin, del Informe. Para ello, repasaremos someramente aspectos previos fundamentales, como concepto de normas, evidencia en auditora, las irregularidades, los papeles de trabajo o documentacin para, finalmente, encarar el Informe, sus componentes, caractersticas y tendencias detectadas. Intentaremos, tambin, ofrecer algunas conclusiones de inters, sin perder de vista en todo caso que en el mundo auditor de hoy todo ejercicio de prediccin es, en principio, una temeridad. Las normas En Estados Unidos, tanto la Auditora como la Informtica (y las Comunicaciones), tienen un desarrollo muy experimentado y, sobre todo, adaptativo. Los parmetros de velocidad y tiempo hacen aconsejable un esfuerzo por conseguir la disponibilidad armonizada de normas legales y normas de origen profesional. Si la globalizacin antes mencionada es un hecho incuestionable, el sabio uso de los llamados principios generalmente aceptados har posible la adaptacin suficiente a la realidad de cada poca. En este sentido, no podemos olvidar que los organismos de armonizacin, normalizacin, homologacin, acreditacin y certificacin tendrn que funcionar a un ritmo ms acorde con las necesidades cambiantes. l conjunto ISO-CEN-AENOR y los vinculados con seguridad, ITSEC/ITSEM Europa, TCSEC USA y Cotnmon Criterio UE/Norteamrica, necesitan ir ms rpido, ya que su lentitud est provocando, en un mundo tan acelerado, la aparicin de multitud de organizaciones privadas, consorcios y asociaciones que con muy buena voluntad y ptimo sentido de la conveniencia mercantil, pretenden unificar normas y promocionar estndares. Por ltimo, conviene que se clarifique el panorama normativo, de prcticas y responsabilidades en lo que concierne a los problemas planteados por los servicios profesionales multidisciplinares, ya que el Informe de Auditora Informtica se compone de tres trminos: Informtica, Auditora e Informe. La evidencia La evidencia consiste en Auditora Informtica, en las pruebas que la avalan, sin olvidar la importancia relativa y el riesgo probable, inherente y de control. La certeza absoluta no siempre existe, segn el punto de vista de los auditores; los usuarios piensan lo contrario. No obstante lo dicho, el desarrollo del control interno, incluso del especficamente informtico, est en efervescencia. Pero volvamos a la evidencia, porque ella es la base razonable de la opinin del Auditor Informtico, esto es, el Informe de Auditora Informtica. La evidencia tiene una serie de calificativos; a saber: La evidencia relevante, que tiene una relacin lgica con los objetivos de la auditora. La evidencia fiable, que es vlida y objetiva, aunque con nivel de confianza. La evidencia suficiente, que es de tipo cuantitativo para soportar la opinin profesional del auditor. La evidencia adecuada, que es de tipo cualitativo para afectar a las conclusiones del auditor. En principio, las pruebas son de cumplimiento o sustantivas. La opinin deber estar basada en evidencias justificativas, es decir, desprovistas de prejuicios, si es preciso con evidencia adicional.

Las irregularidades Los organismos, las empresas y la Direccin tienen la responsabilidad principal y primaria de la deteccin de irregularidades, fraudes y errores; la responsabilidad del auditor se centra en planificar, llevar a cabo y evaluar su trabajo para obtener una expectativa razonable de su deteccin. Es, pues, indudablemente necesario disear pruebas antifraude, que lgicamente incrementarn el coste de la auditora, previo anlisis de riesgos (amenazas, importancia relativa..). Por prudencia y rectitud, convendr aclarar al mximo -de ser posible- si el Informe de Auditora es propiamente de auditora y no de consultora o asesora informtica, o de otra materia afn o prxima. Aunque siempre debe prevalecer el deber de secreto profesional del auditor, conviene recordar que en el caso de detectar fraude durante el proceso de auditora procede actuar en consecuencia con la debida prudencia que aconseja episodio tan delicado y conflictivo, sobre todo si afecta a los administradores de la organizacin objeto de auditora. La documentacin En el argot de auditora se conoce como papeles de trabajo la "totalidad de los documentos preparados o recibidos por el auditor, de manera que, en conjunto, constituyen un compendio de la informacin utilizada y de las pruebas efectuadas en la ejecucin de su trabajo, junto con las decisiones que ha debido tomar para llegar a formarse su opinin. El Informe de Auditora, si se precisa que sea profesional, tiene que estar basado en la documentacin o papeles de trabajo, como utilidad inmediata, previa supervisin. La documentacin, adems de fuente de know how del Auditor Informtico para trabajos posteriores as como para poder realizar su gestin interna de calidad, es fuente en algunos casos en los que la corporacin profesional puede realizar un control de calidad, o hacerlo algn organismo oficial. Los papeles de trabajo pueden llegar a tener valor en los Tribunales de justicia. Por otra parte, no debemos omitir la caracterstica registral del Informe, tanto en su parte cronolgica como en la organizativa, con procedimientos de archivo, bsqueda, custodia y conservacin de su documentacin, cumpliendo toda la normativa vigente, legal y profesional, como mnimo exigible. Los trabajos utilizados, en el curso de una labor, de otros auditores externos y/o expertos independientes, as como de los auditores internos, se reseen o no en el Informe de Auditora Informtica, formarn parte de la documentacin. Adems, se incluirn: El contrato cliente/auditor informtico y/o la carta propuesta del auditor informtico. Las declaraciones de la Direccin. Los contratos, o equivalentes, que afecten al sistema de informacin, as como el informe de la asesora jurdica del cliente sobre sus asuntos actuales y previsibles. El informe sobre terceros vinculados. Conocimiento de la actividad del cliente. El informe Se ha realizado una visin rpida de los aspectos previos para tenerlos muy presentes al redactar el Informe de Auditora Informtica, esto es, la comunicacin del Auditor Informtico al cliente, formal y, quiz, solemne, tanto del alcance de la auditora (objetivos, perodo de cobertura, naturaleza y extensin del trabajo realizado) como de los resultados y conclusiones. Es momento adecuado de separar lo significativo de lo no significativo, debidamente evaluados por su importancia y vinculacin con el factor riesgo, tarea eminentemente de carcter profesional y tico, segn el leal saber y entender del Auditor Informtico.

Aunque no existe un formato vinculante, s existen esquemas recomendados con los requisitos mnimos aconsejables respecto a estructura y contenido. Tambin es cuestin previa decidir si el informe es largo o, por el contrario, corto, por supuesto con otros informes sobre aspectos, bien ms detallados, bien ms concretos, como el informe de debilidades del control interno, incluso de hechos o aspectos; todo ello teniendo en cuenta tanto la legislacin vigente como el contrato con el cliente. En lo referente a la redaccin, el Informe deber ser claro, adecuado, suficiente y comprensible. Una utilizacin apropiada del lenguaje informtico resulta recomendable. Los puntos esenciales, genricos y mnimos del Informe de Auditora Informtica son los siguientes: 1. Identificacin del Informe El ttulo del Informe deber identificarse con objeto de distinguirlo de otros informes. 2. Identificacin del Cliente Deber identificarse a los destinatarios y a las personas que efecten el encargo. 3. Identificacin de la entidad auditada Identificacin de la entidad objeto de la Auditora Informtica. 4. Objetivos de la Auditora Informtica Declaracin de los objetivos de la auditora para identificar su propsito, sealando los objetivos incumplidos. 5. Normativa aplicada y excepciones Identificacin de las normas legales y profesionales utilizadas, as como las excepciones significativas de uso y el posible impacto en los resultados de la auditora. 6. Alcance de la Auditora Concretar la naturaleza y extensin del trabajo realizado: rea organizativa, perodo de auditora, sistemas de informacin..., sealando limitaciones al alcance y restricciones del auditado. 7. Conclusiones: Informe corto de opinin Lgicamente, se ha llegado a los resultados y, sobre todo, a la esencia del dictamen, la opinin y los prrafos de salvedades y nfasis, si procede. El Informe debe contener uno de los siguientes tipos de opinin: favorable o sin salvedades, con salvedades, desfavorable o adversa, y denegada. 7.1 Opinin favorable. La opinin calificada como favorable, sin salvedades o limpia, deber manifestarse de forma clara y precisa, y es el resultado de un trabajo realizado sin limitaciones de alcance y sin incertidumbre, de acuerdo con la normativa legal y profesional. Es indudable que entre el informe de recomendaciones al cliente, que incluye lo referente a debilidades de control interno en sentido amplio, y las salvedades, existe o puede existir una zona de gran sensibilidad; tan es as que tendr que clarificarse al mximo, pues una salvedad a la opinin deber ser realmente significativa; concretando: ni pasarse, ni no llegar, dicho en lenguaje coloquial; en puridad es un punto de no retorno. 7.2 Opinin con salvedades. Se reitera lo dicho en la opinin favorable al respecto de las salvedades cuando sean significativas en relacin con los objetivos de auditora, describindose con precisin la naturaleza y razones. Podrn ser stas, segn las circunstancias, las siguientes: Limitaciones al alcance del trabajo realizado; esto es, restricciones por parte del auditado, etc. Incertidumbres cuyo resultado no permita una previsin razonable. Irregularidades significativas. Incumplimiento de la normativa legal y profesional.

7.3. Opinin desfavorable. La opinin desfavorable o adversa es aplicable en el caso de: Identificacin de irregularidades. Incumplimiento de la normativa legal y profesional, que afecten significativamente a los objetivos de auditora informtica estipulados, incluso con incertidumbres; todo ello en la evaluacin de conjunto y reseando detalladamente las razones correspondientes. 7.4. Opinin denegada. La denegacin de opinin puede tener su origen en: Las limitaciones al alcance de auditora. Incertidumbres significativas de un modo tal que impidan al auditor formarse una opinin. Irregularidades. El incumplimiento de normativa legal y profesional. 8. Resultados: Informe largo y otros informes Parece ser que, de acuerdo con la teora de ciclos, el informe largo va a colocar al informe corto en su debido sitio, o sea, como resumen del informe largo (quiz obsoleto?). Los usuarios, no hay duda, desean saber ms y desean transparencia como valor aadido. Es indudable que el lmite lo marcan los papeles de trabajo o documentacin de la Auditora Informtica, pero existen aspectos a tener en cuenta: El secreto de la empresa. El secreto profesional. Los aspectos relevantes de la auditora. 9. Informes previos No es una prctica recomendable, aunque s usual en algunos casos, ya que el Informe de Auditora Informtica es, por principio, un informe de conjunto. Sin embargo, en el caso de deteccin de irregularidades significativas, tanto errores como fraudes, sobre todo, se requiere una actuacin inmediata segn la normativa legal y profesional, independientemente del nivel jerrquico afectado dentro de la estructura de la entidad. Recordemos al respecto el delito societario y la responsabilidad civil del Auditor (Informtico). 10. Fecha del Informe El tiempo no es neutral; la fecha del Informe es importante, no slo por la cuantificacin de honorarios y el cumplimiento con el cliente, sino para conocer la magnitud del trabajo y sus implicaciones. Conviene precisar las fechas de inicio y conclusin del trabajo de campo, incluso la del cierre del trabajo. En casos conflictivos pueden ser relevantes aspectos tales como los hechos posteriores al fin del perodo de auditora, hechos anteriores y posteriores al trabajo de campo. 11. Identificacin y firma del Auditor Este aspecto formal del informe es esencial tanto si es individual como si forma parte de una sociedad de auditora, que deber corresponder a un socio o socios legalmente as considerados. 12. Distribucin del Informe Bien en el contrato, bien en la carta propuesta del Auditor Informtico, deber definirse quin o quines podrn hacer uso del Informe, as como los usos concretos que tendr, pues los honorarios debern guardar relacin con la responsabilidad civil.

EJEMPLO SOBRE INFORME DE AUDITORA

Ttulo Lugar y fecha de Emisin Destinatario

INFORME DE AUDITORIA Crdoba, ... de ................... de 20..... Al Director del Departamento de Informtica Sr. ........... Control de acceso

Asunto

Identificacin del Trabajo

Con fecha ........., se procedi a examinar el software denominado................ versin ............

Alcance

La auditora se realiz utilizando lotes de pruebas cuyos datos fueron genedos por ............. De lo observado oportunamente se sugiere ...............

Opinin

Firma del Profesional

JHC

Marco Jurdico de la Auditora Informtica

El Derecho Informtico, a diferencia de la Informtica Jurdica, es aquella parte del Derecho que regula el mundo informtico evitando que se convierta en una jungla donde siempre sale ganando el ms fuerte. Fruto del mismo son: la proteccin de datos personales, la proteccin jurdica de los programas de computacin, los delitos informticos, el documento electrnico, el comercio electrnico, y la contratacin electrnicas informtica entre otras materias. El auditor informtico, si quiere realizar bien su labor y a la vez evitar situaciones desagradables y un tanto peligrosas, est obligado a conocer esta rama del Derecho, pues es la que regula el objeto de su trabajo. Desconocer las normas que regulan la proteccin de los datos personales, la piratera de los programas de computacin, las obligaciones contractuales, los delitos informticos, las responsabilidades civiles y penales en que puede incurrir puede tener consecuencias graves si, como es fcil que ocurra, dichas circunstancias se presentan en el entorno en que trabaja.

La Proteccin de Datos de Carcter Personal El artculo 18.4 de nuestra Constitucin emplaza al legislador a limitar el uso de la informtica para garantizar el honor, la intimidad personal y familiar de sus ciudadanos y el legtimo ejercicio de sus derechos. Fruto de este mandato constitucional fue la promulgacin de la Ley Orgnica 5/1992 de 29 de octubre de Regulacin del Tratamiento Automatizado de los Datos de carcter personal (LORTAD). La LORTAD se inspira en los siguientes principios: Principio de finalidad. Antes de la creacin de un fichero de datos de carcter personal3 ha de conocerse el fin del mismo (art. 4.1). Este principio, a su vez, engloba otros dos: el principio de pertinencia y el de utilizacin abusiva. Principio de pertinencia (art. 4.1). Los datos deben ser pertinentes, es decir estar relacionados con el fin perseguido al crearse el fichero. Principio de utilizacin abusiva (art. 4.2). Los datos recogidos no deben ser utilizados para otro fin distinto a aquel para el que fueron recabados. Principio de exactitud (art. 43 y 4.4). El responsable del fichero debe poner los medios necesarios para comprobar la exactitud de los datos registrados y asegurar su puesta al da. Principio de derecho al olvido (art. 4.5). Los datos debern desaparecer del fichero una vez se haya cumplido el fin para el que fueron recabados. Principio del consentimiento (art. 6). El tratamiento automatizado de los datos requerir el consentimiento del afectado, salvo que la Ley disponga otra cosa contemplndose algunas excepciones y teniendo el carcter de revocable. Principio de los datos especialmente protegidos (art. 7). Se debe garantizar de forma especial el tratamiento automatizado de los datos de carcter personal cuando ellos se refieran a ideologa, religin o creencias del afectado, as como los referentes a su origen racial, salud, vida sexual o a la comisin de infracciones penales o administrativas. Principio de seguridad (art. 9). El responsable deber adoptar las medidas necesarias de ndole fsica, organizativa o lgica con objeto de poder garantizar la seguridad de los datos de los ficheros. Principio de acceso individual (art. 14). Cualquier persona tendr derecho a saber si sus datos son tratados de forma automatizada y a tener una copia de los mismos. En el caso de que stos sean inexactos o se hubiesen conseguido de forma ilegal tiene derecho a que sean corregidos o destruidos. Principio de publicidad (art. 38). Es preciso que exista un fichero pblico en el que figuren los diseos de los ficheros de datos de carcter personal, tanto los de titularidad pblica como privada.

Como rgano garante de estos derechos en la Ley figura la Agencia de Proteccin de Datos, ente de derecho pblico con personalidad jurdica propia y plena capacidad pblica y privada que acta con plena independencia de las Administraciones Pblicas.

La Proteccin Jurdica de los programas de Computacin Un programa de computacin es un de bien inmaterial. Un bien inmaterial es: Fruto o creacin de la mente. Para que se haga perceptible para el mundo exterior es necesario plasmarlo en un soporte. Puede ser disfrutado simultneamente por una pluralidad de personas. La proteccin de los programas de computacin est regulada en el Texto Refundido de la Ley de la Propiedad Intelectual (a partir de ahora TRPI) El artculo 10 del TRPL al referirse al objeto de la propiedad intelectual dice: "Son objeto de propiedad intelectual todas las creaciones originales literarias, artsticas o cientficas expresadas por cualquier medio o soporte tangible o intangible, actualmente conocido o que se invente en el futuro". y al enumerar las obras comprendidas incluye entre ellas los programas de computacin. El TRPI regula la proteccin de los programas de computacin en el Ttulo VII del Libro 1 (arts. 95 a 104). El autor por el solo hecho de crear una obra tiene una serie de derechos que se dividen en: morales y patrimoniales o de explotacin. Los derechos morales, enumerados en el artculo 14, son irrenunciables e inalienables. Por contra los derechos patrimoniales o de explotacin pueden ser transferidos libremente.(art. 17) A la titularidad de los derechos sobre los programas de computacin dedica el TRPI el artculo 97: 1. Ser considerado autor del programa de computacin la persona o grupo de personas naturales que lo hayan creado, o la persona jurdica que sea contemplada como titular de los derechos de autor en los casos expresamente previstos por esta ley. 2. Cuando se trate de una obra colectiva tendr la consideracin de autor, salvo pacto en contrario, la persona natural o jurdica que la edite o divulgue bajo su nombre. 3. Los derechos de autor sobre un programa de computacin que sea resultado unitario de la colaboracin entre varios autores sern propiedad comn y correspondern a todos stos en la proporcin que determinen. 4. Cuando un trabajador asalariado cree un programa de computacin, en el ejercicio de las funciones que le han sido confiadas o siguiendo las instrucciones de su empresario, la titularidad de los derechos de explotacin correspondientes al programa de computacin as creado, tanto el programa fuente como el programa objeto, correspondern, exclusivamente, al empresario, salvo pacto en contrario. Cuando exista una relacin mercantil se estar a lo pactado en el contrato. La inscripcin de un programa de computacin en el Registro de la Propiedad Intelectual no es constitutiva de derechos sino simplemente declarativa de los derechos de propiedad intelectual sobre aqul, no constituyendo una prueba indestructible sobre la titularidad de una obra determinada, sino que constituye una nueva presuncin de dicha titularidad. Las infracciones del derecho de autor pueden ser perseguidas por la va civil y la va penal. El artculo 102 est referido a la infraccin de los derechos respecto a los programas de computacin:

a) Quienes pongan en circulacin una o ms copias de un programa de computacin conociendo o pudiendo presumir su naturaleza ilegtima. b) Quienes tengan con fines comerciales una o ms copias de un programa de computacin, conociendo o pudiendo presumir su naturaleza ilegtima. c) Quienes pongan en circulacin o tengan con fines comerciales cualquier instrumento cuyo nico uso sea facilitar la supresin o neutralizacin no autorizadas de cualquier dispositivo tcnico utilizado para proteger un programa de computacin. En la va penal las infracciones del derecho estn tipificadas en los artculos 270, 271 y 272 del Cdigo Penal pudiendo llegar las penas de prisin a cuatro aos y las multas a veinticuatro meses para los casos ms graves.

Las Base de Datos y la Multimedia Una base de datos se compone de un contenido y de una estructura de ese contenido. El contenido de una base de datos puede ser: textos, grficos, sonidos, imgenes fijas e imgenes en movimiento. En lenguaje informtico a esto se le suele denominar media. En un principio en una base de datos participan: el creador o promotor, el distribuidor y el usuario. Creador o promotor es toda aquella persona fsica o jurdica que partiendo de una idea selecciona, clasifica y ordena un determinado tipo de informacin creando una base de datos, la mantiene y la actualiza. Distribuidor es asimismo toda persona fsica o jurdica que comercializa el producto. Por ltimo, usuario es toda persona fsica o jurdica que utiliza y consulta la base. Entre creador o promotor y distribuidor existe una relacin contractual en la que el primero se compromete a la creacin, mantenimiento y actualizacin de la base y el segundo a su comercializacin, aunque en algn caso podra llegar a su distribucin gratuita. Los contratos entre el distribuidor y el usuario suelen ser de los denominados de adhesin, en los que el primero fija las condiciones y el segundo simplemente se adhiere a ellas. En definitiva lo que se protege en una base de datos no es simplemente el almacenamiento de obras, su ordenacin y recuperacin sino que es todo el procedimiento de creacin y el resultado final de la misma, en cuanto a su contenido, anlisis, almacenamiento, clasificacin, seleccin y ordenacin que caracteriza a la base de datos en s. Como hemos dicho anteriormente, en lenguaje informtico se denomina media a las diferentes clases de archivos que se pueden utilizar en un sistema, estos pueden ser: a) Archivos de textos. Estos contienen la descripcin numrica de la informacin redactada mediante signos alfanumricos. b) Archivos grficos. Contienen la descripcin numrica de un diseo. c) Archivos de sonidos. Contienen la descripcin numrica de una onda sonora. d) Archivos de imgenes fijas. Contienen la descripcin numrica de una imagen formada por pxeles ordenados en columnas y filas. e) Archivos de imgenes en movimiento. Contienen la descripcin numrica de imgenes en movimiento y se llaman corrientemente vdeos. Multimedia se puede definir como la combinacin de todo tipo de seales de voz, datos, imgenes y escritura. Es un concepto global que abarcar una gran diversidad de servicios. Las obras multimedia suelen ser producto de un equipo, se trata de obras colectivas y su titularidad suele tenerla una persona jurdica. En gran nmero de casos una obra multimedia ser una obra derivada, pues se trabajar sobre una obra ya existente de la que se debern tener los derechos correspondientes salvo que se trate de obras de dominio pblico.

Auditora de Proyectos El nivel de competencia que existe, hoy en da, entre las empresas les obliga a tomar decisiones rpidas y acertadas. Es necesario, para ello, el funcionamiento adecuado de los sistemas informticos (mediante la incorporacin de las nuevas tecnologas) y su continua actualizacin. De esta forma, es decir, combinando esas tecnologas con una adecuada organizacin y una gestin eficiente, las empresas podrn alcanzar sus objetivos de manera satisfactoria. En este artculo se pretende elaborar el esquema de un procedimiento (Ver Figura) para llevar a cabo las auditoras de la explotacin de los sistemas de informacin.

Inicio

Contrato o Carta de encargo

Planificacin

Planificacin Estratgica: Estudio y evaluacin de riesgos Establecimiento de objetivo Planificacin detallada: Enfoque de auditora Establecimiento de procedimientos

Ejecucin de procedimientos Ejecucin Pruebas de cumplimiento Pruebas sustantivas

Revisin del Trabajo Conclusin Elaboracin de Informes Distribucin de Informes

Fin

Archivo de papeles de trabajo

Para hacer el seguimiento y comprobar que el sistema de informacin est actuando como es preceptivo, ste habr de disponer de un control interno que prevenga los eventos no deseados o en su defecto los detecte y los corrija. Es conveniente recordar que el resultado de la auditora parcial de un sistema de informacin no se puede extrapolar al conjunto del sistema. El funcionamiento inadecuado de alguno (o algunos) de los procesos y recursos que intervienen en otras partes del sistema (subsistemas) puede invalidar el sistema de informacin.

Importancia de la Auditora del Desarrollo Aunque cualquier departamento o rea de una organizacin es susceptible de ser auditado, hay una sede de circunstancias que hacen especialmente importante al rea de desarrollo, y por tanto tambin su auditora, frente a otras funciones o reas dentro del departamento de informtica: Los avances en tecnologas de los computadores han hecho que actualmente el desafo ms importante y el principal factor de xito de la informtica sea la mejora de la calidad del software.

 El gasto destinado a software es cada vez superior al que se dedica a hardware. A pesar de la juventud de la ciencia informtica, hace aos que se produjo la denominada crisis del software. Incluye problemas asociados con el desarrollo y mantenimiento del software y afecta a un gran nmero de organizaciones. En el rea del hardware no se ha dado una crisis equivalente. El software como producto es muy difcil de validar. Un mayor control en el proceso de desarrollo incrementa la calidad del mismo y disminuye los costes de mantenimiento. El ndice de fracasos en proyectos de desarrollo es demasiado alto, lo cual de nota la inexistencia o mal funcionamiento de los controles en este proceso. Las aplicaciones informticas, que son el producto principal obtenido al final del desarrollo, pasan a ser la herramienta de trabajo principal de las reas informatizadas, convinindose en un factor esencial para la gestin y la toma de decisiones.

Para tratar la auditora del rea de desarrollo es necesario, en primer lugar, acotar las funciones o tareas que son responsabilidad del rea. Teniendo en cuenta que puede haber variaciones de una organizacin a otra, las funciones que tradicionalmente se asignan al rea de desarrollo son: Planificacin del rea y participacin, en la medida que corresponda, en la elaboracin del plan estratgico de informtica. Desarrollo de nuevos sistemas. Esta es la funcin principal y la que da sentido al rea de desarrollo. Incluir para cada uno de los sistemas, el anlisis, diseo, construccin e implantacin. El mantenimiento se supondr funcin de otra rea. Estudio de nuevos lenguajes, tcnicas, metodologas, estndares, herramientas, etc, relacionados con el desarrollo y adopcin de los mismos cuando se considere oportuno para mantener un nivel de vigencia adecuado a la tecnologa del momento. Establecimiento de un plan de formacin para el personal adscrito al rea. Establecimiento de normas y controles para todas las actividades que se realizan en el rea y comprobacin de su observancia. Una vez fijados los objetivos de control, ser funcin del auditor determinar el grado de cumplimiento de cada uno de ellos. Para cada objetivo se estudiarn todos los controles asociados al mismo, usando para ello las pruebas de cumplimiento propuestas. Con cada prueba de cumplimiento se obtendr alguna evidencia, bien sea directa o indirecta, sobre la correccin de los controles. Si una simple comprobacin no ofrece ninguna evidencia, ser necesaria la realizacin de exmenes ms profundos. En los controles en los que sea impracticable una revisin exhaustiva de los elementos de verificacin, bien porque los recursos de auditora sean limitados o porque el nmero de elementos a inspeccionar sea muy elevado, se examinar una muestra representativa que permita inferir el estado de todo el conjunto. El estudio global de todas las conclusiones, pruebas y evidencias obtenidas sobre cada control permitirn al auditor obtener el nivel de satisfaccin de cada objetivo de control, as como cules son los puntos fuertes y dbiles del mismo. Con esta informacin, y teniendo en cuenta las particularidades de la organizacin en estudio, se determinar cules son los riesgos no cubiertos, en qu medida lo son y qu consecuencias se pueden derivar de esa situacin. Estas conclusiones, junto con las recomendaciones formuladas, sern las que se plasmen en el informe de auditora.

A continuacin se agrupan los distintos objetivos de control: Organizacin y gestin del rea de desarrollo Proyectos de desarrollo de sistemas de informacin: o Aprobacin, planificacin y gestin del proyecto o Anlisis Anlisis de requisitos Especificacin funcional o Diseo Diseo tcnico o Construccin Desarrollo de componentes Desarrollo de procedimientos de usuario o Implantacin Pruebas, implantacin y aceptacin o Mantenimiento

Auditora de la Organizacin y Gestin del rea de Desarrollo Aunque cada proyecto de desarrollo tenga entidad propia y se gestione con cierta autonoma, para poderse llevar a efecto necesita apoyarse en el personal del rea y en los procedimientos establecidos. La importancia de estos aspectos ha motivado que se dedique un apartado exclusivo a la organizacin y gestin del rea de desarrollo. Se consideran ocho objetivos de control: 1. El rea de desarrollo debe tener unos cometidos asignados dentro del departamento y una organizacin que le permita el cumplimiento de los mismos. 2. El personal del rea de desarrollo debe contar con la formacin adecuada y estar motivado para la realizacin de su trabajo. 3. Si existe un plan de sistemas, los proyectos que se lleven a cabo se basarn en dicho plan y lo mantendrn actualizado. 4. La propuesta y aprobacin de nuevos proyectos debe realizarse de forma reglada. 5. La asignacin de recursos a los proyectos debe hacerse de forma reglada. 6. El desarrollo de sistemas de informacin debe hacerse aplicando principios de ingeniera del software ampliamente aceptados. 7. Las relaciones con el exterior del departamento tienen que producirse de acuerdo a un procedimiento. 8. La organizacin del rea debe estar siempre adaptada a las necesidades de cada momento,

Auditora de Proyectos de Desarrollo de SI Cada desarrollo de un nuevo sistema de informacin ser un proyecto con entidad propia. El proyecto tendr unos objetivos marcados y afectar a determinadas unidades de la organizacin. Debe tener un responsable y ser gestionado con tcnicas que permitan conseguir los objetivos marcados, teniendo en cuenta los recursos disponibles y las restricciones temporales del mismo. La auditora de cada proyecto de desarrollo tendr un plan distinto dependiendo de los riesgos, la complejidad del mismo y los recursos disponibles para realizar la auditora. Esto obliga a que sean la pericia y experiencia del auditor las que determinen las actividades del proyecto que se controlarn con mayor intensidad en funcin de los parmetros anteriores. A continuacin se definirn objetivos y tcnicas de control generales aplicables a cualquier proyecto. El auditor decidir los objetivos ms importantes en funcin de las caractersticas del proyecto y de la fase a auditar.

Aunque los objetivos de control se han catalogado en funcin de la fase del proyecto a la que se aplican, la auditora de un proyecto de desarrollo se puede hacer en dos momentos distintos: a medida que avanza el proyecto, o una vez concluido el mismo. Las tcnicas a utilizar y los elementos a inspeccionar, normalmente los productos y documentos generados en cada fase del desarrollo, sern los mismos en ambos casos. La nica diferencia es que en el primer caso las conclusiones que vaya aportando el auditor pueden afectar al desarrollo del proyecto, aunque nunca participar en la toma de decisiones del mismo.

Aprobacin, planificacin y gestin del proyecto Objetivo del control: El proyecto de desarrollo debe estar aprobado, definido y planificado formalmente. El proyecto se debe gestionar de forma que se consigan los mejores resultados posibles teniendo en cuenta las restricciones de tiempo y recursos. Controles: Debe existir una orden de aprobacin del proyecto que defina claramente los objetivos, restricciones y las unidades afectadas. Se debe comprobar que: o Existe una orden de aprobacin del proyecto refrendada por un rgano competente. El estudio de viabilidad debe haber seguido el cauce establecido. o En el documento de aprobacin estn definidos de forma clara y precisa los objetivos del mismo y las restricciones de todo tipo que deben tenerse en cuenta (temporales, recursos tcnicos, recursos humanos, presupuesto, etc.). o Se han identificado las unidades de la organizacin a las que afecta. Debe designarse un responsable o director del proyecto. Se debe comprobar que: o La designacin se ha llevado a cabo segn el procedimiento establecido. o Se le ha comunicado al director su nombramiento junto con toda la informacin relevante del proyecto. El proyecto debe ser catalogado y, en funcin de sus caractersticas, se debe determinar el modelo de ciclo de vida que seguir. Se debe comprobar que: o Se ha catalogado y dimensionado el proyecto segn las normas establecidas. o Se han evaluado los riesgos asociados al proyecto, especialmente cuando se van a usar tecnologas no usadas hasta el momento. o Se ha elegido el ciclo de vida ms adecuado al tipo de proyecto de que se trata. o Se ha hecho uso de la informacin histrica que se dispone tanto para dimensionar el proyecto y sus riesgos como para seleccionar el ciclo de vida. Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo tcnico que realizar el proyecto y se determinar el plan del proyecto. Se debe comprobar que: o La designacin del director del proyecto y del equipo de desarrollo se ha llevado a cabo segn el procedimiento establecido. o Los participantes que pertenezcan a otras reas (sistemas, comunicaciones, ofimtica, etc.) se han solicitado segn el protocolo existente. o Si participa personal externo, los perfiles profesionales son adecuados a las funciones que van a realizar. El contrato cumple el protocolo de contratacin. o Se ha comunicado a todos los miembros del equipo de desarrollo los objetivos del proyecto, la responsabilidad que tendrn en el mismo, las fechas en lasque participarn y la dedicacin (completa/parcial). o El plan de proyecto realizado es realista y utiliza la informacin histrica de la que se disponga para realizar estimaciones.

Los responsables de las unidades o reas afectadas por el proyecto deben participar en la gestin del proyecto. Se debe comprobar que: o Se ha constituido formalmente el comit de direccin del proyecto y en l estn incluidos los responsables de todas las unidades afectadas. o El comit tiene una periodicidad de reunin mnima, y en cualquier caso siempre que lo exija el desarrollo del proyecto, debe tener competencia para la asignacin de recursos, la revisin de la marcha del proyecto y para modificar el plan del proyecto en funcin de las revisiones. o Las reuniones se hacen con un orden del da previo y las decisiones tomadas quedan documentadas en las actas de dicho comit. o El nmero de reuniones y la duracin de las mismas no superan un lmite razonable comparado con la envergadura del proyecto. Se debe establecer un mecanismo para la resolucin de los problemas que puedan plantearse a lo largo del proyecto. Se debe comprobar que: o Existen hojas de registro de problemas y que hay alguna persona del proyecto encargada de su recepcin, as como un procedimiento conocido de tramitacin. o Hay un mtodo para catalogar y dar prioridad a los problemas, as como para trasladarlos a la persona que los debe resolver, informando si es necesario al director del proyecto y al comit de direccin. o Se controla la solucin del problema y se deja constancia de la misma. Debe existir un control de cambios a lo largo del proyecto. Se debe comprobar que: o Existe un mecanismo para registrar los cambios que pudieran producirse, as como para evaluar el impacto de los mismos. o La documentacin afectada se actualiza de forma adecuada y se lleva un control de versiones de cada producto, consignando la ltima fecha de actualizacin. o Se remite la nueva versin de los documentos actualizados a los participantes en el proyecto. Cuando sea necesario reajustar el plan del proyecto, normalmente al finalizar un mdulo o fase, debe hacerse de forma adecuada. Se debe comprobar que: o Se respetan los lmites temporales y presupuestarios marcados al inicio del proyecto. Si no es as debe ser aprobado por el comit de direccin. o Se han tenido en cuenta los riesgos del reajuste. o Se ha hecho uso de la informacin histrica que se dispone en el rea sobre estimaciones. o Se notifica el cambio a todas las personas que de una u otra forma participen en el proyecto y se vean afectados. o Si existe un plan de sistemas, se actualizar en consecuencia. Debe hacerse un seguimiento de los tiempos empleados tanto por tarea como a lo largo del proyecto. Se debe comprobar que: o Existe un procedimiento que permita registrar los tiempos que cada participante del proyecto dedica al mismo y qu tarea realiza en ese tiempo. o Las productividades que se obtienen para distintos empleados en las mismas tareas son similares y estn en consonancia con la informacin histrica. Se debe controlar que se siguen las etapas del ciclo de vida adoptado para el proyecto y que se generan todos los documentos asociados a la metodologa usada. Se debe comprobar que: o Antes de comenzar una nueva etapa se ha documentado la etapa previa y se ha revisado y aceptado, especialmente en las fases de anlisis y diseo. o La documentacin cumple los estndares establecidos en el rea. o Se respeta el plan establecido y en caso contrario se toman las medidas oportunas o se procede a la aprobacin de una modificacin del plan. o Se respeta el uso de recursos previamente establecido.

Cuando termina el proyecto se debe cerrar toda la documentacin del mismo, liberar los recursos empleados y hacer balance. Se debe comprobar que: o La documentacin del proyecto es completa y est catalogada perfectamente para accesos posteriores. o Los recursos, tanto personales como materiales, se ponen a disposicin del rea o departamento del que provienen. o El comit de direccin y el director del proyecto hacen balance del proyecto, estudiando los posibles problemas y sus causas, los cambios de plan, etc. Toda esta informacin se registra en los archivos histricos sobre estimaciones y problemas. o La nueva aplicacin se incorpora al catlogo de aplicaciones existentes con toda la informacin relevante de la misma.

Auditora de la fase de anlisis La fase de anlisis pretende obtener un conjunto de especificaciones formales que describan las necesidades de informacin que deben ser cubiertas por el nuevo sistema de una forma independiente del entorno tcnico. Esta fase se divide en dos mdulos: Anlisis de Requisitos del Sistema (ARS) En este mdulo se identificarn los requisitos del nuevo sistema. Se incluirn tanto los requisitos funcionales como los no funcionales, distinguiendo para cada uno de ellos su importancia y prioridad. A partir del conocimiento del sistema actual y sus problemas asociados, junto con los requisitos que se exigirn al nuevo sistema, se determinarn las posibles soluciones alternativas que satisfagan esos requisitos y de entre ellas se elegir la ms adecuada. Se consideran dos objetivos de control: Los usuarios y responsables de las unidades a las que afecta el nuevo sistema establecern de forma clara los requisitos del mismo. En el proyecto de desarrollo se utilizar la alternativa ms favorable para conseguir que el sistema cumpla los requisitos establecidos. Controles: En el proyecto deben participar usuarios de todas las unidades a las que afecte el nuevo sistema. Esta participacin, que se har normalmente a travs de entrevistas, tendr especial importancia en la definicin de requisitos del sistema. Se debe comprobar que: o Existe un documento aprobado por el comit de direccin en el que se determina formalmente el grupo de usuarios que participar en el proyecto. o Los usuarios elegidos son suficientemente representativos de las distintas funciones que se llevan a cabo en las unidades afectadas por el nuevo sistema. o Se les ha comunicado a los usuarios su participacin en el proyecto, informndoles del mbito del mismo y de qu es lo que se espera de ellos, as como la dedicacin estimada que les supondr esta tarea. Se debe realizar un plan detallado de entrevistas con el grupo de usuarios del proyecto y con los responsables de las unidades afectadas que permita conocer cmo valoran el sistema actual y lo que esperan del nuevo sistema. Se debe comprobar que: o Existe un plan consensuado con el comit de direccin que detalla para cada entrevista la fecha, hora y lugar, tipo de entrevista (individual, en grupo, por escrito, etc.) y un guin de los aspectos que en ella se tratarn. o Se entrevista a todos los integrantes en el grupo de usuarios y a todos los responsables de las unidades afectadas. o Se remite el guin a los entrevistados con tiempo suficiente para que stos puedan preparar la entrevista y la documentacin que deseen aportar a la misma. o El guin incluye todas las cuestiones necesarias para obtener informacin sobre las funciones que el entrevistado realiza en su unidad y los problemas que necesita resolver.

Una vez documentadas las entrevistas, se contrastan las conclusiones de las mismas con los entrevistados.

A partir de la informacin obtenida en las entrevistas, se debe documentar el sistema actual as como los problemas asociados al mismo. Se debe obtener tambin un catlogo con los requisitos del nuevo sistema. Se debe comprobar que: o Se ha realizado un modelo fsico del sistema actual, incluyendo los objetivos y funciones de cada unidad, as como sus flujos de entrada y salida de informacin. o Se han catalogado los problemas del sistema actual as como que estos problemas son reales. o Se han realizado el modelo lgico de datos y el modelo lgico de procesos del sistema actual, as como que stos son correctos y que se han llevado a cabo con las tcnicas usadas en el rea. o Existe el catlogo de requisitos que estn justificados. o Los requisitos son concretos y cuantificables, de forma que pueda determinar se el grado de cumplimiento al final del proyecto. o Cada requisito tiene una prioridad y est clasificado en funcional o no funcional. o El catlogo de requisitos ha sido revisado y aprobado por el grupo de usuarios y por el comit de direccin, constituyendo a partir de este momento el contrato entre stos y el equipo que desarrolla el proyecto. Debe existir un procedimiento formal para registrar cambios en los requisitos del sistema por parte de los usuarios. Se debe comprobar que: o El procedimiento existe y est aprobado. o Es coherente con el procedimiento de control del cambio general para el proyecto. Dados los requisitos del nuevo sistema se deben definir las diferentes alternativas de construccin con sus ventajas e inconvenientes. Se evaluarn las alternativas y se seleccionar la ms adecuada. Se debe comprobar que: o Existe un documento en el que se describen as distintas alternativas. o Hay ms de una alternativa, y en caso contrario, que no existe realmente otra posible. o Cada alternativa est descrita desde un punto de vista lgico (al menos modelo lgico de procesos) y es coherente con los requisitos establecidos. o Si existe en el mercado algn producto que cumpla con unas mnimas garantas los requisitos especificados, una de las alternativas debe ser su compra. o Si no lo impiden las caractersticas del proyecto una de las alternativas debe ser el desarrollo del sistema por parte de una empresa externa. o Se han evaluado las ventajas e inconvenientes de cada alternativa de forma objetiva (anlisis coste/beneficio por ejemplo), as como los riesgos asociados. o El comit de direccin ha seleccionado una alternativa como la ms ventajosa y es realmente la mejor para la organizacin.

Especificacin Funcional del Sistema (EFS) Una vez conocido el sistema actual, los requisitos del nuevo sistema y la alternativa de desarrollo ms favorable, se elaborar una especificacin funcional detallada del sistema que sea coherente con lo que se espera de l. La participacin de usuarios en este mdulo y la realizacin de entrevistas siguen las pautas ya especificadas en el anlisis de requisitos del sistema, por lo que se pasa por alto la comprobacin de estos aspectos. El grupo de usuarios y los responsables de las unidades afectadas deben ser la principal fuente de informacin. Se considera un nico objetivo de control: El nuevo sistema debe especificarse de forma completa desde el punto de vista funcional, contando esta especificacin con la aprobacin de los usuarios.

Controles: Se debe realizar un modelo lgico del nuevo sistema, incluyendo Modelo Lgico de Procesos (MLP) y Modelo Lgico de Datos (MLD). Ambos deben ser consolidados para garantizar su coherencia. Se debe comprobar que: o Se ha partido de los modelos realizados en el anlisis de requisitos del sistema. o Existe el MLP, se ha realizado con la tcnica adecuada y es correcto tcnicamente. Describir qu debe realizar el sistema sin entrar en la forma en que lo har. Los procesos manuales deben estar diferenciados. Los usuarios deben entender las convenciones de smbolos usadas. o La captura de los requerimientos estn reflejados todos los agentes externos, incluidos otros sistemas con los que el sistema intercambia informacin. Para cada flujo de datos de entrada o de salida debe estar documentado el contenido, la frecuencia, suceso que lo origina, etc. o Existe el MLD, se ha realizado con la tcnica adecuada y es correcto tcnicamente. o En el MLD estn reflejadas todas las estructuras de datos, as como las relaciones entre las mismas. o El MLP y el MLD son coherentes entre s. o El MLP y el MLD han sido aprobados por los usuarios y por el comit de direccin. Debe existir el diccionario de datos o repositorio. Se debe comprobar que: o Existe el diccionario de datos, es correcto y se gestiona de forma automatizada. o Se respetan en su gestin todos los procedimientos de control de cambios. Debe definirse la forma en que el nuevo sistema interactuar con los distintos usuarios. Esta es la parte ms importante para el usuario porque definir su forma de trabajo con el sistema. Se debe comprobar que: o Se han descrito con suficiente detalle las pantallas a travs de las cuales el usuario navegar por la aplicacin, incluyendo todos los campos significativos, teclas de funcin disponibles, mens, botones, etc. Si hay normas de diseo o estilo de pantallas en el rea, se verificar que se respetan. o Se han descrito con suficiente detalle los informes que se obtendrn del sistema y los formularios asociados, si stos existen. Si hay normas de diseo o estilo de informes y formularios en el rea, se verificar que se respetan. o La interfaz de usuario se ha aprobado por el grupo de usuarios y por el comit de direccin. La especificacin del nuevo sistema incluir los requisitos de seguridad, rendimiento, copias de seguridad y recuperacin, etc. Se debe comprobar que: o Esta informacin se ha solicitado a los usuarios en las entrevistas correspondientes a este mdulo y se ha documentado y contrastado. o Se han aadido estos requisitos al catlogo de requisitos ya realizado en el ARS. Se deben especificar las pruebas que el nuevo sistema debe superar para ser aceptado. Se debe comprobar que: o Se ha elaborado el plan de pruebas de aceptacin del sistema, que ste es coherente con el catlogo de requisitos y con la especificacin funcional del sistema y que es aceptado por el grupo de usuarios y por el comit de direccin. o El plan de pruebas de aceptacin tiene en cuenta todos los recursos necesarios.

Auditora de la fase de diseo En la fase de diseo se elaborar el conjunto de especificaciones fsicas del nuevo sistema que servirn de base para la construccin del mismo. Hay un nico mdulo: Diseo Tcnico del Sistema (DTS) A partir de las especificaciones funcionales, y teniendo en cuenta el entorno tecnolgico, se disear la arquitectura del sistema y el esquema externo de datos. Se considera un nico objetivo de control:

Se debe definir una arquitectura fsica para el sistema coherente con la especificacin funcional que se tenga y con el entorno tecnolgico elegido.

Controles: El entorno tecnolgico debe estar definido de forma clara y ser conforme a los estndares del departamento de informtica. Se debe comprobar que: o Estn perfectamente definidos todos los elementos que configuran el entorno tecnolgico para el proyecto (servidores, ordenadores personales, perifricos, sistemas operativos, conexiones de red, protocolos de comunicacin, sistemas gestores de bases de datos, compiladores, herramientas CASE, cliente/servidor, libreras, etc.). o Se dispone de los elementos seleccionados, estn dentro de los estndares del departamento de informtica y son capaces de responder a los requisitos establecidos de volmenes, tiempos de respuesta, seguridad, etc. Se deben identificar todas las actividades fsicas a realizar por el sistema y descomponer las mismas de forma modular. Se debe comprobar que: o Se han documentado todas las actividades fsicas que debe realizar el sistema. o El catlogo de actividades es coherente con las funciones identificadas en el MLP del mdulo EFS. o Se han identificado las actividades que son comunes, as como las que ya existan en las libreras generales del rea. o Existe el documento con el diseo de la estructura modular del sistema, se ha realizado con una tcnica adecuada y es correcto. o El tamao de los mdulos es adecuado, el factor de acoplamiento entre ellos es mnimo y la cohesin interna de cada mdulo es mxima. o Los mdulos se disean para poder ser usados por otras aplicaciones si fuera necesario. o Los componentes o programas del nuevo sistema se han definido con detalle a partir del diseo modular, la definicin es correcta y sigue los estndares del rea. La descripcin de los componentes es suficiente para permitir su programacin por parte de un programador sin conocimiento previo del sistema. o Se deben especificar los requisitos de operacin de los componentes. o Se han detallado las interfaces de datos y control con otros mdulos y sistemas, as como la interfaz de usuario ya especificada en el mdulo EFS. Se debe disear la estructura fsica de datos adaptando las especificaciones del sistema al entorno tecnolgico. Se debe comprobar que: o El modelo fsico de datos est basado en el MLD obtenido en el mdulo EFS e incluye todas las entidades, relaciones, claves, vistas, etc. o Tiene en cuenta el entorno tecnolgico y los requisitos de rendimiento para los volmenes y frecuencias de acceso estimados. Se debe disear un plan de pruebas que permita la verificacin de los distintos componentes del sistema por separado, as como el funcionamiento de los distintos subsistemas y del sistema en conjunto. Se debe comprobar que: o Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto. o Las personas que realizarn las pruebas de verificacin son distintas a las que han desarrollado el sistema. o Es adecuado para validar cada uno de los componentes del sistema, incluyen do pruebas del tipo caja blanca para cada mdulo, Tendrn en cuenta todas las posibles condiciones lgicas de ejecucin, adems de posibles fallos del hardware o software de base. o Permite validar la integracin de los distintos componentes y el sistema en conjunto.

Auditora de la Fase de Construccin En esta fase se programarn y probarn los distintos componentes y se pondrn en marcha todos los procedimientos necesarios para que los usuarios puedan trabajar con el nuevo sistema. Estar basado en las especificaciones fsicas obtenidas en la fase de diseo. Hay dos mdulos.

Desarrollo de los Componentes del Sistema (DCS) En este mdulo se realizarn los distintos componentes, se probarn tanto individualmente como de forma integrada, y se desarrollarn los procedimientos de operacin. Se considera un nico objetivo de control: Los componentes o mdulos deben desarrollar se usando tcnicas de programacin correctas. Controles: Se debe preparar adecuadamente el entorno de desarrollo y de pruebas, as como los procedimientos de operacin, antes de iniciar el desarrollo. Se debe comprobar que: o Se han creado e inicializado las bases de datos o ficheros necesarios y que cumplen las especificaciones realizadas en el mdulo de diseo. o En ningn momento se trabaja con informacin que se encuentra en explotacin. o Se han preparado los procedimientos de copia de seguridad. o Se han preparado los editores, compiladores, herramientas, etc. necesarios. o Estn disponibles los puestos de trabajo y el acceso a los equipos, redes, etc. o Estn disponibles todos los elementos lgicos y fsicos para realizar las pruebas unitarias de los componentes y las pruebas de integracin. o Estn documentados todos los procedimientos de operacin para cuando el sistema est en explotacin. Se debe programar, probar y documentar cada uno de los componentes identificados en el diseo del sistema. Se debe comprobar que: o Se han desarrollado todos los componentes o mdulos. o Se han seguido los estndares de programacin y documentacin del rea, el cdigo es estructurado, est bien sangrado y contiene comentarios suficientes. o Se ha probado cada componente y se ha generado el informe de prueba. Si los resultados de las pruebas no son satisfactorios, se modifica el cdigo y se vuelve a realizar la prueba. Si se detecta un fallo de especificacin o diseo, el proyecto se actualizar segn el procedimiento establecido para ello. Deben realizarse las pruebas de integracin para asegurar que las interfaces entre los componentes o mdulos funcionan correctamente. Se debe comprobar que: o Las pruebas de integracin se han llevado a cabo segn lo especificado en el plan de pruebas realizado en el mdulo de diseo. o Se han evaluado las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. o No han participado los usuarios. En las pruebas de integracin slo debe participar el equipo de desarrollo.

Desarrollo de los Procedimientos de Usuario (DPU) En este mdulo se definen los procedimientos y formacin necesarios para que los usuarios puedan utilizar el nuevo sistema adecuadamente. Fundamentalmente se trata de la instalacin, la conversin de datos y la operacin/explotacin. Se considera un nico objetivo de control: Al trmino del proyecto, los futuros usuarios deben estar capacitados y disponer de todos tos medios para hacer uso del sistema. Controles: El desarrollo de los componentes de usuario debe estar planificado. Se debe comprobar que: o En el plan del proyecto est incluido el plan para el desarrollo de los procedimientos de usuario e incluye todas las actividades y recursos necesarios. o Los procedimientos se llevan a cabo despus de tener la especificacin funcional del sistema y antes de la implantacin del mismo.

Se deben especificar los perfiles de usuario requeridos para el nuevo sistema. Se debe comprobar que: o Estn definidos los distintos perfiles de usuario requeridos para la implantacin y explotacin del nuevo sistema. o Para cada perfil se ha definido el rango de fechas y la dedicacin necesaria. Se deben desarrollar todos los procedimientos de usuario con arreglo a los estndares del rea. Se debe comprobar que: o Estn desarrollados todos los procedimientos de usuario, recopilados formando el manual de usuario, y son coherentes con las actividades descritas en EFS. o Cada procedimiento describe claramente qu realiza, el perfil de usuario asociado, as como los recursos que son necesarios (equipos, consumibles, perifricos especiales, espacio, etc.). o Los manuales de usuario y el resto de procedimientos cumplen los estndares del rea y llevan asociado su control de versiones. A partir de los perfiles actuales de los usuarios, se deben definir los procesos de formacin o seleccin de personal necesarios. Se debe comprobar que: o La comparacin de perfiles de usuarios y recursos requeridos con los actuales es realista y los procedimientos que se derivan son adecuados y estn aprobados por los responsables de las unidades afectadas. o Los procedimientos de formacin estn individualizados y se adaptan a cada persona, y se le ha comunicado a cada usuario el plan de formacin que seguir. o Se han definido y preparado los recursos necesarios para impartir la formacin (aulas, medios audiovisuales, material para los asistentes, tutoriales, etc.). Se deben definir los recursos materiales necesarios para el trabajo de los usuarios con el nuevo sistema. Se debe comprobar que: o Se han determinado los recursos necesarios para cada usuario (consumibles, perifricos especiales, espacio, etc.). o Se han comparado con los recursos existentes y se ha planificado el alquiler, leasing, adquisicin, etc. de los recursos no disponibles dentro de plazo.

Auditora de la fase de Implantacin En esta fase se realizar la aceptacin del sistema por parte de los usuarios, adems de las actividades necesarias para la puesta en marcha. Hay un nico mdulo:

Pruebas, Implantacin y Aceptacin del Sistema Se verificar en este mdulo que el sistema cumple con los requisitos establecidos en la fase de anlisis. Una vez probado y aceptado se pondr en explotacin. Se consideran dos objetivos de control: El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en explotacin. El sistema se pondr en explotacin formalmente y pasar a estar en mantenimiento slo cuando haya sido aceptado y est preparado todo el entorno en el que se ejecutar. Controles: Se deben realizar las pruebas del sistema que se especificaron en el diseo del mismo. Se debe comprobar que: o Se prepara el entorno y los recursos necesarios para realizar las pruebas. o Las pruebas se realizan y permiten verificar si el sistema cumple las especificaciones funcionales y si interacta correctamente con el entorno, incluyendo interfaces con otros programas, recuperacin ante fallos, copias de seguridad, tiempos de respuesta, etc. o Se han evaluado los resultados de las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia.

El plan de implantacin y aceptacin se debe revisar para adaptarlo a la situacin final del proyecto. Se debe comprobar que: o Se revisa el plan de implantacin original y se documenta adecuadamente. o Est incluida la instalacin de todos los componentes desarrollados, as como los elementos adicionales (libreras, utilidades, etc.). o Incluye la inicializacin de datos y la conversin si es necesaria. o Especifica los recursos necesarios para cada actividad, as como que el orden marcado para las actividades es compatible. o Se ha tenido en cuenta la informacin histrica sobre estimaciones. El sistema debe ser aceptado por los usuarios antes de ponerse en explotacin. Se debe comprobar que: o Se sigue el plan de pruebas de aceptacin aprobado en la fase de anlisis, que debe incluir la conversin de datos y la explotacin. o Las pruebas de aceptacin son realizadas por los usuarios. o Se evalan los resultados de las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. o El grupo de usuarios y el comit de direccin firman su conformidad con las pruebas de aceptacin. Se deben instalar todos los procedimientos de explotacin. Se debe comprobar que: o Se han instalado adems del sistema principal todos los procedimientos auxiliares, por ejemplo copias, recuperacin, etc., tanto manuales como automticos. o Estn documentados de forma correcta. o Los usuarios han recibido la formacin necesaria y tienen en su poder toda la documentacin necesaria, fundamentalmente manuales de usuario. o Se han eliminado procedimientos antiguos que sean incompatibles con el nuevo sistema. Si existe un sistema antiguo, el sistema nuevo se pondr en explotacin de forma coordinada con la retirada del antiguo, migrando los datos si es necesario. Se debe comprobar que: o Hay un perodo de funcionamiento en paralelo de los dos sistemas, hasta que el nuevo sistema est funcionando con todas las garantas. Esta situacin no debe prolongarse ms tiempo del necesario. o Si el sistema antiguo se va a mantener para obtener informacin se debe dejar en explotacin en modo de slo consulta. o Los datos se convierten de acuerdo al procedimiento desarrollado y se verifica la consistencia de la informacin entre el sistema nuevo y el antiguo. Debe firmarse el final de la implantacin por parte de los usuarios. Se debe comprobar que: o Existe el documento y que ha sido firmado por el comit de direccin y por el grupo de usuarios. o Contiene de forma explcita la aceptacin de la implantacin correcta del sistema. Se debe supervisar el trabajo de los usuarios con el nuevo sistema en las primeras semanas para evitar situaciones de abandono de uso del sistema. Se debe comprobar que: o El ndice de utilizacin del sistema es adecuado a los volmenes que se esperaban para cada una de las reas afectadas por el nuevo sistema. o Se ha comprobado, al menos informalmente, la impresin de los usuarios respecto al nuevo sistema.

Auditora del Mantenimiento Varios investigaciones y experiencias revelan que la etapa de mantenimiento consume la mayor parte de los recursos empleados en un proyecto software. Por tanto, esta etapa debe ser especialmente considerada en los estudios de productividad y de la Auditora Informtica. La mantenibilidad, factor crtico de estudio en Auditora Informtica del Mantenimiento, es el factor de calidad que engloba todas aquellas caractersticas del software, destinadas a hacer que el producto sea ms fcilmente mantenible y, en consecuencia, a conseguir una mayor productividad. Se considera un nico objetivos de control:

Mejorar la productividad y la calidad del sistema a travs del mantenimiento del mismo.

Controles: Para terminar el proyecto se pondr en marcha el mecanismo de mantenimiento. Se debe comprobar que: o El mecanismo existe y est aprobado por el director del proyecto, por el comit de direccin y por el rea de mantenimiento, si sta existiese. o Tiene en cuenta los tiempos de respuesta mximos que se pueden permitir ante situaciones de no funcionamiento. o El procedimiento a seguir ante cualquier problema o para el mantenimiento del sistema ser conocido por todos los usuarios. Incluir al menos la persona de contacto, telfono, esquema de la informacin a aportar, etc. o Debe existir plan de backup y resguardo, como as tambin planeamiento (general y contingencia).

Auditora de las Aplicaciones Como ya se expuso como debe auditarse un proyecto a continuacin nos centraremos en la fase final de la vida de la aplicacin informtica, la de su funcionamiento ordinario. As pues, el objeto consiste en tratar de ayudar a planificar, preparar y llevar a cabo auditoras de aplicaciones en funcionamiento en cuanto al grado de cumplimiento de los objetivos para los que las mismas fueron creadas. Una aplicacin informtica o sistema de informacin habitualmente persigue como finalidad: Registrar fielmente la informacin considerada de inters en tomo a las operaciones llevadas a cabo por una determinada organizacin: magnitudes fsicas o econmicas, fechas, descripciones, atributos o caractersticas, identificacin de las personas fsicas y/o jurdicas que intervienen o guardan relacin con cada operacin, nombres, direcciones, etc. Permitir la realizacin de cuantos procesos de clculo y edicin sean necesarios a partir de la informacin registrada, pudiendo por tanto almacenar automticamente ms informacin que la de partida, aunque siempre basada en aqulla. Facilitar, a quienes lo precisen, respuesta a consultas de todo tipo sobre la informacin almacenada, diseadas en contenido y forma para dar cobertura a las necesidades ms comunes constatadas. Generar informes que sirvan de ayuda para cualquier finalidad de inters en la organizacin, presentando la informacin adecuada: se aplican segn convenga criterios de seleccin, ordenacin, recuento y totalizacin por equipamientos, clculos de todo tipo, desde estadsticos comunes (media, desviacin tpica, valores mnimo, mximo, primero y ltimo, etc.), hasta los ms sofisticados algoritmos. Si este planteamiento se consigue trasladar con rigor a una aplicacin informtica y los usuarios la manejan con soltura y con profesionalidad, la organizacin a la que pertenecen contar con un importante factor de xito en el desarrollo de su actividad. Entre las amenazas al normal cumplimiento de la finalidad de nuestra aplicacin podemos mencionar: La posibilidad de fallo en cualquiera de los elementos que intervienen en el proceso informtico: software mltiple perteneciente a diferentes firmas, ordenador central y dispositivos perifricos, transmisin de datos (servidores, mdems, lneas de comunicaciones, etc.) constituye otra fuente de posibles riesgos. La conexin cada vez ms generalizada de las empresas a entornos abiertos como la Internet multiplica los riesgos que amenazan la confidencialidad e integridad de la informacin de nuestros sistemas. Y en este caso el nmero de interesados en descubrir debilidades que les abran las puertas para enredar y manipular la informacin a la que sean capaces de acceder no tiene lmites. Todas esas amenazas y cualquier otra que pueda ser identificada contra el correcto funcionamiento de nuestra aplicacin y la consecucin de sus objetivos, han debido ser objeto de un anlisis minucioso ya desde la fase de su concepcin. Para cada una de ellas se habrn debido estudiar las posibles medidas tendentes a eliminar los riesgos que entraan o, cuando menos, a reducir la probabilidad de su materializacin hasta niveles razonablemente asumibles, siempre teniendo en cuenta el costo de tales medidas (que no cuesten ms las cintas que el manto, segn el dicho popular). Dichas medidas son fundamentalmente medidas de control interno que, con carcter general, consisten en los procedimientos para verificar, evaluar y tratar de garantizar que todo funciona como se espera: de acuerdo con las polticas, directrices, normas y procedimientos establecidos en los diferentes mbitos de responsabilidad. En el terreno de una aplicacin informtica, el control interno se materializa fundamentalmente en controles de dos tipos: Controles manuales: a realizar normalmente por parte de personal del rea usuario: actuaciones previstas para asegurar que -en su caso- se preparan, autorizan y procesan todas las operaciones, se subsanan adecuadamente todos los errores, son coherentes los resultados de salida respecto a referencias disponibles sobre los datos de entrada, y las bases de datos que dan soporte a la aplicacin mantienen en los niveles debidos diferentes indicadores de medicin de su integridad y totalidad (nmero de registros en ficheros y/o tablas, de relaciones o ndices, totales de magnitudes numricas, conciliaciones, etc.).

Controles automticos: incorporados a los programas de la aplicacin que sirvan de ayuda para tratar de asegurar que la informacin se registre y mantenga completa y exacta, los procesos de todo tipo sobre la misma sean correctos y su utilizacin por parte de los usuarios respete los mbitos de confidencialidad establecidos y permita poner en prctica principios generales de control interno como el referente a la segregacin de funciones. Controles que, segn su finalidad, se suelen clasificar en: Controles preventivos: Tratan de ayudar a evitar la produccin de errores a base de exigir el ajuste de los datos introducidos a patrones de formato y estructura (dato numrico, fecha vlida, etc.), pertenencia a una lista de valores vlidos o a un fichero maestro, rango entre lmites determinados, incorporacin de dgitos de control en datos clave (cdigos de identificacin, referencias de documentos, nomenclaturas, etc.) y. en general, cualquier criterio que ayude a asegurar la correccin formal y verosimilitud de los datos (la exactitud slo puede garantizarla el usuario). Controles detectivos: Tratan de descubrir a posteriori errores que no haya sido posible evitar. Controles correctivos: Tratan de asegurar que se subsanen todos los errores identificados mediante controles detectivos. Despus de lo expuesto, podemos centrar la problemtica de la auditora de una aplicacin: se trata de realizar una revisin de la eficacia del funcionamiento de los controles diseados para cada uno de los pasos de la misma frente a los riesgos que tratan de eliminar o minimizar, como medios para asegurar la fiabilidad (totalidad y exactitud), seguridad, disponibilidad y confidencialidad de la informacin gestionada por la aplicacin. Quede bien entendido que, por muy completa que resulte la revisin que hagamos de una aplicacin informtica y de los controles que incorpora, no es suficiente para garantizar la seguridad de la misma: sta se consolida con la realizacin de una evaluacin de los controles generales y una revisin de los controles de la funcin informtica, que estarn recogidos en el Plan de trabajos de auditora informtica.

Herramientas de la Auditora de una Aplicacin Entre las herramientas ms comnmente utilizadas en la auditora de la aplicacin informtica podemos mencionar: Entrevistas Encuestas Observacin del trabajo realizado por los usuarios Pruebas de conformidad Pruebas substantivas o de validacin Uso de computadoras personales con software especfico de auditora Todas estas herramientas se pueden combinarse para la realizacin de la auditora.

Etapas de la Auditora de una Aplicacin Recoleccin de informacin y documentacin sobre la aplicacin Antes de plantearnos el alcance de los trabajos de auditora sobre aplicaciones informticas necesitamos disponer de un conocimiento bsico de la aplicacin y de su entorno. Realizamos un estudio preliminar en el que recogemos toda aquella informacin que nos pueda ser til para determinar los puntos dbiles existentes y aquellas funciones de la aplicacin que puedan entraar riesgos.

Determinacin de los objetivos y alcance de la auditora El examen de los documentos recopilados y la revisin de los temas tratados a lo largo de las entrevistas mantenidas, es decir, las observaciones tras el examen preliminar, la identificacin de los puntos dbiles y las funciones crticas, deben permitirle al auditor establecer su propuesta de objetivos de la auditora de la aplicacin y un plan detallado del trabajo a realizar. Entendemos que dedicando ms recursos cuanto mayor fuera la debilidad o ms graves las consecuencias de la amenaza que se somete a revisin.

Planificacin de la auditoria Toda auditora, debe ser objeto de una planificacin cuidadosa. En este caso es de crucial importancia acertar con el momento ms adecuado para su realizacin.

Trabajo de campo, informe e implantacin de mejoras En principio las etapas de realizacin del trabajo de campo, de redaccin del informe y de consenso del plan de implantacin de mejoras, no ofrecen peculiaridades de relevancia respecto a otros trabajos de auditora. Es por eso que no vamos a hacer ms referencia a ellas que algn comentario que la experiencia nos sugiere, como por ejemplo, realizacin del trabajo de campo consiste en la ejecucin del programa de trabajo establecido, recomendaciones y sugerencias, redaccin del informe de la auditora, etc.

Auditora de Base de Datos La gran difusin de los Sistemas de Gestin de Bases de Datos (SGBD), junto con la consagracin de los datos como uno de los recursos fundamentales de las empresas, ha hecho que los temas relativos a su control interno y auditora cobren, cada da, mayor inters.

Metodologas para la Auditora de Bases de Datos Aunque existen distintas metodologas que se aplican en auditora informtica (prcticamente cada firma de auditores y cada empresa desarrolla la suya propia) se pueden agrupar en dos clases. Metodologa Tradicional En este tipo de metodologa el auditor revisa el entorno con la ayuda de una lista de control (checklist), que consta de una serie de cuestiones a verificar. Por ejemplo: S Existe una metodologa de diseo de BD? El auditor deber registrar el resultado de su investigacin: S, si la respuesta es afirmativa, N, en caso contrario, o NA (no aplicable). Este tipo de tcnica suele ser aplicada a la auditora de productos de bases de datos, especificndose en la lista de control todos los aspectos a tener en cuenta. N NA

Metodologa de Evaluacin de Riesgos Este tipo de metodologa, conocida tambin por risk oriented approach, empieza fijando los objetivos de control que minimizan los riesgos potenciales a los que est sometido el entorno. Considerando los riesgos, se podra definir por ejemplo los siguientes controles: El SGBD deber preservar la confidencialidad de la base de datos. o Se debern establecer los tipos de usuarios, perfiles y privilegios necesarios para controlar el acceso a la base de datos. o Listar los privilegios y perfiles existentes en el SGBD. o Comprobar si la informacin ha sido corrompida comparndola con otra fuente, o revisando los documentos de entrada de datos y las transacciones que se han ejecutado.

Ciclo de Vida de una Base de Datos A continuacin expondremos algunos objetivos y tcnicas de control a tener en cuenta a lo largo del ciclo de vida de una base de datos que abarca desde el estudio previo hasta su explotacin. Estudio previo y plan de trabajo En esta primera fase, es muy importante elaborar un estudio tecnolgico de viabilidad en el cual se contemplen distintas alternativas para alcanzar los objetivos del proyecto acompaados de un anlisis coste/beneficio para cada una de las opciones. Se debe considerar entre estas alternativas la posibilidad de no llevar a cabo el proyecto (no siempre est justificada la implantacin de un sistema de bases de datos) as como la disyuntiva entre desarrollar y comprar (en la prctica, a veces nos encontramos con que se ha desarrollado una aplicacin que ya exista en el mercado, cuya compra hubiese supuesto un nesgo menor, asegurndonos incluso una mayor calidad a un precio inferior). Desafortunadamente, en bastantes empresas este estudio de viabilidad no se lleva a cabo con el rigor necesario, con lo que a medida que se van desarrollando, los sistemas demuestran, a veces, ser poco rentables.

Concepcin de la base de datos y seleccin del equipo En esta fase se empieza a disear la base de datos, por lo que deben utilizarse los modelos y las tcnicas. La metodologa de diseo debera emplearse para especificar los documentos fuentes, los mecanismos de control, las caractersticas de seguridad y las pistas de auditora a incluir en el sistema, estos ltimos aspectos generalmente se descuidan, lo que produce mayores costes y problemas cuando se quieren incorporar una vez concluida la implementacin de la base de datos y la programacin de las aplicaciones. El auditor debe por tanto, en primer lugar, analizar la metodologa de diseo con el fin de determinar si es o no aceptable, y luego comprobar su correcta utilizacin, como mnimo una metodologa de diseo de BD debera contemplar dos fases de diseo: lgico y fsico, aunque la mayora de las empleadas en la actualidad contempla tres fases; adems de las dos anteriores, una fase previa de diseo conceptual.

Diseo y carga En esta fase se llevarn a cabo los diseos lgico y fsico de la base de datos, por lo que el auditor tendr que examinar si estos diseos se han realizado correctamente; determinando si la definicin de los datos contemplan adems de su estructura, las asociaciones y las restricciones oportunas, as como las especificaciones de almacenamiento de datos y las cuestiones relativas a la seguridad. El auditor tendr que tomar una muestra de ciertos elementos (tablas, vistas, ndices) y comprobar que su definicin es completa, que ha sido aprobada por el usuario y que el administrador de la base de datos particip en su establecimiento. Una vez diseada la BD, se proceder a su carga, ya sea migrando datos d un soporte magntico o introducindolos manualmente. Las migraciones o conversiones de sistemas. como el paso de un sistema de ficheros a uno de bases de datos, o de un tipo de SGBD, entraan un riesgo muy importante, por lo que debern estar claramente planificadas para evitar prdida de informacin y la transmisin al nuevo sistema de datos errneos. Tambin se debern realizar pruebas en paralelo, verificando que la decisin real de dar por terminada la prueba en paralelo se atena a los criterios establecidos por la direccin y que se haya aplicado un control estricto de la correccin de errores detectados en esta fase.

Explotacin y mantenimiento Una vez realizadas las pruebas de aceptacin, con la participacin de los usuarios, el sistema se pondr (mediante las correspondientes autorizaciones y siguiendo los procedimientos establecidos para ello) en explotacin. En esta fase, se debe comprobar que se establecen los procedimientos de explotacin y mantenimiento que aseguren que los datos se tratan de forma congruente y exacta y que el contenido de los sistemas slo se modifica mediante la autorizacin adecuada. Sera conveniente que el auditor pudiera llevar a cabo una auditora sobre el rendimiento del sistema de BD, comprobando si se lleva a cabo un proceso de ajuste (tuning) y optimizacin adecuados que no slo consiste en el rediseo fsico o lgico de la BD, sino que tambin abarca ciertos parmetros del SO e incluso la forma en que acceden las transacciones a la BD.

Tcnicas para el Control de Bases de Datos Existen muchos elementos del entorno del SGBD que influyen en la seguridad e integridad de los datos, en los que cada uno se apoya en la operacin correcta y predecible de otros. La direccin de la empresa tiene, por tanto, una responsabilidad fundamental por lo que se refiere a la coordinacin de los distintos elementos y a la aplicacin consistente de los controles de seguridad. Para llevar a cabo esta labor se deben fijar claramente las responsabilidades sobre los diferentes componentes, utilizar informes de excepcin efectivos que permitan monitorizar los controles, establecer procedimientos adecuados, implantar una gestin rigurosa de la configuracin del sistema, etc. Cuando el auditor se enfrenta a un entorno de este tipo, puede emplear, entre otras, dos tcnicas de control:

Matrices de control Estas matrices, sirven para identificar los conjuntos de datos del SI junto con los controles de seguridad o integridad implementados sobre los mismos.

DATOS Transacciones de entrada Registros de Base de Datos Preventivos verificacin cifrado

CONTROLES DE SEGURIDAD Detectivos informe de reconciliacin Informe de excepcin

Correctivos ---copia de seguridad

Anlisis de los Caminos de Acceso Con esta tcnica se documentan el flujo, almacenamiento y procesamiento de los datos en todas las fases por las que pasan desde el mismo momento en que se introducen, identificando los componentes del sistema que atraviesan (tanto hardware como software) y los controles asociados.

PC
Monitor de Teleproceso

COMPUTADORA CENTRAL
Paquete de seguridad Programa SGBD SO Datos

Con este marco, el auditor puede identificar las debilidades que expongan los datos a riesgos de integridad, confidencialidad y seguridad, las distintas interfaces entre componentes y la complecin de los controles. En la prctica se suelen utilizar conjuntamente ambas tcnicas, si bien la del anlisis de caminos de acceso requiere unos mayores conocimientos tcnicos y se emplea en sistemas ms complejos.

Auditora de Redes Para poder auditar redes, lo primero y fundamental es utilizar el mismo vocabulario (ms bien jerga) que los expertos en comunicaciones que las manejan. Debido a la constante evolucin en este campo, un primer punto de referencia es poder referirse a un modelo comnmente aceptable. El modelo comn de referencia, adoptado por LSD (International Standards Organization) se denomina Modelo OSI (Open Systems Interconection), y consta de estas siete capas:

7 6 5 4 3 2 1

Aplicacin Presentacin Sesin Transporte Red Enlace Fsico

Es donde la aplicacin que necesita comunicaciones enlaza, mediante APL (Application Program Interface) con el sistema de comunicaciones. Define el formato de los datos que se van a presentar a la aplicacin. Establece los procedimientos de aperturas y cierres de sesin de comunicaciones, as como informacin de la sesin en curso. Comprueba la integridad de los datos transmitidos. Establece las rutas por las cuales se puede comunicar el emisor con el receptor, lo que se realiza mediante el envo de paquetes de informacin. Transforma los paquetes de informacin en tramas adaptadas a los dispositivos fsicos sobre los cuales se realiza la transmisin. Transforma la informacin en seales fsicas adaptadas al medio de comunicacin.

La potencia del modelo OSI proviene de que cada capa no tiene que preocuparse de qu es lo que hagan las capas superiores ni las inferiores; cada capa se comunica con su igual en el interlocutor, con un protocolo de comunicaciones especfico. Entre cada par de capa N y capa N-1 est perfectamente definido el paso de la informacin, que se produce dentro de la misma mquina, con mtodos clsicos de programacin en local. Para establecer una comunicacin, la informacin atraviesa descendentemente la pila formada por las siete capas, atraviesa el medio fsico y asciende a travs de las siete capas en la pila de destino. Por tanto, cada capa tiene unos mtodos prefijados para comunicarse con las inmediatamente inferior y superior. De esta manera, se aslan los protocolos que se utilizan en unas capas con los protocolos que se utilizan en otras. Por ejemplo, es posible transmitir trfico TCP/IP (capas superiores), a travs de Ethernet o Token-Ring indistintamente (capas inferiores), gracias a esta independencia entre capas. En los niveles inferiores, habitualmente hasta el nivel tres, es donde se definen las redes LAN (Local Area Network), MAN (Metropolitan Area Network) y WAN (Wide Area Network). Las funcionalidades de estos tres tipos de redes son similares, variando fundamentalmente la distancia que son capaces de salvar entre el emisor y el receptor (LAN: dentro de un edificio, MAN: dentro de un campus o zona urbana, WAN: cualquier distancia), siendo la velocidad inversamente proporcional a la distancia.

Vulnerabilidad en Redes Todos los sistemas de comunicacin, desde el punto de vista de auditora, presentan en general una problemtica comn: La informacin transita por lugares fsicamente alejados de las personas responsables. Esto presupone un compromiso en la seguridad, ya que no existen procedimientos fsicos para garantizar la inviolabilidad de la informacin. En las redes de comunicaciones, por causas propias de la tecnologa, pueden producirse bsicamente tres tipos de incidencias: Alteracin de bits. Por error en los medios de transmisin, una trama puede sufrir variacin en parte de su contenido. La forma ms habitual de detectar, y corregir en su caso, este tipo de incidencias, es sufijar la trama con un Cdigo de Redundancia Cclico (CRC) que detecte cualquier error y permita corregir errores que afecten hasta unos pocos bits en el mejor de los casos. Ausencia de tramas. Por error en el medio, o en algn nodo, o por sobrecarga, alguna trama puede desaparecer en el camino del emisor al receptor. Se suele atajar este riesgo dando un nmero de secuencia a las tramas.

Alteracin de secuencia. El orden en el que se envan y se reciben las tramas no coincide. Unas tramas han adelantado a otras. En el receptor, mediante el nmero de secuencia, se reconstruye el orden original. Por causas dolosas, y teniendo en cuenta que es fsicamente posible interceptar la informacin, los tres mayores riesgos a atajar son: Indagacin. Un mensaje puede ser ledo por un tercero, obteniendo la informacin que contenga. Suplantacin. Un tercero puede introducir un mensaje espurio que el receptor cree proveniente del emisor legtimo. Modificacin. Un tercero puede alterar el contenido de un mensaje.

Para este tipo de actuaciones dolosas, la nica medida prcticamente efectiva en redes MAN y WAN (cuando la informacin sale del edificio) es la criptografa. En redes LAN suelen utilizarse ms bien medidas de control de acceso al edificio y al cableado, ya que la criptografa es muy onerosa todava para redes locales. Dada la proliferacin de equipos que precisan comunicacin de datos dentro de los edificios, es muy habitual plantearse sistemas de cableado integral en vez de tender un cable en cada ocasin. Esto es prcticamente un requisito en edificios con cierto volumen de usuarios. Los sistemas de cableado suelen dividirse segn su mbito. En cada planta o zona se tienden cables desde un armado distribuidor a cada uno de los potenciales puestos. Este cableado se denomina habitualmente de planta. Estos armarios estn conectados, a su vez, entre s y con las salas de ordenadores, denominndose a estas conexiones cableado troncal. Desde las salas de ordenadores parten las lneas hacia los transportistas de datos (Telefnicas o PTTs), saliendo los cables al exterior del edificio en lo que se denomina cableado de ruta. El cableado de planta suele ser de cobre, por lo que es propenso a escuchas (pinchazos) que pueden no dejar rastro. El cableado troncal y el de ruta cada vez ms frecuentemente se tienden mediante fibras pticas, que son muy difciles de interceptar, debido a que no provocan radiacin electromagntica y a que la conexin fsica a una fibra ptica requiere una tecnologa delicada y compleja. En el propio puesto de trabajo puede haber peligros, como grabar/retransmitir la imagen que se ve en la pantalla, teclados que guardan memoria del orden en que se han pulsado las teclas, o directamente que las contraseas estn escritas en papeles a la vista. Dentro de las redes locales, el mayor peligro es que alguien instale una escucha no autorizada. Al viajar en claro la informacin dentro de la red local, es imprescindible tener una organizacin que controle estrictamente los equipos de escucha, bien sean stos fsicos (sniffer) o lgicos (traceadores). Ambos escuchadores, fsicos y lgicos, son de uso habitual dentro de cualquier instalacin de cierto tamao. Por tanto es fundamental que ese uso legtimo est controlado y no devenga en actividad espuria. El riesgo de interceptar un canal de comunicaciones, y poder extraer de l la informacin, tiene unos efectos relativamente similares a los de poder entrar, sin control, en el sistema de almacenamiento del ordenador. Hay un punto especialmente crtico en los canales de comunicaciones que son las contraseas de usuario. Mientras que en el sistema de almacenamiento las contraseas suelen guardarse cifradas, es inhabitual que los terminales u ordenadores personales sean capaces de cifrar la contrasea cuando se enva al ordenador central o al servidor. Por tanto, alguien que intercepte la informacin puede hacerse con las contraseas en claro. Adems, dado que las cartulas iniciales donde se teclea la contrasea son siempre las mismas, se facilita la labor de los agentes de interceptacin, pues proporcionan un patrn del paquete de informacin donde viaja la contrasea a interceptar.

Auditora de Redes Abiertas (TCP/IP) Ante el auge que est tomando el protocolo TCP/IP, como una primera clasificacin de redes, se est adoptando la siguiente nomenclatura para las redes basadas en este protocolo: Intranet: Es la red interna, privada y segura de una empresa, utilice o no medios de transporte de terceros.

Extranet: Es una red privada y segura, compartida por un conjunto de empresas, aunque utilice medios de transporte ajenos e inseguros, como pudiera ser Internet. Internet: Es la red de redes, a donde se conecta cualquier red que se desee abrir al exterior, pblica e insegura, de alcance mundial, donde puede comunicar cualquier pareja o conjunto de interlocutores, dotada adems de todo tipo de servicios de valor aadido. El mayor peligro que representa un acceso TCP/IP no autorizado viene precisamente por la mayor virtud del TCP/IP: su amplia disponibilidad de utilidades. Dada la estandarizacin de las utilidades TCP/IP, es muy razonable suponer que cada mquina con acceso TCP/IP tenga puertos abiertos, que a su vez tienen direcciones normalizadas donde encontrar transmisores de ficheros, servidores de correo, terminales virtuales y todo tipo de servicios de utilidad. Una ausencia de proteccin significara que un tercero puede utilizar estos servicios normalizados, de comn existencia en cualquier mquina, en beneficio propio. Un dispositivo especficamente dedicado a la proteccin de una Intranet ante una Extranet, y fundamentalmente ante Internet, es el cortafuegos (Firewall). sta es una mquina dedicada en exclusiva a leer cada paquete que entra o sale de una red para permitir su paso o desecharlo directamente. Esta autorizacin o rechazo est basada en unas tablas que identifican, para cada pareja de interlocutores (bien sea basado en el tipo de interlocutor o inclusive en su identificacin individual) los tipos de servicios que pueden ser establecidos. Para llevar a cabo su misin, existen diversas configuraciones, donde se pueden incluir encaminadores (routers), servidores de proximidad (proxy), zonas desmilitarizadas, bastiones, etc. Las polticas de proteccin en un cortafuegos suelen denominarse desde paranoicas hasta promiscuas, pasando por todo tipo de gamas intermedias. Dcese de la poltica paranoica cuando est prohibido absolutamente todo, requirindose una autorizacin especfica para cada servicio en concreto entre cada par de interlocutores concretos. Dcese de poltica promiscua cuando todo est autorizado, identificndose especficamente aquellos servicios concretos entre parejas concretas de interlocutores que se prohben. Lo ms habitual es autorizar especficamente servicios (por ejemplo, correo electrnico) para ciertos tipos genricos de usuarios (por ejemplo, a todos), otros servicios (por ejemplo, terminal virtual) a ciertos usuarios especficos (por ejemplo, servidor de terminales virtuales) y el resto no autorizarlo.

INTERNET EXTRANET

Cortafuegos Encaminadores externo

Cortafuegos Encaminadores interno

INTRANET

Zona desmilitarizada BASTION Servidor proxy

Proteccin de una red lntranet

Para proteger la red interna Intranet del exterior suele utilizarse el esquema expuesto en la figura, o bien variaciones del mismo. Se parte de la base de que la informacin que viaja entre la Intranet y el exterior ha de atravesar la zona desmilitarizada (DMZ de sus siglas inglesas), pasando por dos encaminadores. Un encaminador protege los accesos desde el exterior hacia la zona desmilitarizada (encaminador externo) y otro protege los accesos desde la zona desmilitarizada hacia la Intranet (encaminador interno). En la zona desmilitarizada se instalan aquellos servicios a los que haya que acceder desde el exterior y desde el interior, en una mquina especialmente segura, denominada bastin, que debe ser dedicada exclusivamente a este fin. Por ejemplo, un servidor proxy accede a un servidor Internet, recuperando la informacin que haya solicitado un usuario interno, y almacenndola para que pueda ser recuperada desde la Intranet. De esta manera se evita una conexin directa desde una mquina interna a un servidor Internet. Del mismo modo, el correo electrnico podra recibirse en un servidor instalado en la zona desmilitarizada y reexpedirse hacia

el interior. El objetivo es evitar establecer sesiones directas entre una mquina Intranet y una mquina externa. Los encaminadores impedirn que se establezcan conexiones de este tipo, salvo aquellas que especficamente se determinen. El encaminador externo slo permitir que atraviese trfico autorizado entre el exterior y el bastin, y el encaminador interno har lo propio con el trfico entre el bastin y la red interna. Para comprobar los controles de acceso desde el exterior, as como las vulnerabilidades en la red interna, cortafuegos, servidores, etc..., existen programas especficos ya comercializados, como por ejemplo SAFEsuite, Satan, Cops... que facilitan esta tarea, comprobando las vulnerabilidades ya conocidas. Las nuevas versiones de estos programas, que aparecen regularmente, incluyen comprobaciones de las nuevas debilidades detectadas. Como en el caso de los antivirus, se deben tener estos programas actualizados a fecha reciente.

Auditora de la Red Fsica Ha de auditarse hasta qu punto las instalaciones fsicas del edificio ofrecen garantas y han sido estudiadas las vulnerabilidades existentes. En general, muchas veces se parte del supuesto de que si no existe acceso fsico desde el exterior a la red interna de una empresa las comunicaciones internas quedan a salvo. Debe comprobarse que efectivamente los accesos fsicos provenientes del exterior han sido debidamente registrados, para evitar estos accesos. Debe tambin comprobarse que desde el interior del edificio no se intercepta fsicamente el cableado (pinchazo). En caso de desastre, bien sea total o parcial, ha de poder comprobarse cul es la parte del cableado que queda en condiciones de funcionar y qu operatividad puede soportar. Ya que el tendido de cables es una actividad irrealizable a muy corto plazo, los planes de recuperacin de contingencias deben tener prevista la recuperacin en comunicaciones. Como objetivos de control, se debe marcar la existencia de: reas controladas para los equipos de comunicaciones, previniendo as accesos inadecuados. Proteccin y tendido adecuado de cables y lneas de comunicaciones, para evitar accesos tsicos. Controles de utilizacin de los equipos de pruebas de comunicaciones, usados para monitorizar la red y su trfico, que impidan su utilizacin inadecuada. Atencin especfica a la recuperacin de los sistemas de comunicacin de datos en el plan de recuperacin de desastres en sistemas de informacin. Controles especficos en caso de que se utilicen lneas telefnicas normales con acceso a la red de datos para prevenir accesos no autorizados al sistema o a la red. Controles: Comprobar que: El equipo de comunicaciones se mantiene en habitaciones cerradas con acceso limitado a personas autorizadas. La seguridad fsica de los equipos de comunicaciones, tales como controladores de comunicaciones, dentro de las salas de ordenadores sea adecuada. Las personas con responsabilidad y conocimientos estn incluidas en la lista de personas permanentemente autorizadas para entrar en las salas de equipos de comunicaciones. Se toman medidas para separar las actividades de electricistas y personal de tendido y mantenimiento de tendido de lneas telefnicas, as como sus autorizaciones de acceso, de aquellas del personal bajo control de la gerencia de comunicaciones. En las zonas adyacentes a las salas de comunicaciones, todas las lneas de comunicaciones fuera de la vista. Las lneas de comunicaciones, en las salas de comunicaciones, armarios distribuidores y terminaciones de los despachos, estarn etiquetadas con un cdigo gestionado por la gerencia de comunicaciones, y no por su descripcin fsica o mtodos sin coherencia. Existen procedimientos para la proteccin de cables y bocas de conexin que dificulten el que sean interceptados o conectados por personas no autorizadas. Se revisa peridicamente la red de comunicaciones, buscando intercepciones activas o pasivas.

Los equipos de prueba de comunicaciones usados para resolver los problemas de comunicacin de datos deben tener propsitos y funciones definidos. Existen controles adecuados sobre los equipos de prueba de comunicaciones usados para monitorizar lneas y fijar problemas incluyendo: o Procedimiento restringiendo el uso de estos equipos a personal autorizado. o Facilidades de traza y registro del trfico de datos que posean los equipos de monitorizacin. o Procedimientos de aprobacin y registro ante las conexiones a lneas de comunicaciones en la deteccin y correccin de problemas En el plan general de recuperacin de desastres para servicios de informacin presta adecuada atencin a la recuperacin y vuelta al servicio de los sistemas de comunicacin de datos. Existen planes de contingencia para desastres que slo afecten a las comunicaciones, como el fallo de una sala completa de comunicaciones. Las alternativas de respaldo de comunicaciones, bien sea con las mismas salas o con salas de respaldo, consideran la seguridad fsica de estos lugares. Las lneas telefnicas usadas para datos, cuyos nmeros no deben ser pblicos, tienen dispositivos/procedimientos de seguridad tales como retrollamada, cdigos de conexin o interruptores para impedir accesos no autorizados al sistema informtico.

Auditora de la Red Lgica Cada vez ms se tiende a que un equipo pueda comunicarse con cualquier otro equipo, de manera que sea la red de comunicaciones el substrato comn que les une. Ledo a la inversa, la red hace que un equipo pueda acceder ilegtimamente a cualquier otro, incluyendo al trfico que circule hacia cualquier equipo de la red. Y todo ello por mtodos exclusivamente lgicos, sin necesidad de instalar fsicamente ningn dispositivo. Simplemente si un equipo, por cualquier circunstancia, se pone a enviar indiscriminadamente mensajes, puede ser capaz de bloquear la red completa, y por tanto al resto de los equipos de la instalacin. Es necesario monitorizar la red, revisar los errores o situaciones anmalas que se producen y tener establecidos los procedimientos para detectar y aislar equipos en situacin anmala. En general, si se quiere que la informacin que viaja por la red no pueda ser espiada, la nica solucin totalmente efectiva es la encriptacin. Como objetivos dc control, se debe marcar la existencia de: Contraseas y otros procedimientos para limitar y detectar cualquier intento de acceso no autorizado a la red de comunicaciones. Facilidades de control de errores para detectar errores de transmisin y establecer las retransmisiones apropiadas. Controles para asegurar que las transmisiones van solamente a usuarios autorizados y que los mensajes no tienen por qu seguir siempre la misma ruta. Registro de la actividad de la red, para ayudar a reconstruir incidencias y detectar accesos no autorizados. Tcnicas de cifrado de datos donde haya riesgos de accesos impropios a transmisiones sensibles. Controles adecuados que cubran la importacin o exportacin de datos a travs de puertas, en cualquier punto de la red, a otros sistemas informticos.

Controles: Comprobar que. EI software de comunicaciones, para permitir el acceso, solicita cdigo de usuario y contrasea. Revisar el procedimiento de conexin de usuario y comprobar que: o Los usuarios no pueden acceder a ningn sistema, ni siquiera de ayuda, antes de haberse identificado correctamente. o Se inhabilita al usuario que sea incapaz de dar la contrasea despus de un nmero determinado de intentos infructuosos. o Se obliga a cambiar la contrasea regularmente.

Las contraseas no son mostradas en pantalla cuando se teclean. Durante el procedimiento de identificacin, los usuarios son informados de cundo fue su ltima conexin para ayudar a identificar potenciales suplantaciones o accesos no autorizados. Cualquier procedimiento del fabricante, mediante hardware o software, que permita el libre acceso y que haya sido utilizado en la instalacin original, ha de haber sido inhabilitado o cambiado. Se toman estadsticas que incluyan tasas de errores y de retransmisin. Los protocolos utilizados, revisados con el personal adecuado de comunicaciones, disponen de procedimientos de control de errores con la seguridad suficiente. Los mensajes lgicos transmitidos identifican el emisor, la fecha, la hora y el receptor. El software de comunicaciones ejecuta procedimientos de control y correctivos ante mensajes duplicados, fuera de orden, perdidos, o retrasados. La arquitectura de comunicaciones utiliza indistintamente cualquier ruta disponible de trasmisin para minimizar el impacto de una escucha de datos sensibles en una ruta determinada. Existen controles para que los datos sensibles slo puedan ser impresos en las impresoras designadas y vistos desde los terminales autorizados. Existen procedimientos de registro para capturar y ayudar a reconstruir todas las actividades de las transacciones. Los ficheros de registro son revisados, si es posible a travs de herramientas automticas, diariamente, vigilando intentos impropios de acceso. Existen anlisis de riesgos para las aplicaciones de proceso de datos a fin de identificar aquellas en las que el cifrado resulte apropiado. Si se utiliza cifrado: o Existen procedimientos de control sobre la generacin e intercambio de claves. o Las claves de cifrado son cambiadas regularmente. o El transporte de las claves de cifrado desde donde se generan a los equipos que las utilizan sigue un procedimiento adecuado. Si se utilizan canales dc comunicacin uniendo diversos edificios de la misma organizacin, y existen datos sensibles que circulen por ellos, comprobar que estos canales se cifran automticamente, para evitar que una interceptacin sistemtica a un canal comprometa a todas las aplicaciones. Si la organizacin tiene canales de comunicacin con otras organizaciones se analice la conveniencia de cifrar estos canales. Si se utiliza la transmisin de datos sensibles a travs de redes abiertas como Internet, comprobar que estos datos viajan cifrados. Si en una red local existen ordenadores con mdems, se han revisado los controles de seguridad asociados para impedir el acceso de equipos forneos a la red local. Existe una poltica de prohibicin de introducir programas personales o conectar equipos privados a la red local. Todas las puertas traseras y accesos no especficamente autorizados estn bloqueados. En equipos activos de comunicaciones, como puentes, encarninadores, conmutadores, etc, esto significa que los accesos para servicio remoto estn inhabilitados o tienen procedimientos especficos de control. Peridicamente se ejecutan, mediante los programas actualizados y adecuados, ataques para descubrir vulnerabilidades, que los resultados se documentan y se corrigen las deficiencias observadas. Estos ataques deben realizarse independientemente a: o Servidores, desde dentro del servidor. o Servidores, desde la red interna. o Servidores Web, especficamente. o Intranet, desde dentro de ella. o Cortafuegos, desde dentro de ellos. o Accesos desde el exterior y/o Internet o o

Auditora de Seguridad Para muchos la seguridad sigue siendo el rea principal a auditar, hasta el punto de que en algunas entidades se cre inicialmente la funcin de auditora informtica para revisar la seguridad, aunque despus se hayan ido ampliando los objetivos. Cada da es mayor la importancia de la informacin, especialmente relacionada con sistemas basados en el uso de tecnologas de la informacin y comunicaciones, por lo que el impacto de los fallos, los accesos no autorizados, la revelacin de la informacin, y otras incidencias, tienen un impacto mucho mayor que hace unos aos: de ah la necesidad de protecciones adecuadas que se evaluarn o recomendarn en la auditora de seguridad.

Objetivos de la seguridad y de la Auditora de la Seguridad

Podemos hablar de Objetivos de Control respecto a la seguridad, que vienen a ser declaraciones sobre el resultado final deseado o propsito a ser alcanzado mediante las protecciones y los procedimientos de control. Debe evaluarse en la auditora si los modelos de seguridad estn en consonancia con las nuevas arquitecturas, las distintas plataformas y las posibilidades de las comunicaciones, porque no se puede auditar con conceptos, tcnicas o recomendaciones de hace algunos aos (que en realidad no son tantos).

Tipos de controles: Controles directivos, que son los que establecen las bases, como las polticas, o la creacin de comits relacionados o de funciones: de administracin de seguridad o auditora de sistemas de informacin interna. Controles preventivos: antes del hecho, como la identificacin de visitas (seguridad fsica) o las contraseas (seguridad lgica). Controles de deteccin, como determinadas revisiones de accesos producidos o la deteccin de incendios. Controles correctivos, para rectificar errores, negligencias o acciones intencionadas, como la recuperacin de un archivo daado a partir de una copia. Controles de recuperacin, que facilitan la vuelta a la normalidad despus de accidentes o contingencias, como puede ser un plan de continuidad adecuado.

Auditora de la Seguridad Fsica Se evaluarn las protecciones fsicas de datos, programas, instalaciones, equipos, redes y soportes, y por supuesto habr que considerar a las personas: que estn protegidas y existan medidas de evacuacin, alarmas, salidas alternativas, as como que no estn expuestas a riesgos superiores a los considerados admisibles en la entidad e incluso en el sector, por ejemplo por convenio o normativa especfica; y si bien todos estos aspectos suelen ser comunes con las medidas generales de la entidad, en una auditoria de sistemas de informacin nos preocupamos especialmente por quienes estn en el rea o de los daos que puedan afectar a los usuarios de los sistemas si entra dentro de la auditoria. Las amenazas pueden ser muy diversas: sabotaje, vandalismo, accidentes de distinto tipo, incendios, inundaciones, averas importantes, derrumbamientos, explosiones, as como otros que afectan a las personas y pueden impactar el funcionamiento de los centros, tales como errores, negligencias, huelgas, epidemias o intoxicaciones. Desde la perspectiva de las protecciones fsicas algunos aspectos a considerar son: Ubicacin del centro de procesos, de los servidores locales, y en general de cualquier elemento a proteger, como puedan ser los propios terminales, especialmente en zonas de paso, de acceso pblico, o prximos a ventanas en plantas bajas. Proteccin de ordenadores porttiles, incluso fuera de las oficinas: aeropuertos, automviles, restaurantes, etc. Estructura, diseo, construccin y distribucin de los edificios y de sus plantas.

Riesgos a los que estn expuestos, tanto por agentes externos, casuales o no, como por accesos fsicos no controlados. Amenazas de fuego (materiales empleados); riesgos por agua: por accidentes atmosfricos o por averas en las conducciones; problemas en el suministro elctrico, tanto por cadas como por perturbaciones. Controles tanto preventivos como de deteccin relacionados con los puntos anteriores, as como de acceso basndose en la clasificacin de reas segn usuarios, incluso segn da de la semana y horario. El control deber afectar a las visitas, proveedores, contratados, clientes.., y en casos ms estrictos igualmente a los empleados; los ex empleados se debern considerar visitas en todo caso. Proteccin de los soportes magnticos en cuanto a acceso, almacenamiento y posible transporte, adems de otras protecciones no fsicas, todo bajo un sistema de inventario, as como proteccin de documentos impresos y de cualquier tipo de documentacin clasificada Es fcil y barato obtener copias magnticas peridicas de datos y de programas frente al perjuicio que nos puede causar el no haberlo hecho; es mucho ms difcil o caro, o no es posible, obtener copias con igual valor de otros objetos o activos como obras de arte. Todos los puntos anteriores pueden, adems, estar cubiertos por seguros.

Auditora de la Seguridad Lgica Es necesario verificar que cada usuario slo pueda acceder a los recursos a los que le autorice el propietario, aunque sea de forma genrica, segn su funcin, y con las posibilidades que el propietario haya fijado: lectura, modificacin, borrado, ejecucin... trasladando a los sistemas lo que representaramos en una matriz de accesos en la que figuraran los sujetos: grupos de usuarios o sistemas, los objetos que puedan ser accedidos con mayor o menor granularidad: un disco, una aplicacin, una base de datos, una librera de programas, un tipo de transaccin, un programa, un tipo de campo... y para completar la tripleta, las posibilidades que se le otorgan: lectura, modificacin, borrado, ejecucin... Desde el punto de vista de la auditoria es necesario revisar cmo se identifican y sobre todo autentican los usuarios, cmo han sido autorizados y por quin, y qu ocurre cuando se producen transgresiones o intentos: quin se entera y cundo y qu se hace. En cuanto a autenticacin, hasta tanto no se abaraten ms y generalicen los sistemas basados en la biomtrica, el mtodo ms usado es la contrasea, cuyas caractersticas sern acordes con las normas y estndares de la entidad, que podran contemplar diferencias para segn qu sistemas en funcin de la criticidad de los recursos accedidos. Algunos de los aspectos a evaluar respecto a las contraseas pueden ser: Quin asigna la contrasea: inicial y sucesivas. Longitud mnima y composicin de caracteres. Vigencia, incluso puede haberlas de un solo uso o dependientes de una funcin tiempo. Control para no asignar las x ltimas. Nmero de intentos que se permiten al usuario, e investigacin posterior de los fallidos: pueden ser errores del usuario o intentos de suplantacin. Si las contraseas estn cifradas y bajo qu sistema, y sobre todo que no aparezcan en claro en las pantallas, listados, mensajes de comunicaciones o corrientes de trabajos (JCL en algunos sistemas). Proteccin o cambio de las contraseas iniciales que llegan en los sistemas, y que a menudo aparecen en los propios manuales. Controles existentes para evitar y detectar caballos de Troya: en este contexto se trata de un programa residente en un PC que emulando un terminal simule el contenido de la pantalla que recoge la identificacin y contrasea dcl usuario, grabe la contrasea y devuelva control al sistema verdadero despus de algn mensaje simulado de error que normalmente no despenar las sospechas del usuario. La no-cesin, y el uso individual y responsable de cada usuario, a partir de la normativa. Siempre se ha dicho que la contrasea ha de ser difcilmente imaginable por ajenos y fcilmente recordable por el propio usuario, y este ltimo aspecto se pone en peligro cuando un mismo usuario ha de identificarse ante distintos sistemas, para lo que puede asignar una misma contrasea, lo que supone una vulnerabilidad si la proteccin es desigual, por ser habitual que en pequeos sistemas o aplicaciones

aisladas las contraseas no estn cifradas o lo estn bajo sistemas vulnerables; si opta por asignar varias contraseas puede que necesite anotarlas. La solucin ms adecuada por ahora puede consistir en utilizar sistemas de identificacin nicos (single sign-on) que faciliten la administracin y el acceso, permitindolo o no a segn qu usuarios/sistemas/funciones, o bien adoptar cualquier otro tipo de solucin que, con garantas suficientes, pueda propagar la contrasea entre sistemas. En la auditora debemos verificar que el proceso de altas de usuarios se realiza segn la normativa en vigor, y que las autorizaciones requeridas son adecuadas, as como la gestin posterior como variaciones y bajas, y que los usuarios activos siguen vigentes, y si se revisa cules son inactivos y porqu, por ejemplo contrastando peridicamente con la base de datos de empleados y contratados. Debiera estar previsto bloquear a un usuario que no accediera en un perodo determinado 35 das? Otra posible debilidad que debe considerarse en la auditora es si pueden crearse situaciones de bloqueo porque slo exista un administrador, que puede estar ausente de forma no prevista, por ejemplo por haber sufrido un accidente, e impedir la creacin de nuevos usuarios en un sistema de administracin centralizada y nica; en ms de una ocasin, segn de qu entorno se trate hemos recomendado la existencia de algn usuario no asignado con perfil especial y contrasea protegida que pueda utilizar alguien con autoridad en caso de emergencia: todas sus operaciones debern quedar registradas para control y auditora,

Auditora de la Seguridad y el Desarrollo de Aplicaciones Todos los desarrollos deben estar autorizados a distinto nivel segn la importancia del desarrollo a abordar, incluso autorizados por un comit si los costes o los riesgos superan unos umbrales; se revisar la participacin de usuarios, y de los auditores internos si la auditora es externa, a qu libreras pueden acceder los desarrolladores, si hay separacin suficiente de entornos, la metodologa seguida, ciclos de vida, gestin de los proyectos, consideraciones especiales respecto a aplicaciones que traten datos clasificados o que tengan transacciones econmicas o de riesgo especial, trminos de los contratos y cumplimiento, seleccin y uso de paquetes, realizacin de pruebas a distintos niveles y mantenimiento posterior, as como desarrollos de usuarios finales. El pase al entorno de explotacin real debe estar controlado, no descartndose la revisin de programas por parte de tcnicos independientes, o bien por auditores preparados, a fin de determinar la ausencia de caballos de Troya, bombas lgicas y similares, adems de la calidad. Otro aspecto es la proteccin de los programas, al menos desde dos perspectivas: de los programas que sean propiedad de la entidad, realizados por el personal propio o contratado su desarrollo a terceros, como el uso adecuado de aquellos programas de los que se tenga licencia de uso.

Auditora de la Seguridad en el rea de Produccin Las entidades han de cuidar especialmente las medidas de proteccin en el caso de contratacin de servicios: desde el posible marcado de datos, proceso, impresin de etiquetas, distribucin, acciones comerciales, gestin de cobros, hasta el outsourcing ms completo, sin descartar que en el contrato se prevea la revisin por los auditores, internos o externos, de las instalaciones de la entidad que provee el servicio. Tambin debe revisarse la proteccin de utilidades o programas especialmente peligrosos, as como el control en generacin y cambios posteriores de todo el software de sistemas, y de forma especial el de control de accesos. Otro aspecto a revisar es el control de los formularios crticos. La gestin de problemas y cambios y la calidad son aspectos que tambin tienen que ver con la seguridad.

Auditora de la Seguridad de los Datos Es un aspecto que puede entenderse dentro de la Produccin y las Comunicaciones, pero que merece ser tratado de forma especfica. Decamos que los datos y la informacin pueden llegar a constituir el activo ms crtico para la entidad, hasta el punto de que en muchas multinacionales la funcin genrica de administracin de seguridad tiene la denominacin de Data Security.

Los datos, adems de alfanumricos, pueden consistir en imgenes de planos, en otros diseos u objetos, grficos, acsticos, y otros, y estar almacenados en medios y soportes diversos. La proteccin de los datos puede tener varios enfoques respecto a las caractersticas citadas: la confidencialidad, disponibilidad e integridad. Puede haber datos crticos en cuanto a su confidencialidad, como datos mdicos u otros especialmente sensibles (sobre religin, sexo, raza...), otros datos cuya criticidad viene dada por la disponibilidad: si se pierden o no se pueden utilizar a tiempo pueden causar perjuicios graves y, en los casos ms extremos poner en peligro la continuidad de la entidad, y finalmente otros datos crticos atendiendo a su integridad, especialmente cuando su prdida no puede detectarse fcilmente o una vez detectada no es fcil reconstruirlos. Tipos de controles en la seguridad de los datos, que es lo que ha de revisarse en la auditora: Desde el origen del dato, que puede ser dentro o fuera de la entidad, y puede incluir preparacin, autorizacin, incorporacin al sistema: por el cliente, por empleados, o bien ser captado de otra forma, y debe revisarse cmo se verifican los errores. Proceso de los datos: controles de validacin, integridad, almacenamiento: que existan copias suficientes, sincronizadas y protegidas. Salida de resultados: controles en transmisiones, en impresin, en distribucin, en servicios contratados de manipulacin y en el envo; conciliacin previa de salidas con entradas, por personas diferentes, para detectar errores y posibles Intentos de fraude. Retencin de la informacin y proteccin en funcin de su clasificacin: destruccin de los diferentes soportes que la contengan cuando ya no sea necesaria, o bien desmagnetizacin. Es necesaria la designacin de propietarios, clasificacin de los datos, restriccin de su uso para pruebas, inclusin de muescas para poder detectar usos no autorizados, as como aprovechar las posibilidades de proteccin, control y auditora del Sistema de Gestin de Bases de Datos que se est utilizando. En cuanto a la clasificacin de datos e informacin debe revisarse quin la ha realizado y segn qu criterios y estndares; no suele ser prctico que haya ms de cuatro o cinco niveles. En ocasiones la denominacin sin clasificar se aplica tanto a los datos que no requieren proteccin -en ocasiones incluso conviene divulgarlos- como a los que estn pendientes de clasificar, por lo que es necesario diferenciar las dos situaciones. Tambin es conveniente que se distinga por categoras, asociadas a reas funcionales o proyectos. Aquellos soportes que contengan datos o informacin de los niveles ms crticos estarn especialmente protegidos, incluso cifrados. Entre esos soportes pueden estar: magnticos, papel, comunicaciones, correo electrnico, fax, e incluso voz. En algunas entidades tienen etiquetas o cartulas para diferenciar soportes, listados y documentos cuyo contenido est especialmente clasificado, lo que en ocasiones puede llegar a alertar incluso a distancia a quienes no estn autorizados. Respecto a cliente/servidor es necesario verificar los controles en varios puntos, y no slo en uno central como en otros sistemas, y a veces en plataformas heterogneas, con niveles y caractersticas de seguridad muy diferentes, y con posibilidad de transferencia de ficheros o de captacin y exportacin de datos que pueden perder sus protecciones al pasar de una plataforma a otra. En el caso del contenido de ficheros y bases de datos, las etiquetas debieran acompaarles incluso en extracciones parciales que variaran de plataforma, lo que en la actualidad no est plenamente conseguido en todos los casos cuando en las redes intervienen plataformas y sistemas que no se entienden bien entre s en cuanto a seguridad; aunque en este momento hay intentos de cierta normalizacin y van apareciendo herramientas que van permitiendo la proteccin en entornos heterogneos. Tambin pueden usarse bases de datos distribuidas, lo que puede aadir complejidad al sistema y a los controles a establecer. La informacin del nivel ms alto de clasificacin normalmente se entregar (o dejar ver) bajo controles estrictos, incluso anotando qu se entreg o ense, a quines, cundo, y con la autorizacin de quin si este extremo es necesario. En la auditora, si entra en los objetivos, se analizar la destruccin de la informacin clasificada: tipo de destructora, tamao de las partculas, y especialmente dnde se almacena hasta su destruccin, que suele ser un punto dbil. En el caso de soportes magnticos stos habrn de ser destruidos, desmagnetizados de forma adecuada, o sometidos a varias grabaciones diferentes antes de su nueva utilizacin. En el caso de ser necesario el transporte de datos clasificados debe realizarse por canales seguros, y si es en soporte magntico o por transmisin deben ir cifrados, adems de la posibilidad de transportar

soportes magnticos en compartimentos cerrados y que la llave no est en poder de los transportistas o est protegida.

Auditora de la Seguridad en Comunicaciones y Redes En las polticas de la entidad debe reconocerse que los sistemas, redes y mensajes transmitidos y procesados son propiedad de la entidad y no deben usarse para otros fines no autorizados, por seguridad y por productividad, tal vez salvo emergencias concretas si as se ha especificado, y ms bien para comunicaciones por voz. En funcin de la clasificacin de los datos se habr previsto el uso de cifrado, que en la auditora se evaluar o se llegar a recomendar, y se revisarn la generacin, longitud, comunicacin, almacenamiento y vigencia de las claves, especialmente de las maestras. Cada usuario slo debe recibir en el men lo que pueda seleccionar realmente. Los usuarios tendrn restriccin de accesos segn dominios, nicamente podrn cargar los programas autorizados, y slo podrn variar las configuraciones y componentes los tcnicos autorizados. Debern existir protecciones de distinto tipo, y tanto preventivas como de deteccin, ante posibles accesos sobre todo externos, as como frente a virus por diferentes vas de infeccin, incluyendo el correo electrnico. Se revisarn especialmente las redes cuando existan repercusiones econmicas porque se trate de transferencia de fondos o comercio electrnico. Algunas de los puntos complementarios a revisar son: Tipos de redes y conexiones. Informacin y programas transmitidos, y uso de cifrado. Tipos de transacciones. Tipos de terminales y protecciones: fsicas, lgicas, llamada de retorno. Proteccin de transmisiones por fax s el contenido est clasificado, si bien es preferible evitar el uso de este medio en ese caso. Proteccin de conversaciones de voz en caso necesario. Transferencia de ficheros y controles existentes. Consideracin especial respecto a las conexiones externas a travs de pasarelas (gateway) y encaminadores (routers), as como qu controles existen. Ante la generalizacin de modalidades avanzadas de proceso, empiezan a preocupar y a ser objeto de auditora aspectos como: Internet e Intranet: separacin de dominios e implantacin de medidas especiales, como normas y cortafuegos (firewall), y no slo en relacin con la seguridad sino por accesos no justificados por la funcin desempeada, como a pginas de ocio o erticas, por lo que pueden suponer para la productividad. El correo electrnico, tanto por privacidad (PGP, Pretty Good Privacy se est usando mucho) y para evitar virus como para que el uso del correo sea adecuado y referido a la propia funcin, y no utilizado para fines particulares, como se ha intentado hacer en muchas entidades y no siempre con xito, con otros recursos anteriores como telfono, fax, fotocopiadoras, o el uso de los propios ordenadores. Otro de los aspectos que preocupan es la proteccin de programas, y tanto la prevencin del uso no autorizado de programas propiedad de la entidad o de los que tenga licencia de uso, como la carga o transmisin de otros de los que no se tenga licencia o simplemente para los que no exista autorizacin interna. Tambin preocupa el control sobre las pginas web: quin puede modificarlo y desde dnde, porque se han dado casos desagradables en alguna entidad que impactan muy negativamente en su imagen, y no tanto por los que lo ven directamente, sino por la publicidad que en los medios se pueden dar a estos hechos. Finalmente preocupan tambin los riesgos que puedan existir en el comercio electrnico, aunque se estn empezando a utilizar sistemas fiables como SET (Secure Electronic Transaction). En relacin con todo ello, y para facilitar el control y la auditora, es necesario que queden registrados los accesos realizados a redes exteriores y protegidos esos registros, as como la fecha y hora y el usuario o sistema, as como el tipo de informacin transferida y en qu sentido.

Auditora de la Continuidad de las Operaciones Es uno de los puntos que nunca se deberan pasar por alto en una auditora de seguridad, por las consecuencias que puede tener el no haberlo revisado o haberlo hecho sin la suficiente profundidad: no basta con ver un manual cuyo ttulo sea Plan de Contingencia o denominacin similar, sino que es imprescindible conocer si funcionara con las garantas necesarias y cubrira los requerimientos en un tiempo inferior al fijado y con una duracin suficiente. Hablamos de Plan de Contingencia o Plan de Continuidad, frente a otras denominaciones que en principio descartamos como Recuperacin de Desastres o Plan de Desastres. En la auditora es necesario revisar si existe tal plan, si es completo y actualizado, si cubre los diferentes procesos, reas y plataformas, o bien si existen planes diferentes segn entornos, evaluar en todo caso su idoneidad, as como los resultados de las pruebas que se hayan realizado, y si permite garantizar razonablemente que en caso necesario, y a travs de los medios alternativos, propios o contratados, podra permitir la reanudacin de las operaciones en un tiempo inferior al fijado por los responsables del uso de las aplicaciones, que a veces son tambin los propietarios de las mismas pero podran no serlo. Si las revisiones no nos apodan garantas suficientes debemos sugerir pruebas complementarias o hacerlo constar en el informe, incluso indicarlo en el apartado de limitaciones. Es necesario verificar que la solucin adoptada es adecuada: centro propio, ajeno compartido o no... y que existe el oportuno contrato si hay participacin de otras entidades aunque sean del mismo grupo o sector. Un punto fundamental en la revisin es la existencia de copias actualizadas de los recursos vitales en un lugar distante y en condiciones adecuadas tanto fsicas como de proteccin en cuanto a accesos; entre dichos recursos estarn: bases de datos y ficheros, programas (mejor si existen tambin en versin fuente), JCL (Job Control Language) o el equivalente en cada sistema, la documentacin necesaria, formulados crticos y consumibles, documentacin, manuales tcnicos, direcciones y telfonos, los recursos de comunicaciones necesarios: datos y voz, y cualesquiera otros requeridos para funcionar con garantas. Otras debilidades a veces son: que exista copia del propio plan fuera de las instalaciones primarias, que est previsto ejecutar determinado software en un equipo alternativo, con identificacin especfica diferente de la del equipo primario que es el inicialmente autorizado; y que se tenga copia accesible del contrato, tanto para demostrar algo al proveedor como para verificar los trminos pactados. Es necesario en la auditora conocer las caractersticas del centro o sistema alternativo, y debe revisarse si la capacidad de proceso, la de comunicacin y la de almacenamiento del sistema alternativo son suficientes, as como las medidas de proteccin. Debe existir un manual completo y exhaustivo relacionado con la continuidad en el que se contemplen diferentes tipos de incidencias y a qu nivel se puede decidir que se trata de una contingencia y de qu tipo. A pesar de la importancia del tema y de las consecuencias nefastas que se pueden derivar si no se han previsto las contingencias es muy frecuente que los mismos no existan.

This document was created with Win2PDF available at http://www.daneprairie.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only.