Buenas,
Entrada breve, o eso espero. Es un tema recurrente, pero que no paro de encontrarme una y otra vez. Dicen que es frecuente que el hombre tropiece dos veces con la misma piedra. En este caso nos gusta tropezar un trillón de veces en exactamente la misma piedra: la selección incorrecta del alcance adecuado para una auditoría de sistemas.
Se entiende por alcance, en palabras llanas, aquello que será objeto de escrutinio en la auditoría. Seleccionar un buen alcance no es tan fácil como podríamos pensar, y es frecuente ver errores de selección que posteriormente condicionan el resultado del trabajo.
Errar en el alcance es errar en la planificación, esa fase de la auditoría de sistemas en la que nos empeñamos una y otra vez en cometer los mismos errores. Las consecuencias de tener un alcance incorrecto en el trabajo son obvias y manifiestas: el resultado final puede quedar invalidado, la imagen de la función de auditoría puede quedar perjudicada y los responsables directos del trabajo quedarán en tela de juicio. Así de graves son los resultados de equivocarse cuando se planifica, y así hay que hacerlo constar cuando un proyecto fracasa, cuando una unidad de negocio se siente insatisfecha con el trabajo o cuando hay que depurar responsabilidades, si es que alguna vez se depuran. Equivocarse es de humanos, y lo que hay que hacer cuando fallamos es tomar nota y mejorar, no enterrar los problemas debajo de la alfombra.
Os voy a poner un ejemplo sencillito sobre cómo marrar planificando un alcance. Imaginemos un sistema normalito, con un servidor web haciendo las veces de frontend, y un servidor de aplicaciones conectado a una base de datos en el backend. Imaginad que esta base de datos es alimentada constantemente por un sistema ETL que hará las funciones de extracción, transformación, consolidación y carga en la base de datos. Vamos a suponer que este sistema es un motor simplificado de inteligencia empresarial, una suposición que nos aleja poco de la realidad, ya que raro es el motor de business intelligence que carece de un motor ETL para consolidar los datos antes de ser sometidos a la magia del análisis.
Imaginaos que este sistema, sin más interrelaciones con el entorno, es el que abastece al negocio con la inteligencia necesaria para la toma de decisiones. Para este ejemplo simplificado varias podrían ser las tareas que planeamos ejecutar: realizar un pentest a las IPs del conjunto, analizar la seguridad de los interfaces web expuestos, auditar la base de datos, estudiar los procesos y los controles existentes, realizar pruebas de integridad pre y post carga … y todas sus combinaciones. Pero en todas esas combinaciones siempre hay un denominador común: basta con obviar algo relevante para el riesgo para que la opinión de auditoría quede invalidada.
¿Dónde está el error común? Pues sencillo. Si no sabes que un motor de business intelligence puede estar alimentado por un sistema ETL, lo más probable es que no lo audites, ya que no vas a preguntar por él y no siempre tendrás a un auditado delante que te confiese todos y cada uno de los entresijos de sus procesos y sistemas. En este ejemplo sencillo cualquiera puede determinar un alcance con más o menos solvencia, pero en la vida real, los procesos están interconectados, la cantidad de sistemas es infinitamente superior y olvidarse de algo es relativamente fácil. Habitual, diría yo.
Los errores en la fijación de los alcances son directamente imputables a los que realizan la planificación. La razón más común es la ausencia del debido conocimiento, bien en lo que concierne a la parte del negocio, bien en lo que a sistemas se refiere. Es decir, bien por no conocer bien la parte procedimental, bien por no dominar la auditoría técnica. Parece mentira, pero a veces la gente olvida que en una auditoría de sistemas, ¡¡¡sorpresa!!! hay que auditar sistemas, que misteriosamente siempre tienen una parte técnica y otra no técnica. Da igual la parte que dejes fuera, en el momento que no consideras ambas, salvo que el riesgo así lo justifique, el trabajo es incompleto e ineficiente. ¿Sigues sin captarlo?
Volvamos al ejemplo del motor de business intelligence. Tan necesario es esforzarse en comprender el proceso y determinar que la segregación de funciones es adecuada, es decir, que el ejecutivo de cuentas no pueda ver los informes de resultados de toda la fuerza de ventas, y que el gerente del equipo no pueda ver la información que sí ve el director de ventas, como impedir que con un RMAN/rman nos metamos en la cocina en el Oracle de turno, lo que nos faculta a volcar todos los datos e informes en cómodos plazos, o lo que viene siendo tirar sentencias SQL a nuestro antojo y conveniencia sin importar si somos el CEO, el jefe de ventas o el vecino del quinto.
Por tanto y resumiendo, el alcance es un aspecto crucial a la hora de definir en qué se esfuerza una función de auditoría. Este alcance debe ser completo, y debe estar sometido a la ponderación de riesgos (o lo que es lo mismo, no perder el tiempo mirando cosas que no aportan nada) y debe reflejar la realidad del negocio en todos sus aspectos (es decir, no podemos dejarnos nada en el tintero). Sólo cuando tengamos claro que vamos a escrutar todo lo que es relevante para el riesgo y que el resto no nos interesa, en su vertiente técnica como no técnica, estaremos preparados para la siguiente fase: calcular los recursos necesarios y repartir responsabilidades en el equipo.
Tratad de recordar estas pautas cuando estés planificando. Arruinar la reputación de un equipo de profesionales por cometer errores de este tipo es fácil y restablecer la credibilidad cuesta años de trabajo, si es que alguna vez la conseguimos restablecer.
Un saludo,
Está última frase Sergio;
# Tratad de recordar estas pautas cuando estés planificando. Arruinar la reputación de un equipo de profesionales por cometer errores de este tipo es fácil y restablecer la credibilidad cuesta años de trabajo, si es que alguna vez la conseguimos restablecer.
Es tan demoledora como real…
Como siempre un placer leerte -;)
Hola Sergio,
Acertado el artículo como siempre. Es por ello que los archiconocidos checklist suelen ser sinónimo de enfado por parte del auditado o de un alcance insuficiente.
En mi experiencia, es interesante las auditorías integradas. En ellas hay una serie de perfiles que interactúan para compartir su conocimiento del negocio (auditores de procesos y business justo con auditores de aplicaciones e infraestructura). La única pega es que se tarda más tiempo (en los tiempos que corren, esto no es trivial), pero el resultado suele ser mejor y además todos los implicados aprenden de las otras disciplinas involucradas.
Por otro lado, ¿cuál es tu opinión de un enfoque macro/micro risk assessment para determinal alcances a alto nivel? En casos de auditorías de procesos extensos, hay mucha diversidad de opiniones.
Como siempre, gracias por tus artículos.
Un abrazo.
Fer.
@Dabo,
Siento la tardanza. Tan real que se ve por todos lados. Y sí, es absolutamente demoledora, pero es lo que hay, y es que lamentablemente he visto situaciones de ese tipo, y me imagino que las seguiré viendo.
@Fernando,
Mil perdones por el retraso, que he andado en mil cosas y todas ellas ajenas a las teclas :)
Coincido contigo en los beneficios de las auditorías integradas, es decir, aquellas en las que se aborda un mismo negocio desde distintas perspectivas y áreas de conocimiento. Hagamos una contabilidad, y el de sistemas que mire los sistemas, y el de contabilidad que mire los números, eso sí, compartiendo conocimiento, alcance y objetivos, no cada uno por su lado. Como bien dices el beneficio es obvio: más profundidad y más aprendizaje para todos.
Sobre los enfoques macro/micro es cierto que hay disparidad de criterios. Yo creo que la única manera de fijar un buen alcance es tener una combinación de ambos. En el macro detectados a vista de pájaro los negocios que queremos auditar, y en el micro afinamos el tiro estableciendo el alcance que cumple con los objetivos que nos hemos planteado.
El problema con este enfoque es que usualmente se pone a los equipos a trabajar sólo con los resultados del macro, y cuando se plantan los recursos en el micro, se descubre que vamos o cortos o largos de recursos. Quizás merecería la pena antes de asignar definitivamente a nadie a un trabajo tener muy claro qué alcance hay a raíz de la salida del micro risk.
¿Qué te parece a tí? Me interesa tu opinión :)
Saludos,
Hola Sergio,
Lo mismo; he estado bastante desconectado en las últimas semanas.
En cuanto al tema de alcances de auditorías, en la organización para la que trabajo (multinacional de más de 10K trabajadores) la metodología establece varias pautas que se deben tener en cuenta.
1. Este tipo de negocios de grandes multinacionales están frecuentemente sujetos a estricta regulación. La pérdida de licencias de operación en las jurisdicciones y/o áreas geográficas está considerado como catastrófico y catalogable como una contingencia de BCM, ya que impide totalmente la operación. La presión regulatoria se ha intensificado y es muy dinámica. Por tanto, el análisis de lo que una auditoría debe cubrir en estos casos requiere la colaboración entre los departamentos de cumplimiento, legal y auditoría. La identificación de los alcances debe incluir los aspectos regulatorios, por lo que la parte de gobiernes es clave. No obstante se pueden escribir ríos de tinta en los que ni el negocio ni la función de auditoría son capaces de identificar todos los requerimientos regulatorios en un entorno tan cambiante. Sin duda en mi experiencia, todo un reto.
2. Para los clusters y/o procesos de negocio que generan más de un X% del negocio y/o del beneficio, la parte inicial es un macro risk assessment basado en potencial impacto financiero (esto es muy importante, ya que como bien apuntas si vamos a mirar algo, ha de mirarse lo que es verdaderamente relevante para el negocio). Dinero perdido o dejado de ganar por el negocio por unidad de tiempo. Categórico y visual
Típico “heat map” rojo/amarillo/verde para calcular riesgo por probabilidad de ocurrencia a alto nivel. Poco detalle pero centrado en lo más relevante. Esta evaluación no entra per se como parte de los alcances de la auditorías, sino que es empleado como información de partida para el plan anual de auditoría, que es refrescado cada 3-4 meses dependiendo de la evolución de los riesgos y de los negocios.
3. Después, para cada área/proceso/negocio, se realiza el micro risk assessment. Esta parte tiene en cuenta la información que se ha identificado en el macro risk assessment para determinar los alcances. La catalogación de impacto de no disponibilidad, de criticidad/confidencialidad de datos manejados y riesgos inherentes de la propia infraestructura tecnológica son algunas de las variables a tener en cuenta, como en todas las auditorías..
Desgraciadamente, la poca coordinación entre los equipos de auditoría IT y negocio, y las ganas de protagonismo de algunos actores puede hacer que los alcances se distorsionen por factores como temas políticos o la indisponibilidad de recursos. A veces los comités de auditoría prefieren varias auditorías con un nivel de cobertura más limitado que otras auditorías con más profundidad, pero esto una vez más dependerá de la criticidad y en el propio apetito de riesgo de la organización. En mi opinión es muy difícil hallar un balance que satisfaga a todos y por tanto se acaba yendo a mínimos utilizando programas de trabajo demasiado genéricos y poco integrados.
Finalmente, en mi opinión la terna regulación/macro/micro es un buen comienzo, pero aún no he visto ningún framework milagroso para establecer una metodología de auditorías integradas. Si sabes de algo, sería interesante que escribieras una entrada en tu blog.
Muchas gracias por tu comentario, Sergio.
Un saludo.