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)

TECNICAS DE DETECCIÓN DE FRAUDES III

Análisis de Patrones

Como un complemento a los anteriores artículos TÉCNICAS DE DETECCIÓN DE FRAUDES I y TÉCNICAS DE DETECCIÓN DE FRAUDES II a continuación tenemos un artículo breve sobre el Análisis de Patrones.

Un patrón es una serie de características que se van repitiendo en el tiempo, por ejemplo en un campo autonumérico el patrón será que existen incrementos de 1, por tanto todos los datos de este campo deberán ajustarse a estos incrementos, para verificar esto se hacen pruebas como detección de faltantes o verificación de secuencia.

Un patrón derivado del modelo Entidad Relación será la definición de campos claves que tienen por características que no se repiten por tanto se pueden aplicar pruebas de duplicados/repetidos a estos campos.

Otro patrón del modelo Entidad Relación será la existencia de llaves foráneas que existan en la tabla maestra, lo contrario significaría la existencia de registros huérfanos por ejemplo ventas realizadas por vendedores que no existen o cobro de sueldos por empleados inexistentes.

El análisis de patrones se pueden aplicar no solamente a los datos en general, sino también a datos específicos, por ejemplo a los depósitos/retiros que realiza un cliente en una institución financiera, se podrán definir patrones de montos máximos, mínimos, promedio, días y horas de retiro habituales, y ya hablando de ATM (Cajeros Automáticos) establecer de que ATMs habitualmente realiza los retiros. También podemos establecer patrones para las operaciones que realizan los funcionarios en el aplicativo, por ejemplo un cajero por sus funciones no realizará registro de nuevos clientes, esta actividad la realizará un funcionario de plataforma.

TÉCNICAS DE DETECCIÓN DE FRAUDES II

TÉCNICAS VISUALES

En el anterior artículo de Técnicas de Detección de Fraudes I se puso énfasis en La Ley de Benford – Análisis de Frecuencia digital, utilizando estas técnicas se pueden lograr resultados impresionantes, sin embargo estos deben ir acompañados (para cuestiones legales y facilitar la comprensión de las conclusiones a personas que no son del área como Abogados, Jueces ciudadanos, Fiscales, etc.) de gráficos que ilustren los resultados, mostrando los elementos relacionados involucrados en un hecho “irregular”, recordando la frase “Un gráfico vale más que mil palabras”.

El análisis visual ayudará al FRAUDITOR a entender los elementos (cosas y personas), los eventos y la interrelación que existen entre ellos, todo esto en forma gráfica.

Una práctica muy recomendable al aplicar este tipo de técnicas es crear una representación gráfica de un hecho normal o regular y luego preparar otra gráfica para el hecho anormal, irregular o fraude.

Las técnicas visuales pueden ser generadas con programas tan conocidos como el Excel, Visio o también pueden realizarse representaciones animadas o reconstrucción de los hechos con programas como Flash u otros programas de diseño animado en 3D.

Si bien el artículo trata sobre Técnicas de detección de fraude, las Técnicas visuales se pueden utilizar antes (Diseño Controles), durante (Auditorias Contínuas) y después de ocurrido el fraude (Auditorias Forenses, Peritajes Contable-Informáticos), de la misma forma que se utilizan los procedimientos analíticos en Auditoria Financiera.

1. ANÁLISIS DE TENDENCIAS

El siguiente ejemplo es la representación de la evolución de las cuentas 183 que son las partidas pendientes de imputación (según el Manual de cuentas SBEF), estas cuentas tienen como característica recibir la imputación de aquellas transacciones a las cuales no se puede identificar plenamente, como máximo deben permanecer con saldo 30 días. En el gráfico podemos visualizar que en el transcurso de 4 años estas cuentas presentaron saldos, por ejemplo la cuenta 183.07 Operaciones por liquidar tiene un comportamiento por demás anormal y las demás cuentas no se quedan atrás.



2. FLUJOGRAMAS

Al diseñar procedimientos operativos se hace uso de los flujogramas, a tiempo de hacer una evaluación de Control Interno relativas a pruebas de cumplimiento, también podemos utilizarlos. En temas de fraude nos pueden servir para graficar la diferencia que existe entre un hecho normal y un fraude. A continuación presentamos la gráfica de la siguiente situación.

Una Institución Financiera cuenta con un Sistema de Información Financiera por módulos que no están completamente integrados a la contabilidad, en el análisis se verán los módulos de CAJAS (CJ), CAJAS DE AHORROS (CA) y CONTABILIDAD (CO), al final de cada día se realiza el posteo de los módulos Cajas y Caja de Ahorro a Contabilidad, este proceso se realiza en el Servidor de cada sucursal (el encargado es el Jefe de Sucursal) y luego se consolida la información en la oficina central.



Proceso Irregurlar – Fraude Cometido por el Jefe de Sucursal

El siguiente gráfico nos muestra un proceso irregular de retiro de dinero por parte del Jefe de Sucursal (retiros de cuentas de familiares y amigos), los cuales antes de contabilizarse eran revertidos y antes de enviar la información de la sucursal a la central. Para evitar el descuadre contable se utilizaban las cuentas Partidas Pendientes de Imputación. En este proceso vale la pena hacer resaltar la concentración de funciones en una sola persona Reversiones, Contabilidad, Administración del Sistema de Información.



3. LINEAS DE TIEMPO
Este tipo de análisis nos permite visualizar en el tiempo varios elementos y al mismo tiempo interrelacionar sucesos, personas, empresas y llegar a formarnos una idea global de la evolución de los hechos y cómo podríamos haber prevenido ciertas situaciones, en el ejemplo tenemos que durante 3 años por lo menos el Jefe de Sucursal no salió de vacaciones.



4. OTRAS REPRESENTACIONES VISUALES
Finalmente podemos utilizar la combinación y adecuación de una gran variedad de representaciones visuales de la realidad que se utilizan en diferentes ámbitos profesionales, desde la Contabilidad, Administración e Informática, los cuales se mencionan a continuación:

Gráficos para representar datos numéricos
- Columnas (apilado, 3D)
- Barras (apilada)
- Lineas / Tendencias
- Circular (3D)
- XY (Dispersión)
- Areas
- Anillos
- Radial
- Superficie
- Burbujas
- Cotizaciones

Gráficos para administración de proyectos
- Diagramas PERT
- Diagramas Gantt
- Linea de tiempo

Gráficos estadísticos
- Gráficos basados en el análisis de regresión (lineal y logarítmica)
- Gráficos basados en el análisis de correlación
- Gráficos basados en el análisis de dispersión
- Gráficos de agrupamiento (claustering)

Gráficos para el modelado de datos:
- Diagrama de contexto
- Diagrama de flujo de datos
- Diagrama Entidad – Relación
- Diagrama de transición de estados
- Diagrama de estructuras
- Diagramas de flujo
o Diagramas de Nassi-Shneiderman
o Diagramas de Ferstl
o Diagramas de Hamilton-Zeldin
o Diagramas de análisis de problemas
o Diagramas HIPO
o Diagramas IPO

Gráficos para el modelado de procesos y datos: UML
- Diagramas de casos de usos
- Diagramas de estados
- Diagramas de secuencias
- Diagramas de colaboraciones
- Diagramas de actividades
- Diagramas de componentes
- Diagramas de distribución

Diagramas de flujo en Visio
- Diagramas de auditoria
- Diagramas de Causa – Efecto
- Diagramas de funciones (Segregación de Funciones)

TECNICAS DE DETECCIÓN DE FRAUDES I

ANALISIS DE FRECUENCIA DIGITAL Y LA LEY DE BENFORD

Artículo publicado en la revista NOBOSTI



Las técnicas de detección de fraudes utilizadas por el FRAUDITOR (Auditor Investigador de Fraudes) son variadas y muchas de ellas no tan nuevas, algunas son bastante simples y otras algo complicadas, la complicación de estas técnicas se sobrelleva con la gran cantidad de programas que tenemos disponibles en el mercado desde una hoja de cálculo (Microsoft Excel), programas de base de datos (Access, MySQL, Informix, SQL Server, Oracle), programas estadísticos (SPSS, Minitab), programas de mineria de datos (Clementina, Darwin, Enterprise Miner, Intelligent Miner), programas de extracción, análisis de datos y detección - prevención de fraudes (IDEA, ACL, Gestor AUDISIS, DATAS), otros ( TOAD, Sistema de Auditoria Seguridad y Control - SAS).

Dentro de estas técnicas podemos mencionar las siguientes:
* Análisis Estadístico: Análisis de regresión, análisis de correlación, análisis de dispersión, La Ley de Benford – Análisis de Frecuencia digital.
* Patrones: Secuencias, investigación de faltantes y duplicados, análisis histórico de tendencias, análisis de ratios.
* Técnicas de análisis visual: Análisis de relaciones, análisis de líneas de tiempo, gráficos de agrupamiento (clustering)
* Procedimientos analíticos de auditoria: Análisis vertical y horizontal de las cuentas de balance y de resultados; Análisis de indices/ratios historicos.

Los resultados de estas técnicas no necesariamente indican que existe fraude en un grupo de datos analizados, simplemente nos dan indicaciones donde poner mayor atención en el análisis, los resultados los tendremos que valorar de acuerdo a las particularidades de nuestro negocio, por ejemplo puede ser que existan transacciones en Depósitos a Plazo Fijo que las realiza el “Administrador de Base de Datos” (ABD), entonces una vez detectadas estas transacciones de carácter operativo debemos investigarlas mas a fondo, es decir determinar que tipo de operaciones son, en que fechas se realizan y creo que lo mas importante si existe autorización formal para que el ABD las realice y la revisión de la normativa interna relacionada.

En el presente articulo nos centraremos en el Análisis de Frecuencia Digital y La Ley de Benford.

Para los ejemplos que se plantearan, nos referiremos a la siguiente estructura de datos de una tabla que almacena los transacciones en ventanilla (caja) de una entidad financiera del segundo semestre de la gestión 2007:



ANÁLISIS DE FRECUENCIA DIGITAL
Consiste en agrupar los datos en función a una variable para luego realizar operaciones de totalización como: contar, sumar, promediar, encontrar el máximo o mínimo, calcular la desviación estándar o la varianza.

Ejemplo: La variable elegida será “Usuario” y la operación de totalización será un simple conteo, es decir iremos contando cuantas transacciones realizo cada usuario en el segundo semestre del 2007, obtenemos los siguientes resultados:



De este resultado podemos comenzar ya una investigación tomando en cuenta los valores extremos el mínimo y el máximo, o solamente comparar los usuarios que tenemos en el resultado con la planilla de sueldos del segundo semestre 2007. Esta misma información la podemos hacer mes por mes e ir acumulando un histórico por usuario para determinar tendencias de cantidad de transacciones por cada usuario y realizar su grafico respectivo:



Del anterior grafico podemos determinar la evolución en cantidad de transacciones por cada usuario y verificamos que los usuarios admin, dvargas y hrosales no son usuarios habituales en caja en ninguno de los meses analizados respecto de los usuarios rrivero, mmarco, froca y lvaca; otra revisión adicional podría consistir en revisar los perfiles de estos 3 usuarios y poner especial énfasis en la autorización para realizar las 2 transacciones que realiza el usuario genérico “admin” y que funcionario lo utiliza, asimismo se deberá realizar una revisión de las Políticas, Normas y Procedimientos (PNPs) sobre el ciclo de vida de los identificadores de usuarios.

De acuerdo al criterio del FRAUDITOR, este podrá combinar los otros operadores de totalización, analizarlos y concluir sobre la base de sus resultados. Asimismo como en este caso no solamente elegimos una técnica y nos centramos únicamente en la elegida, sino que mas bien la integramos con otras técnicas, tal es el caso del Análisis de Frecuencia Digital que se puede combinar con las técnicas de Análisis de Correlacion, Análisis de dispersión y Generar información histórica para realizar Análisis de Tendencias, Análisis de Ratios, Análisis de Regresión.

Como mencionamos líneas arriba, este tipo de técnicas las podemos realizar con diversas herramientas, entre ellas podemos citar:

En Excel a través de las Tablas y Gráficos Dinámicos con las limitaciones que tiene esta herramienta de 65.536 registros hasta la versión 2003 y 1.048.576 registros en la versión Vista.

En Access mediante las Consultas de Tablas de Referencias Cruzadas.

En IDEA y ACL se puede calcular a través de opciones de Totalización de campos.

LEY DE BENFORD
De esta técnica podemos comentar que no es nada nueva, puesto que tiene su origen el año 1881 enunciada por Simon Newcomb y posteriormente el año 1930 por Frank Benford quien era un físico de la General Electric. En 1994 Mark Nigrini utiliza esta Ley para detectar posibles fraudes e irregularidades en datos fiscales y para detectar contabilidades contaminadas.

La Ley de Benford en términos sencillos dice que aquellos números de la vida real que empiezan por el dígito 1 ocurren con mucha más frecuencia que el resto de números. Esta Ley plantea que la ocurrencia de los dígitos en una serie de datos pueden predecirse. Ningrini define la Ley de Benford como aquella que predice la frecuencia esperada de aparición de los dígitos en series de numeros. Otra forma de enunciarla es: los primeros dígitos de los números no se distribuyen de manera equiprobable. Los resultados que arroja esta Ley respecto a la probabilidad de ocurrencia de los dígitos es la siguiente:



Como toda Ley, para que sea aplicable deben cumplirse ciertas condiciones:

* El conjunto de datos debe estar formado por magnitudes medibles de un mismo fenómeno, es decir las transacciones de caja de una entidad, importes de gastos familiares, los votos obtenidos por un candidato en las diferentes mesas de sufragio.

* No debe existir una limitación de máximo y mínimo, es decir debe ser una variable cuantitativa sin restricciones. En el caso de “Moneda”, los resultados de nuestro análisis no tendrían sentido, puesto que este campo solo puede asumir dos valores 1 o 2.

* Los datos no deben ser números asignados por ejemplo los números de teléfono de Santa Cruz comienzan siempre con 3, los de Cochabamba con 4, estos conjuntos de datos no se ajustan a la Ley de Benford.

* Debe haber un mayor numero de valores pequeños que grandes, es decir el cumplimiento de “La Ley de Pareto” que dice que generalmente el 80% del importe total se encuentra en el 20%

Recomendaciones:

* El tamaño del conjunto de datos debe ser mayor a 1.000 elementos para establecer conclusiones de auditoria para la prueba del primer digito y para la prueba de los 3 primeros dígitos se recomienda al menos 10.000 datos.

* El valor máximo entre el mínimo (diferente de cero) debe ser por lo menos 100.

* Preferiblemente analizar datos generados en periodos largos de tiempo (una o varias gestiones fiscales por ejemplo) que sobre cortos (un dia por ejemplo).

* Lo ideal es trabajar con datos que registren 4 o mas dígitos, aunque con 3 dígitos se pueden obtener excelentes resultados.

* La Ley de Benford es de escala invariante, se puede utilizar esta Ley independientemente de su escala de medida, es decir si trabajamos en metros o millas tendríamos el mismo resultado, en términos financieros es independiente de la moneda en la cual expresemos los importes.

* Utiliza programas que incluyen esta Ley dentro de sus opciones como son el IDEA, ACL, DATAS, Auriga, aunque si uno no dispone de estas, con una planilla Excel podría ser suficiente con las limitaciones inherentes del Excel.

Ejemplo: La variable analizada será “Importe” considerando que todas las transacciones están en una misma moneda. Los resultados del ejemplo tomado versus la Ley de Benford se expresan en la siguiente tabla y luego se realiza su grafica correspondiente:



Para el primer digito de un conjunto de datos se toma la probabilidad de ocurrencia del primer digito según La Ley de Benford, de tal manera que si esta cantidad esperada y la real muestran una diferencia significativa es un indicador de que los datos son posiblemente inventados, errados o fraudulentos. Con el ejemplo de transacciones de caja, para el primer digito significa que existirán mas transacciones que comiencen con el numero 1 que transacciones que comiencen con el numero 9, realizando los cálculos tenemos que 15.430 transacciones tienen como primer digito 1 y solamente 1.230 transacciones tienen como primer digito 9.



De los resultados anteriores tenemos para el primer digito 5 una probabilidad de ocurrencia según la Ley de Benford de 7.92 % y tenemos que con los datos actuales tenemos un 11.76 %, esta diferencia es una alerta de un posible fraude o irregularidad en las operaciones que comienzan con el digito 5 en su importe. Las diferencias que indican posibles fraudes pueden ser diferencias en más o en menos respecto la Ley de Benford. Para confirmar o afinar los resultados podemos realizar análisis adicionales como son la prueba del segundo digito, tercer digito, primeros 2 dígitos, primeros 3 digitos y la prueba de los 2 ultimos digitos.

La Ley de Benford y los numeros aleatorios
Si aplicamos La Ley de Benford a una serie de números generados aleatoriamente, la Ley no se cumple, puesto que todos los dígitos tendrán la misma probabilidad de ocurrencia (equiprobables).

Ejemplo: Se generaron datos aleatorios (la misma cantidad que los analizados en el ejemplo anterior 47.634) con Excel teniendo como resultado el siguiente grafico cuyos primeros dígitos tienen una probabilidad de ocurrencia de entre 10% y 11%, verificando que la Ley no se cumple para estos datos, algunos llaman a esto el grado de Benforicidad, es decir cuan aplicable es La Ley de Benford a un conjunto de datos.



Aplicaciones de esta Ley se hicieron en procesos eleccionarios: Elecciones de Ecuador (Noboa, Correa, Roldos, Viteri, Rosero, Villacis), Elecciones de Presidente de los EEUU (2004), Referéndum de Venezuela (2004), Presidente de México (Julio 2006)

Finalmente concluir que las herramientas son solo eso, herramientas y no reemplazan la experiencia y criterio del FRAUDITOR. Parafraseando el dicho “El genio es 10% inspiración y 90% de trabajo” decimos “El Frauditor utiliza 10 % de técnicas y herramientas y 90 % de criterio profesional”. Para las investigaciones forenses (informática y auditoria) no solamente se deben considerar los resultados de las técnicas y herramientas, también y quizás lo mas importante es considerar la validez de los resultados obtenidos y su debido respaldo para fines legales, considerar por ejemplo garantizar la cadena de custodia de la evidencia, diferenciar la evidencia persuasiva (auditoria) de la evidencia conclusiva (legal).