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.

Los Procesos de Gestión de TI

COBIT 5 ha generado una serie de procesos de referencia para el Gobierno de TI. El libro que describe estos procesos se llama “COBIT 5 Enabling Processes” y la traducción oficial del libro es “COBIT 5 Procesos Catalizadores”. A los que no estamos en el mundo de la química, nos puede parecer difícil asimilar el término en el área de las Tecnologías de la Información.

Un catalizador es, según la Real Academia de la Lengua Española, un cuerpo (químico) capaz de producir una transformación catalítica. La Catálisis está definida, por el mismo ente, como el “Favorecer o acelerar el desarrollo de un proceso”.  Sin embargo, el concepto no está limitado al área química, es por lo tanto, genérico. En el caso que nos ocupa, se trata de favorecer o acelerar el desarrollo del proceso de Gobierno de TI.

El concepto de “catálisis” queda bien al Marco de Referencia COBIT. Cuando un Gerente de TI en la década de inicio de este siglo se sentaba a dirigir las operaciones de TI  de una organización, la principal dificultad era el identificar qué se tenía que llevar a cabo para una gestión exitosa, mientras la Alta Dirección presionaba por resultados inmediatos, mejoras en el servicio de TI  para la organización y lo más exigentes o visionarios, la agregación de valor al negocio a través del uso de las Tecnologías de la Información.  La situación era crítica para muchos que sólo tenían estudios relacionados con la Ingeniería de Sistemas, las Ciencias de la Computación y similares. Les iba mejor a los que tenían segundas o primeras carreras en áreas como Administración de Empresas, Ingeniería Industrial o incluso Maestrías en Administración de Negocios. Estos últimos identificaban rápidamente puntos críticos del negocio y tomaban decisiones rápidamente. También eran más habilidosos para obtener el presupuesto necesario para implementar los procesos de gestión de TI y la adquisición de herramientas que permitieran implementaciones efectivas y sólidas.

La función de TI es eminentemente técnica, pero requiere de otras habilidades no técnicas para lograr resultados de manera exitosa.  Esto implica la necesidad de procesos catalizadores. De esta manera,  aparte de encender equipos y operar sistemas, un gerente de TI debe de conocer que hacer en la Gestión de TI.

Lo que debe de hacer la gestión de TI ha sido definido por la Asociación de Auditoría y Control de Sistemas de Información, ISACA, a través de la investigación exhaustiva de las mejores prácticas y su uso en empresas de diferentes tamaños y tipos. Los procesos que la Gerencia de TI debe de adoptar ya están definidos y son considerados catalizadores porque acelerarán la gestión exitosa de TI, sin ser un fin en sí mismos. Por esta razón, las habilidades técnicas deben de seguir siendo el principal eje de acción de la Gerencia de TI, para planificar la adecuada infraestructura tecnológica,  la selección de software a desarrollar o adquirir, los procesos de desarrollo del personal técnico y usuario de la tecnológica, con el fin importante, de apoyar significativamente los procesos de negocio. Los procesos de gestión de TI permitirán que estas importantes funciones sean mejor administradas, controladas, analizables y mejorables, proporcionando una ruta a seguir en la mejora de la Gestión de TI. Siendo redundantes, podemos decir que ayudan a mejorar la Gestión de TI, mientras se mejoran los resultados que TI provee al negocio.

La Evaluación de los Procesos de TI

Esta semana ISACA liberó los libros de evaluación de los procesos de TI de la versión 5 de COBIT. Los libros incluyen tanto el modelo de evaluación, como la guía para asesores y herramientas de diagnóstico. Revisando los documentos, recordé los momentos en los que me ha tocado discutir con gerentes de TI sobre el nivel de cumplimiento sobre un determinado proceso y la tendencia que las gerencias de TI tienen a pretender cumplir un requerimiento regulatorio con procedimientos con fallas de diseño, que a veces no son los más efectivos al momento de su implementación y que aunque no están aportando valor a la gestión del negocio, se mantienen porque no existe un criterio que defina el nivel de cumplimiento, especificando qué es y cómo se evidencia, monitorea y evalúa un determinado proceso o control. De alguna manera, esta tendencia es alimentada por pobres requerimientos regulatorios, que emiten la necesidad de implementar  un control, pero no especifican medidas de evaluación objetivas, soportadas por evidencia, que muestren claramente la naturaleza auto evaluadora del control interno y su fin último de mejorar las operaciones del negocio. He visto muy pocas legislaciones que tengan ese nivel de detalle, tal vez contadas con los dedos de una mano.

En el caso de COBIT, desde la versión 4 implemento un Modelo de Evaluación de Procesos, que definitivamente ayuda a establecer una metodología de revisión, que incluso está soportada por un estándar internacional, el “ISO/IEC 15504-2:2003, Information Technology-Process assessment-part 2: Performing an assessment”. Seguir una metodología ayuda a evitar las discusiones sobre el nivel de cumplimiento o el nivel de desempeño que un control de TI debe de tener para ser considerado el necesario para el cumplimiento de los objetivos de negocios de la organización. Es definitivamente algo recomendable.

La implementación exitosa de procesos de TI se puede lograr en ambientes en los que la evaluación se entiende como un proceso independiente de aseguramiento de que los controles de TI cumplen con los requerimientos establecidos, tienen criterios de diseño bien definidos y estos son cumplidos y se ejecutan con un nivel de desempeño adecuado para el cumplimiento de los requerimientos del negocio. Esto deja claro que debe de existir en la Gerencia de TI el conocimiento de las variables por las que serán evaluados los procesos de TI y debe de ser parte de sus funciones el asegurar su implementación, funcionamiento, así como la mejora el desempeño.

La Gerencia de TI debe de pensar de manera integral la implementación de procesos de TI, teniendo una idea clara de los procesos de TI que requiere, del nivel de implementación requerido y de la forma en la que debe de autoevaluar el funcionamiento de los procesos. Esto proporciona una ruta de mejora, que permitirá a la función de TI desarrollarse mejor. Esta claridad también permitirá la división de funciones, asignando tareas de diseño e implementación a unas personas y permitiendo el ingreso de evaluadores independientes a realizar la evaluación de los procesos. Esta es la forma en la que un Framework como COBIT ayuda a comunicarse mejor, entender qué se está evaluando, aportar objetividad y facilitar la mejora continua.

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.

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.

La preparación para la Auditoría Forense.

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

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

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

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

El Control Interno de TI

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

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

La Formulación de la Estrategia de TI

Podemos realizar cualquier acción, incluyendo la Gestión de TI, con o sin estrategia. La diferencia será que sin estrategia perderemos ventajas en la utilización de los recursos, desenfocaremos el resultado final e incrementaremos los riesgos. Tener una visión estratégica en TI es fundamental para el éxito de cualquier operación de negocios. La Gestión de TI debe de ser liderada por una sólida estrategia, formulada para apoyar los objetivos de negocio y anticiparse a los retos que el negocio mismo le impondrá en el futuro.

Una característica de la Gestión Estratégica de TI es la visión completa de la función de TI. Carecer de visión completa implica empezar a dejar vacíos en el soporte al negocio. Todos sabemos que los negocios no van a parar por la carencia de soporte tecnológico, por lo que al dejar vacíos, estos serán llenados con “soluciones innovativas” de parte de los usuarios de tecnologías o servicios de TI proporcionados por terceras personas. Definitivamente, no tener en el radar todas las funciones de soporte de TI, permite que se generen múltiples versiones de soporte de TI en las empresas. Es importante entender que tener visión completa no necesariamente implica tener las soluciones en el presente. Más bien, implica conocer las necesidades de TI de la organización y el momento en el que son requeridas y por lo tanto estar listos para esos momentos de verdad que toca vivir en toda administración de TI.

La generación de una estrategia de TI pasa por el reconocimiento de las capacidades actuales y el establecimiento de la brecha real y la brecha permitida por las necesidades del negocio, así como todas las acciones necesarias para cerrar esa brecha en el momento oportuno. También incluye la predicción de cambios en las tecnologías, en el soporte que  los fabricantes de la tecnología que usamos darán y la integración futura de tecnologías, para tomar decisiones de recambio, nuevas adquisiciones, mejoras en la capacidad y similares. Una gestión de TI con una buena estrategia debe de tener formulada su ruta de proyectos para un periodo de 5 años, 2 de los cuales deben de estar a detalle, con presupuestos financiados y recursos asignados para garantizar la operatividad de la estrategia.

Ahora que nos acercamos a el final del año 2012, es conveniente que no sólo revisemos nuestro presupuesto para el 2013, sino también que revisemos como va la ejecución de la estrategia de TI. Si el caso es que la estrategia no existe, también es tiempo para formular una. Para tomar una iniciativa que definitivamente apoyará al negocio de cualquier organización. Es el momento de evaluar desde todo punto de vista, por lo que mi recomendación es para todos los Gerentes de TI, que tengan una reunión de evaluación con todas las áreas de negocio que sirven, para que les comenten su opinión sobre el apoyo que la Gestión de TI proporciona y a partir de ahí decidan si su estrategia esta bien o requiere de ajustes.

La Seguridad de los Password

Aunque siempre se ha considerado que los passwords son un mecanismo “secreto” para proporcionar seguridad a nuestras acciones en sistemas de información y especialmente a nuestros datos, proporcionando confidencialidad, muy poco se hace para informar a todos los que usamos passwords sobre las amenazas existentes y la vulnerabilidad que presenta este mecanismo de control de acceso.

Revisando la seguridad de sistemas de información, descubrí que muchas herramientas de evaluación de seguridad en las configuraciones de los equipos, lo que realmente hacen es intentar descifrar los passwords y cuando lo logran, declaran el password como “débil”. Esto implica que en el lapso de segundos, algunos passwords pueden ser descifrados y lo sorprendente es la cantidad de cuentas que pueden tener passwords débiles en un sistema. Entonces, considerando esta situación de passwords descifrables en segundos y la existencia de hackers que utilizan programas para buscar estas cuentas y a partir de ahí revisar cuales pueden ser explotables, apropiándose de sus privilegios dentro del sistema, tenemos una situación de riesgos que en la mayoría de empresas podría ser alta. Este hecho definitivamente amerita la atención de la Gestión de TI.

A partir de esta realidad, lo que corresponde es revisar nuestra política de creación de passwords. Un factor determinante de la política, aunque no el único, es el tamaño. La teoría de cifrado de passwords se basa en la creación de algoritmos confiables, pero públicos, con los cuales se crea un texto cifrado a partir del texto legible para el usuario. El hecho de que el algoritmo sea conocido, aparte de aportar confianza al método usado, también proporciona un medio para que se creen algoritmos de descifrado de passwords. Adicionalmente, un hacker puede optar por la “búsqueda exhaustiva” de todas las posibles opciones, lo cual es cada vez más soportado por la capacidad de computo existente. Este último elemento principalmente, justifica que los passwords utilizados tengan como mínimo 12 caracteres. Existe un sitio web: http://howsecureismypassword.net, donde se pueden probar los passwords y saber que tan fácil o difícil es el descifrado de un password, a partir del tiempo que tomará en descifrarlo.

Si nos ponemos del lado del usuario, la dificultad de recordar un password es lo que los lleva normalmente a escoger una palabra pequeña como password. El promedio letras que podemos encontrar en un password es de 6 a 8 letras. Una recomendación, que podría ser parte de la política, es el utilizar cuatro letras de tres palabras que le sean familiares al usuario y armar el password separando cada grupo por un carácter especial o número. Esta regla aunque se oye difícil, en realidad es fácil de mostrar. Por ejemplo, si yo quiero que la frase “Libros Ciencia Ficción” sea la base de la creación de mi password, puedo terminar con el password lbrs_cnci_fcco, que de acuerdo al sitio antes mencionado, le tomaría a una computadora personal trescientos mil años descifrarlo. Esto hace de este password un éxito. Si usamos una parte de este password, por ejemplo lbrs_cnci, el tiempo cae gramáticamente a 22 horas. Esto es con 9 caracteres. Prueben combinaciones más pequeñas y más largas para entender las variaciones y apliquen lo que aprendan en afinar su política de creación de passwords y el trabajo de enseñar estos elementos de seguridad a los usuarios. En el caso de los passwords de servidores y bases de datos debería de ser mandatorio el crear passwords de más de 12 caracteres, incluyendo además caracteres especiales. El password es un elemento de la seguridad de los sistemas de información que depende totalmente de los humanos, por lo que se debe de implementar correctamente a través de políticas agresivas, que mantengan seguros todos los puntos de acceso a la infraestructura tecnológica de una organización.

