LOGs DE AUDITORIA

Uno de los controles preventivos más importantes respecto a seguridad que pueden integrarse a un software aplicativo, es la creación de los “Logs de Auditoria”, tanto es así que la ISO 17799 nos da lineamientos generales, los cuales se analizarán en el presente artículo y se propondrán estructuras de tablas que nos podrían ayudar a generar logs mediante el aplicativo (programación) o mediante la base de datos (triggers). Al realizar el análisis indicaremos ¿qué información debemos almacenar en la base de datos para poder hacer revisiones posteriores y aportar tanto con evidencia de auditoria como evidencia para fines legales (forense)?.

Una vez implementados los Logs de Auditoría estaremos en condiciones de poder analizar los datos almacenados, por ejemplo aplicar “Técnicas de Detección de Fraudes” como la Ley de Benford, Análisis estadístico, Análisis de Patrones y Relaciones, Análisis Visual, Data Mining, Procedimientos analíticos, todas estas técnicas optimizadas mediante el uso de CAATTS “Computer Aided Audit Techniques and Tools”.

Lo primero tanto para otorgar acceso a los diferentes aplicativos como al comenzar a analizar los datos con Técnicas de Detección de Fraudes, es determinar quienes serán/son/fueron los responsables de la creación, eliminación o modificación de los diferentes registros de la Base de Datos, para esto debemos considerar los lineamientos del domino 11 de la ISO 17799 referida al Control de Accesos.

Control de Accesos

“Objetivo: Asegurar el acceso autorizado de usuario y prevenir accesos no autorizados a los sistemas de de información”

En base a la guía de implementación del punto 11.2.1. Registro de usuarios, sugerimos crear la siguiente tabla:


Con esta tabla se podrán identificar a los diferentes usuarios del aplicativo de tal forma de hacerlos responsables por las acciones que ellos realicen en el aplicativo. Esto deberá ir acompañado de una columna adicional en las tablas donde se considere necesario identificar al responsable, por ejemplo si hablamos de una entidad financiera la tabla que contenga las transacciones de caja, deberá contener por cada registro una columna que indique que usuario realizó la transacción. Adicionalmente es de suma utilidad un campo autonumérico que lo denominamos “identificador” para poder detectar en las revisiones faltantes y repetidos en los registros, este campo identificador lo incluimos en cada una de las siguientes tablas sugeridas.

En base a la guía de implementación de los diferentes puntos de Control de Accesos, sugerimos crear también las siguientes tablas:


En base a esta tabla, se puede realizar el control en la repetición de contraseñas en el último año por ejemplo, o al momento de que los usuarios cambien su contraseña impedirles que reciclen sus contraseñas como mínimo no pueden utilizar las últimas 3 contraseña.


En base a esta tabla se podrá parametrizar la seguridad de accesos, siendo más exigentes o menos exigentes al momento de crear las contraseñas, el tiempo para cambiar contraseñas, así mismo podrían definirse tiempos diferentes de expiración de clave diferenciando entre los usuarios administradores, supervisores y normales, puesto que la ISO 17799 recomienda que los usuarios con mayores privilegios cambien su contraseña con mayor frecuencia.

Una vez que se tienen como mínimo las anteriores tablas, esto se deberá reforzar con una GESTIÓN adecuada de la Seguridad de la Información, por ejemplo respecto de la administración del ciclo de vida de los usuarios, es decir desde que se crean los usuarios hasta se dan de baja (temporal o definitiva), considerando las prácticas recomendadas en el ISO 17799. Por ejemplo contar con una política de control de accesos, procedimiento de altas y bajas de usuarios, Controles en la asignación de privilegios. Para fines legales (forense) es muy importante que los usuarios se les haga entrega de una relación escrita de sus derechos de acceso; la petición a los usuarios para que reconozcan con su firma que comprenden las condiciones de acceso; antes de contratar personal hacerles entrega de una breve explicación de las políticas, normas y procedimientos y su firma expresando conformidad con las consecuencias que podrían generar las violaciones a la política de seguridad; los usuarios deben conocer que por ninguna circunstancia deben tratar de probar una debilidad.

Lo anterior es meramente enunciativo y no limitativo, para mayores detalles es siempre bueno regresar al documento origen que da lugar a estas recomendaciones como es la ISO 17799.

Al estar en la capacidad de identificar de forma inequívoca a los usuarios del aplicativo pasamos a dar recomendaciones de tablas que almacenen información para monitorear y realizar auditorias respecto de las acciones que realizaron los usuarios, para ello nos basaremos en el dominio 10. Gestión de Comunicaciones y Operaciones y punto 10.10 Monitoreo:

Gestión de Comunicaciones y Operaciones : Monitoreo

“Objetivo: Detectar las actividades de procesamiento de información no autorizada.”

“10.10.1. Registro de Auditoria: Los registros de auditoria grabando actividades de los usuarios, excepciones y eventos de la seguridad de información deben ser producidos y guardados para un periodo acordado con el fin de que asistan en investigaciones futuras y en el monitoreo de los controles de acceso.”

De acuerdo con la guía de implementación deberíamos almacenar ciertos datos, sugerimos crear una tabla que contenga los siguientes datos:


La tabla Registro de Auditoria deberá incluir un campo clave autonumérico, el cual nos permita hacer pruebas de auditoria de detección de faltantes y repetidos. Así también el campo Evento deberá desagregarse (normalizar) y crear tablas específicas para almacenar los tipos de eventos a las cuales acceden los usuarios.


El contenido de la tabla Evento podría ser el siguiente:


Hasta este punto, podría surgir la duda de cómo llenamos los datos en estas tablas, pues bien tenemos por lo menos 2 alternativa. La primera alternativa es llenar las tablas mediante el aplicativo, esto significa mucho esfuerzo en programación, especialmente cuando existen cambios en la Base de Datos. La segunda alternativa es llenar las tablas mediante el diseño de triggers, esta opción tiene la ventaja de ser independiente del aplicativo y las tablas se llenarán ya sea cuando se haga modificaciones directamente mediante sentencias SQL o mediante opciones de menú o comandos del aplicativo. También podría surgir la duda de si integrar las pistas de auditoria en las tablas normales del aplicativo o crear nuevas tablas, la elección de la alternativa dependerá de las características de cada organización, puesto que si se cuentan con las fuentes no habría ningún problema de modificar la Base de Datos e integrar las pistas de auditoria en las tablas normales, pero si no se contara con las fuentes, lo más seguro es que en el contrato tenemos limitaciones de hacer modificaciones a la estructura de la base de datos, entonces lo que nos queda hacer es crear tablas independientes a las del aplicativo o simplemente realizar el requerimiento de creación de pistas de auditoria a nuestro proveedor de software.

Cada motor de base de datos tiene su particularidad al manejar los triggers o audit trails, sin embargo al utilizarlos deberemos considerar las caracterísiticas generales de una pista de auditoria que nos debe responder las siguientes preguntas:

* ¿Qué se hizo?
Creación, Modificación, eliminación de registros
Accedió al aplicativo, ingresó datos, imprimió un reporte, realizó una reversión, etc.
* ¿Quién lo hizo?
El usuario que lo realizó
* ¿Cuándo lo hizo?
La fecha y hora de registro del evento
* ¿Dónde lo hizo?
En qué programa, módulo, menú, submenú, item del submenú

Triggers

Los triggers son objetos que se relacionan a tablas y son ejecutados o mostrados cuando sucede algún evento en sus tablas asociadas. Estos eventos son aquellas sentencias (INSERT, DELETE, UPDATE) que modifican los datos dentro de la tabla a la que está asociado el trigger y pueden ser disparados antes (BEFORE) y/o después (AFTER) de que la fila es modificada.
En SQL Server por ejemplo definirse como un tipo especial de procedimiento almacenado que se ejecuta automáticamente cuando un usuario intenta modificar datos sobre una tabla determinada. Los triggers se almacenan en la base de datos en forma similar a los procedimientos almacenados, sin embargo NUNCA son ejecutados explícitamente por los usuarios, sólo se disparan cuando el gestor detecta una modificación.
Una consideración importante podría ser cifrar (encriptar) el código de los disparadores creados, de este modo evitará que se conozca cómo y donde se está almacenando la información de auditoria, como también luego restringir el acceso a las tablas específicas de logs de auditoría.

Análisis de Riesgos

Otro elemento de mucha importancia es la elección de que eventos o procesos que almacenaremos en el log, podríamos tener la tentación de recolectar “todos” los datos y sus modificaciones que se nos ocurran, luego de un tiempo nos daremos cuenta que la base de datos creció considerablemente y especialmente la tabla “Registro de Auditoria”. Si la tabla de logs crece exageradamente, se incrementará como lógica consecuencia el tiempo de generación/restauración de las copias de respaldo y posiblemente las consultas a la Base de Datos se harán más lentas. Para elegir de qué eventos deseamos realizar el registro de auditoria podemos acudir a una de las diferentes metodologías de “Análisis de Riesgos” y en función al resultado determinar los datos que así lo requieran. Adicionalmente las Pequeñas y Medianas Empresas (PyMES) pueden tener limitaciones en cuanto a capacidad de dispositivos de almacenamiento a pesar de la bajada de precios.

Como respuesta a los factores arriba mencionados, a pesar del Análisis de Riesgo realizado, con el tiempo el log irá creciendo, entonces el Administrador de Base de Datos (ABD) podría optar por vaciar la tabla “Registro de Auditoria” cada semestre o año por ejemplo, esto no esta bien ni mal en sí mismo, tendrá que ir acompañado de las formalidades adecuadas, es decir entre las Políticas, Normas y Procedimientos (PNPs) de Seguridad de la Información deberá realizarse la modificación que establezca y autorice al ADB a realizar el borrado de datos de esta tabla, no sin antes haber realizado una copia de respaldo de la Base de Datos (diaria, semanal, mensual, etc) de tal forma que se garantice que se puedan realizar futuras investigaciones sobre los datos de la tabla “Registro de Auditoria”, de no cumplirse con estas formalidades, el ADB estaría actuando en forma negligente y parecería que quisiera ocultar “algo”.


Revisión de las Pistas de Auditoria

Finalmente, los datos almacenados de suceso/eventos tanto los normales como los que no lo son que podemos denominarlos como errores, irregularidades, ilegales, ilícitos, o fraudes deben ser monitoreados constantemente, justamente para detectarlos a tiempo y también para que este tipo de controles sirvan como un elemento disuasivo y pasen de simples controles detectivos a ser controles preventivos.

La ISO 17799 indica:

“10.10.2. Los procedimientos para el uso del monitoreo de las instalaciones de procesamiento de información deben ser establecidos y los resultados de las actividades de monitoreo deben ser revisadas regularmente.”

Las personas encargadas de realizar las tareas de revisión deberían ser los siguientes, cada uno desde su punto de vista particular de acuerdo a sus funciones, formación y experiencia:
* Administrador de la Base de Datos (Interno)
* Oficial de Seguridad de la Información (Interno)
* Auditor (Interno)
* Auditor de Sistemas (Interno/Interno)
* Auditor Financiero (Externo)
* Perito Informático (Externo)