La importancia de seleccionar un alcance adecuado en auditoría de sistemas

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,