Tema 4. Seguridad en El Ciclo de Vida Del Software (Ii)

Tema
4

Seguridad en el Software
Seguridad en el ciclo de
vida del software (II)
Índice
Esquema 3
Ideas clave 4
4.1. Introducción y objetivos 4
4.2. Pruebas de seguridad basadas en riesgo 5
4.3. Revisión de código 19
© Universidad Internacional de La Rioja (UNIR)
4.4. Pruebas de penetración 27
4.5. Operaciones de seguridad 35
4.6. Revisión externa 38
4.7. Referencias bibliográficas 40
A fondo 43
Test 52

Esquema

3
Tema 4. Esquema
Ideas clave
4.1. Introducción y objetivos

Para conseguir software confiable que solo realice las tareas para las que está
diseñado y minimizar al máximo los ataques en la capa de aplicación y por tanto el
número de vulnerabilidades explotables, es necesario seguir un proceso sistemático
o disciplina que aborde la seguridad en todas las etapas del ciclo de vida de desarrollo
del software que incluya una serie de buenas prácticas de seguridad (S‐SDLC) como
especificación requisitos seguridad casos de abuso, análisis de riesgo, análisis de
código, pruebas de penetración dinámicas, modelado de amenazas, operaciones de
seguridad y revisiones externas, necesarias para asegurar la confianza y robustez del
mismo.

Normalmente, el modelo más propicio para el desarrollo de software en las
organizaciones suele ser una combinación de dos o más modelos de los ciclos de vida
(cascada, espiral, etc.). Sin embargo, hay que tener en cuenta que lo importante no
es el modelo seguido, sino la incorporación de buenas prácticas de seguridad en las
diferentes fases de este y unos hitos o puntos de control donde se verifiquen los
entregables de cada fase. Entre las razones principales para añadir prácticas de
seguridad en el SDLC tenemos:

▸ Mayor probabilidad de capturar adecuadamente los requisitos y tomar decisiones
de diseño correctas y no cometer errores involuntarios de codificación.
▸ Dificultad de los agentes maliciosos para explotar vulnerabilidades y debilidades
del software, pues el resultante de un ciclo de vida S‐SDLC será más robusto en
su entorno de ejecución y en su interacción con entidades externas.

En la figura siguiente se presenta un diagrama conceptual de dos de las prácticas de
seguridad más importantes, revisión de código y test de penetración realizadas
4
Tema 4. Ideas clave
mediante herramientas de análisis estático y dinámico que escanean el código fuente
y la aplicación en su entorno de ejecución respectivamente, en busca de
vulnerabilidades comunes. Posteriormente se desarrollan en este tema.

Figura 1. Revisión de código y test de penetración.

Los objetivos del presente tema son:

 Conocimiento y comprensión de las buenas prácticas de seguridad a incluir en un
S‐SDLC en las fases de Codificación, Pruebas y Operación.
 Profundizar en el estudio de la principal práctica de seguridad: revisión de código.
 Estudiar las prácticas de seguridad aplicables en estas fases del SDLC como
pruebas de penetración, operaciones de Seguridad, revisión externa y pruebas de
seguridad basadas en riesgo.

4.2. Pruebas de seguridad basadas en riesgo

Hasta hace unos pocos años las pruebas de software se desarrollaban en base a la
demostración de sus requisitos, como forma de comprobar el correcto
funcionamiento de sus capacidades e incluso sus funciones y servicios de seguridad,
sin embargo, no sirven para determinar cómo se comportará en condiciones
anómalas y hostiles, ni si está libre de vulnerabilidades.
5
Tema 4. Ideas clave

Identificando los riesgos del sistema y diseñando las pruebas en base a ellos,
bajo la perspectiva de un atacante, un probador de seguridad de software
puede enfocar correctamente las áreas de código donde un ataque
probablemente pudiera tener éxito.

Figura 2. Pruebas seguridad basadas en riesgo.

Aunque los componentes de seguridad, como la criptografía, la autenticación y el
control de acceso, jueguen un papel crítico en la seguridad de software, la seguridad
en sí misma es una característica de la totalidad del sistema, por tanto, no se refiere
solamente a los mecanismos y elementos de seguridad. Un desbordamiento de buffer
es un problema de seguridad independientemente de si existe un componente de
seguridad o en un interfaz hombre máquina no crítico. Por esta razón, las pruebas de
seguridad necesariamente deben implicar dos tipos de aproximaciones:


Figura 3. Tipos de pruebas seguridad del software.
6
Tema 4. Ideas clave
Los objetivos de las pruebas de seguridad basadas en el riesgo son los siguientes:

 Verificar la operación confiable del software bajo condiciones hostiles de ataque.
 Verificar la fiabilidad del software, en términos 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 aparición de
anomalías, errores, y el manejo de estas mediante excepciones, que minimicen el
alcance e impacto de los daños que puedan resultar de los ataques.

Las pruebas de seguridad deberían comenzar a nivel de componente antes de la
integración del sistema. Se deben de utilizar los modelos de ataque, casos de abuso
y análisis de riesgos desarrollados al comienzo del ciclo de vida, para mejorar el plan
de pruebas con casos diseñados desde el punto de vista de los atacantes basados en
los escenarios de abuso. Esto implica tanto pruebas de caja negra como de caja
blanca.

Técnicas de pruebas que son particularmente útiles para las pruebas basadas en
riesgo incluyen las mostradas en el siguiente diagrama:

7
Tema 4. Ideas clave

Figura 4. Tipos de pruebas seguridad basadas en riesgo.

El análisis de caja blanca implica el análisis y el entendimiento tanto de código fuente
como del diseño. Esta clase de pruebas es muy eficaz en el hallazgo de errores de
programación, bugs, cuando automáticamente se explora el código mediante
herramientas y debilidades de diseño, flaws, cuando se realiza el análisis de riesgo.
Las exploraciones de código pueden automatizarse con un analizador estático. Una
desventaja de esta clase de pruebas consiste en que se podría encontrar una
vulnerabilidad potencial donde en realidad existe un falso positivo. Hay que revisar
el resultado de las herramientas de análisis estático para identificarlos.
8
Tema 4. Ideas clave

Figura 5. Puntos fuertes y débiles pruebas caja blanca. Fuente: adaptado de López, S. (2012).

 Revisión de diseño. Las vulnerabilidades de nivel de diseño son la categoría de
defectos más difícil de manejar, además son tanto frecuentes como críticos.
Lamentablemente, averiguar si un programa tiene vulnerabilidades de nivel de
diseño requiere conocimiento y experiencia. Ejemplos de problemas de nivel de
diseño incluyen manejo de errores en sistemas orientados a objetos, objetos
compartidos, relaciones de confianza, canales de datos sin protección,
mecanismos de control de acceso incorrectos, carencia de auditorías, registro
(logs) y errores en el ordenamiento de eventos.

 Revisión de código o análisis estático de código. Se considera una de las prácticas
de seguridad más importantes, consiste básicamente en el análisis del código
fuente antes de ser compilado, para detectar errores, construcciones inseguras de
codificación e indicadores de vulnerabilidades o debilidades de seguridad futuras.

 Inyección de fallos en código fuente. Una forma de análisis dinámico en el que el
código fuente sea «instrumentado» por los cambios de la inserción. A
continuación, compilar y ejecutar el código instrumentado para observar los
9
Tema 4. Ideas clave
cambios en el estado y el comportamiento que surgen cuando las partes
instrumentadas de código se ejecuta. De esta manera, el aparato de medida puede
determinar y cuantificar cómo, incluso, el software reacciona cuando es forzado
en estados anómalos, tales como los provocados por fallos intencionales. Esta
técnica ha demostrado ser particularmente útil para detectar el uso incorrecto de
punteros y matrices, y la presencia de las llamadas peligrosas y condiciones de
carrera.

Inyección de fallos es un complejo proceso de prueba y por lo tanto tiende a ser
limitada al código que requiere garantía muy alta.

Para la realización de estas pruebas se utilizan motores inyección. Este
instrumento usa el navegador para interceptar transacciones y permitir a un
analista estudiarlas. Aunque esta clase de pruebas sea posible con Perl y una
interfaz de línea de comandos, la colección de resultados y la automatización hace
que el valor de las herramientas de la segunda generación sea considerable.

El análisis de caja negra se refiere al análisis de un programa ejecutándolo y
sondeándolo con varias entradas, por lo que se centra en estructuras de datos,
componentes, APIs, estado de programa, etcétera. No usa análisis de código fuente
de ninguna clase. La visión obtenida durante el análisis de riesgo arquitectónico es
muy útil en la planificación de este tipo de pruebas de seguridad.


Figura 6. Puntos fuertes y débiles pruebas caja negra. Fuente: adaptado de López, S. (2012).
10
Tema 4. Ideas clave
 Pruebas de penetración. Su propósito se centra en la determinación de
vulnerabilidades internas a un componente o entre ellos, que estén expuestas al
acceso externo y si pueden ser explotadas para comprometer el software, los
datos o su entorno y los recursos. Engloba, normalmente, la ejecución de otros
tipos de pruebas de caja negra, que se describen en los siguientes párrafos:
• Escaneo de vulnerabilidades.
• Explotación de vulnerabilidades.
• Fuzz testing.
• Análisis dinámico (DAST) para aplicaciones web.

La explotación de las vulnerabilidades encontradas se puede realizar de forma
automática con las siguientes herramientas:

Aplicación Licencia S.O.
Metasploit Framework Comercial / Libre Windows, Linux
https://www.metasploit.com/
Core Impact Comercial Windows, Linux
https://www.coresecurity.com/pro
ducts/core‐impact
Canvas Comercial Windows, Linux
http://www.immunitysec.com/pro
ducts/canvas/index.html
Tabla 1. Herramientas explotación de vulnerabilidades.

En apartados posteriores de este documento se desarrollan este tipo de pruebas.

 Análisis dinámico (Dynamic Application Security Testing‐DAST). Detectan
debilidades y vulnerabilidades de seguridad en aplicaciones Web mientras se
están ejecutando. Emplea técnicas de inyección de fallos en una aplicación, por
ejemplo, entrada de datos maliciosos tal y como se representa en la figura
siguiente, para identificar vulnerabilidades comunes, como inyección SQL, cross‐
site scripting, open redirect, command injection, path traversal etc. También
identifica problemas de configuración del servidor, autenticación, inicio de
11
Tema 4. Ideas clave
sesiones, etc. Lo más eficiente es la realización de pruebas conjuntas SAST y DAST,
pues ayudan a minimizar la cantidad de falsos positivos.

Figura 7. Funcionamiento pruebas Análisis Dinámico (DSAT). Fuente: López, S. (2012).

Acunetix WVS. Comercial / Libre Windows
AppScan. Comercial Windows
Burp Suite. Comercial / Libre La mayoría de ellas
GamaScan. Comercial Windows
Grabber. Open Source Python
Grendel‐Scan Open Source Windows, Linux y Macintosh
IKare. Comercial N/A
N‐Stealth. Comercial Windows
Netsparker. Comercial Windows
Nikto. Open Source Unix/Linux
NTOSpider. Comercial Windows
ParosPro. Comercial Windows
QualysGuard. Comercial N/A
Retina. Comercial Windows
ScanDo. Comercial Windows

SecurityQA Toolbar Comercial Windows
SecPoint Penetrator. Commercial Windows, Linux y Macintosh
Vega Open Source Windows, Linux y Macintosh
Wapiti Open Source Windows, Linux y Macintosh
WebApp360 Commercial Windows
12
Tema 4. Ideas clave
WebInspect Commercial Windows
WebKing Commercial Windows / Linux / Solaris
Trustkeeper Scanner Commercial SaaS
Websecurify. Commercial / Free Windows, Linux y Macintosh
Wikto. Open Source Windows
Zap. Open Source Windows, Linux y Macintosh
Ironwasp. Open Source Windows, Linux y Macintosh
Tabla 2. Herramientas DAST.
 Análisis código binario. Es comparable a la exploración del código fuente, pero se
dirige el software con código ensamblador o ejecutable compilado binario antes
de ser instalado y ejecutado. No hay escáneres de código binario específico se
utiliza herramientas de ingeniería inversa y análisis de ejecutables binarios, como
descompiladores, desensambladores y escáneres de código binario como los
utilizados por Veracode, para analizar el código máquina y modelar una
representación independiente del idioma de los comportamientos del programa,
el control y los flujos de datos, árboles, y las llamadas externas de función.
Ejemplos de este tipo de herramientas son IDAPRO, WinDbg, etc.

 Inyección de fallos en binarios. La inyección de fallos de seguridad induce
tensiones en el software, crea problemas de interoperabilidad entre los
componentes y simula fallos en el entorno de ejecución. Simula tipos de fallos y
anomalías que pudieran resultar de patrones de ataque o la ejecución de lógica
maliciosa que hacen el software vulnerable. Constituye un complemento a las
pruebas de penetración, pues permite al probador enfocarse con más detalle en
las conductas específicas del software en respuesta a patrones de ataque. En
tiempo de ejecución el probador modifica los datos que se pasan por el entorno
de ejecución al software, o por un componente de software a otro. Sin embargo,
los fallos inyectados no deben limitarse solo a aquellos que simulan ataques. Para
obtener una comprensión más completa de todos los posibles comportamientos
del software y sus estados, el probador también debe inyectar fallos que simulan
condiciones muy poco probables, incluso los «imposibles».

13
Tema 4. Ideas clave
 Fuzz testing. Al igual que en la inyección de fallos binario, consiste en la
introducción de datos no válidos (por lo general producido por la modificación
de una entrada válida) al software a través de su entorno o a través de otro
componente de mismo. Las pruebas se llevan a cabo mediante un «fuzzer»,
programa o script que realiza, modifica o combina entradas del software, para
revelar cómo se comporta. Suelen ser específicos de un tipo particular de entrada,
como HTTP, y se escriben para ser utilizados para probar un programa específico,
por lo que no son fácilmente reutilizables. Sin embargo, su valor radica en su
especificidad, ya que a menudo puede revelar vulnerabilidades de seguridad que
las herramientas genéricas de evaluación, como escáneres de vulnerabilidad e
inyectores de fallos no detectan. Para que sean eficaces se requiere que el
probador tenga una comprensión completa del software que está probando y la
forma en que interactúa con entidades externas, cuyos datos simulará el fuzzer.
En la siguiente tabla se presenta herramientas de este tipo.

Programa Descripción
Mangle Fuzzer que genera etiquetas HTML y se autolanzará dentro de un navegador.
Spike Colección de fuzzers.
Wfuzz Fuzzer para web que aplica fuerza bruta sobre el protocolo HTTP. Realiza
pruebas de path discovery (recursivas) o de fuerza bruta sobre variables
(pasadas por GET o por POST). Emplea diccionarios (en el caso de las
inyecciones SQL el diccionario está preparado con los patrones SQL más
empleados). Dependiendo de la prueba que estemos haciendo emplearemos
un diccionario u otro.
Netcat Utilidad Unix que lee y escribe datos a través de conexiones de red usando
los protocolos TCP o UDP. Está diseñada para ser una utilidad de tipo back‐
end que pueda ser usada directamente o fácilmente manejada por otros
programas y scripts.
Radamsa Fuzzer de caja negra basado en mutaciones.
Blab Fuzzer basado en gramática.
American Fuzzer basado en mutaciones.
Fuzzy Lop
Zzuf CERT basic fuzzing framework. Busqueda de bugs.
Sulley Extras para gestionar fuzzing como parte de las pruebas de penetración.
14
Tema 4. Ideas clave
Hping2 Herramienta de red capaz de enviar paquetes ICMP/UDP/TCP hechos a
medida y de monitorizar las respuestas del host destino. Maneja
fragmentación y tamaños arbitrarios de paquetes.
Sniffit Herramienta de monitorización y packet sniffer para paquetes de
TCP/UDP/ICMP capaz de dar información técnica muy detallada acerca de
estos paquetes.
Firewalk Emplea técnicas del estilo traceroute para determinar las reglas de filtrado
que se están usando en un dispositivo de transporte de paquetes.
Tabla 3. Herramientas para la auditoria Fuzzing.
 Escaneo de vulnerabilidades. Este tipo de pruebas analizan los sistemas en busca
