Manual de Auditoría de Sistemas

54
Auditoría de Sistemas Las funciones de la auditoría son: Evalua (determina),verifica (evidencias) y diseña los controles en las actividades y recursos de cómputo de las empresas. Promueve la automatización de las diferentes modalidades de la auditoría. Objetivos 1. Auditoría a la Seguridad en el Centro de Cómputo Riesgos Físicos Organización y Personal Planes de Respaldo 2. Auditoría en: Sistema Operativo Software Aplicativo Archivos 3. Auditoría a las Aplicaciones en Funcionamiento Entrada de Datos Procesamiento Archivos Salidas Utilitarios 4. Auditoría al Desarrollo y/o modificaciones a las aplicaciones Solicitudes Análisis de factibilidad Etapas de la metodología adoptada 5. Auditoría al Ambiente de Redes Seguridad Perfiles de Usuarios 6. Auditoría al ambiente de Microcomputadores Seguridad física Utilización Respaldo Podemos expresar lo gráficamente así:

description

Guía para la realización de una Auditoria de Sistemas

Transcript of Manual de Auditoría de Sistemas

Page 1: Manual de Auditoría de Sistemas

Auditoría de Sistemas

Las funciones de la auditoría son:

Evalua (determina),verifica (evidencias) y diseña los controles en las actividades y recursos de cómputo de las empresas.

Promueve la automatización de las diferentes modalidades de la auditoría.

Objetivos 1. Auditoría a la Seguridad en el Centro de Cómputo

Riesgos FísicosOrganización y PersonalPlanes de Respaldo

2. Auditoría en:Sistema OperativoSoftware AplicativoArchivos

3. Auditoría a las Aplicaciones en Funcionamiento Entrada de Datos ProcesamientoArchivosSalidasUtilitarios

4. Auditoría al Desarrollo y/o modificaciones a las aplicaciones SolicitudesAnálisis de factibilidadEtapas de la metodología adoptada

5. Auditoría al Ambiente de Redes SeguridadPerfiles de Usuarios

6. Auditoría al ambiente de Microcomputadores Seguridad físicaUtilizaciónRespaldo

Podemos expresar lo gráficamente así:

Page 2: Manual de Auditoría de Sistemas

Esquemáticamente los horizontes a donde debemos apuntar las labores de seguridad y de evaluación de la misma en las tareas de Auditoría son:

Controles de Continuidad: Pistas, backup, planes de contingencia, segurosControles de Privacidad y Confidencialidad: Derecho a la intimidad de la información.

Diseño de ControlesMáximos controles no son controles óptimos

Pasos1. Identificación de riesgos

Métodos más usados:- Lluvias de ideas. (Grupo Delphi). Riesgos macros hasta micros.– Segmentar sistema por áreas, por operaciones, por recursos u otros conceptos.- Agrupar causas y efectos de un mismo riesgo.– Redacción en la forma más clara y explícita del posible riesgo.Se requiere conocimiento detallado del procedimiento.

2. Selección de riesgos críticos" La eficiencia global de un sistema es inversamente proporcional a la cantidad de controles existentes en el". Se diseñan controles para los riesgos más importantes.Método recomendado.– Comparación por parejas.- Análisis cualitativo de efectos y probabilidad de ocurrencia.

Page 3: Manual de Auditoría de Sistemas

3. Evaluar las implicaciones de costos, eficiencia, etc., si se decide controlar

4. La administración decide: Asume el riesgo o controla la operación

5. Se diseña los controles detallados para aquellos riesgos que se decide controlar

Objetivo. Definir controles para riesgos críticosMétodo recomendado.– Descomponer riesgos en causas, efectos y formas de ocurrencia.– Examinar procedimientos para:

Eliminar causasDetectar formas de ocurrenciaReducir efectosEstos controles deben ser: Prácticos, razonables, costo-efecto, oportunos, significativos, apropiados, simples y operativos.

Grupo de diseño de controles.Jefe del área.Personal involucradoAdministrativoAuditor

6. Análisis de efectividad de controlesObjetivo. Determinar si los controles propuestos son efectivos para los riesgos críticos.Método recomendado.- Elaborar matriz riesgos-controles– Determinar y calificar la efectividad de cada control para el riesgo o los riesgos que se aplican. Esta calificación puede ser arbitraria, pero lo que se debe mantener es la forma relativa que permita comparar el grado de protección que ofrece un control para un riesgo determinado. Puede ser: Alto, Medio, Bajo, Nulo; 0,1,2 o Mal, Bien, Excelente.- Analizar cada columna de la matriz (riesgo) para determinar el grado de protección global.- Donde la protección no sea suficiente proponer nuevos controles.- Analizar las filas (controles) para determinar si el control propuesto se justifica por su grado de efectividad, para uno o varios riesgos. De lo contrario eliminarlo.Notas.Si para un riesgo crítico solo hay un control que lo minimice suficientemente, este es candidato a selección.Si hay un control que actúe en forma excelente sobre varios riesgos críticos es candidato a selección.Si existen riesgos críticos que no han sido minimizados suficientemente, debo continuar la búsqueda de controles que lo hagan.Tener cuidado con la preselección de controles excluyentes.

7. Análisis de eficiencia

8. Selección de controles.Objetivo. Decidir si se invierte en el control para reducir la posibilidad de ocurrencia del riesgo, o se acepta la probabilidad de perdidas asociadas al riesgo.La implantación de los controles no debe ser más costosa que los recursos involucrados en el riesgo.

Page 4: Manual de Auditoría de Sistemas

9. Definir el punto más adecuado de implantación. La búsqueda del autocontrol, exige los controles se involucren lo mas natural posible dentro de los procesos. Deben ser procedimientos que interfieran lo menos posibles en las normales actividades, es mas, se deben convertir en formas de actuar.

10. Diseñar procedimiento detallado de ejecución del control

11. Documentación. Garantizan el mantenimiento permanente de los controles implantados

Cap. 1 Conceptos Generales

ResumenEl término Políticas de Seguridad, en particular las de Informática PSI, se usa de muchas formas y dando connotaciones diferentes, lo cual en ocasiones hace que se pierda, para muchos, una gran importancia en la tarea de la implementación de la seguridad en las empresas. Acá se presenta una visión integral de este problema y la forma de enfrentar la ardua tarea de diseñar e implantar las PSI.

Introduccion

La Política de Seguridad se define de la siguiente manera: grupo de reglas y regulaciones que dicta cómo una organización protege, maneja y distribuye información sensible. En la práctica, es usual que la referencia a este término se haga teniendo en mente unas cuantas directrices sobre claves de acceso y respaldo de información.

Pero las Políticas de Seguridad se deben enfocar desde una perspectiva de mayor importancia, pues son pieza fundamental en el proyecto de plan de seguridad de una instalación. La forma adecuada para plantear la planificación de la seguridad en una organización debe partir siempre de la definición de una Política de Seguridad que determine el QUÉ se quiere hacer en materia de seguridad en la organización para a partir de ello decidir mediante un adecuado plan de implementación el CÓMO se alcanzarán en la practica los objetivos fijados.

“Definir una Política de Seguridad de red significa elaborar procedimientos y planes que salvaguarden los recursos de la red contra la pérdida y daño" .

Política de Seguridad es un documento formal de reglas para todos los usuarios que tienen acceso a los recursos, tecnologías e información de la organización.

No es una descripción técnica de mecanismos de seguridad, ni una expresión legal que involucre sanciones a conductas de los empleados, es mas bien una descripción de lo que deseamos proteger y el por qué de ello.

Para lograr estos objetivos se debe pasar por una serie de pasos que involucran muchos aspectos y personas. Se parte de la visión que se tenga de la seguridad, la que se mueve entre dos posturas o enfoques:

1. Lo que no esté expresamente permitido está prohibido2. Lo que no esté expresamente prohibido está permitido.

Page 5: Manual de Auditoría de Sistemas

Como una forma de englobar todo lo planteado anteriormente y viendo este asunto desde una óptica integral, como un proceso donde el documento formal es solo un paso y entendiendo la seguridad informática como los procedimientos y mecanismos utilizados para garantizar un razonable grado de protección de los recursos informáticos, se presenta a continuación una propuesta de metodología que facilita esta labor.

Etapas en el Diseño e Implementación de una Política de Seguridad

Como se muestra en la figura 1, el diseñar una Política de Seguridad para su posterior implementación no puede ser un acto caprichoso, de momento, de moda; es un proyecto completo que debe ser asumido con la mayor responsabilidad si se quiere lograr el efecto buscado. Cada una de estas etapas cumple papel importante en el exitoso final del proyecto.

Fig. 1. ETAPAS EN EL DISEÑO E IMPLEMENTACION DE UNA POLITICA DE SEGURIDAD

Recorriendo cada uno podemos ver que tareas en concreto se deben desarrollar y cual es la razón para su inclusión en la propuesta metodológica planteada.

Mercadeo del Proyecto

Vender un nuevo proyecto nunca es fácil y mas si se trata de asuntos relacionados con la seguridad en sistemas, donde muchos consideran que no tienen riesgos o no son de su interés y piensan que las Políticas de Seguridad basta con copiarlas de otras instalaciones o usar el sentido común para expedir un recetario de normas.

