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:
- no tengo que hurgar y analizar en el reporte para armar la tabla de hallazgos que finalmente me pedirán y,
- 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
0 comentarios:
Publicar un comentario