Archivo del sitio

Controles para la Seguridad de la Información

Sin importar el tipo o tamaño de una empresa, todas pueden ser impactadas por fallas en la gestión de la seguridad. El efecto final puede ser experimentado de diferentes formas, como daños a sus equipos, pérdida de información o una disminución en los tiempos de respuesta de los equipos utilizados por los empleados para trabajar. Los usuarios finales normalmente se quejarán de estos problemas diciendo cosas como “no hay sistema”, “el sistema está lento” o “¿No encuentro mis datos?”. El impacto en el negocio dependerá de qué tan crítico sea el momento en el que no hay sistema, o en el que la respuesta es lenta o de la importancia de los datos perdidos.

La Gerencia de Sistemas debe poner la debida atención a entender y analizar los riesgos relacionados con la seguridad de la información y a establecer todos los controles necesarios que permitan reducir la posibilidad de que eventos no deseados les impacten. Durante muchos años he sido testigo de muy buenas intenciones de muchos gerentes de sistemas para establecer los controles necesarios para brindar seguridad a la información de su organización, pero estas intenciones no son compartidas con los gerentes generales o gerentes financieros, que objetan iniciativas, por considerar que los gastos son excesivos. Los segundos a veces cambian de mentalidad cuando se ha sufrido un ataque que implicó pérdidas financieras, daños a la reputación o serios retrasos en las operaciones.

En todo caso, para tranquilidad de todos, los Gerentes de Sistemas tienen que realizar un análisis de riesgos de seguridad de la infraestructura y presentar a la organización el listado de posibles amenazas visualizadas, estableciendo su probabilidad de ocurrencia y el impacto que tendría cada una de ellas en las operaciones, a efectos de que sea claramente entendible por todos la ventaja o desventaja de establecer un control adicional, aunque esto requiera de alguna inversión. Esta práctica es efectiva para visualizar los riesgos, pero debe optimizarse a través de la identificación de controles que permitan, a un costo razonable, mitigar el riesgo.

Los riesgos, para ser entendidos, deben de ser expresados en función de la jerga del negocio. Por ejemplo, si se enuncia como una amenaza el que un virus tome control de un servidor y lo deje inoperante, nuestro riesgo real es que los negocios que se realizan con las aplicaciones existentes en ese servidor se vean interrumpidos porque el servidor fue atacado por un virus. Establecer el impacto en función de la amenaza de perder o retrasar el ingreso de efectivo si llevará al negocio a invertir en tener un sistema antivirus instalado en el servidor y en equipos clientes que tengan relación con el mismo. Si bien en este caso el control primario es el sistema antivirus, y este representa una inversión, se debe de ser muy analítico para decidir la conveniencia o no de implementar controles adicionales, que tal vez no incluyan inversión, pero que requieren del cuidado del personal. Pongamos un par de ejemplos. Si consideramos que para garantizar el éxito de un antivirus, este debe de estar actualizado, tanto en su software, como en las definiciones de virus, podemos entender que es necesario asegurar que la persona responsable del mantenimiento del software antivirus, realiza revisiones rutinarias que verifiquen que el software está funcionando y que resuelva cualquier problema que cause que la solución de antivirus no funcione de la mejor manera posible. Estas revisiones también constituyen un control. Los gerentes deben de exigir a los técnicos que realizan estas funciones que dejen evidencia del monitoreo realizado y de acciones correctivas que se han tomado. Un segundo control podría ser la restricción de utilizar dispositivos de memoria usb en equipos sensitivos. Aquí la decisión debe ser basada en el siguiente razonamiento “Si los puertos usb no son necesarios para mi negocio, los bloqueo”. Esto reduce la posibilidad de que un virus entre directamente al equipo por estos dispositivos. Este control nos llevaría a desactivar la capacidad de que los usuarios administren sus equipos y por lo tanto no puedan sobrepasar la configuración que desactive los puertos usb. También para esto es necesario tener un control del número de equipos existentes en la organización, para garantizar que en todos está debidamente configurada esta configuración.

Como el lector podrá deducir, la amenaza de un virus, estaría siendo mitigada con tres controles. Uno requiere inversión, pero los otros dos requieren de la definición de prácticas de trabajo que ayuden a confirmar la efectividad de la inversión realizada en el antivirus. No implementar estos controles adicionales podría ponernos en la situación en la que se ha invertido en un software de antivirus y aun así se materializa el riesgo.

Esto nos lleva a la conclusión de que los controles de seguridad no están basados totalmente en la inversión que realiza una organización, sino más bien en la aplicación constante de un análisis de los riesgos existentes y la adopción de medidas que mitiguen al máximo la posibilidad de ocurrencia.

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.

El Proceso de la Seguridad de la Información.

La cantidad de amenazas existentes para los sistemas de información es abundante. Por si la cantidad no fuera de por sí un factor de peso, la renovación de las amenazas se convierte en un verdadero problema para los Gerentes de TI, que tienen entre uno de sus objetivos, el mantener segura la información de la organización y evitar riesgos que dañen la imagen, interrumpan o retrasen el cumplimiento de los objetivos de negocio.

Muchas tareas se ponen en riesgo por amenazas a la seguridad de la información. Desde enviar correos, hasta la reinstalación de servidores por fallas causadas por virus y software malintencionado. El simple uso de Tecnologías de la Información, en todas sus formas, expone a una empresa a las amenazas relacionadas con la Seguridad de la Información. Pero si la empresa maneja información que pueda ser atractiva a un atacante, como información relacionada con tarjetas de crédito, información financiera, datos personales y similares, la principal amenaza es que esa información salga de la empresa sin autorización. Los esquemas de ataque en esta última forma son extensos y cambiantes. Incluso instituciones con grandes capacidades de investigación, tienen dificultades para detectar, detener y mucho más para procesar penalmente a un atacante que realice estas acciones.

Una empresa en El Salvador, aún con presupuestos y alcances limitados, está expuesta a estos ataques sí utiliza Tecnologías de la Información, tiene enlaces con el mundo y tiene información de clientes que debe protegerse. Es importante entonces, mantener un perfil activo de la seguridad de la información, no esperando sorpresas, sino más bien, analizando periódicamente las vulnerabilidades existentes, definiendo y ejecutando medidas de eliminación de riesgos y  evaluando los resultados obtenidos. Este ciclo, muy conocido para los que trabajan pensando en la mejora continua, es una ruta simple de protección, que también permite aprovechar las inversiones realizadas en TI. Por ejemplo, la adquisición de un sistema de antivirus puede ser una inversión inefectiva, si una semana después de instalado el sistema, las definiciones de antivirus no han sido actualizadas, dejando expuesta la organización a los nuevos virus. Es típico, que una máquina “crítica” falle, por este fenómeno. Es fácil darse cuenta, que la inversión en el software de antivirus es sólo parte de la solución. Podría decirse que ese es el paso inicial. El proceso de verificación de su efectividad, su correcta aplicación y configuración es mucho más importante para lograr la mitigación de riesgos.

Todo el tema de la Seguridad de la Información debe tratarse de esa manera, como un proceso. No como una solución basada en la adquisición de nuevos dispositivos y software. Temas tan básicos en la Administración de la Seguridad, como el control de accesos a recursos tecnológicos puede salirse del adecuado control sin un proceso continuo de evaluación de su efectividad. Aunque la Auditoría de Sistemas ejerce un control sobre la efectividad de los controles, incluyendo los de seguridad, la Gestión de TI no debe de esperar a que una auditoría de TI le indique vacíos. La Seguridad de la Información es un tema “on line”, de tiempo real, que debe de ser incluido en las responsabilidades y tareas a ejecutar por los responsables de la mantener seguras las operaciones de TI y la información de la organización. A quién le corresponde la responsabilidad es un tema adicional a discutir, dado que no necesariamente tiene que ser la Gerencia de TI, pero lo importante es definir los procesos de Seguridad de la Información, a través de un plan que documente las vulnerabilidades existentes, los mecanismos de protección, la ejecución de los mismos y los controles para verificar la efectividad de los planes. Estos planes deberán de ser flexibles en el tiempo, readaptándose para las nuevas condiciones de amenazas y vulnerabilidades detectadas. Definitivamente, una administración de la Seguridad de la Información requieren de un proceso con mucha proactividad de parte de los responsables.

Organizando las funciones de TI siguiendo estándares

Los Gerentes de TI deben de apoyar sus decisiones en los estándares ampliamente consensados en la industria. Normas de seguridad, marcos de referencia de control y mejores prácticas para proporcionar servicios de TI son las áreas básicas que deben de ayudar a definir las políticas, funciones, procedimientos operativos y prácticas de gestión de TI.  En un país como El Salvador, que tiene que aprovechar todas las ventajas ya generadas por los estándares creados para cada situación, los Gerentes de TI deben de considerar la gama de estándares y revisar su propia realidad para identificar oportunidades de mejora.

El ejercicio es básico. En primer lugar, hay que identificar en base a los requerimientos del negocio, en qué áreas la función de TI debe de apoyar significativamente la creación de valor. Muchos estándares, como los de Continuidad de Negocios, no deben pensarse exclusivamente desde el punto de vista de TI, debido a que los procesos de negocios se logran a  través de una combinación de tecnología, proporcionada por el departamento de TI, y recursos humanos, totalmente independientes de TI. Igual podría pasar con los estándares de seguridad. Existen lineamientos generales por industria o requerimientos basados en la imagen y reputación de la organización que deben de considerarse para establecer que tan lejos se debe de llegar en la implementación de un Plan de Seguridad de la Información. Es importante priorizar los requerimientos para tener un criterio de decisión al momento de planificar los proyectos de implementación de estándares.

Posterior a la clarificación de requerimientos del negocio, se debe de realizar un proceso de selección de los estándares que se adoptarán. El resultado de esta selección debe de indicar un camino a seguir, los criterios a utilizar para definir qué procesos se implementarán, como se realizarán, como será medido el éxito en la ejecución de los servicios de TI, no necesariamente una sucesión de proyectos para implementar estándares. Es importante no considerar los estándares como el fin último. No se trata de llegar a decir: “hemos implementado un número determinado de estándares”. Se trata de ser efectivos y eficientes en el soporte a los proceso de negocio, eliminando riesgos y aportando valor a la organización. Estos elementos, la organización no los mide por el número de estándar implementados, sino por tiempos de respuesta cortos, sistemas de información robustos, resolución de problemas eficiente, que son cosas que permiten realizar negocios sin interrupciones, soportando el logro de los objetivos organizacionales.

Finalmente, la implementación de estándares tiene que materializarse incluyendo sus recomendaciones y prácticas en las políticas, procedimientos y controles necesarios en los procesos de gestión de TI que permitan garantizar un buen uso de los recursos de tecnología de la información de la organización. Esta parte es la que cuesta más a los Gerentes de TI. Ocurre muchas veces que se reciben capacitación sobre los estándares, pero no se establecen medidas que implementen estos estándares en las operaciones de TI. En la mayoría de los casos, se debe a una deficiencia general en el proceso de adopción de estándares, en la que se pretende crear proyectos de implementación “por estándar”, creando conflicto con las prácticas existentes o con la implementación de otros estándares. Es importante en este paso, crear el propio marco de organización de la organización, basado en varios estándares, pero respondiendo a los requerimientos de negocios planteados desde un inicio. De esta forma la gestión de TI sacará provecho de los estándares, logrando un verdadero impacto en la forma en la que la organización percibe el apoyo de TI.

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.

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.

El Uso de Pistas de Auditoría Para Evaluar el Cambio de Sistemas.

Muchos Gerentes de TI, Gerentes Generales, Gerentes Financieros y los miembros de la Alta Dirección de las organizaciones se preguntan sobre como hacer que sus operaciones dejen las suficientes pistas de auditoría para proveer suficiente evidencia de que sus operaciones son eficientes, transparentes y que en los sistemas de información no se registra más que la información correspondiente a transacciones válidas, que pueden ser modificadas por personal debidamente autorizado y que no existen accesos no autorizados a la información. Este escenario de incertidumbre que se realiza en cada organización en mayor o menor medida, puede ser perfectamente administrado si se asignan las funciones y las responsabilidades de la creación de estos mecanismos de registro o controles, además de definir y realizar  revisiones de auditoría que puedan establecer el nivel de confiabilidad de las pistas diseñadas a través de la realización de pruebas y verificaciones de los registros.

Con las prestaciones que ofrecen las Tecnologías de la Información en este momento, es bastante fácil implementar excelentes mecanismos de registro y controles que permitan dejar las pistas de auditoría necesarias para dar al negocio la confiabilidad de sus operaciones. Si pensamos en ERPs modernos, estos incluyen en su diseño, los registros necesarios para dejar las pistas de auditoría necesarias, junto con módulos de consulta destinados para realizar el trabajo del auditor de una manera sistemática. En otra área de software, las bases de datos como ORACLE y Microsoft SQL Server y similares, incorporan los registros de auditoría a nivel del repositorio de datos, permitiendo crear pistas de auditoría adicionales a las que puede dejar una aplicación.

La industria salvadoreña, sin embargo, esta llena de aplicaciones hechas a la medida, que utilizan plataformas tecnológicas que no tienen estas opciones de auditoría y muchas veces ni siquiera la seguridad mínima necesaria para garantizar que en caso se realice algún tipo de registro de auditoría, este no sea objeto de manipulación. Para los auditores de sistemas es un escenario difícil. Pero hay que reflexionar más y pensar quienes tienen el verdadero problema de control. Esto es, la Alta Dirección debe evaluar la cantidad de dinero que se realiza en una operación en base a información procesada y almacenada en una plataforma tecnológica deficiente y evaluar si tiene alta dependencia de la misma, si existen riesgos de casos de fraude, de pérdida de información y casos similares que impacten en pérdidas financieras o de imagen de la organización. Después de evaluar estos riesgos, la Alta Dirección necesita recibir un dictamen del Auditor de Sistemas sobre la confiabilidad de los controles del sistema actual, para poder realizar una evaluación de la conveniencia de invertir en la actualización de la plataforma tecnológica, con el simple objetivo de mejorar el control de las operaciones a través de la incorporación de pistas de auditoría acordes a estándares actuales, que permitirán actualizar el funcionamiento de la empresa salvadoreña a un nivel de modernidad adecuado. Cuando menos, la comparación entre riesgos y nivel de control de las plataformas actuales de una organización, pueden llevar a decisiones de la implementación de controles alternativos, de la segregación de responsabilidades y del establecimiento de puntos de control, así como su frecuencia de revisión para lograr minimizar la posibilidad de que se materialicen los riesgos. Siempre hay algo que se puede mejorar y hay que intentarlo, medir el efecto de las decisiones tomadas y volver a evaluar.

La Construcción de Políticas de TI

Como todo marco regulatorio, el conjunto de normas que rigen las operaciones de TI deben de ser dirigidas por políticas. La construcción de las políticas debe de considerarse como el paso número uno de la generación de un marco regulatorio más grande. ¿Qué debemos evitar? La gerencia de TI debe de implementar normas que apoyen la gestión del negocio, que tengan el mismo sentido de dirección y organización que tiene la empresa, por lo que lo primero que hay que evitar, es el impulso de políticas que se distancien de los planes organizacionales. La principal razón por la cual las políticas deben de ser aprobadas al más alto nivel organizacional es el garantizar que su enfoque ha sido presentado a la alta dirección, que se han discutido las implicaciones y que se han elegido los lineamientos que tienen todo el apoyo de la alta dirección. Esto es especialmente importante en los grandes corporativos, que se expanden en diferentes empresas y muchas veces obligan a la coordinación de diferentes departamentos de informática, algunos de ellos operando sobre diferentes condiciones por el giro al que se dedican, las regulaciones externas aplicables y la situación competitiva. En el ambiente de una empresa más pequeña, siempre tiene importancia la aprobación de la alta dirección, especialmente porque en estas empresas puede suceder que las relaciones de confianza entre los diferentes usuarios con la alta dirección, lleve a los usuarios a solicitar autorizaciones a la alta dirección para no cumplir con las regulaciones de TI, bajo cualquier pretexto, sea válido o no. En estos casos, la definición de políticas y el proceso de discusión que tiene que llevar a un entendimiento de la alta dirección del objetivo de cada política, de los riesgos que se están previendo, de la motivación para incrementar la seguridad de la información o la eficiencia de las operaciones. Se puede decir que la definición de políticas debe de ser visto como el primer punto de integración de las operaciones de TI con el negocio, a un nivel pre-operativo, que establece lineamientos para realizar tareas más específicas, que serán posteriormente detalladas por normas específicas, la adopción de estándares y la definición de procedimientos de trabajo.

Podemos concluir entonces que la construcción de políticas de TI debe de estar en sintonía con las intenciones de la organización y el nivel de soporte de TI necesario para lograr los objetivos del negocio. Por lo tanto, no es sano sólo copiar las políticas de otra organización. La aprobación de políticas por la alta dirección debe de garantizar que se han discutido y entendido las consecuencias de una política determinada y que no se presentarán desviaciones significativas en su ejecución.

A %d blogueros les gusta esto: