Tema 2

Seguridad en el ciclo de vida del software
[2.1] ¿Cómo estudiar este tema?
[2.2] Introducción a la seguridad en ciclo de vida del

software (S- SDLC)
[2.3] Seguridad en las fases del S-SDLC
[2.4] Modelado de ataques
[2.5] Casos de abuso
[2.6] Ingeniería de requisitos de seguridad
[2.7] Análisis de riesgo. Arquitectónico
[2.8] Patrones de diseño
[2.9] Pruebas de seguridad basadas en riesgo
[2.10] Revisión de código 2

[2.11] Pruebas de penetración
[2.12] Operaciones de seguridad

TEMA
[2.13] Revisión externa
[2.14] Referencias bibliográficas

Seguridad en el ciclo de vida del software
Esquema
Modelado de Ingeniería y requisitos Test de Operaciones de

Revisión de código
TEMA 2 – Esquema
ataques de seguridad penetración seguridad
Espe cificación de Cue stione s sobre la Arquitectura de Consideraciones

Patrones de ataque Distribución
re quisitos e xplotabilidad de las las herramientas sobre los test de
vulnerabilidades de análisis penetración
Árboles de ataque De splie gue
estático de
Metodología de Herramientas de Uso de
código
ingeniería de revisión de código he rramientas
Ope racione s
2
requisitos para para realizar un
Reglas
software seguro Aspectos prácticos test de
del manejo de las penetración
Análisis estático
he rramientas
Análisis de riesgo de código como
Casos de abuso He rramie ntas
arquitectónico Métricas de análisis parte del
para te st de
estático de código proceso de
pe ne tración
Creación de casos revisión de
Fases del análisis de
de abuso código Recomendacion
riesgos
Ejemplo caso de Ejemplos. es sobre los test
uso de seguridad y Herramientas de penetración
caso de abuso de análisis
estático de
código fuente
© Universidad Internacional de La Rioja (UNIR)

Seguridad en el Software
Aspectos
prácticos de
manejo de las
he rramientas
Ideas clave
2.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que encontrarás a continuación, además de
leer los apuntes elaborados por el profesor.
El objetivo del presente tema es introducirte en las diferentes prácticas de

seguridad a introducir en el SDLC por una organización con el propósito de obtener
software más seguro y confiable, que presente un mínimo de vulnerabilidades y sea
resistente a los ataques provenientes tanto del entorno interior como del exterior.
2.2. Introducción a la seguridad en ciclo de vida del software

(S-SDLC)
Como se ha comentado en el tema anterior, se puede definir la seguridad del software

como:
El conjunto de principios de diseño y buenas prácticas a implantar en el SDLC, para

detectar, prevenir y corregir los defectos de seguridad en el desarrollo y adquisición de
aplicaciones, de forma que se obtenga software de confianza y robusto frente
ataques maliciosos, que realice solo las funciones para las que fue diseñado,
que esté libre de vulnerabilidades, ya sean intencionalmente diseñadas o
accidentalmente insertadas durante su ciclo de vida, de forma que se asegure su
integridad, disponibilidad y confidencialidad.
El aumento de los ataques al software vulnerable ha dejado patente la insuficiencia de

las protecciones a nivel de infraestructura, en este contexto es conveniente el
minimizar al máximo los ataques en la capa de aplicación y por tanto el
número de vulnerabilidades explotables.
TEMA 2 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

Según Gartner dos tercios de las aplicaciones son vulnerables:
Figura 1. Vulnerabilidad aplicaciones. Fuente: Gartner Inc.
El desarrollo de software seguro y confiable requiere la adopción de un proceso

sistemático o disciplina que aborde la seguridad en cada una de las fases de su ciclo
de vida. Se debe integrar en el mismo dos tipos de actividades de seguridad la primea
es el seguimiento de unos principios de diseño seguro (mínimo privilegio, etc.) y la
segunda la inclusión de una serie de buenas prácticas de seguridad
(especificación requisitos seguridad, casos de abuso, análisis de riesgo, análisis de
código, pruebas de penetración dinámicas, etc.). A este nuevo ciclo de vida con
prácticas de seguridad incluidas lo llamaremos S-SDLC.
Una de las principales ventajas de la adopción de un S-SDLC es el descubrimiento

de errores de codificación y debilidades de diseño en sus etapas tempranas
de su desarrollo, lo que implica, tal y como justificamos en la introducción del
primer tema, un importante ahorro de costes.

Figura 2. Ataques capa aplicación. Fuente: Exploiting software: how to break code
Una vez desplegado el software, es fundamental mantener el nivel de seguridad y

confianza, mediante la realización de labores de bastionado del software de base,
gestión de configuración y pruebas de verificación y validación (V&V) como parte de un
proceso de certificación y acreditación que incluya evaluaciones independientes de
terceros.
Poner en funcionamiento prácticas de seguridad del software, que permitan obtener un

software más confiable, requiere hacer algunos cambios en la forma de
construir software en la mayoría de las organizaciones.
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, lo importante no es el modelo seguido, si no
la incorporación de buenas prácticas de seguridad en las diferentes fases
del mismo y unos hitos o puntos de control donde se verifiquen los entregables de
las mismas.
En el apartado siguiente se presenta un conjunto mínimo de prácticas de seguridad,

que deberían ser una parte integral del S-SDLC. Entre las razones principales para
añadir prácticas de seguridad en el SDLC tenemos:
Mayor probabilidad de capturar adecuadamente los requisitos, 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.
El objetivo del presente tema es introducir al alumno en las diferentes prácticas de

seguridad a introducir en el SDLC por una organización con el propósito de obtener
software más seguro, confiable, que presente un mínimo de vulnerabilidades y sea
resistente a los ataques provenientes tanto del entorno interior como del exterior.
2.3. Seguridad en las fases del S-SDLC
La seguridad del software es algo más que la eliminación de las vulnerabilidades y

la realización de pruebas de penetración. Un aspecto importante de la misma es la
adopción por los gerentes de un enfoque sistémico que incorpore los principios de
diseño estudiados en apartados anteriores y unas buenas prácticas de
Seguridad del Software touchpoint en su Ciclo de Vida de Desarrollo. Su
objetivo es producir software más seguro y confiable, así como el poder
verificar su seguridad, a este nuevo ciclo de vida le denominaremos ciclo
de vida del software seguro S-SDLC.
Lo anterior exige mejorar el SDLC al tener que incluir y describir con mayor
profundidad técnica y detallada los principios y prácticas de seguridad que los
desarrolladores de software, evaluadores e integradores tienen que adoptar para lograr
el doble objetivo de producir sistemas con software más seguro y poder
verificar su seguridad.
Las organizaciones que realizan desarrollos de software, como medida de fomento de

la mejora de seguridad en el software, deberían crear una comunidad de desarrollo
seguro, utilizando tecnologías de colaboración y entornos de desarrollo integrado, con
el objetivo de promover un proceso de mejora continua y fomento del uso de
principios de diseño seguro.
No existe una metodología de ingeniería de seguridad de software que haya probado

unos mejores resultados que otras, todas se basan en la inclusión de prácticas
de seguridad fundamentalmente, por tanto, no importa cuál es el modelo de ciclo

de vida seguido. Lo que sí es importante es que la seguridad sea considerada

desde las primeras etapas del ciclo de vida del software.
7. Revisión 8.
5. Patrones
código Configuración
de diseño
11. segura
3. Ing. 6. Pruebas 1. Modelado
2. Casos 4. Análisis de Revisión 9. Test
Requisitos basadas en de ataques
de abuso riesgos externa penetración
seguridad riesgo 10.
Operaciones
seguridad
Requisitos Codificación
Arquitectura Pruebas Distribución Operación y
Casos de e
Diseño y despliegue mantenimiento
abuso integración
REALIMENTACIÓN
Figura 3. Mejores prácticas de seguridad del software en el SDLC.
La figura anterior, propone un ciclo de vida de desarrollo de software SDLC en cascada

basado en el modelo de McGraw (2005), para otro tipo como los iterativos sería
similar, donde se especifican las actividades y prácticas de seguridad a efectuar en cada
fase del mismo. En el siguiente apartado se muestran diferentes tipos de S-SDLC
adoptados por diferentes empresas y organizaciones. A continuación, se enumeran esas
actividades o mejores prácticas de seguridad del software tomando como referencia el
modelo McGraw (2005) al que se le añaden otras:
» Modelado de ataques.
» Casos de abuso.
» Ingeniería requisitos de seguridad.
» Análisis de riesgo arquitectónico.
» Patrones de diseño.
» Pruebas de seguridad basadas en riesgo.
» Revisión de código.
» Test penetración.
» Configuraciones seguras.
» Operaciones de seguridad.
» Revisión externa.

En la tabla siguiente se representan las prácticas de seguridad y su relación en cada una

de las fases donde son aplicables.
Fase SDLC
Req. Dise. Codif. Prueb. Desp. Oper.
Practica de Seguridad
Casos de abuso X
Ingeniería requisitos de seguridad X
Análisis de riesgo arquitectónico X X X X X
Patrones de diseño X
Pruebas de seguridad basados en riesgo X X X X
Modelado de ataques X X X X X X
Revisión de código X
Pruebas de penetración X X
Configuraciones seguras X
Operaciones de seguridad X
Revisión externa X X X
Tabla 1 Relación entre las prácticas de seguridad y las fases del ciclo de vida.
En los siguientes apartados de este tema se desarrollan las prácticas de seguridad

propuestas para el ciclo de vida.
2.4. Modelado de ataques
Introducción
El principal objetivo de la seguridad del software es el mantener sus propiedades

de seguridad frente a los ataques realizados por personal malicioso sobre
sus componentes y reducir al mínimo posible sus vulnerabilidades
explotables.

Para conseguir que el desarrollo de una aplicación posea las propiedades y principios
de diseño del software seguro presentadas en tema 1, se necesita que el personal de
diseño y desarrollo desarrollen dos perspectivas:
El equipo trabaja para construir un software con las propiedades de