Como se aprecia en la figura 2, se pueden usar diferentes estrategias para involucrar a la alta gerencia en el proyecto, sin la participación de la cual jamás se logrará llevarlo al punto que se requiere.

Esta etapa enfrenta el poco interés de las altas directivas de la empresa, el desconocimiento de la importancia de la seguridad informática y el exceso de tecnicismo de los expertos en seguridad. Para facilitar el trabajo de concientización es bueno apoyarse en casos de fallos de seguridad ocurridos en negocios similares y los efectos generados; hacer notar la responsabilidad que cabe a las empresas que no han realizado los esfuerzos necesarios para minimizar los riesgos y que debido a ello

Page 6: Manual de Auditoría de Sistemas

pueden infringir normas legales o afectar a otros; para finalizar se puede evaluar la razón costo/beneficio de las medidas tendientes a enfrentar con seriedad los aspectos relativos a seguridad y que el no hacerlo podría llevar a graves problemas de imagen y prestigio de la organización

Fig. 2. ETAPA DE MERCADEO DEL PROYECTO

Inventario y Calificación

Para saber que hay que proteger es necesario hacer un juicioso inventario de recursos informáticos (hardware, software y liveware), y de los servicios ofrecidos, donde se determine la importancia para la organización y el grado de criticidad de cada uno. En la figura 3 se aprecian estos elementos.

Fig. 3. ETAPA DE INVENTARIO Y CALIFICACION

Determinar los Objetivos

Page 7: Manual de Auditoría de Sistemas

Están asociados, como se aprecia en la figura 4, a los objetivos de la Seguridad Informática, orientados a proteger la organización contra amenazas que atenten contra:

1. La continuidad de las operaciones.2. La confidencialidad y privacidad de la información manejada.3. La confiabilidad y exactitud el sistema4. La seguridad física.

Fig. 4. OBJETIVOS DE LA SEGURIDAD

Análisis de Amenazas

En la figura 5 se aprecian algunas de las posibilidades que se tienen de conocer los riesgos que se presentan para los diferentes recursos de la organización.

Fig. 5. METODOS DE ANALISIS DE AMENAZAS

La metodología de Análisis de Riesgos, desagrega la situación de riesgo evaluada en Escenarios de Riesgos . A partir de esto se procede a:

Page 8: Manual de Auditoría de Sistemas

1. Elegir un Escenario de Riesgo E.R.2. Determinar las Actividades Sujetas a Control (A.S.C.) asociadas al E.R.3. Elegir una A.S.C.4. Identificar amenazas relacionadas a la A.S.C. elegida.5. Tomar una amenaza.6. Preseleccionar la mezcla de controles para proteger la instalación contra la amenaza elegida7. Repetir los pasos 3 a 6.8. Escoger otro E.R. hasta que se hayan agotado y repetir desde paso 2.9. Seleccionar los controles a recomendar.

Los formatos de calificación recogen la información de cada recurso, la importancia relativa que tiene, los tipos de usuarios asociados a situaciones indeseables, las posibles amenazas y las medidas a implantar para proteger suficientemente los activos contra esos riesgos.

Como otra forma, pero casi siempre acompañando algunos de los métodos anteriores se recurre a la opinión de expertos y a las vivencias de los usuarios del sistema, para recolectar información de los probables riesgos y los efectos a que están expuestos los procesos o corrientes de información.

Políticas de Seguridad Informática

Después de los pasos previos y con los conocimientos ganados se procede a la construcción del documento formal que incluirá los diversos elementos y para lo cual se deben tener en cuenta los aspectos mostrados en la figura 6. Debe entenderse esta etapa como la del diseño de la Política de Seguridad y deben quedar especificados los diferentes componentes que cubrirá y la forma como se aplicará la misma.

La Política de Seguridad tiene dos propósitos centrales:

Informar a todos los usuarios sobre las obligaciones que deben asumir respecto a la seguridad asociada a los recursos de tecnología de Información T.I y

dar las guías para actuar ante posibles amenazas y problemas presentados.

Para que pueda convertirse en esa línea guía, es necesario involucrar a los diferentes sectores en la organización: Alta gerencia, responsables de T.I., los encargados de seguridad, los auditores, gerentes de las dependencias y representantes de los usuarios.

El documento formal debe definir elementos asociados la adquisición de hardware, software y contratación de servicios externos teniendo presente los aspectos referentes a seguridad (outsourcing, mantenimiento a hardware y/o software, desarrollo de aplicaciones, administración de proyectos, etc.); las disposiciones sobre privacidad y control de acceso incluidas las políticas de autenticación; las responsabilidades asociadas a las métodos de actuación y el manejo de incidentes. Un aspecto importante es la declaración de disponibilidad, entendida como el compromiso que hace el área de sistemas informáticos sobre el mínimo nivel la prestación de servicios en términos de tiempo y cobertura que se garantizará .

Page 9: Manual de Auditoría de Sistemas

Un reto importante es lograr todo lo anterior emitiendo un documento sencillo y claro, apoyado por la alta dirección, que permita la normal actuación, haciendo de las políticas procedimientos inmersos en los tareas cotidianas, enfocados a los problemas relevantes, fácil de ajustar a los cambios permanentes, que garanticen su cumplimiento apoyándose en herramientas de seguridad antes que orientado a castigar a los infractores, lo cual no se descarta. Pero hay que resaltar algunas características que hacen de ella una buena Política de Seguridad: La constante actualización y el hacerla pública y respaldada por los usuarios en la vida práctica.

Plan de Implementación

Terminado el diseño, se procede a la fase de construcción. La figura 7 muestra a grandes rasgos las tareas que se deben realizar.

Plan de Auditoría

En un medio cambiante y en especial en las nuevas tecnologías informáticas y de comunicación, no ha pasado mucho tiempo sin que las condiciones varíen, esto puede llevar a nuevos riesgos y debe actuarse proactivamente para lograr los sistemas autocontrolados que tanto se pregonan.

La labor de auditoría entendida como la evaluación y análisis de esa realidad, en forma critica, objetiva e independiente, con el objeto de evaluar el grado de protección que presenta una instalación ante las amenazas a que está expuesta; es parte importante del diseño e implantación de Políticas de Seguridad. No basta con diseñar buenas políticas es necesario llevarlas a la práctica en forma correcta y garantizar que se adecuan a nuevas condiciones.

Retroalimentación

La implementación de Políticas de Seguridad, genera diferentes situaciones en los negocios lo que obliga al manformacintenimiento constante. Los cambios deben iniciarse con un nuevo análisis de riesgos en el sistema de ión o detectados en la labor de auditoría.

Conclusiones

La Política de Seguridad es una herramienta de gran valor para enfrentar el Plan de Seguridad de una instalación y debe entenderse como un proceso integral que parte de la situación real y se construye teniendo en cuenta los recursos y riesgos a que esta expuesta la organización, convirtiéndola en una línea guía de operación y actuación para proteger los activos y garantizar la continuidad y calidad de los servicios ofrecidos.

CAP. 2 Técnicas De Auditoría Asistidas Por Computadoras

Page 10: Manual de Auditoría de Sistemas

También conocidas por su sigla en ingles como CAATs (Computer Assisted Audit Techniques ).

Normas

Normas Internacionales de Auditoria emitidas por IFAC (International Federation of Accountants) en la NIA (Norma Internacional de Auditoria o International Standards on Auditing, ISA) 15 y 16, donde se contempla la necesidad de utilizar otras técnicas además de las manuales.Norma ISA 401, sobre Sistemas de Información por Computadora.SAS No. 94 (The Effect of Information Technology on the Auditor's Consideration of Internal Control in a Financial Statement audit) dice que en una organización que usa Tecnologías de Información IT, se puede ver afectada en uno de los siguientes cinco componentes del control interno:

1) El ambiente de control, 2) evaluacion de riesgos,3) actividades de control,4) información,5) comunicación y monitoreo ademas de la forma en que se inicializan, registran,

procesan y reporta las transacciones.

La norma SAP 1009 (Statement of Auditing Practice) denominada Computer Assisted Audit Techniques (CAATs) o Técnicas de Auditoria Asistidas por Computador (TAACs), plantea la importancia del uso de TAACs en auditorías en un entorno de sistemas de información por computadora

Técnicas Manuales

Inspección. De documentos, procedimientos, activos, para verificar su existencia, mas que para determinar la forma en que se están utilizando.Observación. De procesos o accionesInvestigación o indagación.Confirmación. Ratificar datos.Cálculo. Precisión matemáticaRevisión Analítica. Investigación de fluctuaciones o partidas poco usuales.

