Archivo del sitio
UNIVERSO DE AUDITORIA DE TI, PARTE II
Priorizando las auditorías a realizar.
En el blog anterior, establecimos que el Auditor de Sistemas debe de realizar una investigación para conocer la empresa y la forma en la que las Tecnologías de la Información están soportando los objetivos del negocio. Es una investigación exhaustiva, que permita identificar todos los elementos auditables en la organización y generar una lista de elementos auditables que incluimos en una lista que denominaremos Universo de Auditoría.
Para tratar esa lista, el Auditor de Sistemas debe establecer criterios que le permitan establecer un orden que le indique qué se auditará primero y que se auditará después. Realmente, estamos hablando de que se incluirá en un Plan de Trabajo de la Auditoría de Sistemas, para un horizonte de planificación que normalmente será de un año. Posiblemente para cubrir un Universo de Auditoría de manera completa, se requiere un esfuerzo en horas auditor, que expanda varios años. Esto hace muy importante, que los elementos auditables de la lista del Universo de Auditoría se categoricen para auditar primero los temas de mayor relevancia para la organización, permitiendo al Auditor de Sistemas aportar recomendaciones de manera oportuna.
El primer criterio utilizado es el riesgo. El riesgo se refiere a prever o inferir la ocurrencia de eventos que puedan causar el impacto de que una organización pueda fallar en sus objetivos de negocio. Por contrapartida, el trabajo de soporte de la función de TI contribuye a mitigar estos riesgos, a través la ejecución de acciones que eviten que los eventos de riesgo ocurran o que limiten o mitiguen el efecto causado. Por esta razón, las actividades que desarrolla la función de TI tienden a verse como “controles” que mitigan riesgos en una organización. Si ponemos un ejemplo para clarificar estos conceptos, pensemos en el evento de riesgo que se podría dar cuando se daña un dispositivo que almacena información importante para la organización. El riesgo real, es que el negocio no pueda operar al ritmo esperado por no contar con la información almacenada en el activo informático en cuestión. Esto podría traer un impacto económico, como el retraso o la pérdida de ingresos, o un impacto reputacional, por no poder proporcionar el nivel de servicio esperado por el cliente. La Gerencia de TI, ante este riesgo, puede haber dispuesto varios controles o actividades para mitigarlo. Uno podría ser la ejecución de respaldos frecuentes que permitan contar con un medio de recuperación en casos de falla.
Aunque existen muchas técnicas para realizar una Evaluación de Riesgos, es importante seleccionar una que no demande demasiado esfuerzo de realización, que permita priorizar de manera efectiva, de tal manera que el Auditor de Sistemas pueda obtener una clasificación en un tiempo razonable. Aun así, dependiendo del tamaño de la organización y sus operaciones, este análisis requerirá de un esfuerzo de semanas o quizá meses, pero que resulta importante para lograr efectividad en el trabajo posterior del Auditor de Sistemas. Si la empresa ha madurado la función de Gestión de Riesgos y cuenta con una evaluación organizacional de riesgos muy sólida, esto facilita las cosas. Porque como Auditores de Sistemas, podemos confiar en el trabajo de otros profesionales para cumplir con nuestra función. También es conveniente notar, que el Auditor de Sistemas debe de utilizar su criterio profesional con toda la información que analiza, por lo que, si al analizar una evaluación de riesgos organizacional, existen valoraciones que no considere correctas, el Auditor de Sistemas deberá de realizar sus correcciones para contar con una evaluación de riesgos que satisfaga sus propios criterios. También el Auditor de Sistemas tendrá que relacionar cada elemento del Universo de Auditoría con los riesgos que mitiga. Esto es lo que permite la categorización de los elementos, asignando mayor prioridad a los que mitigan riesgos más críticos y dejando después a los que ataquen riesgos medios o bajos.
Si no existe una Evaluación de Riesgos organizacional, el Auditor de Sistemas deberá realizar su propia valoración de los riesgos existentes y ubicar la importancia que tiene cada elemento del Universo de Auditoría para prevenir, detectar o mitigar los riesgos. En todo caso, se determinará cuáles elementos de la lista resultan más importantes de auditar de acuerdo con los riesgos que ayudan a mitigar, comenzando con los de mayor riesgo.
Un segundo criterio utilizado por el Auditor de Sistemas son los requerimientos regulatorios. Si la organización está sometida a requerimientos de ley que especifican que las Tecnologías de la Información cumplan con ciertos requerimientos, o incluso sean específicas con respecto al trabajo del Auditor de Sistemas, estos pasan a tener una alta prioridad en la lista de elementos auditables. No cumplir con regulaciones de Ley trae impactos directos a la organización y estos deben de ser gestionados y resueltos oportunamente. A veces, dichas regulaciones implican la emisión de informes en momentos específicos, lo que da una pauta del momento en que tienen que ser realizados los trabajos de auditoría para cumplir con el requerimiento legal.
Finalmente, el Auditor de Sistemas deberá de utilizar sus conocimientos de la organización, para determinar la existencia de requerimientos que tienen que priorizarse para lograr efectividad y oportunidad. Aquí entra en juego, los requerimientos específicos de la contraparte directa del Auditor de Sistemas, iniciando por el Gerente de Auditoría, pero que también pueden ser peticiones específicas del Comité de Auditoría, la Junta Directiva o la Alta Administración. Por ejemplo, si la organización realizará inversiones en Tecnologías de la Información, el acompañamiento oportuno durante los proyectos podría ser prioritario. Si se determina que Auditorías previas, internas o externas, de sistemas o de otra índole, reportaron hallazgos relacionados con las Tecnologías de la Información, la revisión del cumplimiento y superación de los hallazgos se vuelve también otro criterio de priorización.
Siguiendo los criterios mencionados, el Auditor de Sistemas estará en capacidad de priorizar la lista de elementos auditables y establecer las prioridades claras sobre las auditorías que realizará. Es normal que un Universo de Auditoría se cubra de forma completa en dos o más años. También es normal, que existan elementos que no se auditen nunca. Lo importante es que el Auditor de Sistemas aportará valor a la organización, proporcionando recomendaciones relevantes, en los momentos que se necesitan.
Si gustan pueden comentar sobre otros criterios que han utilizado en su experiencia profesional para categorizar los elementos auditables de una organización.
Identificar, el primer paso en la Cyberseguridad
Hace unos días recalcaba la importancia del framework de Cyberseguridad de NIST en el contexto de los eventos de ataques a las infraestructuras de TI que están sucediendo. Vamos a iniciar un recorrido por las fases, comentando puntos que han probado ser hitos difíciles de superar en la gestión de la seguridad de la información.
La primera fase se refiere a la identificación de todo lo que tiene importancia para la gestión de la información. El lector debe de tener sumo cuidado en no confundir esta fase con la tradicional identificación de activos de información de otros frameworks. Aunque es necesario tener identificados los activos de información, esto es dispositivos que almacenan, transportan o procesan información, el framework también incluye en esa fase importantes categorías que se relacionan con la identificación de funciones crítica de la gestión de TI. Estas categorías son: el ambiente de negocios, el gobierno de la seguridad, la evaluación de riesgos y el análisis de riesgos operacionales. Estas categorías en la realidad tienden a ser ignoradas en las empresas, pero representan hitos fundamentales en el control de la seguridad de la información. Quizá la más relevante sea la evaluación de riesgos de seguridad porque es la que aporta información crucial para entender la importancia de la seguridad de la información para el negocio. Es también la más difícil de asimilar para el negocio. Mi mejor comentario aquí para los dueños de negocio es: si no quieren gastar de forma aleatoria en seguridad, participen en la evaluación de riesgos para dejarle claro a los responsables de la seguridad adónde es que están los riesgos que impactan en la organización. Es importante mencionar que el framework no es solamente técnico y cuando establece la categoría de evaluación de riesgos, en unos de sus componentes especifica directamente que “los impactos potenciales al negocio” sean identificados. Esta frase debe dejarnos clara la idea de que la implementación de la cyberseguridad debe realizarse de acuerdo con los lineamientos del negocio. Hay que recordar aquí que un riesgo es todo lo que podría pasar que tiene la probabilidad de impedir el lograr los objetivos de negocio.
Tener una idea de los riesgos ayudará también a definir el Gobierno de la Seguridad que es necesario para la empresa. Es importante que se identifiquen roles y responsabilidades a todos los niveles de tal forma que se obtenga la seguridad a partir de un conjunto ordenado de esfuerzos. En el área de gobierno, el establecimiento de políticas de seguridad que son continuamente monitoreadas para establecer su efectividad y necesidades de mejora es una tarea primaria.
En la categoría del ambiente de negocios, es importante considerar aquellos procesos de gestión de TI que están pensados para interactuar con el negocio. El establecimiento de niveles de acuerdo de servicios, la gestión de proveedores, la gestión de la capacidad y similares, que garanticen que la información estará disponible, se mantendrá integra y será confidencial cuando las necesidades del negocio así lo requieran.
Por último, la gestión del riesgo operacional es una necesidad eminente de la Gerencia de TI. Esto es identificar riesgos en las operaciones de TI y preparar acciones mitigantes o de reacción en caso de que se materialicen. Esta categoría es importante para no perder disponibilidad en caso de un evento contingencial. Por ejemplo, que pasaría si un empleado “critico” se enferma. Esto es un riesgo operacional. ¿Hemos preparado a alguien más para desempeñar sus funciones críticas? ¿Sabíamos que era crítico? ¿Tenemos documentación suficiente para responder al negocio aunque falte el empleado? Estas preguntas nos hacen entender que no sólo hay que identificar activos en esta fase, sino que es una fase para identificar todo lo que es importante para una gestión eficiente de la seguridad de la información, tomando como criterio primordial el impacto que se necesita evitar a las operaciones del negocio.
Los Diferentes Ángulos de la Seguridad de la Información
Aunque trabajo en la auditoría de sistemas de información, el análisis de riesgos, de rigor para el ejercicio de la auditoría en general, siempre me lleva revisar y a identificar hallazgos relacionados con la seguridad de la información. De esto podemos concluir, que las amenazas a la seguridad de la información, constituyen uno de los mayores riesgos para que las operaciones de TI cumplan con su objetivo de soportar las operaciones de negocio de una manera eficiente.
Para soportar el negocio eficientemente, las operaciones de TI no pueden ser interrumpidas por ataques que nos lleven a tener que reconfigurar equipos o a perder información. Pero existen amenazas más problemáticas aún para el negocio, como es la posibilidad de que terceros tengan acceso a mi información, que obtengan copia de ella o que la modifiquen. Cada escenario que puse de ejemplo parece más y más siniestro. Pero en ese mundo es en el que se vive. Afortunadamente, el universo de equipos y direcciones IP aún es grande y muchas empresas en el ámbito centroamericano no son objetivos tácitos de este tipo de ataques. Pero eso no significa que las Gerencias de TI pueden tener la guardia baja y no realicen acciones para proteger la información de su empresa. Aunque ya existen estándares definidos para abordar el tema de seguridad a continuación enumero una lista de áreas que deben de ser atendidas como un mínimo desde el punto de vista de la seguridad informática:
1. Las configuraciones de antivirus. Aquí es importante no solo el contar con software de este tipo, sino también garantizar su efectividad a través de la actualización de la definición de virus.
2. Las configuraciones de sistemas operativos. Aunque obviamente son más importantes las de los servidores, equipos clientes desactualizados pueden servir de plataforma para el lanzamiento de ataques, por lo que hay que considerar ambos entornos.
3. Las redes. En estos momentos es ya imposible vivir sin estar conectados. Los ambiente empresariales exigen el uso de correo electrónico, soluciones de comunicaciones, mensajeria y el mismo acceso a la Web. Pero la conectividad debe de ser restringuida a través de un diseño efectivo de la red y la configuración adecuada de los equipos que forman parte de la red, como routers y firewalls, así como por los que la protegen, como los firewalls.
4. La administración del acceso a las aplicaciones. Esto implica la definición de mecanismos de acceso y autenticación efectivos de los usuarios con la autorización para registrar, modificar y consultar datos en una aplicación.
5. Las normas de gestión de la seguridad. Las medidas de seguridad necesitan ser acompañadas de prácticas que garanticen su efectividad. Estas practicas tienen que ver con la revisión rutinaria del estado de todas las salvaguardas establecidas, la evaluación de la efectividad de las medidas, la detección y correción de excepciones e incluso el diseño de nuevas medidas para resolver nuevos incidentes de seguridad.
Áreas adicionales podrian ser consideradas. De acuerdo a las condiciones de cada empresa y su perfil de riesgo se podría llegar a definir cosas como la clafisicación de la información, las protecciones físicas de los activos de información, los planes de continuidad y el cifrado de la información.
Lo importante es que los responsables de la función de TI estén atentos a identificar y resolver los principales riesgos de seguridad de la información que afronta en su ambiente operativo, haciendo uso de las herramientas adecuadas y configurándolas en su nivel óptimo.
Por supuesto, la Alta Dirección debe de hacer uso de la Auditoría de Sistemas para obtener un aseguramiento de que las medidas de seguridad definidas e implementadas en la organización son adecuadas, se han implementado de una forma óptima y se encuentran operacionales. De no ser así, las Auditoría de Sistemas colaborará con la Gerencia General en la definición y verificación de un plan de implementación que permita cerrar las brechas descubiertas y mejorar la posición de seguridad de la organización.
La importancia del Plan de Contingencia de TI
El objetivo de este blog es establecer que es un Plan de Contingencia de TI y su importancia en las organizaciones.
El Plan de Contingencia de TI es una herramienta que mitiga el riesgo de no poder continuar con las operaciones por períodos que se prolongan más allá de lo soportado por los procesos de negocio. Es decir, no estamos hablando de interrupciones debidas a un corte de energía eléctrica. Un corte de energía eléctrica en los países centroamericanos es tan frecuente, que para poder operar, los centros de datos y lugares críticos de procesamiento de datos, deben de tener implementados sistemas de redundancia eléctrica, protección ante los cambios de voltaje y la generación de energía alterna a la fuente primaria. Por supuesto, la inversión a realizar en la protección eléctrica debe ser en proporción a la importancia que tiene el proteger los activos y mantener las operaciones funcionando. Si ponemos de ejemplo un Banco, seguramente para no interrumpir el flujo de atención a clientes, la protección eléctrica incluirá hasta plantas de generación eléctrica con capacidad para mantener operando todas las oficinas de manera continua. No hacer esto, implicaría además de un impacto financiero, al retrasar la percepción de ingresos, un daño a la imagen del Banco, que tendría a los clientes esperando a que se reanuden los servicios.
El Plan de Contingencia de TI va más allá. Cuando el centro de datos falla, junto con todos sus mecanismos de protección primaria, cuando se pone en riesgo no sólo las operaciones, sino la integridad física de las personas, el Plan de Contingencia debe de ser la guía que indica qué hacer. Responde a preguntas como: ¿Qué pasa si se inunda mi área de operaciones? ¿Qué pasa si se incendia el edificio? ¿Qué pasa si un terremoto destruye el edificio? ¿Qué pasa si un volcán hace erupción y me obliga a parar operaciones? En todos estos casos, la ejecución de negocios de manera normal no es posible, por lo que el Plan de Contingencia de TI debe prever como se trasladarán las operaciones, las tareas que hay realizar, quién será el responsable de realizarlas, como se comunicarán los equipos y la ejecución de procedimientos de contingencia para que se reconecten los vínculos con clientes, proveedores y empleados. Definitivamente, un Plan de Contingencia de TI es uno de esos planes que uno quisiese no tener nunca que ejecutar, pero llegado el momento de un desastre, es considerado un activo valioso de la empresa, preparada para afrontar problemas y seguir adelante con la ejecución de planes.
La creación de un Plan de Contingencia de TI inicia con las priorización de todos los activos de información, entendiendo en cada caso el nivel de criticidad para los objetivos de la empresa. Posiblemente, en una organización grande existan servicios que facilitan labores secundarias que no son precisamente en las que hay que enfocarse. Esta categorización debe ser realizada con la participación con los dueños de la información, comenzando con la alta dirección. Como resultado de este análisis, quién realiza el Plan de Contingencia de TI conocerá exactamente el orden en el que deben de afrontarse las contingencias, los servicios que deben iniciarse primero y todos los recursos involucrados. Esta priorización debe ser realizada tanto a nivel cualitativo como a nivel cuantitativo. Debe establecerse claramente el monto de pérdida por el cese de operaciones para poder establecer un plan de contingencia que con una inversión razonable minimice la pérdida. Esto es, el Plan de Contingencia no debe de ser más costoso que la pérdida, porque si ese fuera el caso, no tendría viabilidad financiera. Esto permite concluir que el Plan de Contingencia de TI es importante desde el punto de vista financiero para una organización, reduciendo la pérdida y el impacto en el negocio en caso de un desastre.
La Medición del Riesgo de TI
Iniciaré este tema, planteando la situación ideal de la gestión de riesgos de TI. De manera ideal, una buena organización de TI es capaz de identificar la eminente materialización de un riesgo, algo que está por suceder que impactará negativamente las operaciones normales, ejecutar acciones que eliminen o mitiguen la materialización del riesgo y luego eliminen la causa raíz por la cual se incrementó el riesgo operativo de la organización. Es importante entender que esta situación se puede dar a cualquier nivel, en cualquier área de las operaciones de TI, más sin embargo, la organización está lista para identificar y responder a los riesgos. Fin de la situación ideal. Se vale soñar pensarán algunos, esto suena como la fantasía de un Gerente de Informática.
Medir el riesgo de TI es importante para iniciar proyectos de control interno de TI, seguridad de la información y auditoría de sistemas. Cada norma y procedimiento en estas áreas menciona que se deben de tomar decisiones basadas en el nivel de riesgo existente. Sin embargo, independientemente de la implementación de normas específicas, la gestión de TI necesita conocer de la situación de riesgos existente en las operaciones de TI y tomar decisiones que permitan eliminar o mitigar los riesgos existentes.
Para ejemplarizar un riesgo, pensemos en que sucede en nuestro centro de cómputo cuando existe un alza en el voltaje eléctrico. La vulnerabilidad aquí es el suministro eléctrico, que está expuesto a la amenaza de un incremento en el voltaje, que ciertamente puede dañar servidores y equipos de comunicaciones. El resultado final, al materializarse esta amenaza, es un alto en las operaciones de TI y por consiguiente, un alto en las operaciones de negocio. Manejar este riesgo implica, primero reconocer que esta situación se puede dar, esto es el paso de identificación. Las acciones que se deben de tomar, son preventivas. Este es un riesgo que no podremos mitigar después de ocurrida la incidencia, sin pérdidas grandes para la organización. Las medidas preventivas pueden incluir el diseño de un circuito eléctrico propiamente aterrizado y con el equipo necesario para asegurar que cualquier alza de voltaje es debidamente canalizada hacia el aterrizaje, llegando incluso hasta la desconexión total de la red de suministro y pasando a una alimentación secundaria, ya sea por baterías o plantas eléctricas propias. Obviamente, el nivel de respuesta dependerá de cuánto dinero esté en riesgo.
Como regla general existe una sola razón que permite que todas las decisiones de control y mitigación de riesgos sean tomadas, que es cuando el ingreso proveniente de las operaciones del negocio está en riesgo evidente de ser interrumpido. Disminuir el ingreso es letal para las organizaciones, dado que impacta directamente en los resultados.
La principal dificultad a la hora de evaluar riesgos en TI radica en que normalmente no hay una vinculación de los servicios de TI contra los procesos que generan ingresos y el nivel de dependencia que estos procesos tienen de los servicios. Si hablo solo de la industria salvadoreña, en la mayoría de empresas los mismos “servicios de TI” no han sido definidos, lo cual significa que el universo de riesgos es imposible de definir. Esto es grave en un marco de gestión de TI en el que se quiere conocer, evaluar y gestionar los riesgos de TI. Esto nos lleva a concluir, que para medir el riesgo de TI, se tiene como pre-requisito conocer la operación de TI y la dependencia que el negocio tiene de TI para lograr sus objetivos. Esto implica conocer que hacemos, con qué lo hacemos y establecer una medición del nivel de importancia que tenemos en la creación de valor para la empresa. Créanme que escribir estas líneas es fácil, pero la realidad es que en el entorno salvadoreño la mayoría de empresas no ha logrado aún definir su catálogo de servicios, con lo cual podrían iniciar esta cadena de decisiones que les lleven a una eficiente y efectiva gestión de riesgos. Esto incluso proporciona respuesta a los gerentes de informática que aún preguntan y ¿Para qué implementar normas y metodologías de gestión en TI? Realmente, la implementación planificada del Gobierno de TI, proporciona a los departamentos de TI la visibilidad y el control que permite a toda la organización entender la importancia de la función de TI.
Revisión de las políticas de TI
Con el inicio del año, las revisiones del trabajo realizado resultan pertinentes. Esto incluye la revisión de las políticas de TI. En muchas Gerencias de Informática, se plantea esta tarea como un hito a solventar, en períodos de tiempo que muchas veces son menores a un mes. Como resultado, la revisión no es concluida en el tiempo previsto o no es realizada de manera total. Para realizar bien un proceso de revisión de políticas de TI debemos de entender bien lo que implica, quienes son los involucrados y cuál es el ritmo que debemos de seguir a efectos de tener un marco de control interno de TI actualizado y eficaz.
Todos sabemos que la creación inicial de políticas de TI es una tarea difícil, que a veces toma meses o años de realización. En el desarrollo mismo del proyecto de creación inicial de las políticas de TI ocurren cambios al entorno tecnológico, en el contexto del negocio y en las amenazas externas que percibimos. Por esta razón, es muy probable que al terminar las políticas de TI estas ya requieran de cambios para solventar los nuevos retos. La actualización de las políticas debe de tener como objetivo el cubrir por lo menos el mismo número de riesgos que se pretendió cubrir al momento de su creación. Esto convierte en relevante la actualización permanente de la matriz de riesgos tecnológicos de la organización. Cambios en la matriz indican necesariamente cambios en las políticas de TI. Como ya sabemos, la evaluación de riesgos es una actividad permanente. Si algo es fundamental para la correcta gestión de TI es no dejar pasar desapercibidos los nuevos riesgos que aparecen en la gestión de TI. No hacerlo implica muchas sorpresas para la Gerencia de TI, que van desde el uso ineficiente de los recursos o sistemas que no funcionan hasta la pérdida de información. Muchos problemas. Por lo tanto, los responsables de monitorear los riesgos de TI serán los primeros en señalar la necesidad de una revisión de políticas de TI. Esto en el sentido amplio significa, la actualización de políticas existentes o la creación de nuevas.
Una práctica de gestión de TI saludable, divide las funciones entre varios individuos. Lo mismo pasa con las políticas. Cada política debe de tener definido a un responsable de la formulación, un revisor y la persona que autoriza. Estos roles, pueden ser desempeñados por equipos de trabajo, dirigidos por el responsable directo de cada rol. Muchas veces, esta interacción entre varias personas o grupos es la causa del retraso en la revisión y aprobación de las políticas de TI. Este es un factor que debe de ser considerado al momento de la planificación de la revisión, estableciendo periodos de actualización, revisión y aprobación. De esta manera, se deduce que más que un punto fijo en el tiempo para revisar todas las políticas, el mejor ritmo a seguir será una programación anual que considere la planificación de las evaluaciones de riesgos y la interacción entre los equipos de formulación, revisión y aprobación. En empresas grandes, con muchas políticas, el ciclo de revisión total podría demorar 2 años. Lo importante es conocer esa ruta de creación y actualización de las políticas y estar atentos a los cambios en las necesidades del negocio para poder contribuir de la mejor manera a la obtención de los objetivos 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.
¡Terremoto en Costa Rica! Ayer se probaron los Planes de Contingencia Tecnológica.
No cabe duda que los fenómenos naturales que causan desastres suceden tarde o temprano. Me parece que esa parte de la realidad es conocida y en las organizaciones se espera que suceda lo más tarde posible, lo suficiente como para estar preparados para afrontar la contingencia. Por supuesto, ante un desastre natural del tipo que aconteció ayer en Costa Rica, lo primero es salvaguardar las vidas humanas, la seguridad de la integridad física de las personas. Pero posteriormente al evento, en momentos en los que aún se está sufriendo la experiencia de pasar por el evento, hay que asegurar que los activos de la organización serán protegidos. Leía la noticia sobre como algunas agencias bancarias cerraban “por precaución” y me preguntaba si esa era una medida ya calculada, “paso uno del plan de contingencia tecnológica en caso de terremoto”. Otras noticias decían que las comunicaciones habían tenido problemas en la primera hora posterior al evento. Esto es un impacto en las comunicaciones, que bien podría haber dejado partes de la red de datos de una organización sin acceso. “Paso número 2”, definir el estado de funcionalidad después del evento catastrófico. La verdad es que en esos momentos las decisiones tienen que ser bien medidas. El Gerente del Proceso de Contingencia o el Líder de Contingencia tiene primero que buscar la información y si la obtiene, tomar la mejor decisión a partir de lo que sabe. Si no la obtiene, aún tendrá que tomar la decisión de qué hacer, pero con un margen de error más grande.
Cuando se diseñan los Planes de Contingencia, siempre es bien difícil hacer entender al personal de una organización que hay que pensar en los escenarios de un evento que obligue a la activación del Plan de Contingencia. Por ejemplo, después de un terremoto, podría ser que se cuenten con los empleados claves. En ese escenario, ellos realizarán las actividades claves de recuperación ejecutando los roles que normalmente desempeñan. Escenario 2, no está disponible un empleado clave por las mismas causas del evento. Este escenario obliga a pensar de antemano en la persona, o personas en una cadena de sucesión, que retomarían sus funciones. Este escenario obliga a crear también relaciones de comunicación entre los funcionarios claves y sus sucesores en caso de contingencia. Obliga a establecer capacitaciones para los sucesores. Obliga a revisar que la documentación de los procesos este clara y actualizada, así como obliga a la lectura por parte de los sucesores, quienes podrían incluso hacer observaciones que mejoren la documentación existente. Esos escenarios y muchos más, son los que se tiene que pensar de antemano cuando se está creando un Plan de Contingencia Tecnológica. Escenarios con sus consecuencias en términos de personas involucradas, conocimiento identificado como crítico, capacitaciones y mejor documentación.
Quizá el principal problema del personal en las organizaciones es la falta de imaginación. Siempre la usamos para imaginar lo mejor, por lo que imaginar que sucede algo malo, de carácter catastrófico, nos hace dudar de cuales serían los escenarios de un evento catastrófico. La recomendación es: ¿Tiene su organización un Plan de Contingencia para afrontar estos escenarios? Si la respuesta es no, tienen trabajo y ojalá el tiempo para hacerlo sea menor que lo que falta para el siguiente evento catastrófico.
La planificación de la Auditoría de Sistemas.
Un paso importante en el proceso de Auditoría de Sistemas es la definición de un Plan de Auditoría. Esta es una actividad que debería de hacerse a finales de año, a partir de la experiencia de las auditorías del año actual, a partir de los objetivos de la organización para el nuevo año y a partir de los proyectos planificados para el próximo año y ojalá, a partir de la situación de riesgos evaluados en el momento de realizar la planificación. En un universo de riesgos que siempre es más grande que las horas disponibles para realizar auditorías, siempre tienen que existir criterios para decidir que es lo que se audita y que no. El caso ideal, pero muy infrecuente de ver en nuestras empresas salvadoreñas, es cuando se ha realizado un ejercicio total de análisis de riesgo, el cual se actualiza con las revisiones de auditoría realizadas y de esta forma permite establecer a través de un sistema de calificación cuales áreas presentan más riesgos y entonces, no hay nada más que discutir, se audita lo que tiene mayores riesgos.
Otras empresas adoptan un patrón cíclico. Tienen el inventario de procesos desarrollados en la organización y a partir de este listado, se van eligiendo los temas que se revisarán. Es un enfoque que puede guiarse por el “olfato de riesgo” que tenga el auditor, que no siempre es acertado, pero en fin, es otra manera de actuar.
Si se quiere hacer crecer el nivel del control interno en las operaciones de TI, lo más conveniente es no sólo ver hacia adentro de la organización, sino también ver hacia afuera. La pregunta es ¿Qué establece un marco de referencia como COBIT que debe de realizar la gestión de TI?¿Cuales de estos procesos tendrían una importancia alta para la organización?¿Cuales serían los procesos que aportarían valor a la gestión de TI? A partir de estas respuestas, se puede desarrollar un plan que va a forzar a crecer a las organizaciones en su ambiente de control interno de TI, al considerar los riesgos documentados por los marcos de referencia en la organización, al considerar las prácticas de gestión recomendadas versus las practicas adoptadas o no ejecutadas por la función de TI. Sin duda alguna, este enfoque proporcionará un buen resultado de las auditorías de TI. Si se decide realizar este enfoque, es conveniente que el auditor coordine con la gestión de TI el enfoque de la auditoría. De esta manera se puede lograr un crecimiento simbiótico de la gestión de TI en la organización. No se trata de esconder el criterio de evaluación, se trata de que todos entiendan lo mismo al hablar de un proceso y que exista consenso en la necesidad para la organización. Es conveniente recordar aquí que existen muchos marcos de referencia que la Gestión de TI puede seguir. Incluso la elección del marco de referencia debe de ser guiado por el tipo y nivel de riesgos a mitigar y las necesidades de la organización. Por ejemplo, es inexplicable encontrar organizaciones que tienen que cumplir con marcos regulatorios y ni el responsable de TI implementa la regulación, ni el departamento de auditoría ha realizado una revisión del cumplimiento. Definitivamente, las decisiones tomadas al momento de hacer un Plan de Auditoría impactan en los niveles de cumplimiento de la organización. Siempre hay que pensar que aunque la situación de cumplimiento de normas y regulaciones en una organización no sea el óptimo hoy, esa condición tiene que mejorar en el futuro a partir del trabajo realizado, ya sea en la gestión o en la auditoría de TI.
Creo que dejaré esta entrada hasta aquí. Tengo que hacer un Plan de Auditoría.
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.
Gestión y Auditoría de TI 