A la hora de evaluar un informe de una auditoría técnica de seguridad podemos entrar a valorar diferentes aspectos, pero en este post vamos a considerar para dicho análisis dos conceptos, por un lado, el contenido y, por otro, el formato.
En cuanto al contenido, obvia decir que, como punto de partida, cualquier informe de auditoría tendrá que dar cumplida respuesta a la expectativa del cliente. Si en algún caso el destinatario no tiene claro cual será el tipo de entregables, la información contenida en el mismo y la utilidad que podrá dar al trabajo, estas cuestiones deberán aclararse antes de comenzar, apoyándose en el archiconocido principio “más vale prevenir que curar”.
Como elementos esenciales se tendrá presente que cualquier hallazgo que se incluya en un informe técnico tendrá que regirse bajo los siguientes principios:
- Las pruebas se realizarán con la profundidad requerida para los objetivos propuestos.
- La auditoría se realizará teniendo en cuenta la legislación vigente.
- Los resultados que se obtengan podrán ser medidos, consistentes, y si se repiten las pruebas se obtendrán resultados similares (repetibles).
- Las conclusiones que se obtengan estarán derivadas únicamente de las pruebas realizadas y serán pertinentes, es decir, estarán en línea con los objetivos de la auditoría.
- El lenguaje empleado será acorde a la audiencia que lo reciba.
EVALUACIÓN DEL CONTENIDO
Existen aspectos imprescindibles en cuanto al contenido y que podrán ser clave a la hora de decidir escoger a un proveedor de seguridad u otro. Estos aspectos podrían ser:
- En cuanto a cada uno de los riesgos identificados:
- Grado de abstracción deseado para la tipificación del riesgo, se podría denominar “vulnerabilidad tipo” o “problema tipo de seguridad”.
- Riesgo asociado a la vulnerabilidad identificada en un lugar concreto. (*1)
- Nivel de detalle de la ocurrencia identificada sobre el riesgo tipo. La descripción deberá de facilitar la posibilidad de repetir el proceso de detección para evaluar si la corrección aplicada es correcta. Para evaluar adecuadamente este punto se podría plantear la siguiente reflexión ¿Es suficiente una herramienta automática para realizar esta tarea?, seguramente NO.
- Posibilidad de identificar de forma unívoca e inequívoca la ubicación del riesgo hallado, dirección IP, IP y puerto, URL, URL y parámetro afectado, etc.
- Simplicidad y claridad de la descripción para que alguien “no técnico” pueda interpretarla.
- La inclusión de enlaces o referencias externas que añaden información clarificadora sobre el riesgo hallado.
- Recomendaciones y propuestas de solución para cada riesgo identificado matizando las propuestas para que se puedan adaptar a los riesgos concretos hallados en cada trabajo.
- En cuanto a la valoración ejecutiva, informe ejecutivo, etc. Los aspectos básicos que deberá de incluir podrían ser:
- Resumen introductorio del trabajo realizado, alcance y objetivos.
- Resumen de la metodología empleada.
- Explicación del criterio de riesgo utilizado. (*2)
- Vulnerabilidades clasificadas por Tipo.
- Vulnerabilidades clasificadas por Riesgo (en grupos).
- Ocurrencias de vulnerabilidad destacadas, esto puede ser destacadas por su riesgo base o destacadas por alguna otra característica que hace que sea “diferente”.
- Conclusiones sobre el trabajo realizado apoyadas en hechos contrastables del trabajo. Como parte fundamental de las conclusiones esta el análisis que se ha realizado de la naturaleza de los problemas lo que permitirá evitar o al menos mitigar los problemas identificados para el futuro.
- Plan de acción a corto, medio y largo plazo, permitiendo al cliente establecer correcciones en distintos periodos de tiempo y priorizando en base a “quick-wins”.
- Medidas concretas a realizar, el informe propondrá una serie de medidas concretas cuya aplicación permita reducir considerablemente el riesgo, este punto responderá a preguntas como “¿bueno y ahora qué?”, “¿por donde empezamos?
(*1)(*2) Criterios de evaluación del riesgo: se destaca especialmente la necesidad de utilizar un criterio que permita evaluar el riesgo con valores suficientemente objetivos que además tengan presente el tiempo y el entorno sobre el que se encuentran los sistemas con vulnerabilidades. Se intentará huir del sistema AMB (Alto, Medio, Bajo).
Una buena aproximación a estos parámetros es el estándar CVSS (Common Vulnerability Scoring System) que permite evaluar el riesgo en tres grupos de métricas que son:
- Base: características intrínsecas y fundamentales de una vulnerabilidad que son constantes en el tiempo y en el entorno de usuario.
- Temporal: representa las características de una vulnerabilidad que cambian con el tiempo pero no se ven afectadas por el entorno.
- Entorno: evalúa las características de una vulnerabilidad que son relevantes y únicas a un entorno particular del usuario.
Estos valores se combinarán aplicando una formula que dará un valor numérico entre 0 y 10 para el riesgo base, el temporal y el entorno, en los casos en que sea necesario se podrán crear tres grupos 0<4, style=”mso-spacerun:yes”> Bajo, Medio y Alto.
Los fabricantes facilitan su propia evaluación de vulnerabilidades en base al CVSS para sus productos pero, ¿es acertado que un fabricante de software pueda evaluar el riesgo que representa una vulnerabilidad de sus productos? o por el contrario ¿será mejor que un auditor independiente evalúe el riesgo de una forma más objetiva?
¿Por qué utilizar un estándar como CVSS?, el cliente podrá filtrar los riesgos en base a 14 parámetros que permiten definir, acotar y contextualizar las correcciones, algunas de las preguntas que quedarán resueltas con esta evaluación del riesgo serán:
- ¿Es igual de importante una vulnerabilidad en el entorno de producción que en el entorno de desarrollo?
- ¿Puede explotar esta vulnerabilidad cualquiera o tiene que ser un experto en kung fu?
- ¿Este riesgo es accesible desde Internet o tiene que ser un usuario de la red local?
- ¿Esta vulnerabilidad tiene impacto sobre la disponibilidad de mis sistemas?, ¿y con la integridad?, ¿y con la confidencialidad?
Se puede consultar la información detallada en la página oficial del proyecto.
EVALUACIÓN DEL FORMATO
En cuanto al formato general de la documentación, esta deberá de ser flexible, permitiendo realizar búsqueda, adaptarse al contexto del cliente, y ser fácilmente integrable con distintos gestores documentales, gestores de ticketing, etc.
Algunas de sus características por lo tanto podrían ser:
- En el apartado de la flexibilidad será muy positivo dotar a la documentación de opciones para filtrar los riesgos detectados por distintos criterios, referencias cruzadas, tipos de riesgo, elementos donde impactan etc. Además de permitir la generación de gráficos con todos los datos, subconjuntos, etc.
- Uniformidad de los documentos, formatos de cabeceras, tipologías, etc.
- Identificación univoca de los riesgos, incluir un código único para cada riesgo.
- Se podrán filtrar los alcances generando sub-informes en base a urls, rangos de direcciones IP, etc.
- Se podrán generar salidas xml, csv, etc.
- En cuanto al informe técnico, este deberá de contener su propio manual de uso, explicando cada uno de sus apartados, que son, porqué han de existir y que uso se podrá dar a dicha información.
- Idioma, preferiblemente en el idioma solicitado, si es en castellano, en castellano pero no en “spanglish”.
- En cuanto al informe ejecutivo, podría ser un PowerPoint, conteniendo un resumen claro, conciso y directo sobre el trabajo realizado, hallazgos obtenidos, soluciones, plan de acción y nuevos proyectos.
Autor: Juan de la Fuente Costa
Via Auditoría S21sec
