Yo esperaba un buen reporte de pentest

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!

Es todo. Felices reportes.