¿Cómo pueden los informes de Pentest contribuir a las soluciones estructurales para las vulnerabilidades?

0

Cuando hace un pentest, ¿cuál es su recomendación al cliente sobre cómo manejar / interpretar el informe?

Lo que veo con frecuencia es que los problemas identificados, especialmente los relacionados con el software de desarrollo propio, no se solucionan correctamente. El ejemplo más sencillo es el XSS, que está "remediado" por s /// (reemplaza exactamente la Cadena XSS del informe con nada).

Esta solución, obviamente, no es buena; por un lado, porque el XSS todavía existe y por otro lado porque este error es una clara indicación de que el concepto de manejo de la entrada del usuario no es seguro de ninguna manera. Desde mi punto de vista, esto significa que otras vulnerabilidades de XSS están presentes aunque no las encontré. Asumir que un probador encuentra todas las vulnerabilidades es, en mi opinión, poco realista.

¿Cómo consigo que el cliente piense así? Por ejemplo, quiero que el cliente diga "¡Oh, has encontrado un XSS! Probablemente necesitemos alguna adaptación de tecnología / proceso / arquitectura ... para deshacernos de estas cosas tanto como sea posible. Tal vez utilicemos un marco web e introducamos Solución SAST ".

Aprendí que los bloques de texto de remediación genéricos al final de cada informe no son suficientes en absoluto. Lo que ha demostrado ser bastante efectivo son los talleres de remediación: básicamente se analizan los resultados en un taller de 2 a 3 días y luego se respaldan los desarrolladores durante la implementación. Por supuesto, solo una pequeña cantidad de clientes están dispuestos a pagar por esto (y realmente no tengo los recursos).

    
pregunta pinas 13.11.2018 - 16:45
fuente

2 respuestas

2

En última instancia, la responsabilidad de implementar las recomendaciones de una prueba de penetración / revisión de seguridad, recae en los propietarios del sistema.

Como consultor, puede hacer recomendaciones, así como con XSS puede recomendar que el cliente se asegure de usar una combinación sólida de validación de entrada y codificación de salida para mitigar el riesgo de manera adecuada y puede señalar las debilidades del filtrado de listas negras o otras correcciones ingenuas como deshacerse de personajes específicos.

Sin embargo, al final del día, no puede impedir que los clientes tomen este enfoque en contra de sus recomendaciones.

Por supuesto, si es interno de la organización, tiene más opciones en las que puede intentar obtener estándares de seguridad para sus equipos de desarrollo que diseñen la manera correcta de evitar / reducir la incidencia de los problemas de seguridad.

    
respondido por el Rоry McCune 13.11.2018 - 17:13
fuente
1

Este es un problema en general con las pruebas.

Si sabes por qué se hizo la prueba para empezar, úsala.

Para el software de desarrollo propio, intente guiarlos en marcos y listas como OWASP, para que puedan ver más de la imagen / problema en su totalidad. Da una pista de a dónde pueden ir y enseñarse más a sí mismos. Los costos son a menudo un problema. Así que pagar por un taller para educarlos, puede que no sea una opción. (¡Pero inclúyalo al final!)

Hacer referencia a obligaciones legales o estándares como la familia ISO 27000, a veces ayuda. O si está familiarizado con las leyes y normas locales.

Recuerda, eres un personal técnico, no legal, así que conoce tus límites. "Un problema conocido en el marco OWASP [esto y aquello], y puede ser un incumplimiento de las obligaciones legales otorgadas en ISO 27001 [más o menos específico, dependiendo del tema]. La solución recomendada incluye la revisión de [problema más grande, así como la pequeña corrección.] ".

  • C, probador.
respondido por el cewi 14.11.2018 - 10:36
fuente

Lea otras preguntas en las etiquetas