de vulnerabilidades conocidas. Disponen de información sobre vulnerabilidades
existentes en los sistemas operativos y aplicaciones mediante actualizadas bases
de datos, que utiliza para la detección de las mismas.

La herramienta más utilizada es Nessus, inicialmente de código abierto y versión
gratuita, y actualmente en dos versiones, una profesional comercial y otra de
prueba gratuita (www.nessus.org). A raíz de este cambio se crearon tres proyectos
diferentes a partir de la versión libre, Sussen, Porz‐Wahn y OpenVas (inicialmente
GNessUs). Actualmente el proyecto Porz‐Wahn se unió con OpenVas, la cual
continúa actualizando versiones para las distintas distribuciones de GNU/Linux.
Otras herramientas de extendido uso son Nexpose de Rapid 7, ISS Real Secure, GFI
LANguard, QualysGuard, Nmap y Retina.

En la tabla siguiente, se enumeran y se suministra información de varias
herramientas con diversas funcionalidades que existen actualmente:

15
Tema 4. Ideas clave
Nessus. Libre Linux/Unix, Windows
Nexpose. Comercial Linux/Unix, Windows
AppDetective. Comercial Windows
Open Vas Libre Linux.
GFI LANguard. Comercial Windows
MBSA. Freeware Windows
Nmap. GPL Linux/Unix, Windows, Mac OS X
Retina Network Security Scanner Comercial Windows
SARA. Freeware Linux/Unix, Windows
SATAN Comercial Linxu/Unix
SDS (Shadow Database Scanner) Comercial Windows
SolarWinds Engineer’s Toolset Comercial Windows
Symantec Enterprise Security Comercial Windows
Manager
Tabla 4. Herramientas de análisis de vulnerabilidades.

El análisis 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
también el código fuente del mismo.

 Análisis hibrido o Interactive Application Security Testing (IAST). Otro tipo de
pruebas enfocadas al análisis de aplicaciones tanto Web como de otro tipo, que
implica el uso tanto del código fuente y como del binario ejecutable compilado a
partir de dicho código. Para la realización del análisis, se ejecuta el programa
compilado con un agente dentro del mismo, al tiempo que se «alimentan» las
interfaces externas de la muestra. El revisor sigue y analiza los datos (variables en
memoria) que el programa produce como resultado de su ejecución, de forma que
cualquier vulnerabilidad o anomalía que surja en dicha interfaz se traza
simultáneamente con el código fuente que la genera con mayor eficacia. En
realidad, en este tipo de revisión se realizan tres tipos de análisis:

• Análisis de cobertura. Pone de manifiesto las interacciones entre las diferentes
partes del programa.
16
Tema 4. Ideas clave
• Análisis de frecuencia de espectro. Revela las dependencias entre los
componentes del programa.
• Análisis de patrones. Permite buscar patrones específicos en la ejecución del
programa, tales como excepciones no capturadas, omisiones, errores de

memoria dinámica y problemas de seguridad.

Dado que el agente IAST está trabajando dentro de la aplicación, su análisis se
aplica a toda la aplicación incluido su código. Se comprueba el control de los
tiempos de ejecución, flujos de datos, configuración, peticiones y respuestas
HTTP, bibliotecas, frameworks y otros componentes. El acceso a toda esa
información permite al motor IAST producir resultados más precisos y verificar
una gama más amplia problemas de seguridad que SAST o DAST.

Figura 8. Análisis híbrido.

17
Tema 4. Ideas clave
Ejemplo de herramientas:

Herramientas
1 Valgrind. Para todo tipo de aplicaciones
2 INSURE++ herramienta para análisis de errores para todo tipo de aplicaciones escrita en C,
C++.
3 SCA Fortify mas Web Inspect de HP, disponen de un agente para integrar el resultado de las
dos herramientas.
4 IBM Appscan, con el agente GLASS BOX.
5 Acunetix más Acusensor.
6 SEEKER
Tabla 5. Herramientas análisis híbrido.

Las pruebas de seguridad basadas en el riesgo (pruebas de seguridad desde el punto
de vista del atacante) según lo anteriormente expuesto se deberían 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, apoyándose en el
estado del riesgo ante las posibles amenazas.

En la figura siguiente se muestra las diferentes pruebas a realizar en cada una de las
fases del S‐SDLC:

18
Tema 4. Ideas clave

Figura 9. Distribución pruebas de seguridad a lo largo de las fases del S‐SDLC.

4.3. Revisión de código

Introducción

El análisis estático de código fuente, tal y como comenta McGraw (2005), se
considera la actividad más importante de entre las mejores prácticas de seguridad
que se han de realizar en el curso del desarrollo de una aplicación. En los siguientes
apartados se van a analizar los tipos y categorías de herramientas disponibles tanto
comerciales como de open source, para qué lenguajes están disponibles, cómo y
cuándo se tienen que utilizar y cómo se enmarca el uso de estas herramientas en el
proceso de revisión del código.

19
Tema 4. Ideas clave

Figura 10. Revisión de código.
Los problemas de seguridad de una aplicación pueden ser resultado de dos tipos de
errores principales:

 Errores simples que comete el programador por confusión, un lapsus
momentáneo, etc.
 Carencias de conocimientos del programador.

Con esto en mente, el análisis estático de código fuente es adecuado para identificar
problemas de seguridad por ciertas razones:

 Las herramientas de análisis estático comprueban el código a fondo y
coherentemente, sin ninguna tendencia. Un análisis valioso debe ser lo más
imparcial posible.
 Examinando el código en sí mismo, las herramientas de análisis estático a menudo
pueden indicar la causa de origen de un problema de seguridad, no solamente uno
de sus síntomas.
 El análisis estático puede encontrar errores tempranamente en el desarrollo, aún
antes de que el programa sea ejecutado por primera vez.
 Cuando un investigador de seguridad descubre una nueva variedad de ataque, las
herramientas de análisis estático ayudan a comprobar de nuevo una gran cantidad
de código.

20
Tema 4. Ideas clave
La queja más común y contrastada contra las herramientas de análisis estático de
seguridad es que producen demasiado ruido, es decir, falsos positivos: un problema
descubierto en un programa cuando ningún problema en realidad existe. Un gran
número de falsos positivos puede causar verdaderas dificultades.

Los falsos positivos son seguramente indeseables, pero desde una perspectiva de
seguridad, los falsos negativos son mucho peores. Con un falso negativo, un
problema existe en el programa, pero la herramienta no lo detecta. La penitencia
por un falso positivo es la cantidad de tiempo gastada repasando el resultado. La
penitencia por un falso negativo es mucho mayor, pues no solo se paga el precio
asociado por tener una vulnerabilidad en el código, se vive con un sentido falso de
seguridad que se deriva del hecho de que la herramienta hizo parecer que todo era
correcto.

Todas las herramientas de análisis estático de código producen algunos falsos
positivos y falsos negativos, su balance es normalmente indicativo del propósito de
la herramienta de la misma.

 Objetivo descubrir bugs. El coste de omitir un bug dentro de la primera categoría
es, relativamente pequeño hablando en términos de seguridad.
 Objetivo descubrir defectos relevantes de seguridad. La penitencia por bugs de
seguridad pasados por alto es elevada, por lo que este tipo de herramientas, en
general, producen más falsos positivos para reducir al mínimo falsos negativos.

Para que una herramienta de análisis estático descubra un defecto, el defecto debe
estar visible en el código. Esto podría parecer obvio, pero es importante entender
que el análisis de riesgo arquitectónico es un requisito necesario previo al análisis
estático.

21
Tema 4. Ideas clave
Herramientas de revisión de código (Security Review)

Las herramientas de análisis de seguridad estáticas usan muchas de las mismas
técnicas encontradas en otras herramientas, pero su objetivo está más enfocado a
identificar problemas de seguridad por lo que aplican estas técnicas de manera
diferente.

Para una herramienta de comprobación de propiedades, buscando potenciales
vulnerabilidades de desbordamiento de buffer habría que comprobar la propiedad
«el programa no tiene acceso a una dirección fuera de los límites de memoria
asignada». Las herramientas de seguridad generalmente no pueden heredar la
tendencia de las herramientas de bug finding de reducir al mínimo los falsos positivos
a cargo del aumento de falsos negativos. Se inclinan al lado de la precaución e indican
las partes de código que deberían ser sujetas a revisión manual. Esto quiere decir que
su salida todavía requiere (también las herramientas bug finding requieren revisión
posterior) el repaso humano y lo mejor es aplicar su empleo como una parte de un
proceso de revisión de código.

Fortify Software e IBM, fabrican herramientas de análisis estático de código que
caen dentro de esta categoría.

Consulta más información sobre estas herramientas en:
https://www.microfocus.com/es‐es/products/static‐code‐analysis‐sast/overview

En la práctica lo importante es que estas herramientas suministran importantes
resultados. El hecho de que sean imperfectas no les impide tener un valor
significativo. Los factores principales prácticos que determinan la utilidad de una
herramienta de análisis estático son:

22
Tema 4. Ideas clave
 La capacidad de la herramienta para comprender el programa que se analiza.
 El equilibrio que la herramienta hace entre la precisión, la profundidad y la
escalabilidad.
 Porcentaje de falsos positivos y falsos negativos de la herramienta.
 El conjunto de errores que la herramienta comprueba.
 Las características de la herramienta para hacerla fácil de usar

Arquitectura de las herramientas de análisis estático de código

Independientemente de las técnicas de análisis usadas, todas las herramientas de
análisis estático funcionan aproximadamente del mismo modo, tal y como se muestra
en la figura siguiente. Todas aceptan el código, construyen un modelo (abstracción
del código, modelo de autómata de estado finito, etc.) que representa el programa,
analizan dicho modelo en combinación con una base de conocimiento de seguridad
y terminan presentando sus resultados al usuario.

Figura 11. Diagrama de bloques para una herramienta genérica de análisis de código.

Hay algunas técnicas importantes y estructuras de datos que comparten
compiladores y las herramientas de análisis estático, como son los componentes que
tienen la mayoría de los compiladores:

 Analizador léxico. Constituye la primera fase de la herramienta que consistente
en un programa que recibe como entrada el código fuente de otro programa
(secuencia de caracteres) y produce una salida compuesta de símbolos
23
Tema 4. Ideas clave
(componentes léxicos). Estos símbolos sirven para una posterior etapa del proceso
de traducción, siendo la entrada para el analizador sintáctico. Realiza además
funciones como eliminar espacios en blanco, saltos de línea, tabuladores, ignorar
comentarios, detección y recuperación de errores.

 Analizador sintáctico. Convierte la entrada de componentes léxico de la etapa
anterior en una estructura del árbol, más útil para el posterior análisis y capturan
la jerarquía implícita de la entrada.

 Analizador semántico. Utiliza la entrada el árbol sintáctico creado por el análisis
sintáctico para comprobar restricciones de tipo y otras limitaciones semánticas.

 Estructuras de datos como las tablas de símbolos y de tipos. Es una estructura de
datos donde cada símbolo en el código fuente de un programa se le asocia
información como la ubicación, tipo de datos y ámbito de cada variable, constante
o procedimiento.

Las herramientas de análisis estático realizan varios tipos de análisis:

 Análisis estructural. Realiza comprobaciones de los detalles de la gramática y la
sintaxis del texto de programa creando una estructura de datos denominada
árbol de sintaxis abstracto (AST). Con la tabla de símbolos, realiza la
comprobación de tipos typechecking.

 Análisis de flujo de control. Exploración de los diferentes caminos de ejecución
que se pueden seguir cuando una función se ejecuta.

 Análisis de flujo de datos. Examinan los caminos de movimiento de datos a través
de un programa, por lo general atraviesan el gráfico de flujo de control de una
función y anotan dónde se generan los valores de datos y dónde se usan.

24
Tema 4. Ideas clave
 Taint Propagation. Análisis de flujo de datos para determinar qué es lo que un
atacante puede controlar desde las diversas entradas a la aplicación. Se requiere
saber por dónde entra la información en el programa y cómo se mueve a través
de él. Mediante esta técnica se encuentran muchos defectos de validación de
entrada y representación.

 Pointer Aliasing. Los alias de los punteros son otra clase de problema del flujo de
datos. La finalidad del análisis de alias es determinar qué punteros apuntan a la
misma posición de memoria.

 Análisis local. Analiza una función individualmente en cuanto a posibles caminos
de ejecución eliminando los caminos falsos, que son caminos por los cuales el
código nunca puede ejecutarse porque son lógicamente incoherentes.

 Análisis global. Este análisis requiere hacer comprobaciones de las interacciones
entre las funciones.

 Interpretación abstracta. Es una técnica general formalizada para descartar los
aspectos del programa que no son relevantes, modelando el programa como una
máquina abstracta consistente en una caracterización matemática que recopila
información sobre el flujo de control y de los datos del mismo simulando su
comportamiento.

 Transformadores de predicados. Una alternativa a la simulación es derivar los
requisitos que una función impone a sus llamadores. Trabajando hacía atrás desde
la última sentencia del programa hasta la primera, la postcondición se
transformará en la precondición mediante los predicados de transformación que
abstraen los detalles del programa y crean un conjunto de requisitos que el
programa impone al llamador.

25
Tema 4. Ideas clave
 Model checking. Para propiedades temporales de seguridad como «la memoria
solo debería ser liberada una vez» y «solo los punteros no nulos deberían ser
referenciados» es fácil representarlas como pequeños autómatas de estado finito.

 SAT Solvers. El denominado problema «boolean satisfacibility» consiste en
averiguar si dada una expresión, hay alguna combinación en los valores de las
variables de la expresión que hagan la expresión TRUE.

Ejemplos de herramientas de análisis estático de código fuente

A continuación, se van a enumerar algunas de estas herramientas tanto comerciales
como libres (open source) para lenguajes como C/C++ y java, aunque las herramientas
comerciales soportan varios lenguajes más. Las herramientas libres son en la mayoría
de los casos, proyectos de investigación de universidades. Este apartado se limita a
enumerar algunas de ellas indicando su tipo de licencia y lenguajes que es capaz de
revisar.

Herramienta Licencia Lenguajes
1 SCA de Fortify software de HP, Comercial C, C++, Java y otros
2 AppScam de IBM. Comercial C, C++, Java y otros
3 Prevent de Coverity, Comercial C, Java y otros
4 K8 Inshight de Klocwork, Comercial C, Java y otros
5 VERACODE SaaS C, Java y otros
6 CXSUITE (CHECKMARX) Comercial C, Java y otros
7 CodeSonar de Grammatech, Comercial C, C++
9 SATURN de Stanford University. Libre C
10 BOOP (C) de Graz University of technology. Libre C
11 Magic de Carnegie Mellon University. Libre C
12 Jtest de Parasoft, Comercial Java

13 FindBugs de Maryland k, Libre Java
14 LAPSE (J2EE) de Stanford University y Libre Java
UC3M.
15 Java PathFinder. Libre Java
16 Cppcheck Libre C,C++
26
Tema 4. Ideas clave
17 Polyspace de Mathworks. Comercial C , ada
18 Pc‐lint de Gimpel Sotfware, Comercial C, C++
Figura 11. Diagrama de bloques para una herramienta genérica de análisis de código.

4.4. Pruebas de penetración

Introducción

Una vez terminada la fase de desarrollo se despliega el sistema, se deben llevar a
cabo muchas de las operaciones o actividades de seguridad relacionadas con la
puesta en marcha de la aplicación para su posterior paso a producción y explotación
por parte de los usuarios. Las actividades de seguridad a realizar en esta fase
comprenden la implementación y comprobación de la eficacia de las salvaguardas,
tanto de tipo software (autenticación p.ej.) como de los dispositivos hardware
(firewall p.ej.), que se derivaron de la actividad de análisis de riesgos realizada en la
fase de diseño.