Técnicas de Auditoría Asistidas por Computador (TAAC's)

Computer Assisted Audit Techniques. (CAAT).

SAP 1009 los define como programas de computador y datos que el auditor usa como parte de los procedimientos de auditoria para procesar datos de significancia en un sistema de información.SAP 1009 describe los procedimientos de auditoria en que pueden ser usados las TAACs :

1. Pruebas de detalles de transacciones y balances (Recálculos de intereses, extracción de ventas por encima de cierto valor, etc.)2. Procedimientos analíticos, por ejemplo identificación de inconsistencias o fluctuaciones significativas.3. Pruebas de controles generales, tales como configuraciones en sistemas operativos,

Page 11: Manual de Auditoría de Sistemas

procedimientos de acceso al sistema, comparación de códigos y versiones, 4. Programas de muestreo para extractar datos.5. Pruebas de control en aplicaciones.6. Recálculos.

Datos de Prueba

Se alimenta la aplicación con datos preparados por el auditor y de los cuales conoce los resultados luego de procesarlos. El objetivo es conocer que hace el programa y la acción de los controles implementados su ausencia.

Uso: - Evaluación de controles específicos.- Verificación de validaciones- Prueba de perfiles de acceso- Prueba a transacciones seleccionadas

Anotaciones:- Un elemento de gran importancia en esta técnica es el diseño de los datos de prueba, lo que en últimas determinara la efectividad de esta técnica. Es recomendable seleccionar datos normales, ilógicos, imposibles, con valores extremos, etc.- Es necesario para el funcionamiento de la actividad normal, pues se corre el riesgo de mezclar la información.

- Es sencillo su uso, pero debe tenerse claro su objetivo.IFAC, en su SAP 1009, plantea:Las técnicas de datos de prueba se usan durante una auditoría alimentando datos (por ej., una muestra de transacciones) al sistema de computo de una entidad, y comparando los resultados obtenidos con resultados predeterminados.

ITF (Integrated Test Facility). Prueba Integrada de Facilidad

Page 12: Manual de Auditoría de Sistemas

También conocida como prueba de mini compañía.Su objetivo y uso es similar al caso anterior pero su gran diferencia principal radica en su implementación sin detener el funcionamiento normal de la instalación, mezclando los datos de prueba con los datos reales, en la misma aplicación.

Simulación Paralela

Programas independientes creados por la auditoría para procesar datos reales y simular proceso real.

Software de Auditoría

Page 13: Manual de Auditoría de Sistemas

Según SAP1009, en su parágrafo 26: "El software de auditoría consiste en programas de computadora usados por el auditor, como parte de sus procedimientos de auditoría, para procesar datos de importancia de auditoria del sistema de contabilidad de la entidad. Puede consistir en programas de paquete, programas escritos para un propósito, programas de utileria o programas de administración del sistema. Independientemente de la fuente de los programas, el auditor deberá verificar su validez para fines de auditoría antes de su uso".

SOFTWARE GENERAL DE AUDITORIA

SOFTWARE DE AUDITORIA A LA MEDIDA

Paquete de Auditoría. Son programas generalizados de computadora diseñados para desempeñar funciones de procesamiento de datos que incluyen leer archivos de computadora, seleccionar información, realizar cálculos, crear archivos de datos e imprimir informes en un formato especificado por el auditor".Son usados para control de secuencias, búsquedas de registros, selección de datos, revisión de operaciones lógicas y muestreo.

Software para un propósito específico o diseñado a la medida. "Son programas de computadora diseñados para desempeñar tareas de auditoría en circunstancias específicas. Estos programas pueden ser desarrollados por el auditor, por la entidad, o por un programador externo contratado por el auditor. En algunos casos el auditor puede usar programas existentes en la entidad en su estado original o modificado porque puede ser más eficiente que desarrollar programas independientes".

Page 14: Manual de Auditoría de Sistemas

Si se desarrolla a la medida es posible aprovechar estos programas para aplicar otras técnicas.

Los programas de utilería. "Son usados por la entidad para desempeñar funciones comunes de procesamiento de datos, como clasificación, creación e impresión de archivos. Estos programas generalmente no están diseñados para propósitos de auditoría y, por lo tanto, pueden no contener características tales como conteo automático de registros o totales de control".

Los programas de administración del sistema. "Son herramientas de productividad sofisticadas que son típicamente parte de los sistemas operativos sofisticados, por ejemplo software para recuperación de datos o software para comparación de códigos. Como en el caso anterior estas herramientas no son específicamente diseñadas para usos de auditoria y deben ser utilizadas con cuidado".

Rutinas de Auditoría embebidas en Programas de aplicación. Módulos especiales de recolección de información incluidos en la aplicación y diseñados con fines específicos. Según SAP 1009, se incluyen en estasSnapShots. Es una fotografía interna al sistema, es decir a la memoria, lo que permite obtener resultados intermedios en diferentes momentos de un proceso o conseguir valores temporales de una variable. Se activa mediante ciertas condiciones preestablecidas. Permite al auditor rastrear los datos y evaluar los algoritmos aplicados a los datos.

Archivo de revisión de auditoría. Involucra módulos incrustados en una aplicación que monitorea continuamente el sistema de transacciones. Recolecta la información en archivos especiales que puede examinar el auditor

Page 15: Manual de Auditoría de Sistemas

MODELOS EMBEBIDOS DE AUDITORIA

System control audit Review fileEn resumen los paquetes de auditoria son usados para control de secuencias, búsquedas de registros, selección de datos, revisión de operaciones lógicas y muestreo.

Registros extendidos

Se incluye en algún tipo de registro información significativa sobre las transacciones o el sistema, que luego pude ser consultada por el auditor.

Falta imagen

Técnicas para analizar programas

Traceo.Indica por donde paso el programa cada vez que se ejecuta una instrucción. Imprime o muestra en la pantalla el valor de las variables, en una porción o en todo el programa.

Page 16: Manual de Auditoría de Sistemas

Mapeo.Característica del programa tales como tamaño en bytes, localización en memoria, fecha de ultima modificación, etc

Comparación de código.Involucra los códigos fuentes y códigos objetos.

Falta imagen

Job Accounting Software. Informe de Contabilidad del Sistema.Utilitario del sistema operativo que provee el medio para acumular y registrar la información necesaria para facturar a los usuarios y evaluar el uso del sistema

Consideraciones para el uso de TAAC's

El auditor debe considerar una combinación apropiada de técnicas de auditoría manuales y asistidas por computador.

Conocimiento del sistema sujeto a evaluacion. Conocimiento, pericia y experiencia del auditor en sistemas de informacion. Capacidad del auditor para usar la tecnica, tanto a nivel de planificación, ejecución y

uso de los resultados obntenidos. Disponibilidad de TAACs e instalaciones adecuadas para su implementacion. Poco practico de las pruebas manuales, por imposibilidad de rastros fisicos de las

entradas, procesamientos y salidas de las transacciones o por el alto volumen de información manejado.

Efectividad y eficiencia. Su efectividad debido a la posibilidad de revisar un grueso volumen de transacciones (o tal vez todas), la facil implementacion de la revision analitica. La eficiencia de debe tener en cuenta en terminos de tiempo de preparación, de ejecución y analisis de resultados, gastos adicionales, etc.

Oportunidad de evaluar datos e información en el momento en que esta disponible.

Pasos en la planificación para el uso de TAAC's

Fijar el objetivo de la aplicación de la TAAC. Determinar la estructura (esquema), el contenido y la forma de acceso a los datos,

archivos o bases de datos. Definir los tipos de situaciones a ser analizadas

Page 17: Manual de Auditoría de Sistemas

Definir los procedimientos que se van a seguir. Definir los requerimientos de salida o reportes. Identificar el personal de auditoría y de sistemas que participaran en el diseño y

aplicación de la TAAC. Calcular los estimados de costos y beneficios. Participar en todas las fases relacionadas con el TAAC, para garantizar su control y

documentación. Definir actividades y recursos y determinar su disponibilidad. Aplicación de la TAAC. Evaluar los resultados. Es importante resaltar que las TAACs se apoyan en programas de computador, los

cuales deben ser desarrollados usando las metodologías de ingeniería de software. Es responsabilidad del auditor garantizar el control sobre estos programas, mal haría en confiar la recolección de evidencia a una herramienta o técnica que funciona errónea o deficientemente. Por lo anterior es su deber participar en todas las fases del desarrollo (determinación de erequerimientos, diseño, construccion, prueba e implantación). Debe el auditor mantener bajo su vigilancia estas aplicaciones para evitar que sufran modificaciones no autorizadas.

Documentación de las TAAC's

La Norma Internacional especifica que el estándar de papeles de trabajo es consistente con el de la auditoría como un todo (incluido en NIA 9, Documentación). Puede ser conveniente mantener los papeles técnicos que se refieren al uso de la TAAC separados de los otros papeles de trabajo de la auditoría.La documentación cubre todas las fases:

Planeación: - Objetivos de la TAAC.- TAAC a utilizar.- Controles que se van a implementar.- Personal involucrado, cronograma y costos.Ejecución:- Procedimiento de preparación y prueba de la TAAC.- Detalles de las pruebas realizadas.- Detalles de datos de entrada, procesamiento y datos de salida. Evidencia de Auditoría:- Datos de salida proporcionados.- Descripción del trabajo de análisis sobre salidas.Otros:- Conclusiones de auditoria.- Recomendaciones.Si es el caso, se incluyen sugerencias para mejoras a TAAC utilizada.

Cap. 3 Auditoría a Sistemas de Bases de Datos

Los Sistemas de Gestión de Bases de Datos proveen mecanismos que garantizan la seguridad, consistencia y reglas de integridad. Es de gran importancia para el auditor

Page 18: Manual de Auditoría de Sistemas

de sistemas, conocerlos y apoyarse en ellos para verificar el ambiente de control establecido en la instalación.

Características que apoyan la seguridad en los Sistemas de Bases de DatosLos tópicos que se incluyen tienen que ver con la exactitud, consistencia y confiabilidad de la información y con la privacidad y confidencialidad de los datos. Las Bases de Datos tienen dentro de sus características elementos que pueden ser utilizados para garantizar la calidad de la información almacenada y procesada.Claves PrimariasEsta definición determina que para un valor llave primaria solo existirá una tupla o registro en la tabla. Esta situación garantiza que no se tendrá información repetida o discordante para un valor de clave y puede ser usada como control, para evitar la inclusión de información inconsistente o repetida en las tablas.Dominio de los atributosEl dominio de un atributo define los valores posibles que puede tomar este atributo. Además de los dominios "naturales", usados como tipos de datos, el administrador del sistema puede generar sus propios dominios definiendo el conjunto de valores permitidos. Esta característica, usada en forma correcta, se convierte en mecanismo de control, restricción y validación de los datos a ingresar . Hay que resaltar que estas restricciones siempre serán evaluadas en forma automática por el DBMS. Reglas de IntegridadSon restricciones que definen los estados de consistencia de la Base de Datos. Se debe implementar en especial para verificaciones en cada actualización, para evitar que se caiga en estados de inconsistencia. En particular se debe verificar que se implementen correctamente la regla de la Entidad.(un atributo primo no puede ser nulo) y reglas de Integridad Referencial, esta ultima garantiza que solo se puedan incluir registros para valores previamente ingresados en otras tablas.Algunos ejemplos de su uso pueden ser:- Impedir incluir novedades de nomina a una persona que no exista como trabajador en el archivo maestro de empleados.- Impedir facturar a un cliente que no esté previamente creado en el archivo de clientes.- Impedir borrar de la lista de clientes un registro cuyo código esté incluido en la relación de cuentas por cobrar.Reglas de integridad del negocioCada negocio funciona en forma diferente y tiene reglas asociadas a su actividad que pueden ser definidas como restricciones en la Base de Datos. Esto implicaría que cualquier operación que se realice debe respetar estas limitantes. Por decir algo, condicionar que solo se otorgan descuentos en ventas superiores a $400.000. Estas son condiciones que la administración coloca a la operación y como principio en el desarrollo de una aplicación, deben ser respetadas por esta.VistasSirve como mecanismo de compartimentación de la información almacenada, permitiendo presentar a diferentes usuarios parte del universo, según se considere necesario. Según las políticas de seguridad, es usual que gran parte de los usuarios nunca tengan acceso directamente a las tablas completas, sino que lo hagan a través de las vistas, las cuales, por ser un objeto, son sujetas de otras medidas de seguridad.Perfiles de usuario y Acceso a objetos de la Base de DatosAsignación de nombres de usuarios, con su respectiva clave de acceso (password) y perfiles asociados. Pueden también ser creados roles que serán concedidos a los usuarios según sus funciones.Auditoría

Page 19: Manual de Auditoría de Sistemas

En situaciones en que los datos sean críticos, se debe contar con el riesgo de violación de la seguridad por una persona no autorizada, además de errores involuntarios que igual pueden causar inconsistencias o falta de veracidad de la información. Para estos casos es interesante mantener un archivo de auditoría (logs), donde son registradas todas las operaciones realizadas por los usuarios de las bases de datos. En caso de sospecha de falla en la seguridad, este archivo puede ser consultado para conocer los daños causados y/o identificar a los responsables de las operaciones irregulares.Criptografía de DatosComo recurso de seguridad, se puede mezclar o codificar los datos de modo que, al momento de ser almacenados en disco duro o trasmitidos por alguna línea de comunicación, no sean más que bits ininteligibles para aquellos que los accedan por un medio no oficial. La criptografía es de gran importancia en las bases de datos pues la información esta almacenada por largos periodos de tiempo en medios de fácil acceso, como discos duros.

Disparadores o TriggersSiendo un Triggers o disparador una rutina asociada con una tabla o vista que automáticamente realiza una acción cuando una fila en la tabla o la vista se inserta (INSERT), se actualiza (UPDATE), o borra (DELETE), permiten vigilar y registrar acciones especificas según las condiciones propias del negocio; permitiendo crear logs de auditoria a la medida.Como se puede apreciar los Sistemas de Bases de Datos ofrecen a desarrolladores, administradores y usuarios una gama muy completa de herramientas que permiten garantizar la integridad, consistencia, confidencialidad y en general seguridad de la información almacenada y con un elemento muy importante a favor: Las líneas de código que se requieren por parte del implementador son muy pocas, en ocasiones solo basta con una sencilla sentencia para obligar al DBMS a controlar y mantener las restricciones necesarias.

Metodología tradicional

Revisión del entorno y el estado actual de control apoyado en Checklist

Metodología propuesta

1. Investigación Preliminar. Obtener el inventario de recursos (Hardware, software, orgware y liveware) y la información relevante para apoyar el examen que el equipo de Auditoría realizara. El resultado de esta recopilación se organiza en un archivo de papeles de trabajo denominado archivo permanentemente o expediente continuo de Auditoría.

a. Conocimiento del negocio y del Sistema.

Información sobre la empresa y su objeto social, sobre sus políticas y normas. Además toda la información referente al Sistema de Bases de Datos.Información que se debe solicitar y analizar1. Políticas y normas del negocio en relación con las actividades apoyadas con el Sistema de Bases de Datos.2. Información de objetos de la Bases de Datos (tablas, vistas, procedimientos almacenados, triggers, etc.).3. Diagrama de sistema y de redes del servidor de bases de datos, servidores de replicación y servidores de aplicaciones. Todas las conexiones clientes a la base de

Page 20: Manual de Auditoría de Sistemas

datos incluyendo interfaces de red, direcciones IP, conexiones LAN y WAN.4. Listado de usuarios de la base de datos con sus roles y privilegios.5. Documentación de las aplicaciones sobre la base de datos6. Cuadros organizacionales y descripción de funciones y procedimientos del personal que soporta las bases de datos7. Políticas de administración y procedimientos sobre la base de datos incluyendo procedimientos de seguridad, programas de backup y procedimientos de recover o restauración.8. Documentación de pruebas de recovery o restauraciones.9. Documentación de espacio en disco, tablas de espacio y monitoreo.10. Archivos de arranque de bases de datos. 11. Script de utilidades. 12. Archivos de configuración13. Listados a través de sistema operativo de los directorios de la base de datos mostrando propietarios y permisos hasta el nivel de archivos.14. Listados a través de sistema operativo de los directorios de programas de aplicación que accedan las bases de datos, mostrando propietarios y permisos hasta el nivel de archivos.15. Listado de archivos de usuarios y grupos de usuarios.16. Listado de información de archivos de logs.17. Listado de los servicios habilitados (especialmente en el caso de exposiciones a Internet)

b. Importancia del SGBD en la empresa.

c. Alcance de auditoría.

2. Definir grupos de riesgos

Escenarios de Riesgo Sistema de Bases de Datos1. Objetos de la base de datos y reportes.

Permiso en SGBDPermisos SOInformacion fuera de tablas. Importac ExportPrivacidad y Confidencialidad.Informes a quien no son.DBAAcceso a los datos fuera de DBMSPoliticas de seguridad

2. Programas de aplicacion y utilitarios.Acceso logicoPermiso en SGBDPermisos SODatos en ProgramasModificaciones a AplicacionesEstandares de DesarrolloDocumentacoin CambiosAutorizacion a cambios, pruebas y puesta en marcha.Acceso a fuentes.

Page 21: Manual de Auditoría de Sistemas

Copias de los nuevos programas.Adiconar rutinas de auditoriia

3. Auditoría y SeguimientoLogs.Riesgos: logs muy grandes.Desconocimiento de la informacion contenida

4. Planes de Respaldo y Contingencia.5. Metadatos.6. Seguridad en la Red.7. Acceso a traves de Internet.8. Seguridad Instalaciones y acceso fisico.9. Diseño de la Base de Datos.

LLaves Primarias logicasIntegridad Referencial o mecanismos NormalizacionTriggers mal diseñados.

10.Eficiencia y economia de recursos.11.Almacenamiento.

Cambios no afectan a programas

Agrupación

a. Problemas por seguridad en instalaciones y acceso físico.b. Riesgos relacionados con el acceso lógico y la privacidad a las bases de datos.c. Causados por la relación Sistema Operativo - DBMS.d. Riesgos asociados a las aplicaciones y utilitarios.e. Problemas relacionados con el Diseño de la Base de Datos.f. Asuntos concernientes al Diccionario de datos y documentacióng. Problemas con el Respaldo y planes de contingenciah. Riesgos por personal y organización.i. Auditabilidad.

3. Evaluación del estado de control existente (checklist)

Objetivos de la evaluación para cada grupo de riesgosPreguntar para cada objetivo gravedad, probabilidad, impacto, referencias observaciones.

A continuación se muestran algunos ejemplos.a. Problemas por seguridad en instalaciones y acceso físico.

Objetivos

i. Evaluar la seguridad de las instalaciones contra diferentes riesgos.ii. Evaluar la existencia e planes de acción ante siniestros que involucren las instalaciones.iii. Evaluar las medidas existentes para el control de acceso físico a las instalaciones.

Checklist

Page 22: Manual de Auditoría de Sistemas

b. Riesgos relacionados con el acceso lógico y la privacidad a las bases de datos.c. Causados por la relación Sistema Operativo - DBMS.d. Riesgos asociados a las aplicaciones y utilitarios.j. Problemas relacionados con el Diseño de la Base de Datos.

Objetivos

i. Investigar sobre la metodología de diseño usada.ii. Evaluar la integridad y consistencia de los datos.iii. Evaluar si el Sistema respeta y apoya las reglas del negocio. e. Asuntos concernientes al Diccionario de datos y documentaciónf. Problemas con el Respaldo y planes de contingenciag. Riesgos por personal y organización.

Objetivos

i. Evaluar las funciones del DBAii. Evaluar si el sistema respecta la segregación de funcionesiii. Evaluar las condiciones del personal involucrado con el Sistema de Bases de Datos. h. Auditabilidad.

Objetivos

i. Existencia de logs donde se registre las actividades relacionadas con la bases de datos

ii. Evaluar el grado de uso de la información registrada en los logs si existen.

Checklist

Page 23: Manual de Auditoría de Sistemas

Aplicación de cuestionarios

Informes de emergencia Diseño de pruebas de AuditoríaLos pasos anteriores son base para determinar la naturaleza y extensión de las pruebas de auditoría que deban efectuarse.Las pruebas de auditoría, como se sabe, son de dos tipos: De cumplimiento y sustantivas. Buscan obtener evidencia que los controles establecidos existen en realidad y se utilizan y ejecutan correctamente.Al conjunto de pruebas resultante se denomina Programa de auditoría.El modo en que se verificó cada respuesta de los cuestionarios, debe ser incluida en los checklist.Es un trabajo de escritorio donde se especifica la instalación a evaluar, el número de la prueba, el objetivo de la misma, las técnicas a emplear, el tipo de prueba (de cumplimiento o sustantiva), los recursos necesarios para aplicarla, en cuanto a información, software, hardware y personal. Se describe, además el procedimiento a emplear.Ejecución de pruebasSu propósito es obtener evidencia sobre los controles establecidos, su utilización, y el entendimiento y ejecución de los mismos por parte de las personas. Para cada prueba ejecutada deben adjuntarse los soportes correspondientes.Análisis de efectos de debilidades a. Identificación de debilidadesb. Impacto - Costo de perdidas y adicionales - Probabilidad de ocurrencia.Diseño de controlesDeterminar y evaluar medidas de seguridad adicionalesInforme finalSeguimiento

Procedimientos de Auditoría

Page 24: Manual de Auditoría de Sistemas

Análisis de RiesgosPropósito. Aprovechar el conocimiento de la relación sistema operativo, aplicación, sistema de bases de datos para realizar una auditoria basada en riesgos.

1. Control del ambiente de login en Sistema Operativoa. Asegúrese que el usuario esta adecuadamente restringido por el programa de aplicación o por la seguridad de un menú de opciones.b. Asegúrese que el usuario no puede escaparse del nivel del programa de aplicación y obtener acceso al sistema operativo a la base de datos.c. Asegúrese que el acceso al sistema de bases de datos (roles, privilegios) esta limitado a los objetos de programas de aplicación y el acceso a los objetos del sistema esta restringido desde el identificador de la aplicación de bases de datos.

2. Asegúrese que cada usuario se autentica con la base de datos. a. Asegúrese que cada usuario esta propiamente restringido por el programa o por el menú de seguridad dentro de la aplicación.b. Asegúrese que cada usuario esta restringido desde la administración de bases de datos y las herramientas de desarrollo, igualmente desde las herramientas de consultas.

3. Si los usuarios se conectan a las bases de datos a través de interfaces de administración o desarrollo a. Asegúrese que cada perfil de usuario en las tablas de usuarios es auditado.b. Asegúrese que los roles y privilegios son auditados usuario por usuario.

4. Realice una detallada revisión de los login, procesos de autenticación, perfiles de usuario y roles y privilegios.5. Si un programa es una aplicación Web a través de http o Programas CGI en el servidor:

a. Determine si el enrutador y/o firewall restringe el acceso a la Base de Datos.b. Determine que son adecuados los controles de accesos al servidor web.c. Que se realizan procesos de auditoria sobre los usuarios del sistema operativo y de la base de datos.

Seguridad en el Sistema Operativo

Objetivo. Determinar si el acceso a la base datos a través del sistema operativo es seguro1. Usuario de base de datos y sistema operativo.

a. verifique que todos los usuarios creados en el sistema operativo representan un usuario valido.

b. Asegúrese que las conexiones remotas están controladas.

2. Seguridad de los archivos de bases de datos en el sistema operativo. a. Asegúrese que el propietario de todos los directorios y archivos de Bases de datos es el usuario DBAb. Asegúrese que el grupo propietario es DBAc. En el caso Unix asegúrese que los permisos de los directorios son 755 o menores y de los archivos ejecutables 750. (Esto es especialmente cierto para Oracle).d. Para Unix que el parámetro umask este determinado para que los archivos log no sean escribibles o leíbles por todo el mundo.

Page 25: Manual de Auditoría de Sistemas

e. En el caso de NT asegúrese que los permisos de archivos sean restringidos para que no sean de libre acceso para el grupo everyone.

3. Auditoria a la seguridad de la base de datos para propietarios y grupos. a. Asegúrese que la cuenta del dba, realmente es usada por el administrador de la base de datos.b. En el caso unix, asegúrese que los miembros del grupo dba son limitados a los usuarios de cuenta en la base de datos.c. Asegúrese que los permisos para los archivos de administración de la base de datos están restringidos con acceso solo a la cuenta del administrador del sistema.

Procesos de Conexión y Autenticación

Propósito. Asegurarse que todos los procesos y usuarios son autorizados y autenticados en la base de datos y que los procesos de usuario son controlados.1. Sobre las tablas de usuarios:

a. Determine que todos los usuarios representan un usuario valido y autenticado.b. Prueba que el passwords por defecto en las cuentas de administración del sistema han sido cambiadas.c. Verifique que están definidos los procedimientos para cambios de claves periódicamente y que los passwords son seguros.d. En caso de conexiones con parámetros string, verifique que a través de comandos como ps, no es posible ver la clave del usuario.e. Si la conexión a la base de datos se hace a través de programas o utilidades, asegúrese que están protegidos por permisos de archivos y directorios.

2. En una impresión de la bitácora de sesiones de usuarios: a. Asegúrese que todas los intentos de conexión no exitosos son almacenados, revisados y se les hecho seguimiento.b. En sistemas pequeños considere la posibilidad de auditar todas las conexiones, tanto exitosas como no exitosas.

Control de acceso a la Base de Datos

1. Obtenga listado de todos los archivos de privilegios y roles de usuarios. a. asegúrese que los usuarios interactivos y en ambientes de producción están restringidos solo al privilegio de select. Además la información confidencial debe ser restringida para los usuarios.b. Identifique los procedimientos almacenados y asegúrese que los privilegios para estos están limitados a select y execute a los usuarios que así lo requieran.c. Asegúrese que el privilegio de with grant option esta restringido solo al DBA.

2. Obtenga listado de los archivos de logs: a. Asegúrese que los comandos críticos sobre los objetos (create, alter, drop, etc) son registrados, revisados y se les hace el seguimiento.

Disponibilidad, Respaldo y Recuperación

Page 26: Manual de Auditoría de Sistemas

Propósito. Examinar la disponibilidad de la base de datos para los usuarios y procesos y las apropiadas medidas para limitar los efectos de las fallas en los elementos del sistema.1. Usando comandos similares a df:

a. Identifique espacios de almacenamientos críticos.b. Verifique que los archivos de logs y los archivos de control son montados en diferentes discos y de estos se tienen copias (ojalá espejos)c. Asegúrese que cada disco usa un controlador independiente para minimizar le efecto en una falla del controlador.d. Asegúrese que los requerimientos de espacio de almacenamiento, en el momento del diseño tuvieron en cuenta las proyecciones a futuro.

2. Obtenga un listado de los procedimientos de backup de la base de datos, cronogramas de backup y programas utilitarios de backup.

a. Asegúrese que como mínimo un backup incremental se esta realizando todas las noches (backup de objetos cambiados)b. Asegúrese que los backup lógicos (mientras la base de datos esta arriba) de la base de datos son programados en la noche, cuando los usuarios están fuera y los procesos de lotes han finalizado.c. verifique que cuando se hacen backup lógicos la base de datos se encuentra en modo restringido (usuarios diferentes al dba no pueden conectarse).d. Determine si se hace un backup lógico completo cada semana, para asegurarse que la base de datos completa esta respaldada.e. Asegúrese que un completo backup al sistema esta siendo realizado por lo menos cada mes.

3. Evaluar los medios de almacenamiento, los procedimientos usados, la revisión de las copias, la correcta etiquetada (interna y externa), la seguridad del sitio de almacenamiento y la correcta rotación de las copias.

4. Obtenga y revise la documentación de los procesos de pruebas de recuperación.

Bases de Datos en Red

Propósito. Determinar que las bases de datos en red han sido diseñadas para soportar los requerimientos de disponibilidad y las necesidades de seguridad de las aplicaciones.

1. Partiendo de un diagrama de red donde se especifique los servidores de bases de datos y sus conexiones físicas y lógicas al resto de la red:a. Determine si los altos usos SQL entre componentes en la red (Servidor y aplicaciones) están soportados por canales alta velocidad y alto ancho de banda.b. Asegúrese que los enlaces redundantes son usados para soportar los sistemas de requerimientos de disponibilidad.c. Usando comandos o aplicaciones tipo netstat (protocolo, dirección remota y local y estado) revise el ruteo y direccionamiento IP usado para los servidores de bases de datos.d. Asegúrese que los dispositivos de control de acceso garantizan solo conexiones autorizadas.

Page 27: Manual de Auditoría de Sistemas

Cap. 4 Data Warehouse

Un Data Warehouse es un conjunto de datos integrados orientados a una materia, que varían con el tiempo y que no son transitorios, los cuales soportan el proceso de toma de decisiones de la administración. (W.H. Inmon, considerado como el padre del data warehouse) [Har96]. Esta orientada al manejo de grandes volúmenes de datos, provenientes de diversas fuentes, de muy diversos tipos. Estos datos cubren largos períodos de tiempo, lo que trae consigo que se tengan diferentes esquemas de los datos fuentes. La concentración de esta información esta orientada a su análisis para apoyar la toma de decisiones oportunas y fundamentadas. Previo a su utilización se debe aplicar procesos de análisis, selección y transferencia de datos seleccionados desde las fuentes

Componentes de un Data Warehouse

Como se puede observar en el esquema, cuando un auditor se enfrenta a un Sistema de Bodega de Datos (Data Warehouse), su labor debe tener en cuenta muchos elementos que influyen en la seguridad y buen funcionamiento. En particular resaltamos:

Datos Antiguos: Tienen gran importancia en los procesos iniciales de población de la bodega de datos. Son datos de periodos anteriores. Pueden provenir de 20 años atrás, en algunos casos. La dificultad de ubicación, recuperación y transformación a los formatos requeridos (pueden estar incluso en documentos en papel) es uno de los problemas mas usuales en proyectos de este tipo.

Page 28: Manual de Auditoría de Sistemas

Datos Operacionales: Datos operativos actualizados por aplicaciones OLTP (On Line Processing Transaction. Procesamiento de transacciones en línea.). Están almacenados en las bases de datos en producción.Extractores de Datos: Encargados del copiado y distribución de los datos de acuerdo con el diseño. Se determinan los datos a copiar, desde donde y hacia donde, periodos para las actualizaciones. Se determina si se realiza una regeneración (copia de la fuente de datos en su totalidad) o una actualización (solo se propagan los cambios). Los datos externos son adecuados y limpiados antes de ser sumados a la bodega de datos.Son los enlaces entre los datos en producción y el Data Warehouse (generalmente de tipo relacional)Bodega de Datos: El repositorio de datos actual. Organizadas orientada a intereses concretos. Información histórica reflejando transacciones OLTP, acumuladas por años o en general por periodos largos. Se dice que son servidores de datos para apoyo de decisiones, que añade valor a los datos procedentes de las fuentes en producción. Contienen información detallada y agregada.Metadatos: Los metadatos llevan registros de los datos almacenados, integrados en la misma base de datos. Describen el contenido de los objetos de la bodega de datos: las tablas, índices y el contenido de los datos. Los metadatos definen los formatos, significado y origen de los datos y facilitan el acceso y administración a los datos en la bodega.Contienen la información de la fuente antes de ingresar a la bodega, el mapeo de los datos fuentes a datos en la bodega, historia de las extracciones, logica y algoritmos usados para los procesos de datos (sumarizacion, organización, etc.) y la historia de los cambios en la bodega.Herramientas de Consultas y Extracción de Información: Proveen la interfaz humana con la bodega de datos. En el procesamiento de la información se pasa de simples consultas SQL a OLAP y de esta a Minería de Datos.

Evaluación del SistemaDiseño e Implementación

En esta fase se debe partir de los requerimientos funcionales de información, que generen una ventaja competitiva para la empresa y faciliten la toma de decisiones por parte de la administración.

Riesgos. No realización de riguroso análisis de los sistemas previos, las necesidades

actuales y los requerimientos a futuro. Optar por la arquitectura de data Warehouse que no se acomode al negocio

concretamente. Definición equivocada o mediocre de estructura y esquema eficiente: (granularidad,

índices, esquemas de objetos)

Extracción Inicial de Datos

Riesgos.- Bajo conocimiento de sistemas anteriores para la extracción de datos - Ineficiente y/o erróneo proceso de recuperación y manipulación de datos históricos.

Page 29: Manual de Auditoría de Sistemas

- Poca calidad de los procesos de conversión a esquemas actuales.- Manejo de ausencias, inconsistencia y/o duplicación de datos.

Actualizaciones

Factores de Riesgos.- Definición incorrecta de los periodos para actualización.- Mecanismo de actualización (hacia archivo o directamente hacia sistema).- Herramientas para los cargues a la bodega de datos,- Garantía de completitud de propagación de cambios.- Procesamiento de los campos de agregación antes de la actualización en la bodega.

Extractor de Datos

Riesgos.- Pérdida o no extracción de datos relevantes para el negocio.- Pérdida de fidelidad de los datos extraídos.- Poca efectividad y eficiencia en el proceso.- Desactualización del extractor ante cambios de los sistemas en operación.- Acceso no restringido al software de extracción.- Falla en los procesos de extracción (caída del sistema, inaccesibilidad de los datos, etc.).

Bodega de Datos

- Desactualización de esquemas a nuevas necesidades del negocio.- Acceso no restringido a objetos de Data Warehouese.- Respaldo de los datos almacenados.

Metadatos

Riesgos.- Pérdida de representación de las fuentes y de la bodega por los metadatos.- Ineficiencia y/o inefectividad de los metadatos.- Acceso no restringido.- Nombramiento no estándar de los objetos en Data Warehouse.- Falta de capacitación a usuarios sobre el manejo de los metadatos.- Respaldo de la información de los metadatos.

Herramientas de soporte a la toma de decisiones

Almacenar esta gran cantidad tiene como objetivo reportar información, e incluso conocimiento, que permita actuar en condiciones de menor incertidumbre. Esto incluye el descubrimiento de patrones y tendencias, que puedan ser extrapoladas e intentar predecir comportamientos futuros. Estas técnicas se basan en las matemáticas, estadística, en la psicología, algoritmos genéticos, redes neuronales e incluso en la experiencia.Se debe evaluar si se ha realizado un análisis serio de las necesidades de información del negocio.Verificar que las herramientas que se usan en esta fase son las correctas y se emplean adecuadamente.

Page 30: Manual de Auditoría de Sistemas

Disponibilidad de las herramientas de análisis, acordes con los diferentes niveles de requerimientos.Si la información entregada por estos sistemas en correctamente interpretada y destinadas a generar acciones.Los cambios a programas que generan información deben ser autorizados y revisados antes de ponerlos en producción.Entrenamiento de usuarios en las herramientas utilizadas, que le permita conseguir la información esperada.Adecuación de los programas y herramientas a los cambios en los datos y metadatos.

Sistema Operativo

La bodega de datos se encuentra sobre la plataforma del sistema operativo. La seguridad representada en la disponibilidad, confidencialidad y controles de accesos y privilegios sobre las áreas de almacenamiento y procesamiento están en gran medida dependientes de esta plataforma.

Riesgos.- El Sistema operativo no apoya las políticas de acceso establecidas desde la administración de la bodega de datos.- Los recursos requeridos par los procesos de actualización sean mal atendidos por el sistema operativo.- El sistema operativo permite que programas o usuarios ejecuten y utilicen recursos protegidos desde la bodega de datos.- El sistema operativo no otorga los recursos necesarios para la realización de procesos de alto costo computacional.

Red

Es la infraestructura de comunicación que permite que los diferentes componentes intercambien información. La cantidad de datos contenidos en Data Warehouse incrementa su importancia. Riesgos.- Acceso al sistema desde elementos externos sin autorización (aplicaciones, personas, etc.).- La red se convierta en un cuello de botella para lo operación del sistema.- La inexistencia de elementos que respalden un componente que falle.

Usuarios

Los diseñadores del sistema Data Warehouse no conocen suficientemente el negocio como para modelarlo correctamente.Impericia de usuarios para la obtención de información desde la bodega de datos.No uso de la bodega de datos o mal empleo de la información producida por la misma.

Cap. 5 Auditoría a Sistemas Operativos

El tópico de sistemas operativos será el considerado en este capitulo, tiene especial interés pues los sistemas operativos generan el ambiente de trabajo y la administración de los recursos en cualquier sistema de cómputo y se hace relevante como objeto de estudio y punto de partida para abordar las demás áreas ya mencionadas. En este

Page 31: Manual de Auditoría de Sistemas

caso se busca desarrollar una metodología general que permita auditar diversos sistemas operativos, pero que pueda ser aplicada a un sistema operativo específico como Unix, Linux, Windows, Solaris, Netware, etc.

Metodología propuestaA continuación se proponen y describen las principales etapas que se deben seguir al momento de auditar un sistema operativo. A. Investigación PreliminarB. Identificación y Agrupación de RiesgosC. Evaluación de la Seguridad en la empresa objeto de la AuditoríaD. Diseño de Pruebas de AuditoríaE. Ejecutar Pruebas de AuditoríaF. Análisis del Efecto de las debilidades de SeguridadG. Diseño de ControlesH. Elaboración de Informe de AuditoríaI. Seguimiento

A. Investigación Preliminar

Objetivos Determinar los recursos de cómputo de la empresa y la estructura organizacional de

esta. Evaluar la importancia del sistema de información para los procesos de negocio

objeto de la auditoria y el soporte que los recursos de cómputo dan a estos. Conocer de manera global el sistema operativo sobre el cual se llevara a cabo la

auditoria, identificando los elementos que apoyan la seguridad y administración.

Consideraciones

a. Conocimiento global de la empresa en cuanto a: Área de Tecnología de la Información (Área de sistemas)Estructura organizacional y personal Plataforma de hardware Sistemas operativosSistemas de redes y comunicaciones

b. Conocimiento global del sistema operativo, evaluando las herramientas que proporciona como apoyo a la seguridad y a la administración.

Herramientas o Mecanismos para la realización de la Investigación Preliminar

- Entrevistas previas con el cliente (persona que solicita la realización de la auditoria).- Inspección de las instalaciones donde se llevará a cabo la auditoria y observación

de operaciones.- Investigación e indagación con el personal involucrado en el proyecto de auditoria y

los funcionarios que administran y operan los sistemas a evaluar.- Revisión de documentación proporcionada por la empresa.- Revisión de informes de auditorias anteriores, si se han realizado.- Estudio y evaluación del sistema de control interno.

Documentos a solicitar para la Investigación Preliminar - Listado de aplicaciones en uso y directorio de datos.- Listado de empleados activos y despedidos en el último trimestre.

Page 32: Manual de Auditoría de Sistemas

- Documento de autorización a cada usuario del sistema y aprobación de derechos y privilegios.- Listados de monitoreo del sistema.- Listado de utilidades importantes, con los usuarios y grupos que las acceden. - Políticas de seguridad corporativa.- Documento de configuración inicial del sistema operativo y las autorizaciones para su actualización o cambio.- Documento de definición de los roles en la administración del sistema y la seguridad.- Planes de capacitación y entrenamiento.- Contratos con entes externos relacionados con Tecnologías de la Información.- Informes de auditoría previos.

B. Identificación y Agrupación de Riesgos

ObjetivoIdentificar y clasificar los riesgos a los que esta expuesto el sistema operativo objeto de la auditoria, ya sean propios o generados por entidades externas (personas, procedimientos, bases de datos, redes, etc.) que interactúan con el sistema. Para realizar este análisis se pueden utilizar varios métodos, entre los cuales se proponen:1. Escenarios de RiesgosLos pasos a seguir con este método son los siguientes:- Determinar el sistema a evaluar- Definir escenarios de riesgo (E-R). Se entiende por escenario de riesgo un punto o actividad claramente ubicado dentro del sistema objeto de estudio.- Para cada E-R se determinan actividades sujetas a control (A.S.C). Seentiende por A.S.C., actividades que se realizan en un E-R concreto.- Para cada A.S.C se encuentran las amenazas a que está expuesta(situación de riesgo S-R).- Se califican estas amenazas.- Para cada amenaza se proponen controles que minimicen estos riesgos y se califican de acuerdo a su actuación2. Grupos de RiesgosLos pasos a seguir con este método son los siguientes:- Identificar los grupos de riesgo. Se busca agrupar la amenazas de acuerdo a operaciones o temática similares, a criterio del auditor. - Plantear la justificación para cada grupo de riesgo identificado.- Determinar los objetivos para cada grupo de riesgo. En los objetivos se plantean aquellos aspectos que se quieren evaluar dentro del grupo de riesgo.- Se diseñan instrumentos que permitan evaluar los aspectos planteados en los objetivos.- Se identifican las principales amenazas a las que está expuesto el sistema operativo.Para su estudio se puede dividir los diferentes tópicos a abordar en la investigación de auditoría:Instalación y Configuración InicialAspectos generales a considerar- Políticas y estándares para el proceso de instalación y configuración inicial.- Configuración de servicios (correo, FTP, WWW, DNS). Elección, instalación y activación.- Configuración de parámetros de seguridad.- Sistemas de archivos.- Realización y configuración de particiones.

Page 33: Manual de Auditoría de Sistemas

- Instalaciones por defecto.- Software instalado (Paquetes)Seguridad FísicaAspectos generales a considerar- Acceso del personal al centro de informática y salas de servidores.- Señalización.- Instalaciones eléctricas. - Estado UPS- Almacenamiento de cintas, discos y documentación- Entorno (temperatura, humedad, ventilación).- Ubicación de equipos.- Aseo.Seguridad LógicaAspectos generales a considerar- Mecanismos de control de acceso a objetos del sistema.- Archivos con permisos especiales.- Mecanismos de identificación y autenticación.- Administración de usuarios y grupos (Creación, modificación, bloqueo y eliminación)- Administración de cuentas. (Creación, modificación, bloqueo y eliminación)- Perfiles de usuario y grupos.- Manejo de usuarios especiales.- Manejo de cuentas especiales. (Cuentas sin contraseña, cuentas predeterminadas, cuentas de invitados, Cuentas de acceso de comandos, cuentas de grupo).- Proceso de logon/logoff- Proceso de arranque del sistema.- Cifrado de datos- Acceso remoto.Documentación del SistemaAspectos generales a considerar- Políticas y estándares de los procesos relacionados con el sistema operativo.- Políticas de seguridad de la organización.- Manuales del sistema operativo.- Manuales de procedimientos.- Manuales de usuario.- Manuales de funciones.- Documentación de la instalación y configuración inicial.- Pólizas de seguros.Mantenimiento y soporteAspectos generales a considerar- Soporte del proveedor.- Utilitarios para realización de tareas de mantenimiento.- Planes de mantenimiento lógico y físico.- Contratación de mantenimiento y soporte externo.- Actualizaciones realizadas Hardware.- Actualizaciones realizadas (parches, nuevas versiones).Aspectos administrativosAspectos generales a considerar- Estructura organizacional.- Definición y correspondencia de roles y funciones.- Segregación de funciones- Selección y contratación de personal

Page 34: Manual de Auditoría de Sistemas

- Capacitación y entrenamiento- Ambiente laboral.Monitoreo y AuditoríaAspectos generales a considerar- Evaluación de la función de auditoría interna si existe o externa.- Procedimientos de auditoría realizados con relación al sistema operativo.- Existencia y utilización de herramientas de monitoreo y auditoría.- Procedimientos de monitoreo y ajuste (Tunning)- Reportes de análisis de logs del sistema (instalación, operaciones).- Logs- Reportes de monitoreo y auditoría.- Software de auditoría.Planes de contingencia (Planes de respaldo y recuperación)Aspectos generales a considerar- Existencia de un plan de contingencia.- Conocimiento y divulgación del plan de contingencias.- Pruebas y ajustes al plan de contingencias.- Planes de respaldo (a nivel de personal, software y hardware) y recuperación.- Elaboración y gestión de copias de seguridad (Backups)Administración e implementación de la seguridadAspectos generales a considerar- Función encargada de la administración de la seguridad.- Roles y responsabilidades.- Políticas y estándares.- Entrenamiento y capacitación en seguridad.- Personal Asesor- Procedimientos de administración de la seguridad.- Almacenamiento (Almacenamiento y Filesystem).- Documentación.Servicios que soporta el sistema operativo (aplicaciones, web, correo, proxy, DNS, Base de datos)Aspectos generales a considerarEn este sentido es muy importante tener un grupo de riesgos asociados con los servicios que el sistema operativo evaluado este soportando y la criticidad e importancia que representen para la organización, pues estos pueden ser una puerta de entrada al sistema. Los aspectos a considerar están estrechamente relacionados con el servicio específico y sería bastante extenso enumerar en este punto los aspectos a considerar, los cuales quedan a criterio del auditor de acuerdo al previo que se ha dado hasta aquí.

Ejemplo de Aplicación de la Metodología

A continuación se plantea un ejemplo completo de la aplicación de las herramientas anteriormente descritas. GRUPOS DE RIESGO

Nombre del grupo de riesgo:INSTALACIÓN Y CONFIGURACIÓN INICIALJustificación: Durante el proceso de instalación y configuración del sistema operativo se definen los parámetros que guiaran el funcionamiento y rendimiento de este, dicho

Page 35: Manual de Auditoría de Sistemas

proceso debe realizarse cuidadosamente y se debe garantizar que la configuración final cumpla con lo requisitos funcionales y de seguridad del o los sistemas informáticos que soporta.Objetivos: - Verificar la existencia de políticas y estándares para la instalación y configuración del sistema operativo y evaluarlas.- Evaluar el número de particiones que se realizaron durante el proceso de instalación y el tamaño y distribución de estas.- Verificar los servicios instalados, cuales se encuentran activos y cuales arrancan automáticamente.- Evaluar la configuración de opciones de montaje para los diferentes sistemas de archivos.- Evaluar que paquetes se encuentran instalados en el sistema operativo.- Verificar y evaluar los parámetros de seguridad configurados.- Evaluar si se ha realizado instalación por defecto.

Cuestionario de Control (Instrumento de evaluación)

ESCENARIOS DE RIESGO

Page 36: Manual de Auditoría de Sistemas
Page 37: Manual de Auditoría de Sistemas

C. Evaluación de la Seguridad en la empresa objeto de la Auditoría

ObjetivosDeterminar si los controles existentes protegen apropiadamente la empresa contra los riesgos identificados.En este sentido cuatro métodos pueden combinarse:

1) Análisis de riesgos2) Flujogramas de control3) Cuestionarios de control 4) Matrices de control

D. Diseño de Pruebas de Auditoria

Objetivo Definir Los procedimientos de Auditoria que permitan recolectar la evidencia que apoye los hallazgos y recomendaciones. Consideraciones Una vez realizados los pasos anteriores en este punto se tienen las bases para diseñar las pruebas de auditoria que se han de efectuar.Este es un trabajo de escritorio donde se determina en términos generales: el objetivo de la prueba, se describe brevemente (procedimientos a emplear), tipo de la prueba, técnicas a utilizar, recursos requeridos en cuanto a información, hardware, software y personal.

Tipos de pruebasPruebas de cumplimiento: Busca determinar si existe el control para el riesgo identificado .Pruebas sustantivas: Busca conocer la forma en que esta implementado el control, en caso de que este exista.

Técnicas comúnmente usadas para el Diseño y Ejecución de Pruebas de Auditoría- Observación- Indagación- Conciliación (cruce de información con persona o documentos)- Inspección- Investigación analítica: Evaluar tendencias- Confirmación- TAAC'S: Técnicas de Auditoria Asistidas por Computador.

E. Ejecutar Pruebas de Auditoría

Objetivo Obtener evidencia sobre los controles establecidos, su utilización, y el entendimiento y ejecución de los mismos por parte de las personas. Consideraciones Se ejecutan las pruebas de auditoria diseñadas en el anterior paso, adjuntándose para cada prueba ejecutada los soportes correspondientes.

