Archivo de la categoría: Auditoría de TI

Proceso de revisión de los procesos de gestión de auditoría de TI y del óptimo uso y configuración de las Tecnologías de la Información utilizadas en una organización.

Auditoría de Bases de Datos

Una dificultad inherente de la auditoría de las bases de datos es el nivel de conocimiento que se tiene del motor de bases de datos. Es complicado estar al tanto de todas las opciones disponibles dentro del software de base de datos, las capacidades que proporcionan y como pueden ser usadas para realizar transacciones indebidas. Especialmente importante es saber cuáles transacciones son las que se han ejecutado y el impacto que tienen en el control interno. Para establecer un ejemplo, pensemos en la capacidad que tiene un Administrador de Base de Datos para cambiar el password de un usuario. Esta capacidad podría permitirle cambiar el password de un usuario y luego utilizar el usuario para realizar transacciones indebidas, totalmente amparado en el anonimato. Si pensamos en este escenario de riesgo y comenzamos a estudiar los controles que se pueden implementar, una forma de controlar este riesgo es el establecimiento de roles concretos de usuarios, con la definición de las instrucciones específicas que pueden realizar. Hay que recordar que en la base de datos se pueden realizar 4 tipos de transacciones a nivel de usuario: agregar datos, modificar datos, borrar datos y consultar. Las otras opciones son a nivel de la administración del software y la base de datos misma. Aquí podemos enumerar acciones como la creación de bases de datos, la creación de usuarios, la creación de tablas en la base de datos y la asignación de permisos de acceso a los usuarios para definir que privilegios tendrán sobre las tablas de datos, es decir, si podrán añadir datos, modificarlos, borrarlos o consultarlos. De esta manera, un rol de administrador de bases de datos, no debe de tener acceso a realizar operaciones sobre los datos. El uso de las opciones del administrador de base de datos para asignar privilegios de acceso, debe de ser autorizado por el dueño de la base de datos y monitoreado por la gerencia general y la auditoría interna. De igual manera, los cambios realizados al entorno de la gestión de la base de datos, como el cambio de passwords de usuarios, debe de hacerse de acuerdo a políticas, solicitudes debidamente registradas, agregando mecanismos que garanticen que el usuario tiene control sobre la definición y seguridad de su password. Esto incluye que el usuario este consciente de los riesgos existentes si alguien más conoce y utiliza su password.
Para resumir, la auditoría de bases de datos requiere del conocimiento del auditor del motor de base de datos, de los procedimientos y controles necesarios para administrar transparentemente las bases de datos, así como de los recursos técnicos para verificar el funcionamiento correcto de los controles. En el medio salvadoreño, muchas veces pasa que la Gerencia de TI no ha definido completamente estos controles, por lo que toca al auditor de sistemas evaluar la situación actual del ambiente de control de la base de datos y recomendar los controles necesarios para llevar el sistema de control interno de la base de datos a un nivel óptimo.

La preparación para la Auditoría Forense.

Ciertamente una Auditoría Forense puede resolver incógnitas que surgen como resultado de Incidentes de Seguridad. Pero un análisis forense de TI requiere que las organizaciones piensen también en esta actividad de manera previa, estableciendo los mecanismos necesarios para salvaguardar evidencia que pueda ser utilizada posteriormente de una manera explícita, que no deje dudas sobre las conclusiones alcanzadas y que no esconda, sobrescriba o borre bitácoras importantes para el análisis forense. Una de las principales cosas que debe de realizar una Unidad de Informática cuando quiere tener capacidades forenses ampliadas, es la activación o creación de bitácoras que muestren la actividad que se desarrolla en la plataforma tecnológica. Las bitácoras son un elemento básico, que permite reconstruir con suma precisión las actividades que ha desarrollado un usuario. Desde que ingresa a su equipo, los sitios que ha consultado, los intentos de conexión a sistemas o equipos, la información que ha borrado, que ha modificado o simplemente consultado. Lo principal, cuando se quiere tener capacidad forense, es el análisis de los puntos importantes de control que deben de ser registrados en bitácora. En muchas empresas observo dos cosas:

1. Con sistemas desarrollados internamente no se generan bitácoras o si existen, registran información muy básica de la actividad realizada por los usuarios.