Defensor seguridad necesarias para que sea más resistente a los ataques y
minimizar las debilidades y vulnerabilidad
El equipo se esfuerza por comprender la naturaleza exacta de la amenaza

Atacante a la que el software es probable que se enfrente con el fin de concentrar
los esfuerzos defensivos
Figura 4. Perspectivas de modelado.
La perspectiva del atacante se suele modelar de las siguientes dos formas, que
desarrollamos en párrafos posteriores:
» Patrones de ataque.
» Árboles de ataque.
7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 5. Modelado de ataques.
El uso combinado de patrones de ataque y árboles de ataque captura la probabilidad de

cómo los ataques se pueden combinar y secuenciar, esto proporciona una serie
de datos que nos pueden ayudar a diseñar en el software una serie de respuestas
encaminadas a mitigarlos.

Patrones de ataque
Un ataque aprovecha una vulnerabilidad de una aplicación mediante un

exploit, para obtener un beneficio del sistema como escalada de privilegios, robo y
modificación de datos, modificaciones del funcionamiento, denegación de servicio, etc.
Exploit
Del inglés to exploit, explotar o aprovechar. Es una pieza de software, fragmento de
datos o secuencia de comandos y/o acciones, utilizada con el fin de aprovechar una
vulnerabilidad de seguridad de un sistema de información para conseguir un
comportamiento no deseado del mismo. http://es.wikipedia.org
Los patrones de ataque constituyen un mecanismo o medio para capturar y

representar la perspectiva y conocimiento del ciberatacante con el suficiente
detalle acerca de cómo los ataques se llevan a cabo los métodos más frecuentes de
explotación (exploit) y las técnicas usadas para comprometer el software.
En definitiva, constituyen una clasificación de los ataques y una representación

estructurada del pensamiento del atacante, para que el equipo de diseño y
desarrollo obtengan el conocimiento necesario y los pasos a realizar para mitigar con
mayor probabilidad las acciones de los ciberatacantes, reducir su impacto y seleccionar
las políticas de seguridad más convenientes. Derivan del concepto de patrones de
diseño aplicado en un contexto más destructivo que constructivo y están generados a
partir de un análisis en profundidad de determinados ejemplos de exploits del mundo
real.
Un catálogo de patrones de ataques, que proporciona un conjunto de definiciones

comunes, una taxonomía de clasificación, un esquema de patrones de ataque y un
conjunto de ellos reales, la constituye la iniciativa del MITRE Common Attack
Pattern Enumeration and Classification (CAPEC).
Actualmente incluye 519 patrones reales de ataque, disponible en:

http://capec.mitre.org.
Dependiendo del nivel de detalle que describe y su nivel de abstracción, los patrones de
ataque constituyen un recurso que proporciona valor al conjunto del SDLC, dado

que puede tener diferentes utilidades en sus diferentes fases. En la tabla siguiente se
muestra un resumen de los usos de los patrones de ataques en las diferentes fases del
SDLC.
Fase Utilidad
» Ayuda a identificar requisitos.
Especificación » Ayuda a identificar los riesgos a los que hará frente el software.
de requisitos » Ayuda a definir el comportamiento del sistema para prevenir o reaccionar
ante un tipo específico de ataque probable.
» Proporciona ejemplos de ataques que aprovechan las vulnerabilidades de
Diseño y la arquitectura elegida.
arquitectura » Proporcionan el contexto de las amenazas al que el software se va a
enfrentar, de forma que permite diseñar arquitecturas seguras.
Codificación
» Específica debilidades aprovechadas por los ataques, orientando que
técnicas o prácticas de seguridad de desarrollo evitan estas deficiencias.
» Pueden ser utilizados para orientar las pruebas de seguridad del software
Pruebas en un contexto práctico y realista identificando debilidades concretas para
generar casos de prueba para cada componente.
Operación
» Permitirá la selección de políticas de seguridad y configuraciones acordes
a las amenazas obtenidas de los patrones de ataque.
Tabla 2 Aplicación patrones de ataque a las diferentes fases del SDLC.
Un patrón de ataque, como mínimo, debe describir ampliamente el incidente, las

habilidades y recursos necesarios para ejecutarlo con éxito, en qué contextos es
aplicable y proporcionar información suficiente para permitir a los defensores evitar o
mitigar eficazmente las acciones del atacante. En la tabla siguiente se muestran los
ítems de información de los que consta un patrón de ataque obtenido de CAPEC.
Ítem Descripción
Nombre » Identificador descriptivo del patrón de ataque.
Severidad
» En una escala aproximada típica (muy bajo, bajo, medio, alto, muy
alto) de la gravedad del ataque.
» Descripción detallada del ataque incluyendo la cadena de acciones
Descripción tomadas por el atacante. Descripciones más pormenorizadas podría
incluir árboles de ataque.
» Describe las condiciones que deben existir o funcionalidades y
Prerrequisitos del características que el software de destino debe tener y
ataque comportamiento que debe exhibir para que un ataque de este tipo
tenga éxito.
» Es una escala aproximada (Muy Bajo, Medio Bajo, Alto, Muy Alto).
Probabilidad Este campo se utiliza para capturar un valor global promedio típico
típica del exploit para este tipo de ataque, teniendo en cuenta que no será
completamente exacta para todos.
» Describe el mecanismo de ataque utilizado por este patrón. Con el fin
de ayudar en la normalización y clasificación, este campo comprende
Métodos de
una selección de una lista enumerada de definidos vectores. Este
ataque
campo puede ayudar a definir la superficie de ataque requerida por
este ataque.

Ítem Descripción
» Contiene ejemplos explicativos o casos demostrativos de este ataque.
Ejemplos Pretende ayudar al lector a comprender la naturaleza, el contexto y la
variabilidad de la agresión en términos más prácticos y concretos.
Conocimiento y » Describe el nivel de habilidad o conocimiento específico requerido por
habilidades un agente malicioso para ejecutar este tipo de ataque. Se codifica con
requeridas del una escala aproximada (bajo, medio, alto), así como un detalle de
atacante contexto.
Recursos
» Este campo describe los recursos (ciclos de CPU, direcciones IP,
herramientas, etc.) requeridos por un atacante para ejecutar con
requeridos
eficacia este tipo de ataque.
Métodos de
» Describe las técnicas normalmente utilizadas para investigar y
reconocer un blanco potencial, determinar la vulnerabilidad y
prueba
prepararse para este tipo de ataque.
Indicadores de un
» Describe las actividades, eventos, condiciones o comportamientos que
podrían servir como indicadores de que un ataque de este tipo es
ataque
inminente, está en progreso o ha ocurrido.
» Describe acciones o enfoques que pueden potencialmente prevenir o

mitigar el riesgo de este tipo de ataque. Estas soluciones y
Soluciones y mitigaciones están dirigidas a mejorar la resistencia, reduciendo la
mitigaciones probabilidad de éxito del ataque o para mejorar la capacidad de
recuperación del software objetivo, reduciendo el impacto del ataque
si tiene éxito.
Motivación y
» Comprende una selección de una lista enumerada de motivaciones
definidas o consecuencias. Esta información es útil para la alineación
consecuencias del
de patrones de ataque a los modelos de amenaza y para la
ataque
determinación si son relevantes para un contexto dado.
Descripción del
» Describe el contexto en el que este patrón es relevante y aporta más
antecedentes para el ataque. Esta información es útil para una mejor
contexto
comprensión de la naturaleza de este tipo de ataque.
» Describe, lo más exactamente posible, el mecanismo y el formato de
Vector de un ataque. Debe tener en cuenta la gramática de un ataque, la sintaxis
inyección aceptada por el sistema, la posición de varios campos, y los rangos de
datos que son aceptables.
» Describe los datos de código, configuración u otros a ejecutar o
Payload activar, como parte de un ataque con un vector de inyección de este
tipo.
» Describe el área dentro del software de destino que es capaz de

ejecutar o activar de otro modo la carga útil del vector inyección de un
ataque de este tipo. La zona de activación es donde la intención del
Zona de activación
atacante se pone en acción, puede ser un intérprete de comandos, un
código de máquina activa en un buffer, un navegador cliente, una
llamada API del sistema, etc.
Impacto de » Descripción de los efectos que la activación de la carga útil que un
activación del ataque de este tipo tendría típicamente en la confidencialidad,
payload integridad o disponibilidad del software solicitado.
» Describe el impacto de este patrón de ataque en las características de
seguridad estándar confidencialidad, integridad y disponibilidad. Este
Impacto CIA campo se utiliza para capturar un valor global promedio típico para
este tipo de ataque, teniendo en cuenta de que no será completamente
exacta para todos los ataques.

Ítem Descripción
» Qué vulnerabilidades o debilidades puede el ataque explotar. Se
referencia estándar de la industria CWE. Esta lista debe incluir no
Vulnerabilidades solo a las debilidades que están directamente afectados por el ataque,
relacionadas sino que también aquellas cuya presencia pueda directamente
aumentar la probabilidad de éxito del ataque o el impacto si tiene
éxito.
Requisitos de » Identifica los requisitos de seguridad específicos que son relevantes
seguridad para este tipo de ataques y son lo suficientemente generales como
relevantes para ofrecer oportunidades de reutilización.
Principios de
seguridad
» Identifica los principios de diseño de seguridad que son relevantes
para identificar o mitigar este tipo de ataques.
relacionados
Guía relacionadas
» Identifica las directrices de seguridad existentes que son relevantes
para la identificación o mitigar este tipo de ataque.
» Enumera los recursos de referencia que se utilizaron para elaborar la
Referencias definición de este patrón de ataque y los que podrían ser de utilidad
para ampliar la información sobre este ataque.
Tabla 3 Alcance de información de un patrón de ataque.
Árboles de ataque
Un árbol de ataque se puede definir como:
Un método sistemático para caracterizar la seguridad de un sistema, basado en la

combinación y dependencias de las vulnerabilidades del mismo, que un
atacante puede aprovechar para comprometerlo.
En un árbol de ataque, el objetivo del atacante se coloca en la parte superior

del árbol, documentándose las posibles alternativas de ataque en los diferentes
recorridos del árbol, por los nodos de nivel inferior del árbol que contienen objetivos
intermedios, hasta llegar al nivel inferior que contiene los diferentes métodos o técnicas
de ataque. Cada camino a través de un árbol de ataque representa un tipo de ataque
único. Para cada alternativa, se puede añadir recursivamente otras precursoras que
alcancen diversos objetivos parciales que, en conjunto logran el objetivo principal del
atacante.
Mediante el examen de diferentes ramas del árbol de ataque, el analista puede

identificar todas las posibles técnicas o métodos que podrían ser utilizados
para comprometer la seguridad del sistema.

Básicamente:
» Captura los pasos realizados en ataques con éxito.

» Captura métodos generales y específicos del sistema de ataque, propiedades del
sistema y otras condiciones previas que hacen, lo hacen posible.
» Se enfoca en las causas de las vulnerabilidades, pero no identifica las contramedidas.
» Representan de forma gráfica y textual de directrices de codificación segura,
patrones de seguridad.
En la representación de la estructura de un árbol de ataque se realiza conforme a

los dos siguientes tipos:
» Textual: sigue una estructura de esquema numérico, el nodo raíz, o la meta,

representada en el primer nivel sin sangría y cada objetivo de nivel inferior se
enumeran con sangría de una unidad por nivel de descomposición.
Ejemplo:
Objetivo: Falsificar una Reserva de vuelos

1. Convencer al empleado de agregar una reserva falsa
1.1 Chantaje empleado
1.2 Amenazar empleado
2. Acceder y modificar la base de datos de vuelos
2.1 Realizar una inyección SQL en la página Web
2.2 Iniciar una sesión en la base de datos
2.2.1 Adivinar la contraseña
2.2.2 Obtener la contraseña rastreando la red (sniff)
2.2.3 Robar la contraseña del servidor
2.2.3.1 Obtener una cuenta del servidor (AND)
2.2.3.1.1 Desbordamiento de búfer
2.2.3.1.2 Obtener acceso cuenta empleado
2.2.3.2 Explotar condición de carrera acceso
perfil protegido
» Grafica o semántica: se construye generalmente con el nodo raíz, o la meta, en la

parte superior, al descender por las ramas del árbol se obtienen subobjetivos hasta

que se llega al nivel inferior donde están los métodos de ataque. Un nodo se
descompone como:
O1
Descomposición «AND»
Un conjunto de objetivos de ataque de nivel inferior, que
tienen que ser alcanzados para que el ataque tenga éxito.
O1.1 O1.2
O1 Descomposición «OR»
Una serie de objetivos de ataque de nivel inferior,
cualquiera de los cuales puede lograrse para que el ataque
O1.1 O1.2 tenga éxito.
Figura 6. Aplicación patrones de ataque a las diferentes fases del SDLC.
Meta: Falsificar
Reserva
1. Convercer 2. Acceder y
emplaedo añada modificar la base
reserva datos de vuelos
2.1 Inyección
1.1 Chantaje 1.2 Engañar 2.2 Inicio sesión
SQL página
empleado empleado Base Datos
WEB
2.2.3 Robarr
2.2.1 Advinar 2.2.2 Sniff
password
password password
servidor
2.2.3.2 Exploit
2.2.3.1 Obtener
Condición
cuenta servidor
Carrera
2.2.3.1.2 Obtener
2.2.3.1.1 Buffer
Acceso cuenta
Overflow
Empleado
Figura 7. Vista conceptual de un árbol de ataque. Adaptada de Redwine, S. T. Jr. (2006).

2.5. Casos de abuso
Introducción
Los diagramas de casos de uso constituyen unas buenas prácticas para la obtención de
los requisitos funcionales de una aplicación, sin embargo, para la obtención de
requisitos de seguridad no lo son, sobre todo los no funcionales o requisitos
negativos referidos a actividades que no debería realizar el sistema. Para solucionar lo
anterior se ha creado un tipo especializado de casos de uso que se utilizan para analizar
y especificar las amenazas de seguridad, caso de abuso, Guttorm. y Opdahl (2001) los
definen como:
Un caso de abuso es la inversa de un caso de uso, es decir, una función que el sistema
no debe permitir o una secuencia completa de acciones que resulta en una pérdida para
la organización.
3. Ing. 7. Revisión 8.
Requisitos 5. Patrones
seguridad de diseño
11. segura
6. Pruebas 1. Modelado
basadas en de ataques
riesgo 10.
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 8. Casos de abuso.

Los casos de abuso, o casos de mal uso, son un instrumento que puede ayudar a
pensar de la misma forma que lo hacen los atacantes. Pensando más allá de los aspectos
normativos y funcionales y también estudiando eventos negativos o inesperados, los
profesionales de seguridad de software entienden mejor cómo crear software seguro,
pues permiten obtener una mejor comprensión de las áreas de riesgo del sistema a
través de (Redwine, 2006):
» Identificación los objetivos de seguridad que debe cumplir el software.

» Identificación de las amenazas de seguridad a ser neutralizadas por el software.
» Identificación de los puntos en el software susceptibles de ser atacados.
» Definición de restricciones, o requisitos negativos, necesarios para alcanzar las
contramedidas necesarias y los objetivos de seguridad.
» Obtener requisitos de seguridad que garanticen que el software aplica las
restricciones necesarias.
Los casos de abuso constituyen un excelente medio de análisis de las amenazas

que debe afrontar el software. Son apropiados para el análisis y especificación de
restricciones, o requisitos negativos, ya que se basan en el uso indebido del sistema.
Establecen la base para otros casos de uso de seguridad que proporcionan los
medios para contrarrestar o mitigar las amenazas capturadas en los mismos y una
manera altamente reutilizable de organizar, analizar y especificar los requisitos de
seguridad de los mismos.
Los casos de abuso describen lo que el software no debe hacer en respuesta al

uso incorrecto o malintencionado del mismo por un agente malicioso. Para cada
caso de uso funcional, el desarrollador debería explorar las formas en que
esa función podría ser deliberadamente mal utilizada. El desarrollador tiene
que identificar todas las posibles relaciones entre casos de uso de seguridad y casos
abuso, para especificar restricciones y requisitos de seguridad para evitar un mal uso o
abuso de las funcionalidades del software. En la figura siguiente se muestra la
relación entre el caso de uso de seguridad y el de abuso asociado (Donald,
2003).

Figura 9. Relación entre el caso de uso de seguridad y el de abuso asociado. Extraída de Donald (2003).
En la siguiente tabla se resume las diferencias entre los casos de uso de seguridad y los
casos de abuso (Donald, 2003):
Característica Casos de Abuso Casos Uso Seguridad

Uso Analiza y especifica las amenazas a Analiza y especifica los
la seguridad requisitos de seguridad
Criterio de éxito Éxito del atacante Éxito de la aplicación
Producido Equipo de seguridad Equipo de seguridad
Usado Equipo de seguridad Equipo de requisitos
Actor externo Atacantes y usuarios Usuarios
Conducido por Análisis de vulnerabilidades de Casos de abuso
activos y amenazas
Tabla 4 Diferencias entre los casos de uso de seguridad y los casos de abuso.
Ejemplo caso de uso de seguridad y caso de abuso
Tomando como referencia el artículo de Donald (2003), a continuación, presentamos

un ejemplo caso de uso de seguridad y caso de abuso asociados en su versión gráfica,
que ilustra las diferencias entre ambos. Se presenta un caso de uso tradicional de un
cajero automático que puede realizar las tareas de consulta saldo, depositar, retirar y
transferir fondos. Para manejar con seguridad una de las cuentas, se pueden especificar
los casos de uso de seguridad:
» Control de acceso. Identificación, autenticación y autorización.

» Privacidad. Garantizar la privacidad de datos y comunicaciones.
» Integridad. Garantizar la integridad de datos y comunicaciones.
» No repudio. Garantizar el no repudio de las transacciones.

Los cuatro casos uso resultantes de especificar los requisitos de seguridad, protegen al
cajero automático y a sus usuarios de tres amenazas potencialmente realizables por un
cibercriminal.
CONTROL INGENIERIA
DEPOSITAR DE ACCESO SOCIAL
RETIRAR FONDOS (ABUSO
FONDOS (SEGURIDA
Pirata
D)
informático
ROMPER
PRIVACIDAD
PRIVACIDAD
(SEGURIDAD
GESTION (ABUSO)
)
CUENTAS
USUARIO
USUA
INTEGRIDAD PENETRACION
RIO FRAUDE Cibercriminal
(SEGURIDAD)
(ABUSO)
TRANSFERIR CONSULTAR
FONDOS SALDO
NO AGENTES
REPUDIO CASO USO CASOS
SEGURIDAD ABUSO MALICIOSOS
(SEGUIRI
DAD)
Figura 10. Ejemplo caso de uso de seguridad y caso de abuso. Extraída de Donald (2003).
En el documento de referencia de Guttorm y Opdahl (2001) se presenta un caso de

abuso para un caso de comercio electrónico, en sus dos versiones, textual considerada
como la más importante y gráfica. Presenta varias relaciones:
» Relación caso abuso → uso seguridad: «incluye» y «extiende».

» Relación caso de uso → abuso: «previene» y «detecta».
Previene Inundar el
Bloquear sistema Detecta
Hojear
Extiende repetidos
catálogo
registros
Registrar Incluye Robar

Cliente cliente información
Incluye tarjeta
Extiende Incluye
Encriptar Previene
Ordenar mensaje Interceptar Cibercriminal
compras Incluye comunicacion
es
Incluy
Operador Cambiar e
contraseña Obtener
Incluye Previene Detecta
contraseña
Extiende
Incluye Monitorizar
el sistema
Establecer
Inicio de
política
sesión Incluye
contraseñas
Figura 11. Ejemplo caso de uso comercio electrónico. Fuente: Guttorm, A. y Opdahl, L. (2001)

2.6. Ingeniería de requisitos de seguridad
Introducción
Gran parte de la mayoría de las vulnerabilidades y debilidades del software tienen su

origen en unos requisitos inadecuados, inexactos e incompletos,
principalmente debido a la falta o debilidad de la especificación de los mismos, que no
determinan las funciones, restricciones y propiedades no funcionales del software que
hacen que este sea previsible, confiable y resistente.
Defectos en los requisitos cuestan 10 a 200 veces más para corregir durante la
ejecución, que si se detectan durante la especificación de los mismos. Además, es difícil
y costoso mejorar significativamente la seguridad de una aplicación después de que esté
en su entorno de producción.
La fase de ingeniería de requisitos cubre todas las actividades y tareas que

deben realizarse antes de iniciar el diseño, su principal resultado es la
especificación de los requisitos que definen los aspectos funcionales y no
funcionales del software.
7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 12. Ingeniería de requisitos.
Los requisitos de seguridad deben ser considerados simultáneamente junto con

los demás requisitos, incluidos los relativos a funcionalidad, rendimiento, facilidad

de uso, ya que normalmente los «requisitos de seguridad» a menudo entran en

conflicto con ellos, se hace necesario, por tanto:
Integración satisfactoria de la ingeniería de requisitos de seguridad con la ingeniería de

requisitos en su conjunto.
Los requisitos de las funcionalidades o servicios de seguridad del sistema o

el software a menudo se confunden con los requisitos de software seguro:
» Requisitos servicios de seguridad. Incluye la especificación de funciones que

implementan una política de seguridad, como control de acceso, autenticación,
autorización, cifrado y gestión de claves. En la siguiente figura se muestra un alcance
completo de este tipo de requisitos:
Figura 13. Requisitos servicios de seguridad.
Deben especificar:
o Propiedades que el software debe exhibir, ejemplo: el software debe tener

un comportamiento correcto y predecible y disponer de capacidades de
recuperación frente a ciberataques.
o Nivel requerido de seguridad y salvaguardas de riesgo de las funciones
de seguridad.
o Los controles y normas que rigen los procesos de desarrollo,
implementación y operación del software.
» Requisitos de software seguro. Requisitos que afectan directamente a la

probabilidad de que el software sea seguro. Estos abarcan principalmente los
no funcionales, los que garanticen que el sistema seguirá siendo confiable, incluso
cuando esa confianza se vea amenazada.

Software seguro Actividades

Actividades
ingeniería
seguridad
requisitos
Identificación de
requisitos
Análisis de riesgos.
Modelado de amenazas
Patrones de ataques
Análisis de
Requisitos
requisitos Casos de abuso
Manejo de excepciones
Especificación
de requisitos. Especificación formal
Documentación
Verificación de
requisitos
Figura 14. Vista de alto nivel de las tareas y artefactos involucrados en la fase de requisitos.
Es fundamental que los requisitos de seguridad del software sean:
» Completos.
» Precisos.
» Coherentes.
» Trazables.
» Verificables.
Existen, provenientes de ingeniería de software, una serie de herramientas que

permiten mantener la trazabilidad y gestión de los requisitos de seguridad de sistemas
complejos y críticos. Entre ellas tenemos:
» Praxis High Integrity Systems’ REVEAL.

» Telelogic’s DOORS.
» ChiasTek’s REQTIFY.
» Safeware Engineering’s SpecTRM.
Uno de los problemas típicos relacionados con la ingeniería de software es el análisis

de requisitos o bien no se realiza en absoluto (los requisitos identificados se
especifican directamente sin ningún análisis o modelado) o se limita a los requisitos
funcionales, haciendo caso omiso de las exigencias de calidad y otras limitaciones,
como la arquitectura, el diseño, implementación y pruebas.

2.7. Análisis de riesgo. Arquitectónico
Introducción
Según estudios y estadísticas disponibles se sabe que aproximadamente un 50 % de los

defectos de seguridad se deben a errores en la fase de diseño denominados
«debilidades» o «flaws» en idioma Ingles. Identificando el riesgo y después con
la gestión del mismo se pueden mitigar gran parte de los problemas de
seguridad de un software.
7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 15. Análisis de riesgos.
En la figura anterior, se puede observar que el análisis de riesgos está a caballo entre
la fase análisis de requisitos, donde se obtienen los requisitos de
seguridad, se modelan ataques y realizan casos de abuso, y la fase de la fase
de arquitectura y diseño. Sigue en importancia a la revisión de código, si bien este
hecho puede variar dependiendo de las características de la organización, de sus tipos
de sistemas, cantidad de software, etc.
En la fase de análisis al obtener los requisitos de seguridad se han obtenido bastantes

conclusiones acerca de los activos del sistema y del impacto que los posibles ataques
pueden causar, pero es en la fase de diseño de la arquitectura del sistema donde se
especifican todos los activos porque se obtienen todos los componentes hardware y
software del sistema, se configura la arquitectura y se deciden las salvaguardas
concretas que van a protegerlo, en función de los requisitos de seguridad y los casos de
abuso.

Un análisis de riesgo riguroso implica un exhaustivo entendimiento del impacto sobre

el negocio u objetivos de la organización, que puede requerir un conocimiento de leyes
y regulaciones tanto como del modelo de negocio soportado por el software. También,
los desarrolladores y diseñadores habrán llegado a ciertas suposiciones sobre su
sistema y los riesgos que este afronta.
Un acercamiento a un prototipo de análisis y gestión de riesgo típico implica varias

actividades principales que a menudo incluyen un número de actividades básicas:
» Leer y entender las especificaciones, documentos de arquitectura, y otros

documentos de diseño.
» Discutir sobre el objetivo de análisis con el grupo: brainstorming.
» Determinar los límites del sistema y datos sensibles y críticos.
» Probar el software si ya existe algún prototipo.
» Estudiar el código y otros componentes de software incluyendo el empleo de
herramientas de análisis de código.
» Identificar las amenazas y las fuentes relevantes de ataque. Esta tarea se deriva
fácilmente si se ha hecho previamente la obtención de casos de abuso y los requisitos
de seguridad del sistema.
» Identificar vulnerabilidades posibles, aprovechando el uso de herramientas y
documentación sobre vulnerabilidades comunes.
» Discutir las posibles modificaciones o parches para corregir vulnerabilidades.
» Determinar la probabilidad de riesgo.
» Planificar escenarios de ataque para explotación de las vulnerabilidades.
» Determinar el posible impacto sobre los activos y objetivos de negocio.
» Clasificar los riesgos.
» Desarrollar una estrategia de mitigación.
» Recomendar las salvaguardas para mitigar los riesgos.
» Informe de conclusiones.
» Proporcionar la información básica en cuanto a dónde emplear recursos de
mitigación limitados.
Modelado de Amenazas
Un análisis de riesgos es un proceso sistemático que tiene como propósito estimar la

magnitud y probabilidad de los riesgos a los que podría estar expuesta una
organización y saber qué decisión tomar ante una posible eventualidad. Este proceso

aplicado el desarrollo y diseño del software se denomina «modelado de

amenazas». Constituye una herramienta válida para evaluar los riesgos inherentes a
una aplicación durante su desarrollo, principalmente en la etapa de diseño, y que puede
ser utilizada por equipos de desarrollo que no cuenten con expertos en seguridad.
Existen varios métodos o metodologías de modelado de amenazas que se

pueden aplicar al desarrollo de software:
Metodologías
1 CORAS (Consultative Objective Risk Analysis System) and SECURIS (Research Council
of Norway-funded Model-Driven Development and Analysis of Secure Information
Systems).
Herramienta
2 CIGITAL's architectural risk analysis process.
3 OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation). SEI de la
Universidad Carnegie Mellon
4 PTA Technologies Calculative Threat Modeling Methodology (CTMM).
5 Trike. Metodología de evaluación de amenazas.
6 MTAM (Microsoft Threat Analysis and Modeling).
7 PASTA (Process for Attack Simulation and Threat Analysis).
Tabla 5 Metodologías de modelado de amenazas.
Proceso análisis de riesgo Arquitectónico
Cigital usa el proceso de análisis de riesgo arquitectónico que desarrolla un

acercamiento a un análisis de riesgo que implica tres pasos básicos, modelo de Cigital,
Building Security In:
Figura 16. Fases análisis de riesgo arquitectónico.

Análisis de resistencia al ataque. Utiliza patrones y árboles de ataque para

analizar la resistencia al ataque. Para ello comprueba una lista de categorías de riesgos
según el modelo de análisis de amenazas de Microsoft STRIDE.
o Modelado.
o Identificar amenazas.
o Mitigación.
o Validación.
Figura 17. Metodología para el modelado de amenazas.

Fuente: http://www.microsoft.com/security/sdl/adopt/threatmodeling.aspx
» Análisis de ambigüedad. Es un subproceso que pretende descubrir nuevos

riesgos en base al conocimiento de principios de diseño. Aprovecha múltiples
puntos de vista de la arquitectura de software, de varios arquitectos,
para crear una técnica de análisis crítica para encontrar nuevos
defectos, puntos de conflicto y de inconsistencia.
» Análisis de debilidad. Es un subproceso que ayuda al entendimiento del impacto

de dependencias de software externo.

2.8. Patrones de diseño
Según se define en el documento de referencias (McGraw, 2005) los patrones de

diseño son:
Una solución general repetible a un problema de ingeniería de software recurrente,

que está expresamente destinado a contribuir al diseño de software menos
vulnerable, más resistente y tolerante a los ataques.
7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 18. Patrones de diseño.
El concepto de patrones es más familiar en ingeniería de software, relacionados

principalmente con la arquitectura de los sistemas o soluciones para el diseño de los
mismos. Se han desarrollado patrones de diseño de seguridad para casi todas las
fases del SDLC: requerimientos, análisis, diseño, codificación, etc. El uso adecuado de
estos patrones conduce a la remediación de los principales fallos de seguridad, como,
por ejemplo, uno que tuvo un efecto significativo fue un «validador» que construía un
modelo de validación de entrada para defenderse contra los ataques de inyección SQL,
otros ejemplos son los construidos para los lenguajes de programación en C y / o C + +.

A continuación, se presentan ejemplos de este tipo de patrones (Redwine, 2006):
» Schumacher, Markus, Eduardo Fernandez-Buglioni, Duane Hybertson, Frank

Buschmann, and Peter Sommerlad. Security Patterns: Integrating Security and
Systems Engineering. New York, New York: John Wiley & Sons; 2005.
» Blakley, Bob and Craig Heath, Craig. Technical Guide to Security Design Patterns.
San Francisco, California: The Open Group, 2004 y SecurityPatterns Website.
» Steel, Chris, Ramesh Nagappan, and Ray Lai. Core Security Patterns. Indianapolis,
Indiana: Prentice-Hall Professional, 2005 y Viega, John and Matt Messier. Secure
Programming Cookbook for C and C++. Sebastopol, California: O’Reilly, 2003.
» Kienzle, Darrell M., Matthew C. Elder, David Tyree, and James Edwards-Hewitt.
Security Patterns Repository, Version 1.0, “Security Patterns for Web Application
Development: Final Technical Report”, 4 November 2003 y W. Cunningham,
“Portland pattern repository”, Cunningham & Cunningham, Inc,
http://c2.com/ppr/.
2.9. 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.
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.

7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 19. 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 20. Tipos de pruebas seguridad del software.
Los objetivos de las pruebas de seguridad basadas en el riesgo son los

siguientes (Redwine, 2006):
» 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 su manejo de las mismas mediante excepciones que minimicen el alcance
e impacto de los daños que puedan resultar de los ata
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 test que son particularmente útiles para las pruebas basadas en riesgo
incluyen las mostradas en el siguiente diagrama:
Figura 21. 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.
Puntos fuertes Puntos débiles
▪La vulnerabilidad se reporta en la línea

▪Falsos positivos si no se configura bien la
de código fuente
herramienta
▪Los fallos se pueden encontrar aunque
▪Acceder al código fuente no es siempre
no estuvieran accesibles en ejecución
posible
▪Cobertura total si se tiene acceso a todo
▪Algunas debilidades son solo expuestas al
el código de la aplicación
desplegar la aplicación
▪Imprescindible para corregir lo más
▪El software no es fácil de probar si se trata
temprano posible la gran mayoría de los
de pruebas remotas
defectos de seguridad de las aplicaciones
Figura 22. Puntos fuertes y débiles pruebas caja blanca. Extraída 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.
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.

Puntos fuertes Puntos débiles
▪Pruebas «reales» del software: alta

confianza en los resultados ▪No es posible determinar la cobertura de
▪No es necesario facilitar el código fuente todo el código
de la aplicación ▪Fallos que no se ejecuten en las pruebas no
▪El software es fácilmente probado a saldrán a la luz
través de la red: pruebas de ▪Requiere desplegar y ejecutar la aplicación
infraestructura
Figura 23. Puntos fuertes y débiles pruebas caja negra. Extraída de (López, S., 2012).
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:
o Escaneo de vulnerabilidades.
o Explotación de vulnerabilidades.
o Fuzz testing.
o 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
Core Impact. Comercial Windows, Linux
Canvas Comercial Windows, Linux
Tabla 6 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
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 24. Funcionamiento pruebas Análisis Dinámico (DSAT). Extraída de (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
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 7 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».
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 Fuzzy Lop Fuzzer basado en mutaciones.
Zzuf CERT basic fuzzing framework. Busqueda de bugs.
Sulley Extras para gestionar fuzzing como parte de las pruebas de
penetración.
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 8 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:

Nessus. Libre Linux/Unix, Windows
Nexpose. Comercial Linux/Unix, Windows
AppDetective. Comercial Windows
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 9 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:
o Análisis de cobertura. Pone de manifiesto las interacciones entre las

diferentes partes del programa.
o Análisis de frecuencia de espectro. Revela las dependencias entre los
componentes del programa.

o 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 25. Análisis Hibrido.
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 10 Herramientas análisis hibrido
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

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.
Uno de los más interesantes motores inyección de fallos modernos para la seguridad es
la herramienta Cenzic1. Este instrumento usa el navegador para interceptar
transacciones y permitir a un analista estudiarlas. Aunque esta clase de pruebas sea
posible con perl y un 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. Otra herramienta es Holodeck2 útil para la repetición, la inyección de
defectos de seguridad y otras pruebas interesantes. 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.
1 https://www.trustwave.com/Company/Cenzic-is-now-Trustwave/
2 http://www.sisecure.com/

En la figura siguiente se muestra las diferentes pruebas a realizar en cada una de las
fases del S-SDLC (Redwine, 2006):
Figura 26. Distribución pruebas de seguridad a lo largo de las fases del S-SDLC.
2.10. 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.

7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 27. 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.
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.
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
http://www-01.ibm.com/software/rational/products/appscan/source/
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:
» 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.

CONSTRUIR REALIZACION
MODELO ANALISIS
CODIGO
FUENTE
CONOCIMIENTO
SEGURIDAD
SOFTWARE PRESENTACION
RESULTADOS
Figura 28. 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
(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.
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.
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, C, C++, Java y
Comercial
otros
2 AppScam de IBM. C, C++, Java y
Comercial
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
Libre C
technology.
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
Libre Java
y UC3M.
15 Java PathFinder. Libre Java
16 Cppcheck Libre C,C++
17 Polyspace de Mathworks. Comercial C , ada
18 Pc-lint de Gimpel Sotfware, Comercial C, C++
Tabla 11 Herramientas de análisis estático de código fuente.

2.11. 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.
7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 29. 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
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.

6. Realizar 1. Revisar
pruebas información
Fuzzing Modelo
Amenazas
5.
Realización
2. Identificar
análisis vulnerabilidades
dinámico
(DAST) web
4. Ejecutar
Expolit
3. Buscar
(herramienta Expolit
automática o
manual)
Figura 30. Ejecución pruebas de penetración.
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 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
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 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 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.
» Utilización de pruebas de penetración para evaluar aplicaciones COTS.

2.12. Operaciones de seguridad
Introducción
El proceso final a llevar a cabo previo al paso a producción de la aplicación segura, son
las actividades centrales de:
» Distribución.
» Despliegue.
» Operaciones.
7. Revisión 8.
5. Patrones
de diseño
11. segura
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 31. 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.
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 debe 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 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».

Interfaz de usuario
(Autorización, autenticación)
Seguridad de la aplicación
(auditoría, acceso, etc.)
Prácticas de
Red
operación
Gestora bases de datos, (protocolos de
(administración, etc. comunicaciones)
buckup, etc.)
Sistema operativo
(control de acceso
sistema de fichero)
Figura 32. 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/

» NSA guías de configuración de seguridad:
http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml
» NIST Listas de comprobación de configuración de productos TIC:
http://web.nvd.nist.gov/view/ncp/repository
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.

2.13. 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.
5. Patrones
7. Revisión 8.
de diseño
11. segura 9. Test
3. Ing. 4. Análisis 6. Pruebas 1. Modelado
2. Casos Re visión penetración
Requisitos de rie sgos basadas en de ataques
de abuso e xte rna 10.
seguridad riesgo
Operaciones
seguridad
Casos de e
abuso integración
REALIMENTACIÓN
Figura 33. 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.

2.14. 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. Massachusetts: 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. Madrid: UNED.
Barnum, S. y Sethi, A. (2007). Attack Patterns as a Knowledge Resource for Building

Secure. Software Cigital, Inc. Disponible en:
https://capec.mitre.org/documents/Attack_Patterns-
Knowing_Your_Enemies_in_Order_to_Defeat_Them-Paper.pdf
Barnum, S. (2008). Common Attack Pattern Enumeration and Classification (CAPEC)

Schema Description. Department of Homeland Security EE. UU. Software Cigital.
Disponible en:
https://capec.mitre.org/documents/documentation/CAPEC_Schema_Description_v1.
3.pdf
Chess, B., and West, J. (2007). Secure Programming with Static Analysis.
Massachusetts: 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. Disponible en:
https://www.seas.upenn.edu/~lee/09cis480/papers/DACS-358844.pdf
Graff, M. G. y Van Wyk, K. R. (2003). Secure Coding: Principles & Practices. Reino
Unido: O'Reilly.

Guttorm Sindre, A. y Opdahl, L. Capturing Security Requirements through Misuse

Cases. Disponible en:
https://www.researchgate.net/publication/228605351_Capturing_security_requireme
nts_through_misuse_cases
Hoglund. (2004). Exploiting Software: How to Break Code, By G. Hoglund and G.

McGraw. Massachusetts: 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.
Komaroff, M. y Baldwin, K. (2005). DoD Software Assurance Initiative. Disponible en:

http://www.acqnotes.com/Attachments/DoD%20Software%20Assurance%20Initiativ
e.pdf
López, S. (2012). Descubriendo el valor de la Seguridad en las Aplicaciones Web con

IBM AppScan. Nueva York: IBM Corporation.
McGraw, G. (2005). Software Security: Building Security In. Massachusetts: Addison

Wesley Professional.
Microsoft Corp. (2003). Application Security Best Practices at Microsoft: The

Microsoft IT Group Shares Its Experiences. Disponible en:
http://download.microsoft.com/download/0/d/3/0d30736a-a537-480c-bfce-
5c884a2fff6c/AppSecurityWhitePaper.doc
Microsoft Corp (2010). Simplified Implementation of the Microsoft SDL. Disponible

en: 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.
Washington: US Department of Homeland Security.
Sroka, D. Presentación HP Fortify User Training.

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

Lo + recomendado
Lecciones magistrales
Modelado de amenazas
En la presente clase, se desarrolla la metodología de amenazas propuesta por

Microsoft: STRIDE, que puede ser ejecutada tanto por expertos como no expertos en
seguridad de la información (diseñadores, desarrolladores, etc.) y se realiza una
introducción a la herramienta que la soporta.
El vídeo está disponible en el aula virtual.
No dejes de leer…
Simplified implementation of the Microsoft SDL
En documento describe los conceptos básicos del Microsoft security development

lifecycle (SDL) y las actividades de seguridad individuales en cada una de sus fases.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

http://www.microsoft.com/en-us/download/details.aspx?id=12379
TEMA 2 – Lo + recomendado 60 © Universidad Internacional de La Rioja (UNIR)

Attack modeling for information security and survivability
Andrew P. Moore, Robert J. Ellison, Richard C. (2001). Attack Modeling for

Information Security and Survivability. U.S.: Carnegie Mellon University.
Esta nota técnica documenta e identifica patrones de ataque que ocurren comúnmente
al objeto de que los diseñadores de sistemas de información y analistas puedan
utilizarlos para desarrollar sistemas de información más robustos y confiables.

http://resources.sei.cmu.edu/asset_files/TechnicalNote/2001_004_001_13793.pdf
Software design misuse and abuse cases
Artículo interesante sobre el diseño de casos de abuso.

https://www.cigital.com/papers/download/bsi2-misuse.pdf

No dejes de ver…
Secure Development Lifecycles (SDLC): Introduction and Process Models -

Bart De Win
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.
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.
Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

https://www.youtube.com/watch?v=L-gL1YQUrwg

Threat modeling tool 2016 demo
Presentación de las nuevas características de la herramienta de modelado de amenazas

Microsoft Modeling Tool 2016.

https://www.youtube.com/watch?v=7HUOk8BhYW0

Threat modeling
Vídeo que proporciona una descripción del proceso de modelo de amenazas que utiliza
Cigital mediante un ejemplo de aplicación del proceso para identificar fallas potenciales
en un sistema.
Objetivos:
» Describir terminología utilizada en el modelado de amenazas.
» Describir un proceso de modelado de amenazas de un sistema.
» Realizar un modelo de amenazas de algún sistema ficticio.

https://www.youtube.com/watch?v=We2cy8JwVqc
Introduction, threat models
Clase del MIT open course ware del Profeso Zeldovich acerca del modelado de
amenazas.

https://www.youtube.com/watch?v=GqmQg-cszw4&feature=youtu.be

Heartbleed: Lessons for the Cyber Sector
Vídeo sobre el incidente Heartbleed que afecto a una gran cantidad de servidores con el
software Open SSL instalado. Los autores, expertos en seguridad de aplicaciones,
presentan ideas, lecciones aprendidas y directrices de seguridad que proporcionan a
implementar. El acceso al webinar requiere registro.

https://www.youtube.com/watch?v=TGOq4AbUHlQ
No dejes de practicar…
Aplicación IBM security appscan
Demostración de pruebas de caja negra sobre una aplicación web realizada mediante la
aplicación IBM Security AppScan. Para ello hay que bajarse la aplicación, instalarla y
ejecutarla contra la web de demostración Altoro Mutual website:
Está disponible en la siguiente web, previamente debes rellenar unos formularios:

http://www.ibm.com/developerworks/downloads/r/appscan/
Es una licencia de evaluación que solo puede escanear una página web de prueba,
Altoro Mutua en http://demo.testfire.net. Utiliza la plantilla predefinida,
demo.testfire.net, que se muestra en el cuadro de diálogo Nueva digitalización. Cuando
se te solicite el nombre de usuario y contraseña, utiliza:
Nombre de usuario: jsmith.

Contraseña: Demo1234.

La aplicación funciona de forma resumida de la siguiente manera:
Figura 1.
Figura 2.
Figura 3.
Figura 4.
Figura 5.
Figura 6.
Figura 7.
Figura 8.
Figura 9.
Figura 10.
Figura 11.
Figura 12.
Figura 13.
Figura 14. .
Capas del sistema a proteger

+ Información
A fondo
Capturing security requirements through misuse cases
Guttorm Sindre y Andreas L. Opdahl en este trabajo analizan una extensión conceptual
de casos de uso, es decir, casos de mal uso y describen las acciones que no deberían ser
posibles en un sistema.
Accede al documento desde el aula virtual o a través de la siguiente dirección web:

http://www.nik.no/2001/21-sindre.pdf
Software assurance in acquisition: mitigating risks to the enterprise
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. Leer
desde la página 12 a la 49.

https://www.us-cert.gov/bsi/articles/best-practices/acquisition/a-systemic-approach-
assessing-software-supply-chain-risk
TEMA 2 – + Información 67 © Universidad Internacional de La Rioja (UNIR)

Security quality requirements engineering (SQUARE) methodology
Nancy R. Mead, Eric D. Hough y Theodore R. Stehney II elaboran este documento para
obtener y priorizar los requerimientos de seguridad en los proyectos de desarrollo de
software. Se detalla y explican los pasos de la metodología y los resultados de su
aplicación en estudios de casos recientes.

http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA443493
Attack patterns as a knowledge resource for building secure
En este trabajo se analiza el concepto de patrones de ataque, como un mecanismo para

capturar y comunicar la perspectiva del atacante.

http://capec.mitre.org/documents/Attack_Patterns-
Knowing_Your_Enemies_in_Order_to_Defeat_Them-Paper.pdf

Common attack pattern enumeration and classification (CAPEC)
El propósito de este documento es definir un esquema estándar para representar

patrones de ataque y describir de forma detallada el significado y el propósito de cada
elemento de esquema constituyente.

http://capec.mitre.org/documents/documentation/CAPEC_Schema_Description_v1.3
.pdf
Practical measurement framework for software assurance and

information security
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.

http://www.psmsc.com/Downloads/TechnologyPapers/SwA%20Measurement%2010-
08-08.pdf

Application security best practices at Microsoft: the Microsoft IT group

shares its experiences
El documento contiene la descripción de los procesos, las políticas y mejores prácticas

que puedan ser de utilidad para que las organizaciones creen software seguro.

http://download.microsoft.com/download/0/d/3/0d30736a-a537-480c-bfce-
5c884a2fff6c/AppSecurityWhitePaper.doc
A Few Billion Lines of Code Later
Artículo realizado por el equipo de Coverity que describe la experiencia e

implementación de una herramienta de análisis estático comercial.

http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-
later/fulltext
Security Controls for Computer Systems
Artículo que introduce la idea de las pruebas de penetración, así como muchas otras
ideas fundacionales de seguridad de los sistemas.

http://www.rand.org/pubs/reports/R609-1/index2.html

Vsftpd. Probably the most secure and fastest FTP server for UNIX-like
systems
FTPD seguro, en estos documentos se presenta una descripción del diseño e

implementación de programa Vsftpd.

https://security.appspot.com/vsftpd.html#docs
Webgrafía
Synopsys
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.
Accede a la página web a través del aula virtual o desde la siguiente dirección:
https://resources.synopsys.com/
Armitage
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.
Accede a la web desde el aula virtual o a través de la siguiente dirección:

http://www.fastandeasyhacking.com/

NMAP
Escáner que proporciona información de puertos abiertos, versiones de sistemas

operativos, etc.
Accede a la página web desde el aula virtual o a través de la siguiente dirección:

http://nmap.org/
Metasploit
A collaboration of the open source community and Rapid7, Metasploit® software helps
security and IT professionals identify security issues, verify vulnerability mitigations,
and manage expert-driven security assessments.
Accede a la web desde el aula virtual o a través de la siguiente dirección:

http://www.metasploit.com/

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

OWASP.

https://github.com/zaproxy/zaproxy
Burp suite
Escáner de vulnerabilidades de aplicaciones web que dispone de una versión libre y

otra de pago.

http://portswigger.net/burp/
Kali
Distribución de Linux con las herramientas de prueba de penetración preinstaladas.

https://www.kali.org/

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

https://scan.coverity.com/
Joern
Herramienta de análisis estático para lenguaje C y C++.

http://www.mlsec.org/joern/
FindBugs
Herramienta de análisis estático para lenguaje Java.

http://findbugs.sourceforge.net/

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.
Hoff, J. y Chapple, M. (2014). Securing the SDLC for Dummies®, WhiteHat Security
Edition. Nueva Jersey: 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.

Florida: 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.
Shostack, A. (2014). Threat Modeling Designing for Security. Nueva Jersey: John
Wiley & Sons, Inc.
Takanen, A., Demott, J. D. y Miller, C. (2018). Fuzzing for Software Security Testing
and Quality Assurance (2nd Edition). Massachusetts: Artech House.

Actividades
Trabajo: Metodologías de modelado de amenazas
Descripción
Esta actividad te servirá para seguir profundizando en el modelado de amenazas

realizando un trabajo que contenga al menos los siguientes apartados:
» Introducción al modelado de amenazas.

» Estudio de metodologías existentes. Se incluirá un resumen de las principales
características de:
o CORAS (Consultative objective risk analysis system).

o CIGITAL's architectural risk analysis process.
o PTA Technologies calculative threat modeling methodology (CTMM).
o Trike. Metodología de evaluación de amenazas.
o TAM (Microsoft threat analysis and modeling).
o PASTA (Process for Attack Simulation and Threat Analysis).
» Descripción de una metodología en profundidad.

Ejercicio práctico de modelado de amenazas utilizando una herramienta de modelado
como Threat Analysis and Modeling Tool (https://www.microsoft.com/en-
us/download/details.aspx?id=49168) del siguiente caso que se describe a continuación:
Ejercicio práctico de modelado de amenazas
Con objetivo de afianzar los conocimientos adquiridos sobre el modelado de amenazas

se pide el definir, modelar y medir las posibles amenazas de una tienda de libros online,
llamada «Librería On-Line SA».
Últimamente, ha sufrido un ciberataque que ha comprometido las credenciales de sus

clientes. El incidente ha trascendido en los medios de comunicación, lo que ha
producido una pérdida de cuota de mercado importante frente a sus competidores.
TEMA 2 – Actividades 76 © Universidad Internacional de La Rioja (UNIR)

Con el objetivo de mantener su actual posición en el mercado de venta electrónica de

libros y volver a recurar e incluso superar la que tenía, ha contratado a la empresa
InfoSecurity para llevar a cabo un trabajo de modelado de amenazas a sus sistemas
TI e implementar las salvaguardas que se deriven del mismo en función del nivel de
riesgo y la disponibilidad económica. Se le establece los siguientes requisitos de negocio
y técnicos:
» Habrá tres tipos de usuarios en la aplicación: clientes, administrador TI y agente de

ventas.
» Los clientes deben poder buscar productos y gestionar sus pedidos utilizando la
tienda web o llamando a la oficina de ventas.
» Para que un cliente pueda realizar un pedido debe, con anterioridad, registrase para
crearle una cuenta.
» El cliente puede pagar con una tarjeta de crédito, débito o mediante trasferencia
bancaria.
» Los clientes deben iniciar sesión antes para poder personalizar sus preferencias.
» Los clientes deben ser capaces de revisar y modificar sus pedidos realizados.
» Los agentes de ventas pueden conceder descuentos a los clientes.
» Los administradores pueden modificar y eliminar clientes y productos e
información.
» La tienda web de la librería tendrá que ser accesible desde Intranet e Internet.
» La tienda web deberá diseñarse con una arquitectura distribuida por razones de
escalabilidad.
» El cliente necesitará autenticarse en la tienda web con las credenciales de la cuenta
de usuario, que a su vez se comprobarán contra la base de datos implementada en el
backend de la compañía, a través de una interfaz de servicios web.
» La información de la cuenta del usuario y la información del producto deberán
mantenerse en una base de datos relacional.
» El procesamiento de tarjetas de crédito será subcontratado a un procesador de
terceros.
» Las interacciones de los usuarios con la tienda web se almacenan en un servidor de
log interno de la organización.
» La base de datos deberá copiarse periódicamente en una ubicación de un proveedor
de servicios TI de terceros, para propósitos de recuperación ante desastres.
» El sitio web se diseñará lógicamente como una aplicación cliente/servidor
distribuida conforme a un modelo de tres capas: presentación, proceso y datos.

» Los clientes accederán a la aplicación utilizando navegadores web de escritorio y

dispositivos móviles.
» El sitio web se desplegará en Internet protegido por una DMZ de dos capas con
acceso tanto para usuarios internos como externos.
» Físicamente, la aplicación estará completamente alojada en un servidor de
aplicaciones (frontend) alojado en la DMZ con acceso a un servidor de base de datos
que estará en la red interna de la compañía (backend).
» La tecnología utilizada en el desarrollo de la aplicación web es ASP.Net utilizando C
# y la base de datos del backend de la compañía está implementada en base al
producto Microsoft SQL Server.
Los objetivos de seguridad establecidos para la tienda web de Librería On-Line SA son
los siguientes:
» Recuperar la imagen de la compañía deteriorada tras el ciberincidente ocurrido.

» Obtener la posición líder de mercado en venta de libros online.
» Mantener confidencialidad, integridad y disponibilidad de la información
almacenada y trasmitida.
» Proporcionar un servicio seguro a los clientes existentes y potenciales.
» Proporcionar un servicio ininterrumpido a los clientes existentes y potenciales. Se
aplicarán técnicas de monitorización, equilibrio de carga, replicación, recuperación
ante desastres y continuidad del negocio y copias de seguridad recuperables.
» Proporcionar una experiencia de usuario mejorada a los clientes existentes y
potenciales.
» Se establecerán procesos de autenticación, autorización y auditoría.
El sistema estará basado en una típica arquitectura de una aplicación web de tres capas
donde el cliente es un navegador que accede a los servicios proporcionados por el sitio
web de la librería, que contiene una base de datos de los clientes, cuentas y
publicaciones disponibles alojada en un servidor de bases de datos y un servidor web
que implementa toda la lógica de negocio.
Hay que tener en cuenta que nos encontramos en la fase análisis de requisitos del SDLC
identificando requisitos funcionales y de seguridad.

Realización del diagrama DFD de la arquitectura de la aplicación
Para la realización del DFD se utilizará la herramienta Threat analysis and modeling
tool 2016 de la compañía Microsoft, descargable en el siguiente enlace:
https://www.microsoft.com/en-us/download/details.aspx?id=49168
Como ayuda a su manejo, aparte de los manuales que se pueden descargar con
esta herramienta, se aconseja visionar estos dos vídeos:
AppSecEU 16: https://www.youtube.com/watch?v=C5IPkuDnOGs

Microsoft SDL Unit04: https://www.youtube.com/watch?v=WGz2JQ1OlGQ
La aplicación también está disponible, ya instalada y con la plantilla cargada, en el

escritorio virtual de UNIR:
https://salainformaticaunir.u-cloudservices.com
La aplicación permite analizar las amenazas de una aplicación web típica de negocio de
pago electrónico de una librería (textos, libros, revistas, etc.) en formato digital con
opciones de impresión.
El sistema está basado en una típica arquitectura de una aplicación web de tres capas,
donde el cliente es un navegador que acceder a los servicios proporcionados por el sitio
web de la librería, que contiene una base de datos de los clientes, cuentas y
publicaciones disponibles alojada en un servidor bases de datos (que replica a un
hosting externo para tener un backup), un servidor web que implementa toda la lógica
de negocio, un servidor de logs interno como podrían ser un SIEM y por último un
acceso a una pasarela de pagos externa.
Tener en cuenta que nos encontramos en la fase análisis de requisitos del SDLC,
identificando requisitos funcionales y de seguridad.

Información Back-up datos a un

almacenada en tercero
base de datos
Puerto 1433
TCP/IP
Autenticación
Puerto 443
Agente de Aplicación Web Información
HTTP Formulario
Ventas en transito
autenticación
SQL
Server
Puerto 443 Información

TLS en transito
Envió log
Cliente
Servidor ISS
Administrador Servidor de log Procesador
Central de la de tarjetas
Compañia Datos Proceso Presentación de crédito
externo
Topología lógica de la aplicación
Se propone modelar la aplicación mediante el siguiente diagrama DFD que constituye

una representación gráfica que agiliza el proceso de modelado de requerimientos y al
mismo. En la siguiente figura se muestra un modelo básico como ayuda a la realización
del diagrama DFD de la aplicación propuesta. No hay que olvidar configurar las
propiedades de cada elemento del diagrama, por ejemplo, configurar autenticación y
autorización en el servidor web protegerá de posibles amenazas y la herramienta lo
tendrá en cuenta a la hora de calcularlas. Además, saldrán amenazas repetidas. Es
decir, se tendrán menos amenazas.

Un ejemplo puede ser el siguiente, aunque lo puedes modelar de forma diferente según
consideres:
Posible diagrama DFD de la aplicación
La herramienta Threat modeling tool 2016 tiene dos vistas:
» Una de diseño para dibujar el diagrama DFD de la aplicación.

» Una de análisis que calcula las amenazas automáticamente y permite incluir las
salvaguardas manualmente.

Selección de vitas
Vistas Threat analysis and modeling tool 2014
Una vez dibujado el diagrama anterior en la herramienta (u otro que consideres

adecuado para vuestro diseño) produce un análisis automático por cada elemento de la
lista de componentes definidos en el diseño mediante el método STRIDE, tomando
como base la siguiente matriz siguiente:
Relación entre las amenazas del método STRIDE y los elementos de un diagrama DFD.
Cuando se selecciona la vista de análisis, la herramienta mostrará las amenazas

sugeridas para el diagrama de flujo de datos dibujado, donde al clicar en cada una de
ellas nos permite introducir las salvaguardas que consideremos y el análisis DREAD del
paso de la metodología.

Vista análisis Threat analysis and modeling tool
Antes es necesario cargar la plantilla descargable de la plataforma: caso1.tb7 (este

archivo se dejará en el foro, se enviará a las carpetas de descarga o se descarga desde el
siguiente enlace:
http://descargas.unir.net/escueladeingenieria/05 Seguridad_del_Software/caso1.rar
Y cargarla mediante el menú Aply template, según la figura:
Aplicación de Plantilla
Aplicación de plantilla

Valorar las amenazas
Una vez que tenemos identificada la lista de amenazas, el siguiente paso consiste en
puntuarlas de acuerdo al riesgo que suponen. Esto nos permitirá priorizar las
actuaciones a efectuar para mitigar el riesgo.
Para ello utilizaremos el método DREAD (Damage, Reproducibility, Exploitability,

Affected, DIscoverability), en castellano: Daño potencial, Reproductividad,
Explotabilidad, Usuarios afectados y Descubribilidad. El riesgo se puede cuantificar
como el resultado de multiplicar la probabilidad de que la amenaza se produzca, por el
daño potencial de esta:
Riesgo = Probabilidad x Impacto potencial= (R+E+DI) x (D+A) = PxI
Cada valor se cuantifica con un valor entre 1 y 3. En la herramienta se incluye este

análisis modificando las pestañas DREAD (Damage, Reproducibility, Exploitability,
Affected, DIscoverability) a valores de high, medium y low. Hay que realizarlo para
todas las amenazas.
Significado de cada componente valoración del método DREAD.

Se rellena después para cada amenaza la siguiente tabla en la que se incluye un

ejemplo:
Probabilidad Impacto P I Riesgo

de ocurrencia potencial (I)
(P)
Amenaza R / E / DI D/A (R+E+DI) (D+A) PxI
Inyección de ·/2/2 3/3 7 6 42
comandos
SQL
Cálculo riesgo.
Deberás incluir en la memoria esta tabla rellena con al menos 15 de las amenazas
obtenidas de la de la herramienta Threat analysis and modeling tool 2016. Se valorará
que se implemente en idioma español. En la herramienta deberán estar analizadas
todas.
Salvaguardas
Una vez calculado el riesgo con el método DREAD hay que incluir en la herramienta
manualmente para cada una las salvaguardas que ayuden a mitigarlas.
Si se quiere un catálogo más completo de salvaguardas consultar el Libro II de la

Metodología MAGERIT:
http://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metod
olog/pae_Magerit.html#.WTj48mjyjIV

También se puede utilizar como guía el siguiente diagrama:
Salvaguardadas aplicación web
También se puede usar la siguiente tabla de salvaguardas del método STRIDE:
Amenazas Propiedad Salvaguardas

Spoofing identity Autenticación Procesos de autenticación, autorización y
(suplantación de auditoría (AAA): hash, firma digital.
identidad) Protección de secretos.
Protección de secretos.
No almacenamiento de secretos.
Single sign on.
IPSEC
Tempering with Integridad Procesos de AAA: hash, firma digital.
data Códigos de autenticación de mensajes.
(manipulación de Firmas digitales.
datos) Protocolos resistentes a la manipulación.
Listas de control de accesos ACL.
Repudiation No repudio Procesos de autenticación: hash, firma digital.
(repudio) Procesos de auditoría.
Sellado de tiempo.
Information Confidencialidad Procesos de AAA: hash, firma digital.
disclosure Protección de secretos.
(revelación de No almacenamiento de secretos.
información) Protocolos seguros.
Encriptado.
Denial of service Disponibilidad Procesos de AAA: hash, firma digital.
(Denegación de Listas de control de acceso ACL.
servicio) Calidad de servicio.
Elevation of Autorización Listas de control de acceso ACL.
privilege Control de acceso basado en roles.
(elevación de Trabajar con el mínimo privilegio.
privilegios) Validación de entradas.
Figura 29. Salvaguardas método STRIDE.

Metodología de ingeniería de requisitos de seguridad «SQUARE»
Con este trabajo seguiremos profundizando en la ingeniería de requisito de seguridad,

realizando un trabajo sobre la metodología SQUARE que contenga al menos el
siguiente contenido:
» Introducción metodología SQUARE.

» Descripción de los pasos de la metodología.
» Aplicación e inclusión en los diferentes tipos de SDLC: cascada, espiral, RUP y ágil.
» Descripción de algún caso práctico realizado por alguna organización.
» Aplicación al caso práctico descrito en el trabajo «Metodologías de modelado de
amenazas».
Para la realización del caso práctico se puede utilizar la herramienta de apoyo a la

metodología, obtenible en la web de descarga:
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=508052
También se puede descargar una máquina virtual con la aplicación instalada en el

siguiente enlace:
http://descargas.unir.net/escueladeingenieria/05%20Seguridad_del_Software/C7%28
psquare%29.ova
Las credenciales de la misma son:
» Usr: auditor
» pw: Tics2016!
Para acceder a la aplicación tendrás que abrir el navegador Firefox y pinchar en el

acceso directo psquare, las credenciales de la aplicación son:
» User: admin
» Pw: yessir

Test
1. Señala la o las respuestas correctas. ¿Qué incluye la seguridad del software?

A. Patrones de codificación.
B. Principios de diseño seguro.
C. Casos de uso.
D. Buenas prácticas de seguridad.
2. Señala la o las respuestas correctas. Los patrones de ataque en la fase de diseño y

arquitectura:
A. Ayudan a definir el comportamiento del sistema para prevenir o reaccionar ante
un tipo específico de ataque probable.
B. Especifican debilidades aprovechadas por los ataques, orientando qué técnicas o
prácticas de seguridad de desarrollo evitan estas deficiencias.
C. Proporcionan el contexto de las amenazas al que el software se va a enfrentar,
de forma que permite diseñar arquitecturas seguras.
D. Proporcionan ejemplos de ataques que aprovechan las vulnerabilidades de la
arquitectura elegida.
3. Señala la o las correctas. Respecto a los casos de uso de seguridad:

A. Analizan y especifican los requisitos de seguridad.
B. Analizan y especifican las amenazas a la seguridad.
C. Análisis de vulnerabilidades de activos y amenazas.
D. Análisis forense de las actividades maliciosas.
TEMA 2 – Test 88 © Universidad Internacional de La Rioja (UNIR)

4. Señala la o las respuestas incorrectas. Respecto a la ingeniería de requisitos de

seguridad:
A. Requisitos de software seguro. Requisitos que afectan directamente a la
probabilidad de que el software sea seguro.
B. Requisitos de software seguro. Especificación de funciones que implementan
una política de seguridad, como control de acceso, autenticación, autorización,
cifrado y gestión de claves. Estas previenen la violación de la seguridad del
sistema o de la información que procesa, como el acceso no autorizado,
modificación, denegación de servicio, etc.
C. Los requerimientos no funcionales de seguridad deben especificar: propiedades
que el software debe exhibir.
D. Los requerimientos no funcionales de seguridad deben especificar: los controles
y normas que rigen los procesos de desarrollo, implementación y operación del
software.
5. Señala la respuesta incorrecta. El análisis de riesgo implica tres pasos básicos:

A. Análisis de ambigüedad.
B. Análisis de resistencia al ataque.
C. Análisis de robustez.
D Análisis de debilidad.
6. Señala la o las respuestas correctas. 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 defensor.
7. Señala la o las respuestas correctas. El principal problema de las herramientas de

análisis estático:
A. Falsos negativos que produce.
B. Gran cantidad de defectos que encuentra.
C. Reglas de la herramienta.
D. Falsos positivos que produce.

8. Señala la o las respuestas correctas. 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.
9. Señala la o las respuestas correctas. 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.
10. Señala 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.

Tema 2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tema 2

Hochgeladen von

Copyright:

Verfügbare Formate

Seguridad en el ciclo de vida del software

[2.1] ¿Cómo estudiar este tema?

[2.2] Introducción a la seguridad en ciclo de vida del

[2.3] Seguridad en las fases del S-SDLC

[2.4] Modelado de ataques

[2.5] Casos de abuso

[2.6] Ingeniería de requisitos de seguridad

[2.7] Análisis de riesgo. Arquitectónico

[2.8] Patrones de diseño

[2.9] Pruebas de seguridad basadas en riesgo

[2.10] Revisión de código 2

[2.12] Operaciones de seguridad

[2.13] Revisión externa

[2.14] Referencias bibliográficas

Modelado de Ingeniería y requisitos Test de Operaciones de

Espe cificación de Cue stione s sobre la Arquitectura de Consideraciones

© Universidad Internacional de La Rioja (UNIR)

2.1. ¿Cómo estudiar este tema?

El objetivo del presente tema es introducirte en las diferentes prácticas de

2.2. Introducción a la seguridad en ciclo de vida del software

Como se ha comentado en el tema anterior, se puede definir la seguridad del software

El conjunto de principios de diseño y buenas prácticas a implantar en el SDLC, para

El aumento de los ataques al software vulnerable ha dejado patente la insuficiencia de

TEMA 2 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

Según Gartner dos tercios de las aplicaciones son vulnerables:

Figura 1. Vulnerabilidad aplicaciones. Fuente: Gartner Inc.

El desarrollo de software seguro y confiable requiere la adopción de un proceso

Una de las principales ventajas de la adopción de un S-SDLC es el descubrimiento

TEMA 2 – Ideas clave 4 © Universidad Internacional de La Rioja (UNIR)

Una vez desplegado el software, es fundamental mantener el nivel de seguridad y

Poner en funcionamiento prácticas de seguridad del software, que permitan obtener un

Normalmente, el modelo más propicio para el desarrollo de software en las

En el apartado siguiente se presenta un conjunto mínimo de prácticas de seguridad,

Mayor probabilidad de capturar adecuadamente los requisitos, tomar decisiones de

TEMA 2 – Ideas clave 5 © Universidad Internacional de La Rioja (UNIR)

Dificultad de los agentes maliciosos para explotar vulnerabilidades y debilidades del

El objetivo del presente tema es introducir al alumno en las diferentes prácticas de

2.3. Seguridad en las fases del S-SDLC

La seguridad del software es algo más que la eliminación de las vulnerabilidades y

Las organizaciones que realizan desarrollos de software, como medida de fomento de

No existe una metodología de ingeniería de seguridad de software que haya probado

TEMA 2 – Ideas clave 6 © Universidad Internacional de La Rioja (UNIR)

de vida seguido. Lo que sí es importante es que la seguridad sea considerada

Figura 3. Mejores prácticas de seguridad del software en el SDLC.

La figura anterior, propone un ciclo de vida de desarrollo de software SDLC en cascada

TEMA 2 – Ideas clave 7 © Universidad Internacional de La Rioja (UNIR)

En la tabla siguiente se representan las prácticas de seguridad y su relación en cada una

En los siguientes apartados de este tema se desarrollan las prácticas de seguridad

2.4. Modelado de ataques

El principal objetivo de la seguridad del software es el mantener sus propiedades

TEMA 2 – Ideas clave 8 © Universidad Internacional de La Rioja (UNIR)

El equipo trabaja para construir un software con las propiedades de

El equipo se esfuerza por comprender la naturaleza exacta de la amenaza

Figura 4. Perspectivas de modelado.

Figura 5. Modelado de ataques.

El uso combinado de patrones de ataque y árboles de ataque captura la probabilidad de

TEMA 2 – Ideas clave 9 © Universidad Internacional de La Rioja (UNIR)

Un ataque aprovecha una vulnerabilidad de una aplicación mediante un

Los patrones de ataque constituyen un mecanismo o medio para capturar y

En definitiva, constituyen una clasificación de los ataques y una representación

Un catálogo de patrones de ataques, que proporciona un conjunto de definiciones

Actualmente incluye 519 patrones reales de ataque, disponible en:

TEMA 2 – Ideas clave 10 © Universidad Internacional de La Rioja (UNIR)