Las certificaciones de COBIT 5 están en pleno desarrollo.

Estamos en Noviembre de 2012, mes en el cual la APMG está lanzando el programa de certificación de COBIT 5 Foundations. A partir de este mes, los profesionales que estén interesados en profundizar en COBIT 5 podrán optar a iniciar la preparación para tomar la certificación en los diferentes niveles. Según ha publicado APMG en su sitio web (http://www.apmg-international.com/en/qualifications/cobit5/cobit5.aspx), el esquema de certificación de COBIT 5 tiene los niveles de Fundamentos (Foundations), Implementador y Evaluador. Adicionalmente, existe un curso de Introducción a COBIT 5, que ha sido impartido en las principales ciudades de todo el mundo, desde el lanzamiento de COBIT 5 en el mes de abril de 2012. Como Consultor en Gestión de TI, me interesan todos los niveles, pero mi recomendación para los profesionales de TI es que evalúen su desarrollo profesional y cargo actual, así como las perspectivas de su carrera profesional, para identificar que nivel de certificación que más les conviene.

Es importante conocer que COBIT es un marco de referencia ineludible para los que trabajan en el área de Soporte al Negocio a través de las Tecnologías de Información. Esto es cierto para todos los niveles. Aunque un profesional de TI no esté a nivel directivo y no participe en el diseño del servicio al negocio, siempre es importante que identifique que parte del servicio de TI es su responsabilidad, entienda en qué contexto está operando, cuales son los objetivos y las reglas de medición por la que se está evaluando y como impacta en los objetivos organizacionales. Posiblemente para profesionales de TI que laboran a nivel operativo, lo más recomendable sea el curso de Introducción a COBIT 5, para identificar todos los componentes de COBIT y estar atento a colaborar con su implementación en la organización. El curso de introducción, incluso esta recomendado para personas que no son profesionales de TI, pero coordinan las Tecnologías de la Información a un alto nivel, tales como Gerentes Generales, CEO, Presidentes, miembros de juntas directivas, auditores de sistemas y personal de auditoría interna. Es decir, todo el personal que gobierna y controla las Tecnologías de la Información en la empresa.

Muchas veces, cuando escuchamos sobre estándares y metodologías, siempre lo vemos como una decisión que alguien tomo en algún momento en el pasado y nos es ajeno el saber que es ser pionero en ese campo. En el caso de COBIT 5 la generación de profesionales de TI laborando en el período 2012 al 2015, estará exactamente en el tiempo de su inicio. Esto me indica que posiblemente la adopción venga hasta el año 2014 o 2015, como siempre pasa con todo, ya sean estándares, metodologías o tecnologías. Personalmente he tenido la experiencia de empresas que implementaron COBIT 4.1 y tienen la firme convicción de seguir con esa versión hasta que algo importante pase como para ameritar el esfuerzo de un cambio. Como ya he dicho en otros blogs, la concepción de COBIT es muy general y ayuda a brindar orden a la serie de estándares y metodologías de gestión de TI existentes, por lo que su implementación puede verse como un proyecto de varios años, durante los cuales, se implementan las diferentes metodologías elegidas para ayudar a gestionar las TI en la empresa. Lo importante es iniciar, para ir generando el orden en la Gestión Empresarial de TI.

A %d blogueros les gusta esto: