TEMA 2 : Seguridad en el

ciclo de vida del

software

2.8. PRUEBAS DE SEGURIDAD BASADAS EN RIESGO

2.8. Pruebas de seguridad basadas en

riesgo

Identificando los

riesgos del sistema y

diseando las pruebas

en base a ellos, bajo la

perspectiva de un

atacante, un probador

de seguridad de

software puede

enfocar

correctamente las

reas de cdigo

donde un ataque

probablemente

pudiera tener xito.

2.8. Pruebas de seguridad basadas en

riesgo

La seguridad en s misma es una caracterstica de la totalidad del sistema,

por tanto no se refiere solamente a los mecanismos y elementos de

seguridad.

Las pruebas de seguridad necesariamente deben implicar dos tipos de

aproximaciones:

Pruebas de seguridad funcionales: pruebas de los mecanismos de

seguridad para asegurar que su funcionalidad est correctamente

implementada.

Pruebas de seguridad perspectiva atacante: realizacin de pruebas

de seguridad en base al riesgo motivadas por el entendimiento del

estado del riesgo y por tanto del nivel de seguridad del sistema. Tratan

de simular la actuacin de un posible atacante.

2.8. Pruebas de seguridad basadas en

riesgo

Los objetivos de las pruebas de seguridad basadas en el riesgo son los

siguientes:

Verificar la operacin confiable del software bajo condiciones hostiles de

ataque.

Verificar la fiabilidad del software, en trminos de comportamiento seguro y

cambios de estado confiables.

Verificar la falta de defectos y debilidades explotables.

Verificar la capacidad de supervivencia del software ante la aparicin de

anomalas, errores y su manejo de las mismas mediante excepciones que

minimicen el alcance e impacto de los daos que puedan resultar de los

ataques.

2.8. Pruebas de seguridad basadas en

riesgo

En los modelos de ciclo de vida tradicionales en los que no se tienen en cuenta prcticas de

seguridad la mayora de incidencias ni la realizacin de pruebas basadas en riesgo, se tiene que

la mayora de incidencias se tienen antes de salir a produccin, sin embargo cuanto estas

medidas se aplican se obtiene un perfil descendente en el que la mayora de la incidencias

aparecen durante la fase de codificacin.

2.8. Pruebas de seguridad basadas en

riesgo

Las pruebas de seguridad

deberan comenzar a

nivel de componente

antes de la integracin

del sistema.

2.8. Pruebas de seguridad basadas en

riesgo

Revisin de diseo: son la categora de defectos ms difcil de manejar, adems son tanto

frecuentes como crticos.

El anlisis de caja blanca implica el anlisis y el entendimiento tanto de cdigo fuente como

del diseo. Esta clase de pruebas es muy eficaz en el hallazgo de errores de programacin,

bugs cuando automticamente se explora el cdigo y flaws cuando se realiza el anlisis de

riesgo.

2.8. Pruebas de seguridad basadas en

riesgo

Revisin de cdigo o anlisis esttico de cdigo: Se considera una de las

prcticas de seguridad ms importantes, consiste bsicamente en el

anlisis del cdigo fuente antes de ser compilado, para detectar errores,

construcciones inseguras de codificacin e indicadores de

vulnerabilidades o debilidades de seguridad futuras.

El anlisis de caja gris en una mezcla de las dos anteriores, es una prueba

que combina pruebas en donde no solo se tiene en cuenta la interfaz del

aplicativo, sino tambin el cdigo fuente del mismo.

2.8. Pruebas de seguridad basadas en

riesgo

Anlisis dinmico de cdigo: Implica el uso tanto del cdigo fuente y como del binario

ejecutable compilado a partir de dicho cdigo.

En este tipo de revisin se realizan tres tipos de anlisis:

Anlisis de cobertura: Pone de manifiesto las interacciones entre las diferentes partes del

programa.

Anlisis de frecuencia de espectro: Revela las dependencias entre los componentes del

programa.

Anlisis de patrones: Permite buscar patrones especficos en la ejecucin del programa,

tales como excepciones no capturadas, omisiones, errores de memoria dinmica y

problemas de seguridad.

Ejemplo de herramientas:

Valgrind, DAST Hp Fortify y Acunetix.

2.8. Pruebas de seguridad basadas en

riesgo

2.8. Pruebas de seguridad basadas en

riesgo

Inyeccin de fallos en cdigo fuente: Una forma de anlisis dinmico en el que el cdigo

fuente sea instrumentado por los cambios de la insercin, a continuacin, compilar y

ejecutar el cdigo instrumentado para observar los cambios en el estado y el

comportamiento que surgen cuando las partes instrumentadas de cdigo se ejecuta.

El anlisis de caja negra se refiere al anlisis de un programa ejecutndolo y sondendolo con

varias entradas, no usa anlisis de cdigo fuente de ninguna clase y necesitan tambin

centrarse en estructuras de datos, componentes, APIs, estado de programa, etctera.

2.8. Pruebas de seguridad basadas en

riesgo

Test de penetracin: Su propsito se centra en la determinacin de vulnerabilidades internas a un componente o entre ellos, que estn expuestas al acceso externo y si pueden ser explotadas para comprometer el software, los datos o su entorno y los recursos.

Anlisis cdigo binario: Es comparable a la exploracin del cdigo fuente, pero se dirige el software con cdigo ensamblador o ejecutable compilado binario antes de ser instalado y ejecutado. No hay escneres de cdigo binario especfico se utiliza herramientas de ingeniera inversa y anlisis de ejecutables binarios, como descompiladores, desensambladores y escneres de cdigo binario como los utilizados por Veracode, para analizar el cdigo mquina y modelar una representacin independiente del idioma de los comportamientos del programa, el control y los flujos de datos, rboles, y las llamadas externas de funcin. Ejemplos de este tipo de herramientas son IDAPRO, WinDbg, etc.

2.8. Pruebas de seguridad basadas en

riesgo

Inyeccin de fallos en binarios: Induce tensiones en el software, crea problemas de

interoperabilidad entre los componentes y simula fallos en el entorno de ejecucin.

Simula tipos de fallos y anomalas que pudieran resultar de patrones de ataque o la

ejecucin de lgica maliciosa que hacen que el software vulnerable. Complemento a

las pruebas de penetracin, pues permite al probador enfocarse con ms detalle en las

conductas especficas del software en respuesta a patrones de ataque.

Fuzz testing: Consiste en la introduccin de datos no vlidos (por lo general producido

por la modificacin de una entrada vlida) al software a travs de su entorno o a

travs de otro componente de mismo. Suelen ser especficos de un tipo particular de

entrada, como HTTP, y se escriben para ser utilizados para probar un programa

especfico, por lo que no son fcilmente reutilizables. Sin embargo, su valor radica en su

especificidad, ya que a menudo puede revelar vulnerabilidades de seguridad que las

herramientas genricas de evaluacin

2.8. Pruebas de seguridad basadas en

riesgo

Escaneo de vulnerabilidades: Analizan los sistemas en busca de

vulnerabilidades conocidas. Disponen de informacin sobre

vulnerabilidades existentes en los sistemas operativos y aplicaciones

mediante actualizadas bases de datos, que utiliza para la deteccin de

las mismas. La herramienta ms utilizada es Nessus, inicialmente de cdigo

abierto y versin gratuita. Proyectos diferentes a partir de la versin libre:

Sussen, Porz-Wahn y OpenVas (inicialmente GNessUs). Otras herramientas

de extendido uso son ISS Real Secure, Nmap y Retina.

2.8. Pruebas de seguridad basadas en

riesgo

Las pruebas de seguridad se deberan estructurar en las siguientes fases:

Descomponer el sistema en sus componentes fundamentales.

Identificar las interfaces de los componentes.

Clasificar las interfaces de los componentes por su riesgo potencial.

Averiguar las estructuras de datos usadas por cada interfaz.

Encontrar problemas de seguridad inyectando datos maliciosos, apoyndose

en el estado del riesgo ante las posibles amenazas.

2.8. Pruebas de seguridad basadas en

riesgo

Diferentes pruebas a realizar en cada una de las fases del S-SDLC