Archivo de la categoría: Riesgos de TI
UNIVERSO DE AUDITORÍA DE TI, PARTE I
La efectividad en la elección de qué auditar.
Los Auditores de Sistemas trabajamos con limitados recursos, especialmente de tiempo, para auditar un área que es muy importante, sino vital, para el logro de los objetivos del negocio. Esta situación nos lleva a priorizar qué auditar, teniendo forzosamente que dejar algunos temas para después. Sin embargo, es importante tener una idea clara del estado del uso de las Tecnologías de la Información en la organización a efecto de que la priorización no deje por fuera alcances transcendentes para el cumplimiento de la empresa. Aquí es dónde la tarea de crear el Universo de Auditoría ayuda a enfocar los recursos de Auditoría de la mejor manera.
Definición del Universo de Auditoría.
El Universo de Auditoría se refiere a todas las posibles auditorías que se pueden realizar en una organización. Cada evaluación de auditoría debe tener un alcance que permita al auditor dar a la organización resultados efectivos, esto es, informes que provean las recomendaciones necesarias de manera oportuna.
Previo a la creación del Universo de Auditoría, el Auditor de Sistemas tiene que realizar tareas que le permitan tomar decisiones bien informadas sobre que incluir y que no en el Universo de Auditoría, así como el tener la capacidad de evaluar de la manera más precisa posible los riesgos existentes.
En esta entrada del blog, vamos a tratar sobre la fase de generación de los elementos auditables de una organización, para posteriormente abordar el tema de cómo priorizar.
En la primera parte del proceso el Auditor de Sistemas debe asegurarse que entiende el funcionamiento del negocio, los procesos o actividades que son importantes para el logro de objetivos de la empresa y los principales riesgos que afronta en relación con su dependencia de las Tecnologías de la Información. Hay que recordar que las Tecnologías de la Información son cada vez más relevantes en todos los tipos de negocio, pudiendo llegar a ser un factor indispensable para las operaciones en muchas industrias, o un factor diferenciador en otras. Posteriormente, se debe de entender completamente como se están gestionando las Tecnologías de la Información. El Auditor de Sistemas debe entender porque las Tecnologías de la Información son importantes para la empresa, cómo están soportando los objetivos de negocio y los riesgos a la operación. También se debe conocer la forma en que el departamento de TI se ha organizado para responder a las necesidades de la organización, las Tecnologías actualmente implementadas y los planes para adoptar nuevas plataformas o mejorar/actualizar las actuales.
Estas dos actividades de recopilación de información permitirán crear una lista de elementos que podrán ser considerados dentro del Universo de Auditoría. Esta es una fase en la que interesa capturar todos los elementos posibles. Estos elementos incluyen cosas como: el esquema normativo o políticas vigentes, la organización, procesos de gestión de TI implementados y sus normas de referencia, Tecnologías específicas utilizadas, proyectos, e incluso actividades específicas, como los respaldos de datos, que por su importancia requieren de consideración especial. Esto es un paso crucial porque impacta en la forma en la que la organización identificará el trabajo del Auditor de Sistemas como valioso. Por ejemplo, si se decide evaluar la Gestión de la Continuidad como una sola auditoría, el estudio podría tomar mucho tiempo, incluso meses en ser ejecutado. Si en el transcurso de esos meses, falla un equipo crítico y se descubre que los respaldos no se habían gestionado bien y el tiempo de recuperación se expande por esta razón, la empresa se vería impactada en costos adicionales tanto por el mismo proceso de reparación, como por el hecho de trabajar con métodos alternativos mientras se termina la recuperación. Si se define como una actividad auditable los procedimientos de Gestión de Respaldos, este estudio se podría realizar antes que abordar todo el proceso de Gestión de la Continuidad y probablemente en dos semanas o un poco más, el Auditor de Sistemas tendría la información suficiente para detectar cualquier problema con la ejecución de los respaldos, alertar a la organización y coordinar planes de acción de manera oportuna.
Una regla general para considerar cada elemento a incluir en un Universo de Auditoría es que la ejecución de una auditoría para cada elemento pueda ser realizada en menos de un mes. Esto permitirá al Auditor proporcionar al menos mensualmente, resultados a la empresa que serán oportunos y eficaces.
Atendiendo las tendencias de la auditoría ágil, que busca dar resultados inmediatos, en lugar de la realización de evaluaciones largas que tomen demasiado tiempo, el auditor de sistemas debe evaluar cada proceso que entrará al universo de auditoría y si este debe examinarse en una sola auditoría o si por practicidad, debe de realizarse en varias auditorías con alcances más limitados.
Si por ejemplo tomamos el proceso de Gestión de la Seguridad, nos daremos cuenta de que hacer una evaluación única para el tema, representará un esfuerzo de muchas horas, que se podrían llegar a traducirse en meses. Este tipo de procesos es conveniente partirlos en varias secciones, como, por ejemplo, Estrategia de Seguridad, Seguridad en Servidores, (Qué incluso se puede subdividir por tipos de sistema operativo), Seguridad en la red, Gestión de Accesos en aplicaciones. Esto permitirá realizar una priorización más acertada de acuerdo con el nivel de riesgo percibido en cada área que se pueda auditar.
Un proceso que también tiene que subdividirse y darle prioridad, son las evaluaciones normativas, es decir, las que son mandadas por alguna norma o ley aplicable al área de negocios de la organización. El Auditor de Sistemas debe de identificar los requerimientos regulativos e incluirlos como un elemento auditable dentro del Universo de Auditoría.
Concluyendo, en la primera fase de la creación del Universo de Auditoría, el Auditor de Sistemas realizará una investigación sobre el funcionamiento de la empresa y su modelo de negocio, las Tecnologías de la información utilizadas para soportar el negocio y la forma en la que se gestionan, a efectos de ir creando una lista de todo lo que se pueda auditar. En la próxima entrada del blog veremos cómo se tratará esa lista para categorizarla de acuerdo con criterios de priorización. Mientras tanto, coméntenme si les parece útil contar con una lista guía de elementos auditables y si les gustaría verla en el sitio. Hasta pronto.
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.
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.
La Administración Segura de los Recursos de TI
Para los profesionales en Auditoría de Sistemas que trabajamos siguiendo estándares internacionales en diferentes áreas es difícil auditar ambientes que no siguen estándar alguno. Seguir un estándar proporciona un criterio verificado por una organización que tiene un respaldo que garantiza que los resultados no son antojadizos y que en la elaboración del estándar se ha seguido una metodología que garantice resultados satisfactorios si el estándar es seguido. En el primer mundo las regulaciones han venido a ser tan amplias, que seguirlas se ha convertido en la norma y las auditorías que se basan en estándares resultan normales y en la mayoría de los casos sirven sólo para confirmar que se está siguiendo una buena práctica en la gestión de TI y los riesgos a la seguridad de la información están mitigados. Por otro lado, en el medio centroamericano gestionar tecnología sin seguir estándares es más bien la norma seguida. Esto es un producto de la calidad de nuestras universidades, que adoptan prácticas de gestión de Tecnologías de la Información de manera tardía y en muchas ocasiones sin el soporte adecuado de entrenamiento, tanto para los docentes como para los estudiantes. Es una situación difícil, pero superable por una gestión proactiva de la Gerencia de Tecnologías de la Información. No me sentiría bien, para terminar con esta idea, sin mencionar que también he tenido la experiencia de conocer excelentes Gestiones de Tecnologías de la Información en el área centroamericana, las que han venido a ser una excepción, pero que me confirman que si se puede gestionar a primer nivel los recursos de TI.
Para poner un ejemplo concreto, en la administración de servidores, muchas veces se pasan por alto configuraciones consideradas inseguras, o para decir un término más adecuado a la situación actual, explotables. ¿Qué estándar existe para configurar un servidor? Existen varias opciones. Si nuestra operación se realizará en un país del primer mundo, tendríamos el mandato de aplicar alguna de ellas. En mi opinión, en Centroamérica como estamos en un ambiente no regulado en este aspecto, tenemos la gran ventaja de poder elegir la que más nos convenga para nuestra operación. Primero, podríamos ver a lo que los fabricantes llaman las mejores prácticas. Cada fabricante propone para su producto no sólo configuraciones recomendadas que aportan seguridad a la operación del servidor, sino también medios para probar fácilmente si existen desviaciones en las configuraciones recomendadas. Esto último hace más fácil que un administrador pueda dar seguimiento al nivel de seguridad del equipo bajo su responsabilidad. Como depender de los consejos de un proveedor sobre su propio producto no es suficiente para asegurar que su operación es segura, existen fuentes independientes que generan recomendaciones sobre la configuración de los servidores. Por ejemplo, el Instituto Nacional de Estándares y Tecnologías, del departamento de comercio de los Estados Unidos, ha emitido varios documentos, tanto de carácter general como para productos específicos, que sirven de guía para mitigar riesgos a la seguridad de la información. Una opción ampliamente utilizada en la Industria de la Seguridad de la Información son las recomendaciones del Centro para la Seguridad de Internet (CIS – Center for Internet Security) que provee recomendaciones para productos específicos. Estas recomendaciones vienen en la forma de Benchmarks, es decir, a partir de un consenso realizado entre expertos en seguridad. Estas opciones son de alto carácter técnico, esto implica que indican valores específicos esperados en archivos de configuración y valores de parámetros utilizados. Son tan técnicas, que cuando se auditan, se pueden auditar por medio de software, lo que permite tener una opinión de la seguridad de un centro de datos en forma rápida. En mi experiencia, auditar centros de datos siguiendo estos estándares, así como algunos otros, ayuda a mejorar la postura de seguridad de una organización. Esto es sumamente importante, porque aunque en nuestra región no se exige la aplicación de estándares para administrar tecnología de la información, si tenemos los mismos riesgos de seguridad, porque estamos insertados en un medio común, la Internet.
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.
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.
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.
¡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.
Gestión y Auditoría de TI 