Page 38: Manual de Auditoría de Sistemas

F. Análisis del Efecto de las debilidades de Seguridad

Consiste en dos pasos: - Identificar las debilidades- Determinar el impacto más probable que tendrá cada debilidad.

G. Diseño de Controles

Este tema fue tratado en capitulo anterior.

H. Elaboración de Informe de Auditoría

Objetivos Comunicar a las personas o entes involucrados en la organización con los sistemas

los resultados de la auditoria, para que ellos hagan la gestión necesaria para implementar los controles que cubran aquellas situaciones de riesgo de mayor relevancia, y mantengan y optimicen los que funcionan eficientemente.

Servir de apoyo en la toma de decisiones, gracias a la información que proveen. Hacer parte de la documentación para futuras auditorías.

Consideraciones Por ser información que de cierta manera puede afectar la imagen de la empresa si

sale a la luz pública, debe ser de carácter confidencial. La elaboración del informe debe ser cuidadosa e en cuanto a la información que

contiene, no debe dar lugar a ambigüedades, y los hallazgos y recomendaciones deben ser claramente descritos.

El informe debe estar documentado: información provista por la empresa y principalmente las pruebas de auditoría; Pues esto es el sustento de los hallazgos, conclusiones y recomendaciones.

I. Seguimiento

Objetivo La empresa debe tomar las recomendaciones consignadas en los informes de auditoria y dar inicio a un proceso de implementación de mejoras basado en dichas recomendaciones

Consideraciones El implementar nuevos controles y tener en cuenta las recomendaciones generadas

por la auditoria es responsabilidad de la empresa que contrató la auditoria. El auditor puede participar en el nuevo proceso aportando su conocimiento y

experiencia, pero bajo otros términos contractuales.

En que consiste el Seguimiento

Esta es la etapa final del proceso de auditoria, pero también es la etapa inicial de un proceso de retroalimentación que lleva a la mejora de los sistemas, el trabajo del auditor llega hasta la entrega de los respectivos informes, de aquí en adelante es decisión de la empresa implementar las recomendaciones e involucrar al antes auditor

Page 39: Manual de Auditoría de Sistemas

en el nuevo proceso. Este es el punto neurálgico de la auditoria, ya que de nada vale hacer un estudio minucioso si una empresa no está dispuesta a implementar las medidas o controles recomendados, por esta razón debe medirse el impacto costo - beneficio de las recomendaciones, ya que ninguna organización está dispuesta a pagar por la seguridad de algo más de lo que este vale

Cap. 6 Auditoría Redes Locales

Los auditores de sistemas deben, en las empresas actuales, obligatoriamente enfrentar su labor profesional en Redes de Computadores, por donde se transporta información sensitiva y vital para las organizaciones. etc.

Objeto de estudio

Dividir los diferentes escenarios en grupo y para cada uno evaluar los riesgos a que esta expuesto el sistema.

1. Diseño e implementación de la reda. Analisis de necesidadesb. Diseño y escogencia de la arquitectura.

Revisar el procedimiento seguido en la selección, adquisición e instalación de la red LAN.Evaluar los estándares soportados en la arquitectura seleccionada

2. Documentación de la Red a. Revisar los manuales de diseño.b. Verificar que exista un plano de las instalaciones correctamente

documentados los centros de cableado, los servidores y los puntos de red.3. Mantenimiento y adecuación de la Red

a. Verificar que se evalué la calidad de la red en cuanto a disponibilidad, fiabilidad y velocidad de acuerdo a las aplicaciones y usuarios que soporta.

b. Evaluar si los cambios funcionales de la organización se ven reflejados en modificaciones de la LAN.

c. Conocer si se realiza mantenimiento a la red y si quienes lo hacen son idóneos en estas actividades.

d. Evaluar si las labores de mantenimiento no han generados problemas con información o funcionamiento de la red.

4. Estado actual a. Políticas de seguridad

Evaluar si existen políticas de seguridad.Si existen, si son acordes con la organización.Si son conocidas por el personal.

b. Controles Físicosc. Controles lógicos

