22 ago 2014

Yo esperaba un buen reporte de pentest

Por Fausto Cepeda González (@FaustoCepeda)

No me dedico a hacer pentest. Llegué a realizar algunos hace varios años y fueron internos, con alcances limitados. Tengo la certificación CEH pero no me pareció la gran cosa ni me creo hacker ni pentester por haberlo cursado exitosamente. También coordiné y contraté tres servicios de pentest, uno de ellos de muy alto nivel con hackers (en el buen sentido de la palabra, es decir, gente motivada a dominar la tecnología y con conocimientos muy profundos de TI).

Por lo tanto me siento con las credenciales suficientes para poder identificar tanto un buen ejercicio de pentest como un reporte con calidad de los hallazgos. En este artículo voy a abordar el segundo punto: el reporte.
La idea de este artículo me la dio la revisión de un reporte de un pentest. Al irlo leyendo me surgieron algunas críticas del mismo las cuales les comparto.

Carece de tabla de hallazgos

Al final de cuentas, para darle seguimiento a lo que encontró el pentest es necesario entregar una lista de hallazgos, los cuales (a modo de checklist) se irán eliminando conforme la empresa los solucione. Es importante mencionar que a un nivel alto (directivo) le darán seguimiento a la solución de los hallazgos de un pentest por medio de una tabla que incluirá:
  • nombre del hallazgo,
  • descripción del mismo,
  • fecha de solución y
  • estatus actual o avance.
Es todo. Al alto nivel no le interesará realmente saber más para darle seguimiento a la solución de los hallazgos. Por lo tanto, el reporte de decenas de páginas está bien para tener el detalle técnico, pero si me das el listado de hallazgos me facilitarás la vida por dos cuestiones:
  1. no tengo que hurgar y analizar en el reporte para armar la tabla de hallazgos que finalmente me pedirán y,
  2. evitas que yo omita un hallazgo porque no está claramente identificado como tal en el reporte.
Creerás que exagero y que en todos los reportes de pentest se pueden identificar claramente los hallazgos. Pues no. Unos se ponen a escribir y escribir poniendo screenshots aquí y allá sin una división clara del texto en el documento. ¿Cuántos hallazgos hay y cuáles son? Como que el pentester fue escribiéndolo conforme le venían las ideas a la mente y pone todo como un gran bloque de texto, donde los hallazgos están inmersos en algún lugar. Se vuelve un juego de “Encuentra a Wally”. Una tabla de hallazgos solucionaría este problema.

Reporte ejecutivo de los hallazgos.

Por alguna razón muchos pentesters creen que todos hablan su lenguaje (y de paso, aquí quiero incluir a algunos de los encargados de seguridad en las empresas que también hablan con sus terminajos que pocos entienden). Cuando quieres explicarle a tus jefes los hallazgos, pides a los pentesters una presentación y/o resumen ejecutivo. Más de uno falla rotundamente.
Simplemente no pueden salirse de sus XSS, Cross-Site Request Forgery (CSRF), Unvalidated Redirects and Forwards y demás tecnicismos. En sus reportes y presentaciones no hay tablas. No hay impactos. Inexistentes los cuadros de riesgo donde se pueda ver rápidamente la vulnerabilidad, los diferentes perfiles del atacante que podría concretar el ataque, el riesgo y consecuencia. A los ejecutivos sinceramente no les interesa lo difícil que fue encontrar una debilidad, cuál fue el exploit de Metasploit usado (¡y peor aún, con lujo de detalles!) y que si el ataque evade el Enhanced Mitigation Experience Toolkit.
Lo que quieren saber son impactos, riesgos, dificultad para solucionar el hallazgo, facilidad para concretar el ataque, otras defensas que mitiguen el riesgo y soluciones viables a implementar y en qué plazo. No hables de árboles, coméntame del bosque.

Falta investigación de las propuestas de solución

En lo que casi todo pentester falla es al momento de proponerte una solución para el hallazgo. Por cierto, unos ni siquiera ponen esta sección de “soluciones” que porque no es parte del pentest. Es como si fueras al doctor y te dice que tienes varias enfermedades que detectó pero que no te puede decir qué hacer porque su trabajo acaba al momento de encontrarlas. En fin, regresemos al tema.
Decía que las soluciones de los pentesters muchas veces fallan porque si bien son buenos encontrando huecos de seguridad, son pésimos para proponer soluciones efectivas corporativas. Se ve que nunca han estado laborando en una empresa del lado de los administradores de TI. Inclusive a veces te ponen una liga que encontraron en internet, que al final de cuentas revisas y no tiene nada que ver con una solución empresarial, es para que la aplique un usuario casero.
Otras veces el pentester te manda a una liga con “las mejores prácticas”; un documento de cientos de hojas donde yo tengo que adivinar cuál práctica es la que soluciona el hallazgo. En general, mi punto es que los pentesters le dedican tiempo a encontrar huecos de seguridad pero no se sientan para explorar buenas soluciones que se puedan implementar en la vida real corporativa. Si creen que este no es su trabajo, ni me lo digan, sería una discusión infinita (y yo que estoy tratando de hacer que sus reportes salgan mejor).

Ausencia de claridad de las explicaciones

En el mundo de TI nos falla a muchos escribir con claridad. A veces pienso que es todo un arte perdido. Uno se encuentra con párrafos (¡y hasta páginas!) completos que es necesario volver a leer al menos dos veces para entender lo que quisieron decir. Tan fácil que es:
  • incluir un resumen, tabla de hallazgos y conclusión (varias personas es lo único que leerán),
  • ser directo y al grano,
  • incorporar encabezados dentro del documento,
  • sustituir texto con tablas, imágenes, gráficas o screenshots siempre que se pueda,
  • usar bullets que son más fáciles de digerir que kilos de texto,
  • cortar: asegurarse de que cada palabra y párrafo es realmente necesario tenerlo ahí,
  • usar sujeto y predicado, en ese orden; concepto de primaria pero a veces olvidado,
  • evitar el “se”: se recomienda, se bajará el riesgo, se hizo, se tendrá. En lugar del “se”, mejor identificar el quién siempre que se pueda,
  • utilizar verbos en lugar de sustantivos “para la solución de “ -> “para solucionar”,
  • poner siglas con su significado,
  • usar forma positiva en lugar de la negativa: “no es improbable que se eliminen las debilidades por lo tanto no es recomendable parcharlas a menos de que haya certeza de que no se ha mitigado el riesgo previamente por haber evitado una solución no confiable”. WTF?
  • leer el reporte al menos 3 veces buscando incoherencias, errores gramaticales y demás; y no dije 2 veces, dije 3,
  • corregir faltas ortográficas, ¡por Dios!
Fuente: Search Data Center

Suscríbete a nuestro Boletín

3 comentarios:

  1. Interesante, estoy preparando mi primer informe de pentest y lo cierto es que parte de las ideas me van a ayudar a la hora de reescribir algunas secciones (o añadir cosas que faltaban).

    ResponderBorrar
  2. El pentester no va a solucionarte la vida, si pensaste que iba a ser así te equivocaste, el servicio es de penetración, salvo que hallan arreglado otra cosa, luego si quieres solucionarlo contrata un servicio de consultoria del mismo pentester si lo ofrece, o un tercero.

    Si yo te encuentro en un pentest algo simple como un SQLi, no puedo decirte "si cambia esto acá y allá, listo!", el encargado de programar eso que sabe lo que quiere y como va a ser el responsable en arreglarlo con o sin asistencia del pentester.

    ResponderBorrar
    Respuestas
    1. No estoy de acuerdo. Precisamente el pentest es un tipo de auditoría donde en el informe se deben recomendar acciones correctivas (como en todo tipo de auditoría).

      Otra cosa es que para la implementación concreta de esas acciones ya si que te digan que pases por caja y contrates un servicio de consultoría, pero ya estamos hablando de extender el scope de la auditoría.

      Borrar

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!