Archivo del sitio

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.

Las Pruebas de Auditoría de Sistemas

El aseguramiento de la correcta configuración y operación efectiva de los controles de TI implementados en cada componente o proceso de gestión de TI se logra a través de la realización de pruebas. Las pruebas se constituyen por un procedimiento a seguir para garantizar que un determinado control está en funcionamiento, que es eficiente y que sus resultados son efectivos. Las pruebas pueden incluir la revisión de configuraciones clave, de acuerdo a las especificaciones de fabrica de componentes de equipo o sistemas, la revisión de la documentación que evidencia la realización de un proceso, la revisión de las bitácoras de los sistemas de información, la verificación física de los controles ambientales en centros de datos, tales como la temperatura, humedad y el inventario de medidas de seguridad para garantizar acceso solo a personas autorizadas. En ambientes ERP grandes (SAP, Oracle Business Suite y similares) las pruebas a realizar ya están definidas por los mismos controles implementados en la solución de software. En estos casos el auditor tiene más bien que seleccionar de la amplia gama de controles y formas de prueba disponibles, cuales son los que se realizarán en base a la situación siendo evaluada y el perfil de riesgos de la organización.

Lo verdaderamente retador para un auditor de sistemas es cuando se enfrenta a una situación específica, no estándar, como los desarrollos a la medida que implementan muy frecuentemente en las empresas salvadoreñas y centroamericanas. Incluso hay una gran gama de aplicaciones realizadas por consultores locales, que es frecuente encontrar en diferentes empresas, que tampoco tienen documentados sus controles. En estos casos, un auditor de sistemas tiene que volver a lo básico. Primero, hay que entender como esta diseñado el sistema. Verificar la documentación técnica disponible, los procesos de negocio que soporta, experimentar con el sistema en ambientes de prueba. A partir de este aprendizaje, hay que echar a correr el análisis de riesgos, para identificar en que lugares el software presenta mayores riesgos. El arte esta en formular hipótesis de los riesgos existentes, para luego crear pruebas que comprueben o eliminen una hipótesis. Alguien dirá, el método científico aplicado a la Auditoría de Sistemas, pues bien, ¿Quién dijo que no se podía aplicar? De hecho el desarrollo de la ciencia se basa en el constante interrogatorio de la realidad. Pues bien, un buen auditor de TI siempre estará preguntándose que logra verificar una prueba. Incluso en ambientes que se supone están bien documentados, en programas de auditoría comercializados por los fabricantes, un buen auditor de TI puede encontrar los errores que han cometido los diseñadores del plan a partir de un interrogatorio constante de la efectividad de las pruebas, del análisis de los resultados. Hay que recordar que también el auditor debe de ser eficiente a la hora de realizar sus pruebas, por lo que no solo debe de buscar o diseñar las pruebas a realizar, sino buscar que sean las mejores, las que buscan probar o negar una hipótesis de manera más eficiente.

Es importante mencionar que para diseñar pruebas eficientes, el auditor de TI debe también de conocer de la tecnología. Su primera fortaleza debe de ser conocer la tecnología, eso le permitirá saber cuando una prueba es eficiente y cuando puede ser mejorada.

La evaluación de riesgos de TI

Para cubrir el riesgo tecnológico, una organización debe de iniciar por realizar la evaluación de riesgos de las Tecnologías de la Información. ¿Qué implica esto? Varias cosas.

Primero, hay que conocer las operaciones de TI a fondo. No podremos realizar una evaluación de un componente o proceso de TI que no conocemos. Hay que recordar que no estamos hablando de evaluar el riesgo del departamento de tecnología. Estamos hablando del riesgo de que los negocios de la organización sean interrumpidos debido a un soporte deficiente del departamento de TI. Esto implica que tenemos que conocer todos los componentes tecnológicos, infraestructura, así como los procesos de gestión de TI que actualmente soportan al negocio y aquellos que no existen, que están en proyectos o planes, que se piensa que podrían ayudar al negocio, pero que no han sido implementados aún.

Segundo, los riesgos se evalúan a partir de dos aspectos. Uno es la probabilidad de que un suceso negativo a la organización se materialice. El otro es el impacto que tendrá en el negocio. Respecto a los sucesos negativos, podemos pensar de ellos como las amenazas existentes que podrían causar daños a la infraestructura tecnológica o la ejecución exitosa de los procesos de gestión de TI. Las amenazas son todo lo que podría ir mal, una lista grande de cosas negativas que podrían ocurrir sobre las operaciones de TI, tales como daños en equipos, ataques de virus, siniestros en instalaciones, pérdida de recurso humano importante y similares. Estos sucesos negativos podrían o no suceder, por eso es conveniente hablar de ellos en términos de su probabilidad de ocurrencia. No tiene sentido preocuparse de que un Huracán suceda, si nunca ha pasado en una determinada región geográfica. Su probabilidad de ocurrencia es cercana a cero. No digo cero, porque con el cambio climático ya nunca se sabe. Es importante identificar todos los sucesos negativos posibles y su probabilidad de ocurrencia, porque no todos tendrán que ser sujetos de evaluación. En relación al impacto, el segundo aspecto de la evaluación, esto es una medición lo más cuantitativa posible del costo económico, entiéndase  “costo de no estar prevenido”, que tendría la materialización de las amenazas. El impacto puede ser medido en función mediciones como el dinero no facturado, las ventas no realizadas, el costo de remplazo de equipo o los costos de retornar los sistemas al punto de falla. Es común pensar en el impacto en términos genéricos, como impacto alto, medio o bajo, estableciendo valores monetarios a cada uno de estos rangos. Esto permite calificar el impacto, sin tener que especificar un monto específico de impacto. De esta manera, un evaluador puede decidir que considerará como impacto bajo, aquellas pérdidas menores de $1,000.00, impacto medio a las que vayan de $1,000.00 a menos de $5,000.00 e impacto alto a las superiores de $5,000.00. Cuando se mezcla la probabilidad de ocurrencia con el impacto, resulta fácil tener una medición de qué es importante en términos de riesgos. La priorización de proyectos y acciones en la gestión de TI debe de orientarse hacia aquellos riesgos que tienen las probabilidades e impactos más altas.

Las gerencias de TI tienen que guiarse por medidas como esta para tomar sus decisiones, al momento de priorizar proyectos de TI para respaldar las solicitudes de presupuestos y para demostrar la importancia de su función en el negocio. De hecho, las gerencias generales y las Juntas Directivas deberían de evaluar el desempeño de la función de TI en su organización a partir del uso que se haga de esta herramienta para apoyar la Gestión de TI. Aparte de esto, es importante mencionar que la evaluación de riesgos es un buen punto de coincidencia entre la Gestión y la Auditoría de TI. Explicaremos esto en otro día.

El Riesgo Operativo y Tecnológico.

Se me ocurren muchas formas por las cuales las operaciones de TI en una empresa pueden parar. Yo siempre he dicho que las operaciones de TI son como una cadena, tan fuerte como su eslabón más débil. Ha ocurrido que por el mal funcionamiento de un aire acondicionado, se crea una humedad excesiva, que causa corto circuitos en el sistema eléctrico de centros de datos, obligando a parar las operaciones mientras se identifica el daño, se repara y se reinician los sistemas. Si esto tarda una hora, se pueden imaginar el estrago que causaría, por ejemplo en una sucursal bancaria, pasar diciéndoles a los clientes que estaremos reconectados en una hora. Ha ocurrido, es un hecho histórico y probablemente seguirá ocurriendo si la gestión de TI no prevé estas “posibles” fallas.

El riesgo operativo se refiere a la probabilidad de que una empresa incurra en pérdidas financieras por la interrupción de sus operaciones, debido a fallas en los procesos, las personas, las causas naturales, los siniestros y la fallas de sistemas de información. La legislación que regula las operaciones empresariales, especialmente de instituciones financieras y de empresas que cotizan en bolsa, en países desarrollados, ha obligado a las empresas en esos países, a considerar, implementar y demostrar a través de auditorías periódicas, que han realizado una evaluación de sus riesgos operativos y que han realizado las provisiones correspondientes para prevenir su materialización y en caso de que ocurran, existan planes bien definidos que permitan volver a funcionamiento normal en un plazo meta predefinido. Estas normas, se han ido implementando en los países latinoamericanos con mayor o menor rapidez, aplicando enfoques rigurosos algunos mientras otros han adoptado más bien un tono relajado. En El Salvador, la Superintendencia del Sistema Financiero, público en Junio del 2011, las Normas Para La Gestión Del Riesgo Operacional De Las Entidades Financieras, que es la norma que obliga a las Instituciones Financieras Reguladas en El Salvador a considerar el Riesgo Operativo dentro de su gestión.

El riesgo tecnológico se refiere a la probabilidad de que los servicios de TI no alcancen los niveles de servicio requeridos para soportar las operaciones de una empresa e impacten en los resultados. Obviamente, esta incluido dentro del Riesgo Operativo. En la norma salvadoreña se específica que el Riesgo Operativo es la probabilidad de incurrir en pérdidas por fallas, entre otras cosas, de los sistemas de información.  Como ya dije antes, hay muchas cosas que pueden hacer que el riesgo tecnológico se materialice, llevando a las operaciones de TI a una situación de cese de operaciones. Los responsables de la gestión de TI en cada empresa deben de considerar cuidadosamente, la creación de un conjunto de procesos que les permita controlar los diferentes componentes de la infraestructura tecnológica, tales como la administración de la configuración, la administración de cambios, la seguridad, la gestión de proyectos y la gestión de contratos con proveedores entre otros. En el caso del riesgo tecnológico es importante considerar que no solo el cese de operaciones impacta en la organización. Cosas como comprometer la información de la organización podría ser una falla grave, que impacta en la imagen global de la empresa. Esto me indica la necesidad e importancia de crear políticas, procedimientos y auditorías de seguridad de la información. Otras situaciones como la lentitud en el servicio impactan directamente en la imagen ante los usuarios y clientes. Esto me indica la necesidad e importancia de tener un proceso de monitoreo de operaciones eficiente, que lleve métricas precisas del nivel de servicio que permitan tomar decisiones respecto al riesgo tecnológico. Si se piensa bien, la gestión del riesgo tecnológico tiene un nivel de sensibilidad alto, que debe de gestionarse proactivamente.

¿Qué es la auditoría de sistemas?

El principal problema en la gestión de las Tecnologías de la Información en la región centroamericana, desde el punto de vista de la implementación de controles se basa en la inexistencia de una cultura de control entre los responsables de la gestión de las Tecnologías de la Información, tales como Gerentes de Sistemas y Directores de TI, así como de la alta dirección, desde Gerentes Generales, Gerentes financieros, Presidentes y similares. La razón principal podría basarse en que cuando la generación que hoy dirige las empresas pasó por las aulas universitarias, el estado de las Tecnologías de la Información no era lo que es hoy y nadie en esos momentos hubiera predicho como evolucionarían las cosas y la importancia que la información llegaría a tener en las operaciones diarias de las organizaciones.

Sin embargo, las empresas hoy están realizando grandes inversiones en Tecnologías de la Información, necesarias para mantenerse competitivos y muchas veces para potenciar el negocio, por lo que interesa tener control sobre las Tecnologías de la Información para obtener los beneficios esperados y evitar o minimizar los riesgos inherentes. Pensemos en el giro que han tomado los antiguos periódicos de papel y que hoy buscan ganar en el ciberespacio un lugar para no quedar desfasados y ser remplazados totalmente por lecturas digitales.

En este contexto, la auditoría de sistemas tiene el rol de realizar revisiones técnicas de los controles establecidos por los responsables de TI para informar a la alta gerencia sobre posibles riesgos que se generan en la gestión de las Tecnologías de la Información y apoyar con la recomendación de la creación de controles que son necesarios o en la optimización de los existentes. En esta función, la auditoría de sistemas tiene un rol dual. Por un lado, se convierte en los ojos de la alta gerencia para evaluar el funcionamiento de la gestión de TI. Por otro lado, ayuda a formar un marco de control interno en el área de TI de acuerdo con las necesidades de la empresa.

La función de auditoría de sistemas utiliza en sus revisiones como criterios de evaluación diferentes normas y marcos de referencia que han sido creados a partir de consensos internacionales, además de las normas regulatorias locales y las buenas prácticas recomendadas por los fabricantes de tecnología. Esto constituye una garantía de que se realizan evaluaciones objetivas. De hecho, los responsables de TI, en la medida que maduran sobre su aprendizaje de la gestión de TI, van reconociendo las normas y marcos de referencia que les son aplicables y van implementando controles de acuerdo a evaluaciones propias de pertinencia en la organización. Esto es un reconocimiento implícito de la necesidad de control por parte de los responsables de la función de TI en las organizaciones. En un ambiente organizacional que provee mejora continua a sus procesos de gestión, la auditoría de sistemas le aporta los conocimientos necesarios para enfocar la mejora en el control de TI, bajo un enfoque metodológico y sistemático, basado en normas y marcos de referencia reconocidos y totalmente integrado con el plan de auditoría interna de la organización.

A %d blogueros les gusta esto: