Metododlogias auditoria informatica gy graccmelendez ‘IORúpR 15, 2011 28 pagos REPUBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DE EDUCACION SUPERIOR INSTITUTO UNIVERSITARIO DE TECNOLOGIA JUAN PABLO PEREZ ALFONSO (IUTEPAL) SAN FRANCISCO, ESTADO ZULIA Metodología para la realización de una Auditoría de Sistemas de Información Realizado por: Yocelys Martínez C. I. 12. 380. 14 San Francisco, Novie PACE 1 or28 INTRODUCCION to View nut*ge Una de las principale reocu de enes adquieren un sistema de inform us problemas organizacionales es q en que las inversiones que han realizado den soluciones inmediatas, angibles y medibles; y allí donde se veía una oportunidad de mejora, realmente están creando un problema difícil de administrar, controlar y caro de mantener.
Es all( cuando la Auditoria Informática se considera como una herramienta esencial para gestionar el uso adecuado de la tecnología de información, apoyado en la aplicacion de la normativa legal y en estándares informáticos internacionales. Todas las metodologías existentes en seguridad de sistemas van encaminadas a establecer y mejorar un entramado de contramedidas que garanticen que la productividad de que las menazas se materialicen en hechos sea lo más baja posible o al menos quede reducida de una forma razonable en costo- benefic10. sistema de información.
Para organizar las actividades de la Auditoria de Sistemas de Información, la cual contribuya a salvar las brechas existentes entre riesgos de negocio, necesidades de control y aspectos técnicos; que sea aplicable a todos los tamaños y tipos de organización, y que esté dirigida no sólo a auditores de sistemas, sino también a la administración y a los usuarios; que permita además, determinar el alcance de la tarea de auditoría e dentificar los controles mínimos, y que pueda utilizarse como una herramienta de auto-evaluación del área de tecnología informática, es necesario adoptar una metodolog(a En los últimos años se ha incrementado la atención sobre los controles internos, tanto para los audltores, los gerentes, los contadores, como para las entidades reguladoras en general.
Como resultado de un continuo y trabajoso esfuerzo, se han desarrollado varios documentos para definir, valorizar, reportar y mejorar el control interno y ser utilizados como marco de referencia en las organizaciones. En resumen, éstos son: ?? Informe COSO – (Committee of Sponsoring Organizations), de la Comisión de Estudios de Controles Internos. • SAC – (Systems Auditability and Control), de la Fundación de Investigaclón del Instituto de Auditores Internos. • SAS 55 y SAS 78 – Consideraciones de la estructura de Controles Internos en los Informes de los Estados Financieros, del Instituto Americano de Contadores Públicos (CPA) • COBIT (Control Objectives for Information and related Technology), de la Fundación de Auditoría y Control de Sistemas de Información.
Cada uno de ellos ha sido definido para una audiencia en articular: el «COSO» fue diseñado para la Gerencia; el «SAC» para los auditores in 2 8 audiencia en particular: el «COSO» fue diseñado para la Gerencia; el «SAC» para los auditores internos; los SAS 55 y SAS 78 para los auditores externos, y finalmente el «COBIT’ enfocado pnncpalmente para los auditores de sistemas de información. Uno de los estándares que más se están utilizando en el mundo para ser tomado como base para realizar una metodología de control interno en el ambiente de tecnología informática y sistemas de información, es el denominado COBIT (Control Objetives for Information and Related Technology), el cual es un marco de referencia y se fundamenta en los objetivos de control existentes de la Information Systems Audit and Control Foundation (ISACF), y que ha sido mejorado a partir de estándares internacionales técnicos, profesionales, regulatonos y específicos para la industria.
El marco de referencia COBIT otorga especial importancia al impacto sobre los recursos de tecnología informática, así como a los requerimientos de negocios en cuanto a efectividad, eficiencia, confidencialidad, integridad, disponibilidad, cumplimiento y confiabilidad que deben ser satisfechos. Además, el marco de referencia proporciona definiciones para los requerimientos de negocio que son derivados de objetivos de control superiores en lo referente a calidad, seguridad y reportes fiduciarios en tanto se relacionen con tecnología de información. La orientación a negocios es el tema principal de COBIT. Está diseñado no sólo para ser utilizado por usuarios y auditores, sino que en forma más importante, está diseñado para ser utilizado como una lista de verificación detallada para los propietarios de los procesos de negocio.
En forma incremental, las prácticas de egocio requieren de una mayor 28 negocio requieren de una mayor delegación y otorgamiento de autoridad de los dueños de procesos para que éstos posean total responsabilidad de todos los aspectos relacionados con dichos procesos de negocio. En forma particular, esto incluye el proporcionar controles adecuados y herramientas al propietario de procesos de negocio que faciliten el cumplimiento de esta responsabilidad. Ya que una de las preguntas más frecuentes que se realizan los auditores es: ¿Cuál es la mínima cantidad de controles que se deben implementar para poder decir: «está bien controlado»?. Este marco de referencia intenta contestar esta pregunta definiendo los «Objetivos de Control» que deben estar implementados para todas las actividades dentro de la función de tecnología informática y sistemas de información.
El desarrollo del marco de referencia COBIT ha sido limitado a objetivos de control de alto nivel en forma de necesidades de negocio dentro de un proceso de tecnología informática particular, cuyo logro es posible a través del establecimiento de controles, para el cual deben considerarse controles aplicables potenciales. Revisión periódica de controles internos. Para cada objetivo se estudiarán 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 corrección de los planes. Si una simple comprobación no ofrece ninguna evidencia, será necesaria la realización de exámenes más profundos.
En los controles en los que sea impracticable una revisión exhaustiva de los elementos de verificación, bien sea porque 4 28 que sea impracticable una revisión exhaustiva de los elementos de verificación, bien sea porque los recursos de auditoría sean imitados o porque el número de elementos a inspeccionar sea muy elevado, se examlnará una muestra representativa que permita inferir el estado de todo el conjunto. La revisión periódica de controles internos incluye los siguientes pasos a seguir: 1. Las Normas Generales de la Instalación Informática. Se realizará una revisión inicial sin estudiar a fondo las contradicciones que pudieran existir, pero registrando las áreas que carezcan de normativa, y sobre todo verificando que esta Normativa General Informática no está en contradicción con alguna Norma General no informátlca de la empresa. 2. Los Procedimientos Generales Informáticos.
Se verificará su existencia, al menos en los sectores más importantes. por ejemplo, la recepción definitiva de las máquinas debería estar firmada por los responsables de Explotación. Tampoco el alta de una nueva Aplicación podría producirse si no existieran los Procedimientos de Backup y Recuperacion correspondientes. 3. Los Procedimientos Específicos Informáticos. Igualmente, se revisara su existencia en las áreas fundamentales. Así, Explotación no debería detonar una Aplicaclón sin haber exigido a Desarrollo la pertinente documentación. Del mismo modo, deberá omprobarse que los Procedimientos Especficos no se opongan a los Procedimientos Generales.
En todos los casos anteriores, a su vez, deberá verificarse que no existe contradicción alguna con la Normativa y los Procedimientos Generales de la propia empresa, a los que la Informática debe estar sometida. Levantamiento de flujos de transacciones y procedimientos. Es la primera e s 8 Informática debe estar sometida. Es la primera etapa de la auditoria y es en dónde el auditor debe obtener información detallada respecto a las caracteristlcas del flujo de transacciones en área funcional sujeta a su examen. Implica conocer previamente la estructura de la empresa, con el fin de identificar los ciclos de operación en que se localizan los sistemas, los procedimientos y los métodos a que el auditor enfrentará. El levantamiento de información se basa en las siguientes técnicas: * Entrevistas Observaclones de Campo.
La etapa de Levantamiento de información se caracteriza por el hecho de que el auditor averigua exclusivamente las características de un sistema mediante indagaciones con todo el personal involucrado, desde el más alto ejecutivo hasta el último de los ayudantes. Determinación de objetivos de control de funciones. Un «Objetivo de Control», es una definición del resultado o propósito que se desea alcanzar implementando procedimientos de control específicos dentro de una actividad de tecnología informática y sistemas de información. Los objetivos de control muestran una relación clara y distintiva con los objetivos de negocio con el fin de apoyar su uso dentro de toda la organización y más allá del uso exclusivo de los auditores. Los Objetivos de Control están definidos con una orientación a los procesos, siguiendo el principio de reingeniería de negocios.
Estos objetivos de control de tecnología Informática han sido organizados por proceso / actividad, pero también se facilita la entrada a partlr de cualquier punto de vista estratégico, además para lograr enfoques combinados o globales, tales c 6 8 vista estratégico, además para lograr enfoques combinados o globales, tales como instalación / implementación de un proceso, responsabilidades gerenciales globales para un proceso y utilización de recursos de tecnología informática por un proceso. Para mayor facilidad los Objetivos de Control, dentro del COBIT an sido definidos en una manera genérica, sin depender de la plataforma técnica. El marco de referencia identifica un conjunto de 34 Objetivos de Control de alto nivel, uno para cada uno de los procesos de tecnología informatica, agrupados en cuatro dominios: planeación y organización, adquisición e implementación, entrega (de servicio) y monitoreo.
Cubriendo todos los aspectos de tecnología informática. Dingiendo estos 34 Objetivos de Control de alto nivel, el propietario de procesos de negocio podrá asegurar que se proporciona un sistema de control adecuado para el ambiente de ecnología de información. Adicionalmente, correspondiendo a cada uno de los 34 objetivos de control de alto nivel, existe una guía de auditoría o de aseguramiento que permite la revisión de los procesos de tecnología informática, contra los 302 objetivos detallados de control recomendados por COBIT para proporcionar la certeza de su cumplimiento y/o una recomendación para su mejora. Evaluación de seguridad.
La evaluación de seguridad en un sistema resulta beneficioso aplicar listas de chequeo, estas no son un sustituto del formal análisis de riesgos, más bien, al realizarse constituye un punto de artida a éste en aquellos puntos que quedan sujetos a revisión. Además que se pueden tomar medidas correctivas en forma rápida, que no implican mayor costo y esfuerzo. Listas de chequeo La lista de chequeo es consider La lista de chequeo es considerada como una herramienta de auditoria, es uno de los métodos de evaluaclón más viejos ampliamente usados, en seguridad informática consiste en revisar si existen controles administrativos, operativos y técnicos, este proceso no evalúa la efectividad de los controles implantados. Además se identifica que se cumplan los principios e seguridad generalmente aceptados (GSSPs).
Controles administrativos: estos controles hacen referencia a la recolección de documentos como: politicas y normatividad general referente a la seguridad del sistema. [NISTI] Controles operatlvos: estos controles hacen referencia a los procedimientos que siNen para asegurar los requerimientos de seguridad. Ejemplo: planes de contingencia, manejo de incidentes, realización de backups etc. Controles técnicos: estos controles hacen referencia a cualquier dispositivo de hardware o software que aseguran el cumplimiento de los requerimientos de seguridad. Ejemplo: control de acceso y autorización, firewalls, mecanismos de auditoria de eventos, etc.
Por otro lado independiente de si existe en la organizacion o no información estadística de los elementos que determinan los riesgos, es recomendable al grupo evaluador realizar el proceso de análisis de riesgos, así sea en forma cualitativa, con el objeto de crear esta cultura en la organización. Análisis de riesgos El proceso de identificar, analizar y valorar, mitigar o transferir el riesgo es generalmente caracterizado como manejo del riesgo. Hay una serie de preguntas que se hacen en este proceso: 1 . ?Que podría ocurrir? (amenaza) 2. ¿Sl• ocurre, cuánto daño podría causar? 28 en este proceso: 1 . ¿Que podría ocurrir? (amenaza) 2. ¿Sl’ ocurre, cuánto daño podría causar? (impacto) 3. ¿Qué tan a menudo podría ocurrir? 4. ?Qué tan ciertas son las respuestas a las anteriores preguntas? Una vez respondidas acertadamente las anteriores preguntas, se responden ahora las siguientes: 1 . ¿Qué puede ser hecho? (mitigación del riesgo) 2. ¿Cuál es el costo de la medida? (anual) 3. ¿Es la medida efectiva? (análisis costo/beneficio) El manejo de riesgos compara el costo de implementar medidas e seguridad contra los costos generados al ocurrir un evento desfavorable en el sistema que afecte directa o Indirectamente la prestación de servicios. El análisis de riesgos busca cuantificar el impacto de las amenazas potenciales sobre un sistema, comprende cuatro subetapas: 1 -Planeación del análisis de riesgos.
Si el sistema a evaluar es muy complejo y la organización es muy grande, es conveniente para el analista de seguridad elaborar un análisis de riesgos por subsistemas, lo que facilitará también la presentación y comprensión de informes por parte de los directivos de la mpresa. 2. Identificación de amenazas y vulnerabilidades. Las amenazas en el sistema provienen del personal encargado, personal externo, daño en equipos, caída de enlaces, etc. Un análisis de vulnerabilidades, por ejemplo puede identificar solo la ausencia de medidas para reducir los riesgos, lo anterior se puede indicar cualitativamente en binario como si o no. Se encuentran las debilidades o vulnerabilidad desde los siguientes puntos de vista. ?? Vulnerabilidades de software: errores de aplicaciones, errores de sistemas operativos, rutinas de acceso no autorizados, servicios no autorizados ?? Vulnerabilidades de hard operativos, rutinas de acceso no autorizados, servicios no autorizados • Vulnerabilidades de hardware: inapropiada operación, fallas en mantenimiento, inadecuada seguridad física, falta de protección contra desastres naturales • Vulnerabilidades de datos: inadecuados controles de acceso a personal no autorizado • Vulnerabilidades administrativas: ausencia de políticas de seguridad, ausencia de cultura de seguridad, ausencia de procedimientos, falta de educación y entrenamiento en seguridad • Vulnerabilidades de comunicaciones: inadecuados controles de cceso a la red, inadecuados mecanismos para prevenir fallas en comunicaciones • Vulnerabilidades de personal (empleados): inadecuados controles de acceso físico, inadecuados controles de acceso lógico Por medio de entrevistas con cuestionarios previamente diseñados que contemplen los principios y prácticas de seguridad generalmente aceptados, se encontrarán las vulnerabilidades que tiene el sistema 3.
Valoración del impacto a) Método cuantitativo: en este punto se hace una revisión de la información que previamente se ha recolectado, la frecuencia sta basada en las diferentes bitácoras, logs y reportes de incidentes. El impacto se determina en forma cuantitativa tomando diversos: criterios, pero en últimas todos representan valores económicos: valor del # de operaciones que deja el sistema de procesar por la ocurrencia de un evento. Lo ideal es poder expresar el impacto en términos economicos. b) Métodos cualitativos. estos métodos valoran de una forma muy subjetiva el riesgo, a los elementos para valorar los riesgos generalmente se le asignan los valores de alto, medio y bajo. El grupo evaluador tenga expresado en términ