2. Con sistemas adquiridos, las bitácoras disponibles no se activan. Aquí distingo dos comportamientos. Uno es que ni siquiera se conoce la capacidad de registro de las bitácoras. El segundo es que se decide no usarlos para no saturar el sistema.

Aunque las restricciones de tamaño de las bitácoras siempre son una excusa para no usarlas, lo cierto es que debemos de valorar qué es lo que se protege y decidir si el costo de algunos gigabytes más de disco vale la pena para tener capacidad de análisis forense cuando se presenten incidentes de seguridad. Si la decisión es usarlas, el simple hecho de activarlas es parte de la solución. Lo siguiente es el procedimiento de Administración de las Bitácoras. Estos archivos crecerán y en algún momento habrá que eliminar registros del ambiente productivo para dar espacio al registro de nuevos eventos. Pero la eliminación más bien debe de ser un traslado a un almacenamiento debidamente catalogado, que permita en el futuro su consulta sin mayores esfuerzos. Gran parte del éxito de un sistema de bitácoras para el análisis forense, es su capacidad para mantenerse transparentes al usuario. Es decir, quién está siendo monitoreado a través de este medio, no debe conocer de su existencia, ni mucho menos conocer su ubicación y tener acceso a ellas. Se conoce, que cuando un atacante conocedor realiza una acción, al menos tratará de borrar sus huellas para evitar que se conozca su actividad y hasta incluso el ser rastreado e identificado. Con esta pequeña discusión se puede apreciar que la capacidad de análisis forense en TI debe de ser construida desde el diseño de la plataforma. Esto no ha sido la costumbre, ni los profesionales en informática han sido entrenados para incluir un enfoque integral de la seguridad de la información dentro de los criterios de diseño. Pero esto es algo que tendrá que ir cambiando en la medida que las necesidades de seguridad se identifiquen como un requerimiento más del diseño tecnológico.

El Control Interno de TI

BLOG_20121210Desde mi propia experiencia, aprender sobre el control interno no es fácil. Aunque la palabra control aparece en todos los libros de Gestión de Empresas y Producción de Bienes y Servicios, parece que a la mayoría de los profesionales nos entusiasma más el hacer cosas que el controlarlas sistemáticamente. Así, vemos industrias que se desarrollan haciendo cosas, con controles precarios o sin control y son exitosas. Estas experiencias exitosas en las que la falta de control no fue obstáculo para lograr objetivos, llevan a muchos profesionales de la Gestión a pensar que el control no es necesario. Tal vez sólo cuando se administra dinero, como pasa en las organizaciones financieras y entidades comerciales que manejan mucho dinero en efectivo, como los supermercados y almacenes, es que las actividades de control parecen naturales. Es decir, como se puede pensar en darle efectivo a una persona, permitirle que reciba ingresos de efectivo de los clientes y al final del día dejar que se vaya a su casa sin rendir cuentas minuciosamente de todas las transacciones realizadas durante el día. En este caso, incluso se ven controles adicionales, como el de la seguridad del lugar de trabajo, la ejecución de cortes de caja frecuentes para reducir riesgos de robo o pérdida y otros más.  Esto implica que cuando se trata de ingresos, se entiende la necesidad de control. ¿Por qué no se entiende de la misma forma la protección de activos informáticos? A pesar de que han existido casos de fraude en lo que se no se roba dinero en efectivo, sino que se aplican transacciones ficticias, como pagos a créditos o descuentos no autorizados a ciertos clientes. Incluso, cosas más allá del ambiente interno, como el que se roben la información de tarjetas de crédito de los clientes de un almacén, perdiendo la confidencialidad de las operaciones. O que tal de los casos en los que se han tomado el sitio Web de una organización, perdiendo reputación. Y existen muchos casos más, pero todos estos casos, parecen no tener efecto en el entendimiento de que se necesita crear un ambiente de control interno en las operaciones de TI.

El Control Interno, es definido en COBIT 4.1. como “las políticas, procedimientos, prácticas y estructuras organizacionales diseñadas para brindar una garantía razonable de que los objetivos del negocio se alcanzarán y de que los eventos indeseables serán prevenidos o detectados y corregidos”. Esta es una definición simple, fácil de seguir, que nos enseña que el control interno se trata de simples reglas a seguir, para documentar la forma en la que se realizan las actividades, como se realizan, como se supervisan, como se organización la empresa para asignar responsabilidades de supervisión y control. Esto permite evitar desviaciones que nos alejen de los objetivos institucionales, agregando valor y eliminando riesgos. Es cierto que en el caso de las Tecnologías de la Información las complejidades técnicas pueden llevarnos a tener dificultades para comunicar los mecanismos de control, pero por ejemplo, el especificar una política de seguridad de la información, acompañado de un plan documentado de seguridad y un manual de procedimientos de seguridad, proporcionan una mayor garantía a la Alta Dirección, de que la Gestión de TI esta efectivamente manteniendo un ambiente de control interno sano, que ha identificado los controles necesarios y los está ejecutando. Después de todo, le toca a la Auditoría Interna el verificar el diseño y efectividad de los controles, por lo que la Alta Dirección tiene así un balance de funciones para quienes le soportan todas sus operaciones y por lo tanto, no necesita conocer el detalle técnico de cada cosa. Los Auditores si necesitan saber detalles técnicos y por eso existen los Auditores de Sistemas, que normalmente son profesionales en las Tecnologías de la Información, con experiencia y certificaciones que garantizan a las organizaciones que las auditorías realizadas tendrán la calidad requerida y aportarán valor a la organización, a través del fortalecimiento del control interno.

La Auditoría del Licenciamiento de Software.

Mantener los equipos de cómputo funcionando de manera óptima requiere no sólo el software correcto, también requiere las oportunas actualizaciones y la utilización completa del software. Los que trabajamos todos los días con software se sistemas y aplicativos, vemos y entendemos que tiene que crecer, adaptarse a la solución de nuevos problemas, mitigar vulnerabilidades y resolver nuevos requerimientos. El software se mantiene en constante crecimiento, no basta con realizar una instalación y esperar que funcione por tiempo indefinido sin que necesite atención.

Las empresas afrontan problemas para mantener el software de manera óptima porque hay una inversión que realizar, la cual muchas veces requiere de aprobaciones que pueden llevar algún tiempo o mantenerse pendientes por más tiempo del correspondiente.

Si hablamos estrictamente de software de terceros, que tiene que ser adquirido a través de licencias, nos referimos al software que es necesario para poder utilizar los computadores y para brindarle seguridad a las operaciones del negocio. La lista de software en esta categoría incluye sistemas operativos, bases de datos, antivirus, procesadores de texto, hojas electrónicas,  herramientas de desarrollo y algunas otras utilidades que dependiendo del giro del negocio, podrían ser necesarias para lograr resultados óptimos de la inversión de software.  Este tipo de software, es fabricado en versiones. Se dice que es fabricado, porque es un producto de ingeniería de software, aunque muchas veces no se aprecia como tal, debido a la naturaleza relativamente reciente de esta ingeniería.  Las versiones de las diferentes categorías mencionadas anteriormente, tienden a tener una relación de dependencia entre sí, para lograr que funcionen entre sí y para evitar crear vulnerabilidades en la infraestructura que pueden llevar a un paro de operaciones del negocio. Normalmente, el negocio tiene que elegir las aplicaciones que  necesita para desarrollar sus operaciones y a partir de ahí, adquirir el software del cual dependen las aplicaciones para funcionar bien.

Adicionalmente, de manera más frecuente, los fabricantes de software generan actualizaciones, denominadas “patches”, para resolver errores encontrados en el software o para cerrar vulnerabilidades encontradas. A este respecto, para obtener las actualizaciones muchas veces los fabricantes exigen que se contrate el mantenimiento del software. Este es un pago que normalmente es igual o menor al veinte por ciento del costo del software. Es decir, que a la inversión inicial, se debe de presupuestar un pago periódico de mantenimiento para asegurar  el funcionamiento del software. Un error encontrado muy a menudo en las instalaciones de cómputo, es el tener pagadas las actualizaciones y no aplicarlas en los equipos. Los departamentos de TI muchas veces retrasan esta tarea por el tiempo que tienen que utilizar en la realización de pruebas de las nuevas actualizaciones. Es difícil, pero es necesario, porque los contratos de licencia y mantenimiento de los fabricantes de software, no se responsabilizan por fallos en sus productos, trasladando la responsabilidad del uso del mismo al comprador. Esta es una práctica que aunque  no nos gusta a los usuarios, es la forma en la que se adquieren estas licencias de uso de software.

