SÁBADO, 9 DE ENERO DE 2010

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)
Publicado por Frauditor en 0:36 1 comentarios
Etiquetas: BENFORD

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.
Publicado por Frauditor en 0:29 0 comentarios
Etiquetas: BENFORD

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)
Publicado por Frauditor en 0:24 0 comentarios
Etiquetas: BENFORD

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).