Vous êtes sur la page 1sur 16

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