Herramientas para análisis estático de seguridad

Herramientas para análisis estático de seguridad

Estático = se analiza sin ejecutar el software

• Ventajas:

• Consistencia. La herramienta ve lo que ve, sin ideas preconcebidas (que normalmente tienen los desarrolladores o revisores).

• Apuntan a la causa raíz, no a los síntomas. Una prueba de penetración puede establceder que hay un problema, pero no su causa final ni cómo corregirlo.

• Detección precoz. La aplicación no tiene que estar integrada ni necesita ejecutarse.

• Su ejecución es barata. Un sistema puede re-analizarse cuando se aplican cambios, o cuando se descubre una nueva vulnerabilidad de aplicación.

 Inconvenientes:

• Falsos positivos. Impacto (coste) crece al tener que evaluar cada positivo.

• Falsos negativos. Suelen ser incapaces de detectar vulnerabilidades de seguridad achacables al diseño, o específicas del contexto propio de la aplicación (se centran en vulnerabilidades genéricas, de codificación).

• ¿Qué es mejor? En seguridad, sin duda, baja tasa de falsos negativos sin una tasa desproporcionada de falsos positivos

Las etapas iniciales son similares a las que sigue un compilador.

 • El análisis semántico permite pasar a una representación interna del software en la que están representadas las nociones básicas para determinar defectos de seguridad: flujo de datos y llamadas, tipos y tamaños de las variables, entradas y recursos alcanzables, y qué entradas están bajo control (taint) del usuario. Este modelo incluye el entorno (librerías, funciones de sistema, etc.) 

• La “inteligencia” está codificada en reglas que un verificador aplica sobre el modelo interno para determinar posibles defectos.

1. Establecer objetivos

a. Priorizar qué partes a analizar

b. Entender el software (a alto nivel)

c. Comprender riesgos

2. Lanzar herramientas

a. Introducir reglas específicas

b. Compilar el código; lanzar herramienta

3. Revisar resultados

a. Revisión manual a partir de problemas potenciales

b. Si falso positivo: Reconfigurar; Si falso negativo: Añadir regla

c. Registro de problemas (informe formal, gestor de defectos…)

4. Introducir correcciones

a. Revisar (manual/automáticamente) cambios

b. Actualizar “Buenas prácticas”, objetivos alcanzados, y reglas

 ¿Quién ejecuta la herramienta?

• Seguridad del software, desarrolladores, o mejor ambos.

• ¿Cuándo?

• Desde el IDE del programador; en subida de código al

control de versiones; en script de build; al librerar una

versión; en procesos formales de auditoría de código.

• No olvidar que la MAYOR CARGA (90%) de trabajo se

consume al analizar resultados e introducir correcciones.

• ¿Cómo tratar los resultados?

• “Si hay riesgo, se bloquea la liberación de la versión”

• “Una autoridad central filtra y decide”

• Usar aproximación incremental al adoptar técnicas:

• Recordar las tácticas empleadas con los IDS/IPS

Cuestionario

link Herramientas para análisis estático de seguridad