Metodologia de una Auditoria en Sistemas

METODOLOGÍA DE UNA AUDITORÍA DE SISTEMAS

Existen algunas metodologías de Auditorias de Sistemas y todas dependen de lo que se pretenda revisar o analizar,

Pero como estándar analizaremos las cuatro fases básicas de un proceso de revisión:

• Estudio preliminar
• Revisión y evaluación de controles y seguridades
• Examen detallado de áreas criticas
• Comunicación de resultados

 Estudio preliminar:

Incluye definir el grupo de trabajo, el programa de auditoria, efectuar visitas a la unidad

Informática para conocer detalles de la misma, elaborar un cuestionario para la obtención de información para

Evaluar preliminarmente el control interno, solicitud de plan de actividades, Manuales de políticas, reglamentos,

Entrevistas con los principales funcionarios del PAD.

Revisión y evaluación de controles y seguridades:

Consiste de la revisión de los diagramas de flujo de procesos,

Realización de pruebas de cumplimiento de las seguridades, revisión de aplicaciones de las áreas criticas, Revisión de

Procesos históricos (backups), Revisión de documentación y archivos, entre otras actividades.

Examen detallado de áreas criticas:

Con las fases anteriores el auditor descubre las áreas críticas y sobre ellas hace

Un estudio y análisis profundo en los que definirá concretamente su grupo de trabajo y la distribución de carga del

Mismo, establecerá los motivos, objetivos, alcance Recursos que usará, definirá la metodología de trabajo, la

Duración de la auditoría, Presentará el plan de trabajo y analizará detalladamente cada problema encontrado con todo

Lo anteriormente analizado.

Comunicación de resultados:

Se elaborará el borrador del informe a ser discutido con los ejecutivos de la empresa

Hasta llegar al informe definitivo, el cual se presentará esquemáticamente en forma de matriz, cuadros o redacción

Simple y concisa que destaque los problemas encontrados, los efectos y las recomendaciones de la Auditoría.

El informe debe contener lo siguiente:

• Motivos de la Auditoría

• Objetivos

• Alcance

• Estructura Orgánico-Funcional del área Informática

• Configuración del Hardware y Software instalado

• Control Interno

• Resultados de la Auditoria

PLAN DE CONTINGENCIA

Consiste en la identificación de aquellos sistemas de información y/o recursos informáticos aplicados que son susceptibles de deterioro, violación o pérdida y que pueden ocasionar graves trastornos para el desenvolvimiento normal de la organización, con el propósito de estructurar y ejecutar aquellos procedimientos y asignar responsabilidades que salvaguarden la información y permitan su recuperación garantizando la confidencialidad, integridad y disponibilidad de ésta en el menor tiempo posible y a unos costos razonables.

El plan de contingencia debe cubrir todos los aspectos que se van a adoptar tras una interrupción, lo que implica suministrar el servicio alternativo y para lograrlo no solo se deben revisar las operaciones cotidianas, sino que también debe incluirse el análisis de los principales distribuidores, clientes, negocios y socios, así como la infraestructura en riesgo. Esto incluye cubrir los siguientes tópicos: hardware, software, documentación, talento humano y soporte logístico; debe ser lo más detallado posible y fácil de comprender.

Se debe evaluar el nivel de riesgo de la información para hacer:

• Un adecuado estudio costo/beneficio entre el costo por pérdida de información y el costo de un sistema de seguridad.
• Clasificar la instalación en términos de riesgo (alto, mediano, bajo) e identificar las aplicaciones que representen mayor riesgo.
• Cuantificar el impacto en el caso de suspensión del servicio.
• Determinar la información que pueda representar cuantiosas pérdidas para la organización o bien que pueda ocasionar un gran efecto en la toma de decisiones.

Cuando ocurra una contingencia, es esencial que se conozca al detalle el motivo que la originó y el daño producido mediante la evaluación y análisis del problema donde se revisen las fortalezas, oportunidades, debilidades y amenazas, lo que permitirá recuperar en el menor tiempo posible el proceso perdido.

El plan debe incluir una lista de los sistemas, aplicaciones y prioridades, igualmente debe identificar aquellos elementos o procedimientos informáticos como el hardware, software básico, de telecomunicaciones y el software de aplicación, que puedan ser críticos ante cualquier eventualidad o desastre y jerarquizarlos por orden de importancia dentro de la organización. También se deben incluir en esta categoría los problemas asociados por la carencia de fuentes de energía, utilización indebida de medios magnéticos de resguardo o back up o cualquier otro daño de origen físico que pudiera provocar la pérdida masiva de información.

Por todos es bien conocida la importancia que reviste en mantener activa y con fluidez la articulación Universidad – Empresa, de tal forma que el conocimiento impartido en las aulas de clase pueda ser contrastado con las realidades que se vive en las diferentes empresas, resultando beneficiadas ambas partes con planteamientos y soluciones acorde a las necesidades particulares que demanda la región y el país.

• Un Plan de Contingencia es la herramienta que cualquier empresa debe tener, para desarrollar la habilidad y los medios de sobrevivir y mantener sus operaciones, en caso de que un evento fuera de su alcance le pudiera ocasionar una interrupción parcial o total en sus funciones. Las políticas con respecto a la recuperación de desastres deben de emanar de la máxima autoridad Institucional, para garantizar su difusión y estricto cumplimiento.
• Deben realizarse pruebas para determinar la eficacia del plan de contingencia y de los procedimientos de recuperación ante desastres. Las deficiencias deben resolverse y comprobarse inmediatamente. En un plan de contingencia, el objetivo consiste en ejecutar varias tareas en el menor tiempo posible. Cualquier deficiencia en la documentación, capacitación o, incluso, en los aspectos administrativos, pone en peligro la continuidad del negocio.
• La puesta en marcha de los planes a seguir es responsabilidad del encargado de la seguridad, pero también debe existir un compromiso por parte de los usuarios del sistema de información, ejecutivos y todas las personas que de alguna u otra forma ayudan a que el sistema cumpla con los requerimientos para el que fue diseñado, manteniendo sobre todo la integridad y confidencialidad de la información.
• El plan de contingencias tiene diferentes niveles de complejidad y flexibilidad según las necesidades y características de los grupos, empresas u organizaciones. Nunca se contará con los recursos suficientes para estar totalmente preparados, de ahí que el proceso deba ser paulatino e ir evolucionando según el contexto.
• El cambio es inevitable en la construcción de sistemas basados en computadoras; por ello se deben desarrollar mecanismos de evaluación, control e implementación de modificaciones al sistema ocasionadas por nuevos requerimientos de los usuarios, por disposiciones internas de la organización y/o gubernamentales, para corregir errores, para aprovechar los nuevos avances tecnológicos, para satisfacer nuevas necesidades o para mejorar los sistemas en funcionamiento.
• Se debe tener una adecuada seguridad orientada a proteger todos los recursos informáticos desde el dato más simple hasta lo más valioso que es el talento humano, motor de desarrollo y vida de los sistemas de información; pero no se puede caer en excesos diseñando tantos controles y medidas que desvirtúen el propio sentido de la seguridad, por consiguiente, se debe hacer un análisis de costo/beneficio evaluando las consecuencias que pueda acarrear la pérdida de información y demás recursos informáticos, así como analizar los factores que afectan negativamente la productividad de la empresa. 

Riesgos Informaticos

 Riesgo es la incertidumbre que ocurra un evento que podría tener un impacto en el logro de los objetivos.

Los riesgos cuando se materializan, se denominan errores, irregularidades u omisiones, los cuales pueden generar una pérdida monetaria, en la imagen de la empresa o incumplimiento de normativa externa.

 Riesgo = Impacto * Probabilidad

• Impacto: es el efecto o consecuencia cuando el riesgo se materializa
• Probabilidad: representa la posibilidad que un evento dado ocurra.

Clasificacion de los reisgos informaticos:

 Riesgo Inherente:

Riesgo inherente son aquellos riesgos propios de la materia y/o componentes de ésta. Se entiende que una materia por su naturaleza tiene riesgos que surgen por diversas fuentes, como los errores, irregularidades o fallas que pudieran ser importantes en forma individual o en conjunto con otros riesgos. Los riesgos inherentes a la materia pueden tener o no controles elaborados por la dirección para mitigar su probabilidad o su impacto.

Los riesgos inherentes a la materia bajo análisis pueden ser relativos al entorno, ambiente interno, procesos, información, etc.

• Riesgo de Crédito: Exposición a una pérdida real o el costo de oportunidad como consecuencia del incumplimiento de pago de una persona natural o jurídica.
• Riesgo Financiero: ocurrencia de un imprevisto por variaciones o cambios en la economía local o internacional que podría afectar los descalces de caja o posiciones asumidas por inversiones y su liquidez, como asimismo los descalces globales de activos.
• Riesgo Operacional: Se define como el riesgo de pérdida debido a la inadecuación o fallas en los procesos, el personal y los sistemas internos o bien a causa de acontecimientos externos (fraudes, daños activos materiales, fallas en procesos,etc). Incluye riesgos legales y normativos.

Riesgo de Integridad de la Información: Agrupa todos los riesgos asociados con la autorización, integridad, y exactitud de las transacciones según se ingresan, se procesan, se resumen y se informan en los sistemas computacionales de una organización, manifestándose en los siguientes componentes de un sistema:

•  Interfaz usuaria; se refiere a si existen restricciones que hagan que los trabajadores de una organización estén autorizados a desarrollar funciones de negocio sobre necesidad del negocio y la necesidad de lograr una segregación de funciones razonable.
• Procesamiento; se relacionan a la existencia de controles que aseguran que el procesamiento de datos se ha completado y realizado a tiempo.

 Riesgo de Acceso; puede ocurrir en cada uno o todos de los siguientes cinco niveles:

•  Red, el riesgo en esta área está generado por el riesgo de acceso inapropiado a la red a pc´s y servidores.
• Ambiente de Procesamiento, el riesgo se genera con el acceso indebido al ambiente de procesamiento a los programas y datos que están almacenados en ese ambiente.
• Sistemas de Aplicación, está dado por una inadecuada segregación de funciones que podría ocurrir si el acceso a los sistemas estuviese concedido a personas con necesidades de negocio sin definiciones claras.
• Acceso Funcional, dentro de aplicaciones (Código fuente)
• Acceso a nivel de campo o dato.

Riesgo de Disponibilidad

• Riesgos asociados con la interrupción de los sistemas a corto plazo donde las técnicas de restitución/recuperación se pueden utilizar para minimizar el alcance de la interrupción
• Riesgos asociados con desastres que causan interrupciones en el procesamiento de la información a largo plazo y que se centran en controles como backups y planes de contingencia. La capacidad de la empresa para continuar con sus operaciones y procesos críticos puede depender en gran medida de la disponibilidad de determinados sistemas de información.

Riesgo de Infraestructura una organización no tenga una infraestructura eficaz de información tecnológica (HW, SW, personas y procesos) para apoyar eficazmente las necesidades actuales y futuras del negocio de una forma eficiente y eficaz en términos de costos y controles. Principalmente están relacionados con:

• Planificación organizacional; el riesgo de que los planes de información tecnológica no estén integrados con los planes del negocio presentes y futuros, afectando el proceso de toma de decisiones y planificaciones inadecuadas.
• Definición y despliegue de sistemas de aplicación; el riesgo de que las definiciones y necesidades de los usuarios para nuevas soluciones de sistemas provoquen diseños ineficaces o incompletos. Los esfuerzos de desarrollo no siguen un enfoque consistente para confirmar la satisfacción del usuario y del negocio. Los esfuerzos de implantación no consideran adecuadamente el entrenamiento

 MATRIZ DE RIESGO

