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.

La Gestión de la Seguridad de la Información

Escribo este blog en abril de 2014. Este mes, ha sido excepcional para el área de la Seguridad de la Información, debido al descubrimiento de una vulnerabilidad en una implementación del protocolo SSL que podría haber proporcionado una gran capacidad a un potencial atacante para penetrar en servidores y tener acceso a información que no debería de ser conocida. Es un hecho que los conocedores de seguridad se han quedado perplejos ante las dimensiones de la vulnerabilidad detectada. Pero todavía más relevante, es el hecho de que la pieza de código afectada fue publicada en mayo del año 2012, por lo que ha estado operando por 2 años sin que se detectara esta vulnerabilidad. Es importante mencionar que la vulnerabilidad es indetectable desde cualquier infraestructura privada, porque existe en el enlace de comunicaciones, que es público y por lo tanto, se tenía que realizar una prueba de penetración muy detallada, para interceptar los paquetes de información “encriptados” y detectar una forma de acceder a la información que se estaba transportando. Esto ilustra la complejidad del tema de la seguridad. Varias acciones de remediación pueden realizarse en las empresas vulnerables a este problema. Se habla de renovar certificados, de realizar los parches correspondientes, de actualizar palabras secretas (passwords) y cosas similares. Pero si analizamos desde el punto de vista de la Gestión de la Seguridad de la Información, estamos hablando de las mismas actividades que se definen, ejecutan, monitorean y ajustan en un Plan de Seguridad. Esto constituye un indicador claro de la efectividad que proporciona el tener formalmente implementado un Plan de Seguridad de la Información, incluyendo su revisión bianual por parte de un auditor certificado. Es inconcebible, por ejemplo, que en este caso en el que se ha tenido una exposición de más de dos años, los passwords y los certificados sigan siendo los mismos, cuando es una recomendación primaria de seguridad de la información la renovación frecuente. Este es un principio básico, mediante el cual renuevo el mecanismo de seguridad al actualizarlo, logrando que si las credenciales de autenticación han sido comprometidas, la vulnerabilidad generada quede sin efecto al descartarlas. Quiero recalcar aquí, que hasta la tarea de concientización sobre la seguridad de la información es importante. Si tomamos como ejemplo el cambio de passwords, a muchas personas no les gusta o no entienden la necesidad de realizar el cambio y ven la tarea como una tediosa y ridícula petición de la Gerencia de TI. He visto como en algunos lugares se implementa la autenticación con dos factores, lo cual incrementa el trabajo de ingreso a un sistema para el usuario, por lo que para no ser tan autoritativos o molestos, se proporciona como una opción para los usuarios que quieran estar más seguros. Puesto en estos términos, la tasa de usuarios que deciden pasar por el trabajo de utilizar el segundo factor de autenticación resulta baja. Esto definitivamente no es servicio al cliente, en términos de seguridad. Se debe de entender claramente que los usuarios en una organización no son los dueños de la información, por lo cual, deben de acatar todos las regulaciones establecidas para tener segura la información de la organización, que es el fin último de la medida. Todavía más allá, la concientización debe ayudar a dejar claro a un usuario sobre las amenazas existentes, la existencia de posibles vulnerabilidades, haciendo énfasis en esta naturaleza probabilística de su existencia, estableciendo que podrían existir o no, más sin embargo, las medidas de seguridad nos ayudan a estar preparados, logrando prevenir su ocurrencia, detectar su materialización o disminuir su impacto en el logro de objetivos. Así vemos que hasta la tarea de concientización tiene un rol importante en la gestión de la Seguridad de la Información. Por supuesto, medidas más técnicas, como las implementadas en la red de comunicaciones, la utilización de software antivirus, la ejecución de respaldos, la creación de un plan de contingencia y demás, deben de formar un Plan de la Seguridad de la Información completo, que identifique, mitigue y responda a eventos que pongan en peligro la pérdida de confidencialidad, integridad o disponibilidad de nuestra información.

El Ciclo de la Auditoría de Sistemas

El principal objetivo de la Auditoría de Sistemas es la revisión del estado de los controles internos que han sido definidos por la organización para lograr una mayor certeza de que la Gestión de las Tecnologías de la Información soportará efectiva y eficientemente los objetivos de negocios. Los controles son variados, a veces impuestos por la forma de trabajo de la organización, a veces establecidos a través de la Gerencia General y la Gerencia de Informática. En algunas organizaciones, especialmente las  financieras, los controles son requeridos por las normativas regulatorias del país, que buscan desde luego, tener instituciones financieras eficientes, que proporcionen seguridad a los ciudadanos que confían en ellas para administrar sus fondos.

La importancia del establecimiento de controles, radica en la búsqueda del aseguramiento de que los objetivos de negocio serán logrados y no se verán interrumpidos, disminuidos o retrasados por eventos que causen efectos no deseados en las operaciones. Puesto en términos técnicos, los controles mitigan riesgos, que de ser materializados, provocarán algún tipo de pérdida en la organización. A veces, las organizaciones confían en que sus controles son suficientes para prever todos los riesgos a los que se enfrenta. Esta primera aseveración podría ser falsa y esto determina la primera razón por la cual la Auditoría de Sistemas es necesaria, proveyendo una opinión sobre la completicidad de los controles y sobre la efectividad en su diseño. Omitir controles necesarios es la mayor causa de los eventos que impactan negativamente a una organización. Como un ejemplo de esto podemos mencionar lo que pasa cuando se pierde un dispositivo que almacena información importante y al buscar el respaldo, este no se encuentra o está bastante desactualizado, no logrando mitigar el riesgo de pérdida de información. En muchos casos, al revisar el problema, un auditor encuentra que no existen políticas que definan las necesidades de respaldo de datos de la organización, que no hay responsables definidos y que no existen procedimientos de verificación del nivel de éxito que tienen las operaciones de respaldo. Recuerdo una ocasión en la que el dispositivo de cinta que hacia el respaldo presentaba alertas de incompleticidad de la operación de respaldos ¡por un mes! Increíble. Pero cierto.

La segunda confirmación que hace la auditoría de sistemas, es sobre la efectividad de los controles. Esto pasa en organizaciones que han construido un marco regulatorio que consideran completo, que incluye las políticas necesarias, que definen y muestran la voluntad que la alta dirección tiene de gestionar eficientemente las TI, que han definido procedimientos, que han adoptado estándares apropiados y que llevan un sistema de registro considerado completo. En este tipo de organizaciones, he tenido la experiencia de que el personal de TI llena formularios “para cumplir con la auditoría”. Esto desvirtúa la aplicación de un control. Los que gestión TI deben de considerar el control como parte de su trabajo, con un resultado que tiene un impacto en efectividad, eficiencia y calidad directa de su trabajo. Para el caso del dispositivo de respaldo que presentaba error, el técnico responsable debió de conocer de esa situación lo más pronto posible, a efectos de tomar las medidas correctivas necesarias para evitar que se repitiera el error. En estos casos, la Auditoría de Sistemas verifica que la ejecución de los controles no tenga excepciones importantes, que demuestren negligencia u omisión en la ejecución de controles.

La ejecución de ciclos de auditoría en períodos razonables, de acuerdo a la situación de cada organización, permite identificar áreas críticas que tienen controles deficientes y/o que ejecutan sus controles de manera deficiente, permitiendo iniciar un ciclo de mejoras en la Gestión de las TI. Esta acción permite incrementar el nivel de soporte que las Tecnologías de la Información proporcionan a la organización para lograr sus objetivos de negocio.

La Efectividad y la Eficiencia de las operaciones de TI

Cuando se preguntan sobre las razones para tener controles internos de TI, monitoreados a través de procesos de Auditoría de Sistemas, la razón es basada en la búsqueda de la efectividad y la eficiencia de las operaciones de TI. Aunque la efectividad y la eficiencia son dos atributos deseables en cualquier diseño, ya sea de controles o de cualquier otra cosa, es sorprendentemente fácil salirse del curso normal de operaciones y fallar en estos dos atributos en las operaciones de TI.

Antes de hablar más, hay que tener claro que toda la función de TI es considerada secundaria en los procesos de negocio para la mayoría de las empresas, esto es, no es la función que aporta el valor, entiéndase los ingresos, al negocio, sino que soporta o apoya las funciones vitales que sustentan la creación de valor en las organizaciones. Lo que sí se puede afirmar categóricamente en la mayoría de los casos, es que la función de TI es una función de soporte “vital” para las operaciones de TI. Es decir que, al suspenderse o deteriorarse algunos servicios de TI, se impacta directamente los ingresos o la imagen de la organización. Lo cual nos permite concluir, que si los servicios de TI no son eficientes y eficaces, la organización pierde valor.

En un mundo ideal, o mejor dicho, en una función de TI ideal, los servicios que proporciona TI están bien diseñados, tienen sus controles efectivamente diseñados y se ejecutan al pie de la letra, sin excepciones. En un mundo auditable, que es triste decirlo, pero es la realidad de las mayorías de empresas, se realizan las operaciones de TI bajo la ausencia de muchos controles, sin seguir las mejores prácticas conocidas e incluso no aplicando las pocas que puedan tener implementadas. Esto afecta tremendamente a la empresa. Por ejemplo, si una función que atienda incidentes no ha sido propiamente desarrollada, la suma y repetición de incidentes, puede causar tiempos muertos en la generación de ingresos. El personal de TI puede muy fácilmente decirle a sus usuarios internos que se esperen en lo que se reparan o corrigen errores en el sistema, pero en la realidad, esperarse puede implicar retrasar o imposibilitar la generación del ingreso, si el sistema en cuestión sirve para proporcionar servicios directos al cliente, como facturación, atención en ventanilla y similares.

Ser efectivos en la función de TI implica proporcionar el servicio esperado al negocio, con la calidad requerida y de manera oportuna. De esta manera, la función de auditoría de sistemas soporta al negocio en asegurar que los procesos de TI se mantengan cumpliendo con su función y el negocio sea bien soportado.

Ser eficientes en la función de TI implica que no se desperdician valiosos recursos de TI de la organización en otros fines que no sean soportar eficientemente al negocio. Por ejemplo, tener dispositivos para realizar respaldos de datos es eficiente si estos realizan el respaldo de acuerdo con el programa de respaldos diseñado. Si ocurre una falla y se requiere un respaldo que no se hizo, la eficiencia del control se habría perdido.

La auditoría de sistemas ayuda al negocio a determinar la completicidad de controles de las operaciones de TI, conforme a las necesidades y riesgos del negocio. También asegura que los controles existentes son efectivos y se ejecutan de manera eficiente. Para hacer esto, la auditoría de sistemas revisa cada proceso de TI, examinando la existencia de controles y realizando pruebas que ayuden a determinar el nivel de eficiencia con el que se ejecuta. No tener auditoría de sistemas en una empresa en la que la función de TI es vital para soportar las operaciones de negocio, implica poner en riesgo los procesos de negocio que aportan valor a la 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.

A %d blogueros les gusta esto: