¿Haciendo referencia a la lista de gravedad de riesgos estándar del software?

Question

¿Haciendo referencia a la lista de gravedad de riesgos estándar del software?

#1 de John Deters (1 votos)
#2 de Tom K. (1 votos)

1

¿Existe algún material de referencia sobre la gravedad de los hallazgos de seguridad del software estándar? Por ejemplo, la inyección SQL es la gravedad 1, el encabezado que falta es la gravedad 4?

Entiendo que la evaluación de riesgos depende de muchos factores y diferencias ambientales, pero ¿existe una guía general que pueda seguirse?

Mi empresa de software recibe regularmente quejas de un solo cliente que realiza pruebas de penetración baratas cada vez que toman un parche. Se niegan a pagar facturas y desconectan el software hasta que resolvemos los problemas a medida que la empresa de pruebas de penetración presenta los hallazgos de tipo informativo como "Alto riesgo". El riesgo más grave que identificaron fue que un archivo CSS era visible en la fuente, pero no tenían pruebas que respaldaran si era explotable. Su justificación era que el código fuente no debería ser visible.

¿Cómo puedo defender esto y tratar de llevarlo a los intereses de los clientes, así como a los nuestros, que estos probadores de penetración son falsos?

risk-management penetration-test

pregunta Cyassin 09.08.2017 - 03:36

fuente

2 respuestas

Lea otras preguntas en las etiquetas risk-management penetration-test

¿Cuántas veces debe firmar un servidor DNS? ¿Existe una forma pasiva de verificar las implementaciones de DKIM (en el nivel de DNS) sin activar un evento de correo electrónico real?

score 1 · Answer 1

Establezca su propio estándar de clasificación de riesgo y haga que su cliente lo acepte.

Comience por evaluar el riesgo que la aplicación representa para la organización. Por ejemplo, si el sistema maneja cualquier información regulada (PCI, HIPAA, GLBA, PHI, PII, etc.), o si se enfrenta externamente, o si es de misión crítica, llámelo un sistema de alto riesgo, y cualquier cosa que sea la pluma. Los evaluadores encuentran que se clasificarán como un hallazgo de alto riesgo que debe abordarse de inmediato. Pero si no es un sistema de alto riesgo, solo los hallazgos demostrables explotables se considerarán vulnerabilidades de alta severidad que requieren una remediación inmediata. Quizás pueda identificar aún más una clase de aplicaciones de riesgo "muy bajo" que pueden estar exentas de las costosas pruebas con lápiz.

Sus clientes solo tienen tantos dólares de seguridad para gastar. Es su responsabilidad ayudarlos a gastarlos donde tengan la mejor oportunidad de producir resultados significativos.

score 1 · Answer 2

No conozco ningún marco que pueda implementarse que sea tan amplio, que toque todos los posibles problemas de seguridad que puedan surgir en una prueba de penetración y esté en por otro lado, tan específico, que proporciona un sistema de puntuación exacto.

Entiendo que la evaluación de riesgos depende de muchos factores y factores ambientales. diferencias, pero ¿hay todavía una guía aproximada que se pueda seguir?

Hay al menos un factor más a tener en cuenta, y ese es el "apetito por el riesgo" de las organizaciones. Un riesgo específico es un "Riesgo alto" para una organización y un "Riesgo medio" para otra. Si su empresa tiende a tomar decisiones comerciales de alto riesgo de forma regular, es posible que acepten riesgos que otros simplemente no quieren.

Su ejemplo dado fue un archivo CSS visible. Parece que dirías: "Oye, mientras no sea explotable ahora, ¿qué daño hay? ¡Eso no es un riesgo alto!". El razonamiento detrás de su justificación es (tal vez): "Puede que no sea explotable ahora, pero no queremos que el código fuente sea visible, por lo que los atacantes no tienen ideas sobre CÓMO explotarlo en el futuro". (Que es un razonamiento que apoyo para ser honesto).

En mi humilde opinión, hay dos cosas que puedes hacer.

Desde un punto de vista metódico, use el Sistema de puntuación de vulnerabilidad común (CVSS) y compare su resultados de vulnerabilidades en bases de datos de vulnerabilidades que están disponibles públicamente, como esta . (Busque en Sec.SE muchas preguntas sobre este tema). Esto le dará una idea de qué tan grave es una vulnerabilidad y también lo llevará a una mejor evaluación de los resultados de las pruebas de penetración.
Desde un punto de vista empresarial, póngase en contacto con los evaluadores de penetración y haga preguntas. Desafíe sus conclusiones y descubra cuál es el razonamiento detrás de su evaluación. Si tiene la sensación de que cada riesgo identificado termina siendo un "Riesgo Alto", sugiera otro comprobador de penetración a su cliente.