Page 40: Manual de Auditoría de Sistemas

d. Detección de usuarios no autorizadosi. Calidad de contraseñas

iii. Intentos de intromisióniv. Deteccion de intrusos

e. Controles de personal f. Usuarios del sistema

i. Perfiles de usuarioii. Capacitación

e. Controles de Estacionesf. Controles del Servidor

i. Sistema operativo de soporteii. Objetos en el servidoriii. Servicios activos

g. Hardware de comunicaciones. 5. Proteccion de recursos.

a. Soporte a los usuarios Evaluar si existe una persona capacitada para dar soporte a los usuarios de la red y que se encargue de tareas como las siguientes:i. Capacitar a los usuarios para el buen uso de los recursosii. Explicar sobre las políticas de seguridad a que están sujetosiii. Garantizar los recursos de hardware y software que estos requieren para

el cumplimiento de sus labores. b. Respaldo.

Este respaldo debe ser entendido en todas las facetas:Hardware:ServidoresEquipos de Comunicación de datosMedios de transmisión:Canales de comunicaciónSoftware:En particular se debe evaluar la existencia de un método de hacer las copias de respaldo de la información de la empresa. Verificar que:- Se cumpla.- Que se hagan copias en diferentes medios.- Que estén claramente etiquetados los medios.- Que se realicen pruebas de los medios.

c. Protección de aplicaciones y programasd. Verificar si se tiene instalado programa antivirus o en su defecto se han

tomado las medidas de seguridad para evitar la contaminación.e. Corroborar que los accesos a Internet están aislado de los sistemas que

manejen información sensitiva. f. Software no autorizado

Evaluar si se tienen claras políticas y son de conocimiento de los usuarios sobre el software a instalar.Verificar que se realizan revisiones periódicas del software licenciado.

g. Planes de contingencia.Revisar la existencia de planes de contingencia.Si existen corroborar que:Sean conocidos por todos.Que se hayan realizado simulacros.

Page 41: Manual de Auditoría de Sistemas

Que se tengan convenios por escrito para los casos que se requieran recursos extra-empresa