Herramienta fundamental, para evaluar los controles que deben de estar presentes tanto en las aplicaciones como en su entorno. Seleccionadas aquellas funciones que constituyen riesgos y causas de riesgo, pueden ser evaluados con precisión, el éxito alcanzado por cada control, determinando aquellos, que por débiles o insuficientes, actúan adversamente o con un efecto inversamente proporcional al esperado (causas de riesgos).

 Análisis de Riesgos Informáticos

El análisis de riesgos informáticos es un proceso que comprende la identificación de activos informáticos, sus vulnerabilidades y amenazas a los que se encuentran expuestos así como su probabilidad de ocurrencia y el impacto de las mismas, a fin de determinar los controles adecuados para aceptar, disminuir, transferir o evitar la ocurrencia del riesgo.

El proceso de análisis de riesgo genera habitualmente un documento al cual se le conoce como matriz de riesgo. En este documento se muestran los elementos identificados, la manera en que se relacionan y los cálculos realizados. Este análisis de riesgo es indispensable para lograr una correcta administración del riesgo. La administración del riesgo hace referencia a la gestión de los recursos de la organización. Existen diferentes tipos de riesgos como el riesgo residual y riesgo total así como también el tratamiento del riesgo, evaluación del riesgo y gestión del riesgo entre otras. La fórmula para determinar el riesgo total es: RT (Riesgo Total) = Probabilidad x Impacto Promedio A partir de esta fórmula determinaremos su tratamiento y después de aplicar los controles podremos obtener el Riesgo Residual.

Como se describe en el BS ISO / IEC 27001:2005, la evaluación del riesgo incluye las siguientes acciones y actividades.

• Identificación de los activos

• Identificación de los requisitos legales y de negocios que son relevantes para la identificación de los activos

• Valoración de los activos identificados

• Teniendo en cuenta los requisitos legales identificados de negocios y el impacto de una pérdida de confidencialidad, integridad y disponibilidad.

• Identificación de las amenazas y vulnerabilidades importantes para los activos identificados.

• Evaluación del riesgo, de las amenazas y las vulnerabilidades a ocurrir.

• Cálculo del riesgo.

• Evaluación de los riesgos frente a una escala de riesgo preestablecidos

Después de efectuar el análisis debemos determinar las acciones a tomar respecto a los riesgos residuales que se identificaron. Las acciones pueden ser:

• Controlar el riesgo.- Fortalecer los controles existentes y/o agregar nuevos controles.
• Eliminar el riesgo.- Eliminar el activo relacionado y con ello se elimina el riesgo.
• Compartir el riesgo.- Mediante acuerdos contractuales parte del riesgo se traspasa a un tercero.

Aceptar el riesgo.- Se determina que el nivel de exposición es adecuado y por lo tanto se acepta.

PROCEDIMIENTOS Y TECNICAS DE AUDITORIA.

Se requieren varios pasos para realizar una auditoría. El auditor de sistemas debe evaluar los riesgos globales y luego desarrollar un programa de auditoría que consta de objetivos de control y procedimientos de auditoría que deben satisfacer esos objetivos. El proceso de auditoría exige que el auditor de sistemas reúna evidencia, evalúe fortalezas y debilidades de los controles existentes basado en la evidencia recopilada, y que prepare un informe de auditoría que presente esos temas en forma objetiva a la gerencia. Asimismo, la gerencia de auditoría debe garantizar una disponibilidad y asignación adecuada de recursos para realizar el trabajo de auditoría además de las revisiones de seguimiento sobre las acciones correctivas emprendidas por la gerencia.

Planificación de la auditoria

Una planificación adecuada es el primer paso necesario para realizar auditorías de sistema eficaces. El auditor de sistemas debe comprender el ambiente del negocio en el que se ha de realizar la auditoría así como los riesgos del negocio y control asociado. A continuación se menciona algunas de las áreas que deben ser cubiertas durante la planificación de la auditoría:

1. Comprensión del negocio y de su ambiente. Al planificar una auditoría, el auditor de sistemas debe tener una comprensión de suficiente del ambiente total que se revisa. Debe incluir una comprensión general de las diversas prácticas comerciales y funciones relacionadas con el tema de la auditoría, así como los tipos de sistemas que se utilizan. El auditor de sistemas también debe comprender el ambiente normativo en el que opera el negocio. Por ejemplo, a un banco se le exigirá requisitos de integridad de sistemas de información y de control que no están presentes en una empresa manufacturera. Los pasos que puede llevar a cabo un auditor de sistemas para obtener una comprensión del negocio son: Recorrer las instalaciones del ente. Lectura de material sobre antecedentes que incluyan publicaciones sobre esa industria, memorias e informes financieros. Entrevistas a gerentes claves para comprender los temas comerciales esenciales. Estudio de los informes sobre normas o reglamentos. Revisión de planes estratégicos a largo plazo. Revisión de informes de auditorías anteriores.
2. Riesgo y materialidad de auditoria.  Se puede definir los riesgos de auditoría como aquellos riesgos de que la información pueda tener errores materiales o que el auditor de sistemas no pueda detectar un error que ha ocurrido. Los riesgos en auditoria pueden clasificarse de la siguiente manera: Riesgo inherente: Cuando un error material no se puede evitar que suceda por que no existen controles compensatorios relacionados que se puedan establecer. Riesgo de Control: Cuando un error material no puede ser evitado o detectado en forma oportuna por el sistema de control interno. Riesgo de detección: Es el riesgo de que el auditor realice pruebas exitosas a partir de un procedimiento inadecuado. El auditor puede llegar a la conclusión de que no existen errores materiales cuando en realidad los hay. La palabra "material" utilizada con cada uno de estos componentes o riesgos, se refiere a un error que debe considerarse significativo cuando se lleva a cabo una auditoría. En una auditoría de sistemas de información, la definición de riesgos materiales depende del tamaño o importancia del ente auditado así como de otros factores. El auditor de sistemas debe tener una cabal comprensión de estos riesgos de auditoría al planificar. Una auditoría tal vez no detecte cada uno de los potenciales errores en un universo. Pero, si el tamaño de la muestra es lo suficientemente grande, o se utiliza procedimientos estadísticos adecuados se llega a minimizar la probabilidad del riesgo de detección. De manera similar al evaluar los controles internos, el auditor de sistemas debe percibir que en un sistema dado se puede detectar un error mínimo, pero ese error combinado con otros, puede convertiré en un error material para todo el sistema. La materialidad en la auditoría de sistemas debe ser considerada en términos del impacto potencial total para el ente en lugar de alguna medida basado en lo monetario.
3. Técnicas de evaluación de Riesgos  Al determinar que áreas funcionales o temas de auditoría que deben auditarse, el auditor de sistemas puede enfrentarse ante una gran variedad de temas candidatos a la auditoría, el auditor de sistemas debe evaluar esos riesgos y determinar cuales de esas áreas de alto riesgo debe ser auditada. Existen cuatro motivos por los que se utiliza la evaluación de riesgos, estos son: Permitir que la gerencia asigne recursos necesarios para la auditoría. Garantizar que se ha obtenido la información pertinente de todos los niveles gerenciales, y garantiza que las actividades de la función de auditoría se dirigen correctamente a las áreas de alto riesgo y constituyen un valor.
4. Objetivos de controles y objetivos de auditoria. El objetivo de un control es anular un riesgo siguiendo alguna metodología, el objetivo de auditoria es verificar la existencia de estos controles y que estén funcionando de manera eficaz, respetando las políticas de la empresa y los objetivos de la empresa.
5. Procedimientos de auditoria.  Algunos ejemplos de procedimientos de auditoría son: Revisión de la documentación de sistemas e identificación de los controles existentes. Entrevistas con los especialistas técnicos a fin de conocer las técnicas y controles aplicados. Utilización de software de manejo de base de datos para examinar el contenido de los archivos de datos. Técnicas de diagramas de flujo para documentar aplicaciones automatizadas.

Mas informacion sobre Auditoria de Sistemas

http://www.itchetumal.edu.mx/paginasvar/Maestros/mduran/Archivos/METODOLOGIA%20DE%20UNA%20AUDITORIA%20DE%20SISTEMAS.pdf