La comprobación de la eficacia de las salvaguardas implementadas se realiza
principalmente mediante los test de penetración, que tiene como principal
misión verificar cómo el software se comporta y resiste ante diferentes tipos
de ataque.

27
Tema 4. Ideas clave

Figura 12. Test de penetración en el SDLC.

Las pruebas de penetración deben centrarse en aspectos de comportamiento del
software, sus interacciones y vulnerabilidades que no puedan ser detectadas
mediante otras pruebas realizadas fuera del entorno de producción. Deben tratar de
encontrar problemas de seguridad que puedan originarse en su arquitectura y diseño
(frente a errores de codificación que se manifiestan como vulnerabilidades), ya que
este tipo de problema tiende a ser pasado por alto por otras técnicas de prueba.

El plan de pruebas de penetración debe incluir los «peores» escenarios en los que se
puedan reproducir vectores de ataques e intrusiones que se consideran altamente
perjudiciales, como los escenarios de amenazas internas. El plan de pruebas debe
capturar:

 La política de seguridad del sistema se supone que debe respetar o hacer respetar.
 Amenazas previstas.
 Riesgos de seguridad (conducido por casos de abuso, riesgos arquitectónicos y
modelos de ataque).
 Secuencias de ataques probables que se puedan producir.

Los tipos de pruebas empleadas en esta práctica de seguridad básicamente incluyen
la realización de un escaneo de vulnerabilidades para poder identificar la posible
brecha de seguridad del sistema para posteriormente intentar comprometerlo
mediante el uso de una herramienta de explotación automática o la ejecución de un
28
Tema 4. Ideas clave
exploit, de forma manual, contra el mismo. En el caso de ser una aplicación web,
además hay que realizar un «análisis dinámico», DAST, para verificar si existen
vulnerabilidades del tipo inyección SQL, cross‐site scripting, CSRF, inyección de
comandos, path traversal etc. Básicamente habría que seguir los siguientes pasos de
forma cíclica hasta comprometer el sistema:

 Revisar información obtenida de los casos de abuso, patrones de ataque y el
modelado de amenazas.
 Identificación de vulnerabilidades en el software. Ejecutar la herramienta de
escaneo de vulnerabilidades.
 Buscar exploits en Internet acordes a las vulnerabilidades encontradas.
 Ejecutar los exploits contra la aplicación objetivo, de forma automática o manual.
 Realizar pruebas DAST en caso de que la aplicación esté construida con tecnologías
Web.
 Realizar pruebas de Fuzzing.


Figura 13. Ejecución pruebas de penetración.

29
Tema 4. Ideas clave
Consideraciones sobre los test de penetración

Una buena parte de los defectos y vulnerabilidades del software directamente no
está relacionada con la funcionalidad de seguridad. Muchas de las cuestiones
relacionadas con la seguridad implican un mal uso de una aplicación, normalmente
inesperado y descubierto por un atacante. Las pruebas de penetración tienen que
verificar los «aspectos negativos» del sistema, es decir se debe probar la seguridad
de la aplicación en base a los riesgos (conducido por casos de abuso, riesgos
arquitectónicos y modelos de ataque) para determinar cómo se comporta ante los
ataques.

Son pruebas de caja negra. En cualquier caso, la prueba de aspectos negativos es un
desafío mucho mayor que la verificación de un aspecto positivo. Un conjunto de
pruebas positivas satisfactoriamente ejecutadas, por lo general da un alto grado de
confianza de que el software realizará funcionalmente su trabajo como se desea. Sin
embargo, enumerar acciones con la intención de producir un fallo y determinar bajo
qué circunstancias este ocurre es más complicado. Es realmente fácil probar si un
componente funciona adecuadamente o no, pero es muy difícil demostrar si
realmente un sistema es seguro a un ataque malévolo.

Si la realización de pruebas para detección de aspectos negativos no revela ningún
defecto, estas únicamente demuestran que ningún defecto ocurre en las condiciones
particulares de esas pruebas, en ningún caso demuestran que ningún defecto existe.
Cuando se realizan pruebas de penetración que detectan pocas o ninguna
vulnerabilidad de seguridad, quiere decir que la ejecución de esas pruebas
proporciona muy poca seguridad de que una aplicación es inmune ante ataques.
Uno de los problemas principales con el acercamiento más común actual de este tipo
de pruebas es un malentendido de este punto sutil.

Las pruebas de penetración de forma general las más aplicadas de todas las mejores
prácticas de seguridad del software, y suelen ser parte del proceso de aceptación
30
Tema 4. Ideas clave
de final. A causa de restricciones de tiempo, la mayor parte de este tipo de
evaluaciones son realizadas de forma apresurada como un punto de la lista de
comprobación de seguridad al final del ciclo de vida.

Una vez que una aplicación está terminada, está sujeta a las pruebas de penetración
como parte del proceso de aceptación de final. A causa de restricciones de tiempo,
la mayor parte de evaluaciones como estas son realizadas de forma apresurada como
un artículo de lista de comprobación de seguridad al final del ciclo de vida.

Una limitación principal de este acercamiento es que casi siempre representa una
tentativa «demasiado corta y muy tardía» para abordar el problema de la seguridad
al final del ciclo de desarrollo.

Como se ha visto, la seguridad de software es una característica inesperada del
sistema, y el logro de ello implica la aplicación de una serie de touchpoints (mejores
prácticas en todas las fases del ciclo de vida del software. Las organizaciones que
fallan en integrar la seguridad en todas partes del proceso de desarrollo se
sorprenden, normalmente de manera desagradable, de encontrar que su software
sufre de defectos sistemáticos tanto a nivel de diseño como en la puesta en práctica.
En una fase tardía del ciclo de vida, como las pruebas de penetración, los problemas
internos del código son destapados demasiado tarde y las opciones para el remedio
conllevan restricciones tanto de tiempo, como de presupuesto.

La solución de problemas en esta etapa es, la mayoría de las veces, prohibitivamente
cara y casi siempre implica tiritas en vez de curas. Las medidas que se toman después
de las pruebas de penetración tienden a ser en particular reactivas y defensivas, por
ejemplo, ajustando el conjunto de reglas de un firewall.

El verdadero valor de las pruebas de penetración viene de sondar un sistema en su
ambiente final de operación. El entendimiento del ambiente de ejecución y de los
problemas de configuración es el mejor resultado de cualquier prueba de
penetración. Esto es así, sobre todo, porque estos problemas pueden ser
31
Tema 4. Ideas clave
solucionados en realidad tarde en el ciclo de vida. El saber si realmente un servidor
de aplicaciones Websphere está correctamente instalado y que un cortafuegos
funciona correctamente es tan importante para la seguridad final como lo puede ser
la creación de código seguro. Las pruebas de penetración llegan al corazón del
entorno de ejecución y de los aspectos de configuración rápidamente. (De hecho,
su debilidad está en la incapacidad de seguir más allá de estos aspectos con eficacia.).

El éxito de una prueba de penetración depende de muchos factores, pocos de los
cuales se prestan a la métrica y la estandarización. La primera variable y más obvia es
la habilidad, el conocimiento, y la experiencia del probador. Las pruebas de
penetración de seguridad de software (pruebas de penetración, a veces llamadas de
aplicación) actualmente no siguen un proceso estándar de ninguna clase y por lo
tanto no son en particular cuidadosas con una aplicación constante de conocimiento
(pensar en listas de comprobación). El resultado es que solo los probadores expertos
y experimentados pueden realizar pruebas de penetración satisfactoriamente.

El empleo en esta práctica de seguridad de los requisitos de seguridad, casos de
abuso, el conocimiento de riesgo de seguridad y el modelo de ataque en el diseño de
aplicación, es poco corriente en la práctica. Por consiguiente, las conclusiones de
seguridad no son repetibles a través de equipos diferentes y varían extensamente
dependiendo de la habilidad y la experiencia de los probadores. Además, cualquier
régimen de prueba puede ser estructurado de tal modo que influya en las
conclusiones. Si los parámetros de prueba son determinados por individuos no
motivados (deliberadamente o no) para encontrar problemas de seguridad, es muy
probable que las pruebas de penetración acaben en un ejercicio propio de inutilidad.

La interpretación de resultados es también una actividad importante. Típicamente
los resultados toman la forma de una lista de defectos, bugs, y vulnerabilidades
identificadas durante las pruebas de penetración. Las organizaciones de desarrollo
de software tienden a considerar estos resultados como listas de defectos de
seguridad para consultar y conseguir un sistema seguro. En la práctica, una prueba
de penetración puede identificar solo una pequeña muestra representativa de todos
32
Tema 4. Ideas clave
los riesgos de seguridad posibles en un sistema (sobre todo aquellos problemas que
son del entorno de ejecución o implican la configuración operacional). Si una
organización de desarrollo de software se centra únicamente en una pequeña y
limitada lista de problemas de seguridad, se terminará por mitigar solo un
subconjunto del total de riesgos de seguridad y posiblemente no aquellos que
presentan el mayor riesgo.

Todos estos problemas palidecen en comparación con el problema de que las
pruebas de penetración a menudo son usadas como una excusa para declarar la
victoria de seguridad «y ya está todo hecho». Lamentablemente, las pruebas de
penetración realizadas sin basarse en el análisis de riesgos de seguridad conducen
a una falsa sensación de seguridad.

Una gran ventaja de las pruebas de penetración que bien merece mencionarse es que
se posicionan como pruebas de tipo de caja negra. Tomando un sistema en su
verdadero ambiente de producción, los analistas de seguridad pueden llegar a
descubrir problemas operacionales y de configuración, normalmente pasados por
alto durante el desarrollo de software.

Herramientas para test de penetración

Uso de herramientas para realizar las pruebas de penetración. Normalmente, la
realización de este tipo de pruebas de caja negra engloba la realización de otros tipos
de pruebas:

 Escaneo de vulnerabilidades.
 Explotación de vulnerabilidades.
 Fuzz testing.
 Análisis dinámico (DAST) para aplicaciones web.

Con las herramientas de escaneo de vulnerabilidades se encuentran vulnerabilidades
conocidas con poco esfuerzo, que aprovechan las herramientas de explotación de
33
Tema 4. Ideas clave
vulnerabilidades. Las herramientas de análisis dinámico y de fuzzing pueden
observar cómo se ejecuta un sistema, pueden someter los datos mal formados,
malévolos y arbitrarios en los puntos de entrada del sistema en una tentativa de
destapar fallos. Los defectos se reportan al personal de prueba para su análisis.
Cuando es posible, el empleo de estas herramientas se debe dirigir por los resultados
de análisis de riesgo y los modelos de ataque. El empleo de herramientas tiene dos
ventajas principales.

 Cuando se usan con eficacia, se puede realizar la mayoría del trabajo necesario
para pruebas de penetración de software básicas (en la capa de presentación de
un sistema). Desde luego, un acercamiento conducido por herramientas no puede
ser usado como un reemplazo de la revisión de un analista de seguridad experto
(sobre todo porque las herramientas de hoy son en su naturaleza no aplicables en
el nivel de diseño), pero un acercamiento a base del empleo de herramientas
realmente ayuda a aliviar la carga de trabajo de un revisor y así puede bajar el
coste.

 La salida de una herramienta se presta fácilmente a la métrica. Los equipos de
desarrollo de software pueden usar esta métrica para rastrear la tendencia y el
progreso con el tiempo y dirigirse hacia un objetivo de seguridad. Unas métricas
simples, en el uso común de hoy en día, no ofrecen una visión completa del estado
de la seguridad de un sistema. Así es importante acentuar que el certificado de
buen estado de salud de una herramienta de análisis no significa que un sistema
esté libre de defectos.

El valor reside en la siguiente comparación: si la actual ejecución de la herramienta
revela menos defectos que previas ejecuciones, probablemente se ha progresado.

Recomendaciones sobre los test de penetración

 Realizar los test más de una vez.
 Realimentación del resultado de las pruebas de penetración.
34
Tema 4. Ideas clave
 Utilización de pruebas de penetración para evaluar aplicaciones COTS.

4.5. Operaciones de seguridad

Introducción

El proceso final para llevar a cabo, previo al paso a producción de la aplicación segura,
se compone de las actividades centrales de:

 Distribución.
 Despliegue.
 Operaciones.

Figura 14. Operaciones seguridad.

Distribución

El objetivo de distribución segura es reducir al mínimo las posibilidades de
acceso y manipulación del software durante la transmisión de un proveedor a
su consumidor (envío a través de medios físicos o descarga de red) por los
agentes maliciosos.

35
Tema 4. Ideas clave
A la hora de realizar la distribución y despliegue del software desarrollado, es
recomendable el realizar las siguientes buenas prácticas:

 Cambio de los valores de configuración predeterminados durante el desarrollo.
 Utilizar mecanismos de distribución estándar como los utilizados en los derechos
de propiedad intelectual.
 Distribuir el software con una configuración por defecto segura y lo más restrictiva
posible.
 Realizar una guía de configuración de seguridad.
 Proporcionar una herramienta de instalación automática.
 Establecer un medio de autenticación para la persona que va a ejecutar la
instalación y configuración.
 Los interfaces de configuración proporcionados por la herramienta o el script de
instalación deben ser seguro.
 Revisión y limpieza de todo el código fuente por el visible usuario (por ejemplo,
código del cliente de aplicaciones web).

Despliegue

Una configuración cuidadosa y la personalización del entorno de despliegue de
cualquier aplicación de software pueden mejorar enormemente su seguridad. El
diseño de un entorno de despliegue adaptado para una aplicación requiere de un
proceso:

 Comienza en el nivel de componente de red
 Continúa por el sistema operativo y otro software de base como puede ser un
gesto de base de datos, etc.
 Termina con la propia configuración de seguridad de la aplicación y el sistema.

El software puede haber sido diseñado y desarrollado para ser
extremadamente seguro, pero no lo será si sus parámetros de configuración
no se establecen como el diseñador lo diseñó. De manera similar, los
36
Tema 4. Ideas clave
parámetros de configuración de su entorno de ejecución deben ajustarse de
modo que el software no sea innecesariamente expuesto a amenazas
potenciales, a esta tarea se le denomina «bastionado».

Figura 15. Capas del sistema a proteger.

El bastionado del software comprende los procesos y herramientas necesarias para
realizar el control y corrección de los defectos y debilidades de las configuraciones
del software sobre la base de un proceso de control de configuración. En España el
Centro Criptológico Nacional (CCN) y en Estados Unidos el departamento de Defensa
y otros departamentos elaboran directrices de configuración seguras y listas de
control para productos de software comercial, podemos encontrar algunas en:

 Centro Criptológico Nacional (CCN): https://www.ccn‐cert.cni.es/
 NIST Listas de comprobación de configuración de productos TIC:
http://web.nvd.nist.gov/view/ncp/repository

37
Tema 4. Ideas clave
Operaciones

Muchos desarrolladores de software argumentan que la distribución, despliegue y
operaciones no son parte del proceso de desarrollo de software. Hay que ajustar los
controles de acceso a la red y niveles del sistema operativo, así como diseñar un
sistema de registro de eventos, de monitorización, de backup y recuperación de los
sistemas de ficheros que será lo más eficaz durante operaciones de respuesta ante
incidentes. Los ataques llegarán y estar preparado para defenderse de ellos y para
deshacer el daño ocasionado después de que un ataque ha tenido lugar.

4.6. Revisión externa

Un análisis externo por personal ajeno al equipo de diseño es bastante eficaz y
fundamental aportando otra visión de la seguridad del sistema y del riesgo y
contribuyendo a una mejora de la seguridad porque seguramente este análisis va a
descubrir alguna amenaza y riesgo residual existente. Después, terminado el análisis
externo habrá que revisar el análisis de riesgos y si hay nuevas amenazas y riesgos
gestionarlos para que sean mitigados y si es necesario realizar cambios en la
arquitectura hardware y software, realizar cambios en el código y por tanto repetir
la revisión del mismo, los test de seguridad basados en el riesgo que ha cambiado y
volver después del despliegue de la aplicación a pasar los test de penetración.

38
Tema 4. Ideas clave
Figura 16. Revisión externa.

Esto conforma un esquema de seguridad en el ciclo de vida de carácter cíclico en el
que es posible que se tengan que realizar varias veces el mismo tipo de actividades
consecuencia de la naturaleza cambiante y de continua evolución de las aplicaciones
y también del carácter cíclico de los distintos ciclos de vida de desarrollo de
aplicaciones donde en muchos casos se van refinando prototipos, que evolucionan
hasta conseguir el sistema final.

39
Tema 4. Ideas clave
Vídeo: Análisis estático de código

En este vídeo se van a analizar los tipos y categorías de herramientas disponibles,
tanto comerciales como de open source, para qué lenguajes están disponibles, cómo
y cuándo se tienen que utilizar y cómo se enmarca el uso de estas herramientas en el
proceso de revisión del código.

Accede al vídeo a través del aula virtual

4.7. Referencias bibliográficas

Allen, J. H.; Barnum. S.; Ellison, R. J.; McGraw, G.; Mead, N. R. (2008). Software
Security Engineering: A Guide for Project Managers. Addison Wesley Professional.

Bermejo, J. R. y Díaz, G. (2015). Estudio de Técnicas Automáticas de Análisis de
Vulnerabilidades de Seguridad en Aplicaciones Web. UNED.

Barnum, S. y Sethi, A. (2007). Attack Patterns as a Knowledge Resource for Building
Secure. Software Cigital, Inc. https://capec.mitre.org/documents/Attack_Patterns‐
Knowing_Your_Enemies_in_Order_to_Defeat_Them‐Paper.pdf

40
Tema 4. Ideas clave
Barnum, S. (2008). Common Attack Pattern Enumeration and Classification (CAPEC)
Schema Description. Department of Homeland Security EE. UU. Software Cigital.
https://capec.mitre.org/documents/documentation/CAPEC_Schema_Description_v
1.3.pdf

Chess, B., and West, J. (2007). Secure Programming with Static Analysis. Addison‐
Wesley Software Security Series.

Donald, G. (2003). Software Engineering Institute, U.S.A. Security Use Cases. Journal
of Object Technology.

Goertzel, K. M. y Winograd, T. (2008). Enhancing the Development Life Cycle to
Produce Secure Software, Version 2.0. United States Department of Defense Data and
Analysis Center for Software.
https://www.seas.upenn.edu/~lee/09cis480/papers/DACS‐358844.pdf

Graff, M. G. y Van Wyk, K. R. (2003). Secure Coding: Principles & Practices. O'Reilly.

Guttorm Sindre, A. y Opdahl, L. Capturing Security Requirements through Misuse
Cases.
https://www.researchgate.net/publication/228605351_Capturing_security_require
ments_through_misuse_cases

Hoglund. (2004). Exploiting Software: How to Break Code, By G. Hoglund and G.
McGraw. Addison‐Wesley Software Security Series.

Howard, M. y LeBlanc, D. (2003). Writing Secure Code. Microsoft Press.

Howard, M. y Lipner, S. (2006). The Security Development Lifecycle: SDL: A Process for
Developing Demonstrably Secure Software. Microsoft Press.

41
Tema 4. Ideas clave
Komaroff, M. y Baldwin, K. (2005). DoD Software Assurance Initiative.
http://www.acqnotes.com/Attachments/DoD%20Software%20Assurance%20Initiati
ve.pdf

López, S. (2012). Descubriendo el valor de la Seguridad en las Aplicaciones Web con
IBM AppScan. IBM Corporation.

McGraw, G. (2005). Software Security: Building Security In. Addison Wesley
Professional.

Microsoft Corp (2010). Simplified Implementation of the Microsoft SDL.
http://www.microsoft.com/en‐us/download/details.aspx?id=12379

Redwine Jr., S. T. (Editor). (2006). Software Assurance: A Guide to the Common Body
of Knowledge to Produce, Acquire, and Sustain Secure Software Version 1.1. US
Department of Homeland Security.

Sroka, D. Presentación HP Fortify User Training.

Yuan, Xiaohong y Nuakoh, Emmanuel y Williams, Imano y Yu, Huiming. (2015).
Developing Abuse Cases Based on Threat Modeling and Attack Patterns. Journal of
Software, 10, 491‐498. 10.17706/jsw.10.4.491‐498.

Wyk, G. (2003). Secure Coding: Principles & Practices. O'Reilly.

42
Tema 4. Ideas clave
A fondo
Implementación simplificada del proceso SDL

Microsoft (2010). Implementación simplificada del proceso SDL de Microsoft.

http://www.microsoft.com/en‐us/download/details.aspx?id=12379

El documento describe los conceptos básicos del Microsoft Security Development
Lifecycle (SDL) y las actividades de seguridad individuales en cada una de sus fases.

Secure Development Lifecycles (SDLC): Introduction and Process Models ‐ Bart De
Win

Jossie. (24 de junio de 2009). Security Design Reviews [Vídeo]. Channel19.
https://www.youtube.com/watch?v=L‐gL1YQUrwg

Se necesita mucho más que un buen desarrollador para construir software seguro
dentro de una organización. De hecho, la creación de software seguro consiste en
garantizar que la seguridad se tenga en cuenta durante todo el ciclo de vida del
software. Se trata de garantizar que las mejores prácticas de seguridad se empleen
de manera eficiente y que los riesgos descubiertos se aborden adecuadamente y a su
debido tiempo.
43
Tema 4. A fondo

En esta sesión, se presenta una visión general de los modelos SDLC de última
generación para discutir los fundamentos y las piedras angulares de estos modelos.
Esto ayudará a los participantes a comprender el alcance y los diferentes conceptos
de estos modelos. Se incluirá la perspectiva de los modelos de cascada y de desarrollo
ágil para explicar estos modelos.

A systemic approach for assessing software supply‐chain risk

Dorofee, A., Woody, C., Alberts, C., Creel, R. y Ellison, R.J. (2013). A systemic approach for
assessing software supply‐chain risk. En Cybersecurity & Infrastructure Security Agency
[Web]. https://us‐cert.cisa.gov/bsi/articles/best‐practices/acquisition/a‐systemic‐
approach‐assessing‐software‐supply‐chain‐risk

Esta guía proporciona información sobre cómo incorporar prácticas de
aseguramiento del software durante todo el proceso de adquisición durante las fases
de planificación de la contratación de la adquisición, supervisión y aceptación, y
seguimiento.

44
Tema 4. A fondo
Practical measurement framework for software assurance and information security

Bartol, N. (Ed.) y Hamilton, B.A., et al. (2008). Practical measurement framework for
software assurance and information security. En Practical Software & Systems
Measurement [Web].
http://www.psmsc.com/Downloads/TechnologyPapers/SwA%20Measurement%2010‐
08‐08.pdf

Documento de métricas de medidas de seguridad del software e información que
proporciona un método para medir la eficacia de las medidas de seguridad a nivel
organizacional programa o proyecto.

A Few Billion Lines of Code Later

Bessey, A. et al. (2010). A Few Billion Lines of Code Later: Using Static Analysis to Find
Bugs in the Real World. Communications of the ACM, Vol. 53 No. 2, 66‐75.
http://cacm.acm.org/magazines/2010/2/69354‐a‐few‐billion‐lines‐of‐code‐
later/fulltext

Artículo realizado por el equipo de Coverity que describe la experiencia e
implementación de una herramienta de análisis estático comercial.

45
Tema 4. A fondo
Security Controls for Computer Systems

Ware, W.H. (1979). Security Controls for Computer Systems
Report of Defense Science Board Task Force on Computer Security. RAND Corporation
http://www.rand.org/pubs/reports/R609‐1/index2.html

Artículo que introduce la idea de las pruebas de penetración, así como muchas otras
ideas fundacionales de seguridad de los sistemas.

Vsftpd. Probably the most secure and fastest FTP server for UNIX‐like systems

Vsftpd [Web]. https://security.appspot.com/vsftpd.html#docs

FTPD seguro, en estos documentos se presenta una descripción del diseño e
implementación de programa Vsftpd.

Synopsys

Synopsis [Web]. https://resources.synopsys.com/


Sitio web de la empresa SYNOPSYS creada partir de la empresa CIGITAL Inc. con
recursos, libros, vídeos y artículos sobre seguridad del software.

46
Tema 4. A fondo
Armitage

Armitage [Web]. http://www.fastandeasyhacking.com/

Sitio web para descargarse este programa que implementa una interfaz gráfica de la
herramienta de penetración metaexploit. Contiene manuales y vídeos de uso de esta
herramienta.

NMAP

Nmap.org [Web]. http://nmap.org/

Escáner que proporciona información de puertos abiertos, versiones de sistemas
operativos, etc.


47
Tema 4. A fondo
Zap

The OWASP ZAP core project. Zaproxy. GitHub [Web].

https://github.com/zaproxy/zaproxy

Escáner de vulnerabilidades de aplicaciones web, desarrollado en el marco del
Proyecto OWASP.

Burp suite

Portswigger [Web]. http://portswigger.net/burp/

Escáner de vulnerabilidades de aplicaciones web que dispone de una versión libre y
otra de pago.

48
Tema 4. A fondo
Coverity Scan initiatives

Coverity [Web]. https://scan.coverity.com/

Herramienta de análisis estático para lenguaje C y C++.

Joern

Joern [Web]. http://www.mlsec.org/joern/

Herramienta de análisis estático para lenguaje C y C++.
FindBugs

FindBugs [Web]. http://findbugs.sourceforge.net/


Herramienta de análisis estático para lenguaje Java.

49
Tema 4. A fondo
Bibliografía
Allen, J. H.; Barnum, S.; Ellison, R. J.; McGraw, G.; Mead, N. R. (2008). Software
Security Engineering: A Guide for Project Managers. Addison Wesley Professional.

Chess, B. and West, J. Secure Programming with Static Analysis. Addison‐Wesley
Software Security Series.

Fernandez‐Buglioni, E. (14 mayo 2013). Security Patterns in Practice: Designing
Secure Architectures Using Software Patterns. Wiley Software Patterns Series.

Hoff, J. y Chapple, M. (2014). Securing the SDLC for Dummies®, WhiteHat Security
Edition. John Wiley & Sons, Inc.

Howard, M. and LeBlanc, D. (2003). Writing Secure Code. Microsoft Press.

Howard, M. and Lipner, S. (2006). The Security Development Lifecycle: SDL: A Process
for Developing Demonstrably Secure Software. Microsoft Press.

Krassowski, A. and Meunier, P. (2008). Secure Software Engineering: Designing,
Writing, and Maintaining More Secure Code. Addison‐Wesley.

McGraw, G. (2005). Software Security: Building Security In. Addison Wesley
Professional.

Ransome, J y Misra, A. (2013). Core Software Security: Security at the Source.
Auerbach Publications.

Redwine, S. T. Jr. (Editor). (2006). Software Assurance: A Guide to the Common Body
of Knowledge to Produce, Acquire, and Sustain Secure Software Version 1.1. US
Department of Homeland Security.

50
Tema 4. A fondo
Shostack, A. (17 febrero 2014). Threat Modeling: Designing for Security. John Wiley
& Sons Inc.

Takanen, A., Demott, J. D. y Miller, C. (2018). Fuzzing for Software Security Testing
and Quality Assurance (2nd Edition). Artech House
51
Tema 4. A fondo
Test
1. Señala la respuesta correcta. Las perspectivas de las pruebas de seguridad
basadas en el riesgo son las siguientes:
A. Perspectiva gerencia.
B. Perspectiva atacante.
C. Perspectiva usuario.
D. Perspectiva del analista.

2. Señala la respuesta correcta. El principal problema de las herramientas de análisis
estático son:
A. Falsos negativos que produce.
B. Gran cantidad de defectos que encuentra.
C. Reglas de la herramienta.
D. Falsos positivos que produce.

3. Señala la respuesta incorrecta. Las herramientas de análisis estático realizan
varios tipos de análisis:
A. Taint Propagation.
B. Análisis puntual.
C. Model checking.
D. Análisis de flujo de datos.

4. Señala la respuesta incorrecta. Los test de penetración:
A. En ningún caso demuestran que ningún defecto existe.
B. Revisan el código.
C. El entendimiento del ambiente de ejecución y de los problemas de
configuración es el mejor resultado de cualquier prueba de penetración.
D. Las conclusiones de seguridad no son repetibles a través de equipos
diferentes y varían extensamente dependiendo de la habilidad y la experiencia
de los probadores.
52
Tema 4. Test
5. Señalar la respuesta correcta. A la hora de realizar la distribución y despliegue del
software desarrollado, es recomendable el realizar las siguientes buenas
prácticas:
A. Distribuir el software con una configuración por defecto segura y lo más
restrictiva posible.
B. Proporcionar una herramienta de instalación automática.
C. Cambio los valores de configuración predeterminados durante el desarrollo.
D. Todas las anteriores.

6. Señala la respuesta incorrecta. Los objetivos de las pruebas de seguridad basadas
en el riesgo son:
A. Verificar la operación del software bajo en su entorno de producción.
B. Verificar la capacidad de supervivencia del software ante la aparición de
anomalías, errores y su manejo de las mismas mediante excepciones que
minimicen el alcance e impacto de los daños que puedan resultar de los
ataques.
C. Verificar la falta de defectos y debilidades explotables.
D Verificar la fiabilidad del software, en términos de comportamiento seguro y
cambios de estado confiables.

7. Señalar la respuesta incorrecta. El análisis estático de código fuente es adecuado
para identificar problemas de seguridad por ciertas razones:
A. Las herramientas de análisis estático comprueban el código a fondo y
coherentemente, sin ninguna tendencia, que a veces los programadores según
su criterio podrían tener sobre algunas partes del código que pudieran ser más
«interesantes» desde una perspectiva de seguridad o partes del código que
pudieran ser más fáciles para realizar las pruebas dinámicas
B. Examinando el código en sí mismo, las herramientas de análisis estático a
menudo pueden indicar la causa de origen de un problema de seguridad, no
solamente uno de sus síntomas.
53
Tema 4. Test
C. Cuando un investigador de seguridad descubre una nueva variedad de
ataque, las herramientas de análisis estático, no ayudan a comprobar de nuevo
una gran cantidad de código para ver dónde el nuevo ataque podría tener éxito.
D. El análisis estático puede encontrar errores tempranamente en el desarrollo,
aún antes de que el programa sea ejecutado por primera vez.

8. Señalar la respuesta correcta. La principal misión de los test de penetración es:
A. Revisar estáticamente el código del sistema.
B. Comprobar las vulnerabilidades del software.
C. Verificar cómo el software se comporta y resiste ante diferentes tipos de
ataque.
D. Probar la seguridad de la arquitectura del software.

9. Indicar la respuesta incorrecta. Los factores principales prácticos que determinan
la utilidad de una herramienta de análisis estático son:
A. El equilibrio que la herramienta hace entre la precisión, la profundidad y la
escalabilidad.
B. Porcentaje de falsos positivos (no de negativos) de la herramienta.
C. Las características de la herramienta para hacerla fácil de usar.
D. La capacidad de la herramienta para comprender el programa que se analiza.

10. Señalar la respuesta correcta. Una herramienta de análisis de código reporta que
existe una vulnerabilidad de inyección SQL. Sin embargo, después de la
correspondiente verificación, se comprueba que en realidad no existe tal
vulnerabilidad. ¿Qué tipo de limitación de las herramientas de análisis de código
se ha expuesto?
A. Un falso positivo.
B. Un falso negativo.
C. Una vulnerabilidad específica de un lenguaje de programación.
D. Ninguna de las anteriores.

54
Tema 4. Test

Tema 4. Seguridad en El Ciclo de Vida Del Software (Ii)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 4. Seguridad en El Ciclo de Vida Del Software (Ii)

Cargado por

Copyright:

Formatos disponibles

Tema

ScanDo. Comercial Windows

programa, tales como excepciones no capturadas, omisiones, errores de

12 Jtest de Parasoft, Comercial Java

Microsoft (2010). Implementación simplificada del proceso SDL de Microsoft.

The OWASP ZAP core project. Zaproxy. GitHub [Web].

También podría gustarte