Español | English
rss facebook linkedin Twitter

INFORMES DE AUDITORÍA: ¿SON TODOS IGUALES?

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.
Juan de la Fuente Costa
Auditoría S21sec

5 comentarios:

Sergio Hernando dijo...

Hola,

Una buena entrada, completa y significativa. Felicidades.

Solo echo en falta que en las recomendaciones nos mojemos un poco mas en asuntos cruciales como el impacto (económicos, a ser posible) de las recomendaciones, así como el impacto de las respuestas del auditado. Si no es posible la correlación directa entre medidas e inversión, al menos debe hacerse constar de una manera clara el tiempo de resolución para poder estimar los costes usando un equipo de resolución prototipo. La fecha estimada de resolución también es un dato crucial para poder hacer un seguimiento de las recomendaciones efectivo.

Muchas veces los auditores, sobre todo los mas noveles, hacen la recomendación pero no piensan en los colaterales. Recomendar que se quiten los UID 0 en una granja de distribuidos UNIX es sencillo una vez que examinemos los /etc/passwd y similares, pero las implicaciones pueden pasar por tener que rediseñar un sistema de gestión de contraseñas compartidas y de gestion de superusuarios. Y eso no suele requerir un proyecto con cierto impacto en el presupuesto :)

Para mi lo que verdaderamente da valor a las auditorias es la capacidad del auditor de anticiparse a estas cosas y lograr pactar con el auditado las mejoras que mitiguen los riesgos con mejores perspectivas en cuanto a coste y efectividad. Y este dato es siempre el gran ausente en muchos informes :)

Un saludo,

Anónimo dijo...

Espero que los informes de S21sec no sean como se comenta en este post porque entonces nos juntamos con un informe de 200 páginas infumable y que no se puede utilizar para nada. Incluir el alcance, lo que se ha revisado, la metodología y demás son cosas que ya aparecen en la oferta comercial y que no hacen más que cargar el informe con paja y más paja, haciéndolo inmanejable.

A mi dime qué se ha encontrado, qué implicaciones puede tener y cómo lo soluciono. El resto aporta muy poco en un informe de auditoria, aunque sobre gustos...

Fernando Flores dijo...

Excelente información y punto de vista.

Iñaki dijo...

Pues para mi aún hay bastante gap entre lo que se hace en general y lo que a mi me gustaría leer en un informe de este tipo.

Me explico: en el año 2010, dependiendo del objeto de la auditoria en cuestión ya debería existir un listado con la totalidad de las pruebas que se van a realizar, porque esto no es nada nuevo, ni hay que inventar nada. Fijo que con ese listado es posible planificarse mejor con el cliente, tanto en tiempos como en resolución de incidentes.

Además, con ese listado sería posible también incorporar al informe toda esa serie de cosas que se han hecho, y que no han ofrecido resultados, algo que en realidad si es información útil ya que podría ayudar a demostrar que las medidas de seguridad están funcionando. Lo curioso es que esto último además sirve para rellenar papel, que esto gusta (informes bien tochos ingestionables).

Por último, la falta de seguimiento real en el tiempo impide que se hagan informes de tendencias realistas, me refiero a reutilizar la información obtenida anteriormente, no a copiar literalmente parte del informe :)

Estos problemas aparecen sobre todo con el uso de herramientas automáticas, que ni dan lo uno ni lo otro.

Libre opinión, por supuesto, que no atenta contra nadie.

Anónimo dijo...

Molt útil. La direcció correcta a l'enllaç és: http://www.first.org/cvss/cvss-guide.html


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login