Esto nos deja un panorama muy confuso para la Alta Dirección, que tiene que recurrir a las Auditorías de Sistemas para asegurarse de que el software en su empresa está actualizado, de que esta siendo usado de acuerdo con las licencias adquiridas y de que no se están violando derechos de propiedad intelectual en ningún lugar. Muchas veces, como parte de esta revisión incluso se aprenden otras cosas, como encontrar software que no es de la empresa, pero que está instalado en sus equipos, para ser usado por algún empleado que aprovecha los recursos de la empresa para otros fines. Con esto aprendemos que la auditoría del licenciamiento del software puede asegurar el buen uso de la inversión en software en una organización.

Auditando la Segregación de Funciones en los Sistemas.

Este tópico resulta sumamente interesante en las empresas con muchos empleados. En primer lugar, nunca se encuentra un diseño de la segregación de funciones que debía implementar el sistema. Luego, nadie revisa si se están creando faltas a la segregación de funciones. Por último, hasta los auditores tienen problemas para identificar el tamaño del problema de segregación de funciones existentes. Lo que normalmente ocurre, es que producto de una investigación o hallazgo se deduce que un usuario tenía privilegios que impactaban en el criterio de segregación de funciones, pero no se pasa a investigar si había más usuarios en la misma situación, con las mismas transacciones o con otras.

La segregación de funciones es una característica de control interno que busca no permitir que un usuario pueda iniciar, procesar, finalizar y hasta eliminar sus acciones, sin la necesidad de que un segundo o tercero intervengan a manera de control. Por ejemplo, el proceso de adquisición de bienes debería de segregar las funciones siguientes: la requisición o solicitud, la recepción de bienes y la autorización del pago del bien. Si permitimos que estas actividades sean desarrolladas por una misma persona, esta podría autorizar pagos, para bienes que no se han recibido o ni siquiera solicitado, montando un esquema de fraude para la empresa. Este tipo de casos, por la misma naturaleza humana, pasan en todas las organizaciones, grandes o pequeñas, llevando a vacíos de control. Por supuesto, el problema se aborda de manera diferente de acuerdo al tamaño de la organización. Estas funciones podrían no estar separadas en una empresa pequeña, pero precisamente por la característica de ser pequeña, es fácil para los propietarios, realizar una revisión total de todas las operaciones e identificar si se ha cometido algún tipo de error. En organizaciones grandes, la segregación de funciones es un poco más difícil de implementar, pero más necesaria. No solo problemas de fraude se pueden dar por falta de una adecuada segregación de funciones. Por ejemplo, producto de la gran cantidad de transacciones realizadas por la misma persona se puede dar el cruce de pagos, procesando el pago de una factura similar, tal vez del mismo proveedor y con productos similares, en lugar de otra. Con esto concluimos, que también hay situaciones de control interno que requieren de la Segregación de Funciones como mecanismo de control.

Es importante, al momento de auditar la Segregación de Funciones, identificar el nivel de segregación de funciones que se ha diseñado, para conocer si la administración esta conscientemente organizando este control. La mejor evidencia, es la matriz de segregación de funciones, que establece “a priori” las operaciones que no se permite sean realizadas por la misma persona. Establecida esta fuente de información, se procede a verificar que efectivamente se está cumpliendo con el diseño de segregación de funciones objetivo. Si la organización es grande, se tendrá que pasar toda la información a una base de datos, en la cual se buscarán personas que cumplan con el criterio de tener privilegios para las operaciones excluyentes. En estos casos, la principal labor del auditor es la identificación de las fuentes de información para crear la base de datos. Este tipo de labores hace de la tarea de auditar sistemas una actividad retadora, debido a que no siempre la información está disponible de la mejor manera para ser procesada. Si el sistema utilizado no asigna privilegios a nivel de transacciones, probablemente habrá que crear la base de datos a partir de los históricos que indiquen quién hizo cada transacción, es decir, el usuario que hizo las solicitudes de bienes, el usuario que hizo las recepciones y el usuario que autorizó los pagos. Al menos este mínimo de pistas de auditoría debe de existir en el sistema de una organización grande, para tener recursos para realizar el análisis. Definitivamente, esto exige gran creatividad de parte de quién audita los sistemas.

Auditando la Seguridad Física de TI

Las operaciones de Tecnología de la Información muchas veces se limitan a implementar sistemas de información e instalar el equipo informático necesario, descuidando aspectos importantes de la seguridad de la información. Especialmente los aspectos físicos de la seguridad son descuidados, en términos de diseño, mantenimiento y actualización. La seguridad física comprende aspectos como el cuidado de que sólo personal autorizado tenga acceso físico a los equipos sensitivos, la disposición ordenada del equipo, el ordenamiento y separación del cableado eléctrico y de datos, las condiciones de medioambiente, como humedad, temperatura y protección de luz solar y polvo, la disposición adecuada de los espacios de trabajo, tanto en centros de datos como áreas de trabajo y  la protección eléctrica no solo de equipos, sino también de personas. Es decir, la gestión de TI debe de considerar que las operaciones se desarrollan en ambientes físicos, que deben de ser acondicionados para lograr los objetivos de negocios, sin descuidar que fallas relacionadas con la seguridad física comprometan la disponibilidad, integridad y confidencialidad de la información.

Al realizar revisiones de seguridad física se logra detectar aquellos aspectos que presentan riesgos a la seguridad de la información debido a la mala operación de los aspectos mencionados anteriormente. Por experiencia, al realizar la primera evaluación es cuando más elementos relacionados con aspectos físicos de la seguridad se detectan. Por ejemplo, si la ubicación del centro de datos no ha sido bien seleccionada, presentando riesgos físicos, se definirían recomendaciones para mitigar los riesgos identificados. Solo la ubicación del centro de datos puede dar lugar a identificar una serie de riesgos relacionados con la seguridad física, porque en muchas organizaciones, la distribución física de espacios no obedece a evaluaciones técnicas, sino más bien a consideraciones estéticas o a consideraciones de lo que es “justo” para un Gerente General asignarle a las Tecnologías de la Información. Este punto incluso tiene una ley. La ley de Putt. Archibald Putt definió el siguiente enunciado: “La Tecnología esta gobernada por dos tipos de gente: aquellos que entienden lo que no dirigen y aquellos que dirigen lo que no entienden”. Este enunciado, explica porque al realizar una auditoría de la seguridad física encontramos hallazgos como: centros de datos con acceso físico no controlado, con construcciones no seguras, a veces, incluso compartiendo espacio físico con otras áreas, con  capacidad eléctrica inadecuada y sin la protección eléctrica adecuada. Son precisamente las decisiones “no técnicas” sobre los aspectos físicos de la seguridad las que son mayormente identificadas al realizar auditorías. Recuerdo de un lugar en el que se estableció un centro de datos en un lugar que tenia cañerías plásticas de agua descubiertas. El riesgo de dañar información y causar daños a personas por cortocircuitos eléctricos en el caso de romperse una cañería era alto.

La lista de puntos a auditar cuando hablamos de seguridad física es grande. Crece aún más cuanto más crece la operación que se audita. Va desde aspectos como tener la capacidad de restringir accesos físicos con cerraduras hasta evaluar la capacidad de absorber descargas atmosféricas. Definitivamente una amplia gama de aspectos que podrían llevarnos a perder información y fallar en los objetivos de seguridad de la información y la continuidad de las operaciones del negocio.

Auditando el Cumplimiento Regulatorio

El cumplimiento de las regulaciones impuestas por organismos controladores es una tarea que resulta difícil de implementar en las organizaciones salvadoreñas y centroamericanas. Independientemente de las buenas intenciones que tenga la Gerencia de TI en implementar todas las normas, el acompañamiento del Auditor de Sistemas ayuda a verificar el total cumplimiento, así como la mejora en términos de eficiencia y efectividad.

Siempre he pensado que las organizaciones no deberían de esperar que existan regulaciones para trabajar en la mejora de la gestión de TI, debería de ser la forma de operar “de facto” para todos. El no hacerlo implica ser altamente ineficientes en la búsqueda de soluciones a problemas que son ya conocidos y tienen una solución definida. Pensado así, la implementación de una norma debería de estar regida por la pregunta ¿Qué problema necesito resolver? A partir de esta pregunta, se debería de seguir un proceso de selección del estándar o metodología más conveniente, definir el nivel de implementación necesaria y proceder con la implementación. Pasado un tiempo prudencial, dos semanas, un mes, dos meses, realizar una evaluación del funcionamiento de la implementación y luego hacer ajustes. Luego, la Gestión de TI será la realización continua de evaluaciones de mecanismos de control para buscar su mejora.

Cuando una organización está normada, es decir, tiene regulaciones de estricto cumplimiento, lo que ha pasado es que alguien más hizo el análisis de qué normas tenían que implementarse y ha definido la lista necesaria para cumplir con un reglamento. Por supuesto, cuando hay regulaciones, habrá también multas y sanciones, dependiendo del tipo de industria. Lo cual hace que la verificación del auditor sea necesaria para la Alta Dirección, para evitar el impacto de que una revisión de la entidad reguladora encuentre que nuestra empresa no cumple con una regulación. En nuestro medio, este tipo de comportamiento se aplica principalmente a el sector Financiero, por razones obvias. Un segundo sector, corresponde a las empresas que han sido adquiridas por corporativos internacionales, que utilizan las normas como marcos de referencia exigibles a sus subsidiarias.

En todo caso, al involucrar a un Auditor de Sistemas en la revisión del soporte que las Tecnologías de la Información proporcionan al cumplimiento de objetivos institucionales, este tomará en cuenta el cumplimiento regulatorio, así como todas aquellas normas y metodologías que proporcionen una respuesta a la mitigación de riesgos. El objetivo será, en primer lugar, verificar que se cumple con las regulaciones, para evitar impactos provenientes de multas y sanciones impuestas por un organismo regulador. Como objetivo secundario, se verificará que la Gestión de TI haya implementado las normas y metodologías en sus procesos de gestión que sean más relevantes al soporte que dan al negocio. Por ejemplo, si una organización se dedica a las ventas al detalle y depende de sus puntos de venta para mantener el flujo de ingresos, es necesario verificar que los niveles de servicio para los sistemas y equipos que apoyan el proceso de ventas estén correctamente definidos y sean ajustados de acuerdo con las necesidades. Es sorprendente, pero a veces la Gestión de TI olvida crear los procesos de gestión que permitan administrar los niveles de servicios en operaciones que son críticas para el negocio. Por eso, el trabajo del Auditor de Sistemas resulta provechoso para las organizaciones. De esta manera se promueve la mejora continua de los procesos de gestión de TI y se asegura un soporte efectivo y eficiente de las Tecnologías de la Información a los objetivos de negocio.

Controles Sobre Los Datos.

Aunque los datos de una organización residan en Bases de Datos de última tecnología, con altas prestaciones en cuanto a características de seguridad, siempre se tiene que planificar e implementar controles para mitigar el riesgo de que nuestros datos pierdan integridad, confidencialidad o disponibilidad. Muchos gerentes o presidentes de empresas, mantienen la duda sobre la confiabilidad del manejo que las Gerencias de TI realizan. Si la organización es grande, muchas veces las tareas del manejo de datos son asignadas a más de una persona, por lo que la duda recae sobre la organización, procedimientos, estrategias de segregación de tareas y controles definidos para darle seguimiento al mantenimiento saludable de los datos. Las Gerencias de TI tienen que realizar no solo la tarea operativa de coordinar el manejo de los datos, sino también la proactiva demostración hacia la Alta Dirección de la efectividad y transparencia con la que se están administrando los datos. Es muy mala señal, cuando un Auditor de Sistemas pregunta por las políticas y procedimientos de administración de bases de datos y estos no existen. El primer mensaje que se proyecta con este hallazgo es que no se han configurado controles de una manera consciente. Posiblemente existirán controles, porque los técnicos de TI, en cada nivel, a partir de su conocimiento y las características del software que implementen, seguramente activaran algunos controles, llevando la administración de datos a un estado que podría denominarse inicial y de ser muy consistente y seguro, repetible, pero no documentado.  Los Gerentes de TI deben de tener presente una premisa. Sin importar el tipo de organización que se trate, la confianza inicial en el manejo de datos ha sido asignada a ellos, a partir de que es un experto en la gestión de Tecnologías de la Información, pero es su responsabilidad el mantener e incrementar esa confianza a través del establecimiento de políticas y procedimientos que demuestren claramente como se garantiza la efectiva Administración de Datos. Internamente, la Dirección de TI también debe de organizar el proceso de Administración de Datos, de manera que se garantice que técnicamente se están aprovechando las funcionalidades del software administrador de bases de datos, que se han asignado las responsabilidades, que se han documentado todas los diseños relacionados con los datos (diagramas entidad – relación, reglas de transformación de datos, migraciones de datos y similares). Es importante también que las Gerencias de TI propicien el compartimiento de responsabilidades en cuanto a la seguridad de los datos. No hay nada más sospechoso que una Dirección de TI que administra de manera secreta los datos. Secreta para su Junta Directiva, para su Oficial de Seguridad, para su departamento de Auditoría o para cualquier otro mecanismo de control establecido por la Alta Dirección. En realidad, este tipo de organismo debe de formar parte operativa del proceso de Administración de Datos, realizando un rol de verificador de puntos críticos que permitan demostrar la transparencia en el manejo de datos. En organizaciones maduras en el manejo de datos, los Oficiales de Seguridad son los responsables de asignar y monitorear los permisos de acceso a los datos. Esto garantiza que cada función tiene los privilegios que necesita, que usuarios privilegiados no abusan de sus privilegios. De igual manera, se involucran ya sea a un Oficial de Seguridad o a un Oficial de Riesgos en el monitoreo de las bitácoras de auditoría de la bases de datos. Esta segregación de funciones sobre los datos, permite percibir un ambiente de alto control sobre los datos, especialmente cuando al descubrir hallazgos, se ven todos como parte de un mismo equipo que trabaja precisamente para identificar comportamientos anómalos en la gestión de datos.

La Auditoría Continua.

La creciente complejidad de las operaciones, especialmente de las de tipo  financiero, el cumplimiento regulatorio y la necesidad de identificar oportunamente comportamiento anormal dentro de las transacciones financieras, ha  llevado a muchas empresas a la decisión de implementar mecanismos de auditoría  que funcionen en línea, que alerten sobre las actividades sospechosas y que  permitan tomar medidas de protección o corrección más efectivas. Esta  situación, aunque suena ideal requiere de una total transparencia, cumplimiento  de estándares de documentación, asignación y segregación de responsabilidades,  así como la flexibilidad para integrar a la infraestructura de TI los  mecanismos para realizar el seguimiento de auditoría de forma automática. Creo  que el término transparencia habla por si solo. No pueden existir secretos entre la Dirección de TI y el Auditor de Sistemas. El trabajo que la Dirección  de TI realiza no puede seguir lineamientos antojadizos, que cambien a medida  que se desarrollan las operaciones. Aunque seguir planes y estándares de documentación parece lo normal en TI, a veces no  es así, porque los responsables de TI y especialmente los niveles técnicos no siguen los planes de trabajo, realizan  cambios que no son documentados y no documentan sus intenciones a través de  documentos de arquitectura que permitan visualizar tanto a ellos como a su  auditor, la ruta que están siguiendo. Cuando se conoce la arquitectura  objetivo, los cambios resultan transparentes para todos los actores, porque se  entiende que son necesarios para lograr este fin último. La documentación es  otro factor importante. Por ejemplo, al momento de decidir que tablas son claves para dejar pistas de auditoría, si se realiza un cambio a las reglas de  registro en las tablas y esto no es documentado y divulgado, se podrían estar  dejando fuera del seguimiento aspectos importantes del negocio. Desgraciadamente, si  esto se descubre después de un caso de fraude, las omisiones o cambios realizados técnicamente y que no fueron correctamente documentados y divulgados pasan a ser acciones sospechosas para la organización. Por esa razón, la  documentación es importante al momento de establecer un escenario de auditoría continua y para mantenerlo actualizado con los cambios. Esto implica que el proceso de Cambios debe de considerar la notificación al departamento de auditoría, para lograr mantener la transparencia de las operaciones de TI. El éxito de la Auditoría Continua no está en el secreto que mantenga el departamento de auditoría al respecto, sino en la verdadera integración de los mecanismos de auditoría dentro de las operaciones normales del negocio, las aplicaciones y la infraestructura tecnológica. Esto debe de ser conocido por todos, por lo que tienen la responsabilidad de brindar soporte al negocio con las TI y por los que analizan la información de auditoría, que tienen que tener el contexto real de las operaciones de TI, con el objetivo de no crear falsos positivos en sus hallazgos ni dejar pasar verdaderos hallazgos. De esta manera, los responsables de TI tienen la oportunidad de mostrar su proactividad en la buena gestión de TI y el negocio logra detectar problemas y tomar decisiones correctivas o preventivas oportunamente.

Auditando Tecnología … con Tecnología.

Definitivamente las Tecnologías de la Información están aportando mucho al soportar las operaciones de negocios de las empresas. Todas las áreas del conocimiento están recibiendo constantemente dispositivos y software que hacen su labor más eficiente y efectiva. La Auditoría de Sistemas no es la excepción y lo que se conoce como CAAT – Computer Assisted Audit Techniques, ahora están siendo apoyadas con una serie de equipos, metodologías y software. Como comentábamos hace algunos días, las pistas de auditoría que dejan las operaciones realizadas con el apoyo de Tecnologías de la Información son variadas y abundantes. Esto nos lleva a saber qué se ha hecho en los sistemas de información y quién lo ha hecho. Pero ¿Qué hará un auditor de sistemas que se encuentra con una gran cantidad de información en las pistas de auditoría? El enfoque tradicional nos llevaría a poner esa información en alguna aplicación para generar reportes y a partir de ahí, empezar a consultar todo tipo de actividad sospechosa. De esta manera aunque la información fuera bastante, se podían obtener resultados definidos, entendibles para la Alta Gerencia, accionables a partir de la evidencia. Pero hay que reconocer, que este seria un análisis forense, realizado al final de un periodo de revisión, que en muchas empresas es trimestral, semestral y algunas veces anual o bianual. Si estuviésemos hablando de un caso que implique fraude, posiblemente cuando se descubra la evidencia, los responsables habrán desaparecido de la organización.

El enfoque ideal, nos llevaría a configurar en una pieza de software, de manera constante, los parámetros de comportamiento de los sistemas de información que interesa monitorear, para que en el momento en el que la acción capaz de generar un hallazgo de auditoría este pasando, el software emita una alerta, vía correo electrónico para el auditor, para que este analice la información y pueda definir caminos de acción dependiendo de la gravedad del hallazgo. Mucho mejor. Esta es la Tecnología que la Auditoría de Sistemas moderna utiliza para realizar su función.

Y aún hay  más. Debido a la cantidad de amenazas que se generan a partir del mal uso o configuración de las Tecnologías de la Información, los sistemas de auditoría están llegando incluso a permitir el monitoreo constante de las configuraciones de los equipos, comparándolas con estándares existentes por tipos de equipos. Esta tecnología incluso llega a mantener una conexión constante con bases de datos de vulnerabilidades, que permiten la comparación de las configuraciones auditadas contra configuraciones necesarias para cubrir las vulnerabilidades detectadas. Este tipo de Tecnología une la revisión de la configuración con la comparación contra el estándar más actualizado existente para cada tipo de dispositivo. Hay que recordar que la auditoría de sistemas al revisar la infraestructura tecnológica de una organización incluye componentes como bases de datos, equipos de comunicación, aplicaciones y datos, componentes que en centros de datos grandes existen de manera repetitiva, por lo que la ayuda de la Tecnología está más que justificada, para lograr realizar revisiones eficientes y eficaces. Esto es todo un reto para los Auditores de Sistemas, pero si nos gusta la Tecnología, es un trabajo gratificante.

A %d blogueros les gusta esto: