Tema 3

Desarrollo de Software Seguro

Tema 3. Seguridad en el ciclo

de vida del software en las
fases de análisis
Índice
Esquema

Ideas clave

3.1. Introducción y objetivos

3.2. La seguridad en el ciclo de vida del software

3.3. Casos de abuso

3.4. Modelado de ataques

3.5. Ingeniería de requisitos de seguridad

3.6. Referencias bibliográficas

A fondo

Implementación simplificada del proceso SDL

Modelos SDLC de última generación

Test
 Esquema

Desarrollo de Software Seguro 3

Tema 3. Esquema
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

3.1. Introducción y objetivos

Actualmente, 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 minimizar al máximo los ataques en la capa de aplicación y, por lo

tanto, el número de vulnerabilidades explotables.

El desarrollo de software seguro y confiable requiere de 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 deben integrar en él dos tipos de actividades de seguridad: la primera es

e l seguimiento de unos principios de diseño seguro (mínimo privilegio, por

ejemplo); y la segunda, la inclusión de una serie de buenas prácticas de seguridad

(especificación de requisitos de 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 las etapas tempranas de su

desarrollo, lo que implica un importante ahorro de costes.

Figura 1. Ataques de la capa aplicación. Fuente: Hoglund y McGraw (2004).

Desarrollo de Software Seguro 4

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

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,

sino la incorporación de buenas prácticas de seguridad en las diferentes fases de

este, así como unos hitos o puntos de control donde se verifiquen los entregables de

las mismas.

A lo largo del tema se presentará un conjunto mínimo de prácticas de seguridad

que deberían ser una parte integral del S-SDLC en la fase de análisis y requisitos.

Entre las razones principales para añadir prácticas de seguridad en el SDLC

destacan:

▸ 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.

Los objetivos del presente tema son los siguientes:

▸ Conocer y comprender las buenas prácticas de seguridad que se deben incluir en un

S-SDLC en las fases de requisitos.

▸ Profundizar en el estudio de una de las principales prácticas de seguridad como es

el análisis de riesgo de casos de abuso.

▸ Familiarizar al alumno con prácticas de seguridad como el modelado de ataques y la

ingeniería de requisitos de seguridad.

Desarrollo de Software Seguro 5

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

3.2. La seguridad en el ciclo de vida del software

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 es la adopción por

los gerentes de un enfoque sistémico que incorpore los principios de diseño 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

poder verificar su seguridad. A este nuevo ciclo de vida lo denominaremos ciclo de

vida del software seguro o S-SDLC.

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 lo tanto, no importa cuál es el modelo de ciclo de

vida seguido, sino que la seguridad sea considerada desde las primeras etapas del

ciclo de vida del software.

Figura 2. Mejores prácticas de seguridad del software en el SDLC. Fuente: elaboración propia.

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

cascada, basado en el modelo de McGraw (2005). Sería similar también para otro

tipo, como el iterativo, donde se especifican las actividades y prácticas de seguridad

Desarrollo de Software Seguro 6

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

a efectuar en cada fase de este. A continuación, se enumeran esas actividades o

mejores prácticas de seguridad del software:

▸ Casos de abuso.

▸ Modelado de ataques.

▸ Ingeniería de requisitos de seguridad.

▸ Modelado de amenazas.

▸ Análisis de riesgo arquitectónico.

▸ Patrones de diseño.

▸ Pruebas de seguridad basadas en riesgo.

▸ Revisión de código.

▸ Pruebas de penetración.

▸ Operaciones de seguridad.

▸ Revisión externa.

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

una de las fases donde son aplicables:

Desarrollo de Software Seguro 7

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Tabla 1. Relación entre las prácticas de seguridad y las fases del ciclo de vida. Fuente: elaboración propia.

En los siguientes apartados de este tema se desarrollarán las distintas prácticas de

seguridad propuestas para el ciclo de vida.

Desarrollo de Software Seguro 8

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

3.3. Casos de abuso

L o s 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 utiliza para analizar y especificar las amenazas de seguridad. Yuan y sus

colaboradores (2015) lo 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» (Yuan et al., 2015).

Figura 3. Casos de abuso. Fuente: elaboración propia.

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, más allá de los aspectos

normativos y funcionales y estudiando los eventos negativos o inesperados. Los

profesionales de seguridad de software entienden mejor cómo crear software

seguro, pues obtienen una mejor comprensión de las áreas de riesgo del sistema a

través de:

Desarrollo de Software Seguro 9

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Identificación de los objetivos de seguridad que debe cumplir el software.

▸ Identificación de las amenazas de seguridad a ser mitigadas por el software.

▸ Identificación de los puntos en el software susceptibles de ser atacados.

▸ Obtención de las restricciones o requisitos no funcionales de seguridad (requisitos

negativos), necesarios para alcanzar los objetivos de seguridad.

▸ Obtención de los requisitos de seguridad funcionales (requisitos positivos) de los

mecanismos que garanticen que el software cumple con los objetivos de seguridad.

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 la 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 sus

requisitos de seguridad.

Los casos de abuso describen lo que el software no debe hacer en respuesta al uso
incorrecto o malintencionado de este por un agente malicioso. Para cada caso de

uso funcional, el desarrollador deberá explorar las formas en que esa función podría

ser deliberadamente mal utilizada. También tiene que identificar todas las posibles

relaciones entre casos de uso de seguridad y casos abuso, con el fin de especificar

restricciones y requisitos de seguridad para evitar un mal uso o abuso de las

funcionalidades del software.

En la siguiente figura se muestra la relación entre el caso de uso de seguridad y el

de abuso asociado:

Desarrollo de Software Seguro 10

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 4. Relación entre el caso de uso de seguridad y el de abuso asociado. Fuente: Donald (2003).

En la siguiente tabla se resumen las diferencias entre los casos de uso de seguridad

y los casos de abuso:

Tabla 2. Diferencias entre los casos de uso de seguridad y los casos de abuso. Fuente: elaboración propia

a partir de Donald (2003).

Caso de uso de seguridad y caso de abuso

A continuación, presentamos un ejemplo de un diagrama de casos de uso de

seguridad y sus casos de abuso asociados en su versión gráfica. La siguiente figura

(Sindre y Opdahl, 2001) muestra un caso de abuso en un ejemplo de comercio

electrónico que presenta varias relaciones:

Desarrollo de Software Seguro 11

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Relación caso de abuso: uso de seguridad, «incluye» y «extiende».

▸ Relación caso de uso: abuso, «previene» y «detecta».

Los casos de uso resultantes de especificar los requisitos de seguridad protegen al

cajero automático y a sus usuarios de las amenazas potencialmente realizables por

un cibercriminal.

Figura 5. Ejemplo de caso de uso de seguridad y caso de abuso. Fuente: Sindre y Opdahl (2001).

La siguiente tabla muestra un ejemplo de especificación del caso de abuso «Obtener

contraseña» del diagrama de casos de uso y abuso de la figura anterior:

Desarrollo de Software Seguro 12

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Tabla 3. Especificación de caso de abuso «Obtener contraseña». Fuente: elaboración propia.

En el siguiente vídeo, Casos de abuso, puedes ver un resumen de todo lo tratado en

este epígrafe:

Casos de abuso

Desarrollo de Software Seguro 13

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Accede al vídeo:
https://unir.cloud.panopto.eu/Panopto/Pages/Embed.aspx?id=97c8c78c-2eae-

4534-8c46-b17f0116c016

Desarrollo de Software Seguro 14

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

3.4. Modelado de ataques

El principal objetivo de la seguridad del software es el de 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 los

principios de diseño del software seguro, se necesita que el personal de diseño y

desarrollo genere dos perspectivas:

Figura 6. Perspectivas de modelado. Fuente: elaboración propia.

La perspectiva del atacante se suele modelar de las siguientes dos formas:

▸ Patrones de ataque.

▸ Árboles de ataque.

Figura 7. Modelado de ataques. Fuente: elaboración propia.

Desarrollo de Software Seguro 15

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

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

probabilidad de cómo los ataques se pueden combinar y secuenciar, lo que

proporciona una serie de datos que nos permiten 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.

Un patrón de ataque se pude definir como:

Mecanismo o medio para capturar y representar la perspectiva y el

conocimiento del ciberatacante con el suficiente detalle acerca de cómo

los ataques 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 u n a representación

estructurada del pensamiento del atacante para que el equipo de diseño y

desarrollo obtenga el conocimiento y los pasos necesarios a realizar con el fin de

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, lo constituye la iniciativa del MITRE Common Attack

Desarrollo de Software Seguro 16

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Pattern Enumeration and Classification (CAPEC). Actualmente, incluye 519

patrones reales de ataque.

Accede al catálogo a través del aula virtual o desde la siguiente dirección web:

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 tiene diferentes utilidades en cada una de sus fases.

En la siguiente tabla se muestra un resumen de los usos de los patrones de ataques

en las diferentes fases del SDLC:

Tabla 4. Aplicación de patrones de ataque a las diferentes fases del SDLC. Fuente: elaboración propia.

Desarrollo de Software Seguro 17

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

U n patrón de ataque, como mínimo, debe describir ampliamente el incidente, las

habilidades y los recursos necesarios para ejecutarlo con éxito y en qué contexto 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:

Tabla 5. Alcance de información de un patrón de ataque. Fuente: elaboración propia.

Desarrollo de Software Seguro 18

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Á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 las

dependencias de las vulnerabilidades de este, que un atacante puede

aprovechar para comprometerlo.

En un árbol de ataque, el objetivo del atacante se coloca en la parte superior del

árbol. Las posibles alternativas de ataque se documentan en los diferentes recorridos

del árbol por los nodos de nivel inferior, 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 lo hacen posible.

▸ Se enfoca en las causas de las vulnerabilidades, pero no identifica las

contramedidas.

▸ Representa de forma gráfica y textual directrices de codificación segura y patrones

de seguridad.

Desarrollo de Software Seguro 19

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

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, es

representada en el primer nivel sin sangría y cada objetivo de nivel inferior se

enumera con sangría de una unidad por nivel de descomposición:

Figura 8. Estructura textual de un árbol de ataque. Fuente: elaboración propia.

▸ Gráfica 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:

Desarrollo de Software Seguro 20

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Figura 9. Representación gráfica o semántica de la estructura de un árbol de ataque. Fuente: elaboración

propia.

Figura 10. Vista conceptual de un árbol de ataque. Fuente: elaboración propia a partir de Redwine et al.

(2006).

Desarrollo de Software Seguro 21

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

3.5. Ingeniería de requisitos de seguridad

Gran parte de las vulnerabilidades y debilidades del software tiene su

origen en unos requisitos inadecuados, inexactos e incompletos,

principalmente debido a la falta o la debilidad de la especificación de

estos, que no determinan las funciones, restricciones y propiedades no

funcionales del software que hacen que este sea previsible, confiable y

resistente.

Los defectos en los requisitos cuestan de diez a doscientas veces más de corregir
durante la ejecución que si se detectan durante su especificación. 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.

Figura 11. Ingeniería de requisitos. Fuente: elaboración propia.

Desarrollo de Software Seguro 22

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

Los requisitos de seguridad deben ser considerados simultáneamente

junto con los demás requisitos, incluidos los relativos a funcionalidad,

rendimiento y facilidad de uso. Ya que los requisitos de seguridad, a

menudo, entran en conflicto con ellos, se hace necesario, por lo tanto, la

integración satisfactoria de la ingeniería de requisitos de seguridad con

la ingeniería de requisitos en su conjunto.

En la siguiente figura se muestra un alcance completo de los requisitos de seguridad

de una aplicación:

Figura 12. Requisitos de seguridad. Fuente: elaboración propia.

Desarrollo de Software Seguro 23

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Requisitos servicios de seguridad (funcionales o positivos). Incluyen 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. Deben

especificar:

• Propiedades que el software debe exhibir, por ejemplo: el software debe tener un
comportamiento correcto y predecible y disponer de capacidades de recuperación
frente a ciberataques.

• Nivel requerido de seguridad y salvaguardas de riesgo de las funciones de

seguridad.

▸ Requisitos de software seguro (no funcionales o negativos). 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.

▸ Operacionales. Mas enfocados a los controles y normas que rigen los procesos de

desarrollo, implementación y operación del software.

Es fundamental que los requisitos de seguridad del software sean:

▸ Completos. Una especificación de requisitos puede considerarse completa solo

cuando es suficiente para distinguir entre un comportamiento deseado y uno no

deseado, como puede ser el proveniente de entradas y estímulos externos previstos

e imprevistos no solo durante el funcionamiento normal, sino también cuando el

software o cualquiera de sus recursos presenten fallos parciales o totales y, sobre
todo, cuando el software esté bajo un ciberataque.

▸ Precisos. El requisito debe ser único, breve y conciso. Cada palabra extra es una

invitación para introducir defectos.

▸ Coherentes. Cada requisito debe ser comprensible, claro y tener solamente una

interpretación.

Desarrollo de Software Seguro 24

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Trazables. Esto es necesario para asegurar que los requisitos del software no se

pierden en las siguientes fases del diseño o implementación. Es este sentido, el

establecimiento de una trazabilidad entre los artefactos del software y el modelado
de las amenazas, ataques y vulnerabilidades forman la base de la definición de los
requisitos de seguridad del software.

▸ Verificables. Los requisitos de seguridad deben permitir identificar requisitos tanto

de acciones concretas y verificables como de no verificables de requisitos negativos

no funcionales.

Uno de los retos más importantes de la ingeniería de requisitos de seguridad es la

identificación o captura de requisitos de seguridad negativos, es decir, los

requisitos de restricciones en funcionalidades debidos a seguridad y los requisitos no

funcionales de seguridad. Como ejemplo, los provenientes de propiedades de

software o directrices o normas de desarrollo de software.

Los requisitos negativos existen porque hay ciertas funcionalidades del software que
no se deben permitir, pues pueden inducir un estado de inseguridad que le hace

vulnerable, por lo que puede llegar a ser comprometido mediante un exploit. Por

ejemplo:

REQ-1. El software no debe utilizar datos de entrada que no se hayan

validado.

Los requerimientos no funcionales de seguridad deben especificar:

▸ Propiedades que el software debe exhibir, por ejemplo: el software debe tener un

comportamiento correcto y predecible y disponer de capacidades de recuperación

frente a ciberataques.

▸ Nivel requerido de seguridad y salvaguardas de riesgo de las funciones de

seguridad.

Desarrollo de Software Seguro 25

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Los controles y normas que rigen los procesos de desarrollo, implementación y

operación del software.

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, la implementación y las pruebas.

Con relación a lo anterior, es de vital importancia que los requisitos de seguridad

funcionales y no funcionales de los componentes COTS y de software libre

sean analizados, ya que a menudo no alcanzan el nivel de fiabilidad, confiabilidad y

recuperación requeridos.

En teoría, un requisito surge cuando se identifica una necesidad. En la práctica,

otros factores son los que llevan a su detección, como la necesidad de reemplazar

una capacidad cuando un equipamiento obsoleto alcanza su fecha de caducidad,

cambios en la normativa técnica, cambios en la política de seguridad de la

organización que requieren una nueva capacidad, avances en la tecnología que

ponen al alcance nuevas capacidades y modificaciones en el entorno operacional.

Las fuentes más comunes de los requisitos de seguridad para software son:

▸ Política de seguridad de la organización.

▸ Normativa de obligado cumplimiento durante el desarrollo, la implantación y la

operación del software.

▸ Casos de abuso.

▸ Análisis de los modelos de ataque y análisis de riesgo realizado.

▸ Implicaciones de seguridad de la especificación funcional, en cuanto a posibles

vulnerabilidades estimadas de los modelos de ataque y operación de una manera

Desarrollo de Software Seguro 26

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

que no comprometa cualquier parte del software o cualquier otro programa externo
con los que interactúa.

▸ Análisis de la amenaza: a partir de las características de la amenaza de la que surge

la necesidad de la capacidad o del sistema se pueden deducir requisitos.

▸ Avances en investigación y nuevas tecnologías que pueden aportar nuevas

soluciones e ideas que mejoren los procesos del sistema.

▸ Reuniones de grupos de usuarios, que pueden poner en común sus necesidades y

problemas, proponer nuevos requisitos o modificar los ya existentes.

▸ Vulnerabilidades conocidas en los componentes COTS y tecnologías de software

libre.

▸ Requisitos de funciones de seguridad en términos de fiabilidad, confiabilidad y

robustez.

Un modelo útil simplificado de una aplicación para la especificación y análisis de

requisitos es el representado en la figura siguiente, en el que de forma general se

incluyen cinco componentes que contienen todos los programas:

Figura 13. Modelo de aplicación para la especificación y análisis de requisitos. Fuente: elaboración propia.

▸ Interfaz de entrada.

▸ Interfaz de salida.

▸ Datos internos.

Desarrollo de Software Seguro 27

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

▸ Datos críticos de seguridad, como claves criptográficas, datos relacionados con

privilegios y otros datos críticos.

▸ Algoritmos: lógica interna del programa, que procesa los datos internos.

Desde el punto de vista de seguridad de la aplicación, es necesario proteger cada

uno de los cinco componentes de los ciberataques. En este sentido, disponer de

escenarios de operación y uso puede ser de gran ayuda para la comprensión de las

necesidades de seguridad, las capacidades de respuesta a amenazas y una posible

estimación de los daños, así como otros requisitos de calidad como el rendimiento.

Puedes consultar el siguiente vídeo, Ingeniería de requisitos de seguridad, para ver

ejemplos de lo explicado:

Ingeniería de requisitos de seguridad

Accede al vídeo:
https://unir.cloud.panopto.eu/Panopto/Pages/Embed.aspx?id=401a29d1-60cd-

480b-b1cc-b17f011b1992

Desarrollo de Software Seguro 28

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 Ideas clave

3.6. Referencias bibliográficas

Donald, G. (2003). Security use cases. Journal of Object Technology, 2(2), pp. 53-64.
https://www.jot.fm/issues/issue_2003_05/column6/

Hoglund, G. y McGraw, G. (2004). Exploiting software: How to break code. Addison-

Wesley Software Security Series.

McGraw, G. (2005). Software security: Building security in. Addison Wesley

Professional.

Redwine, S. T. Bishop, M., McGraw, G. et al. (2006). Workshop on secure software

engineering education & training. En Proceedings. 19th Conference on Software

Engineering Education and Training. CSEE&T.

https://ieeexplore.ieee.org/document/1617355

Sindre, G. y Opdahl, A. L. (2001). Capturing security requirements through misuse

c a s e s . Proceedings of the 14th Norsk Information Conference (NIK2001).

https://www.se.rit.edu/~se555/Reading%20Materials/Capturing%20Security%20Requ

irements%20through%20Misuse%20Cases.pdf

Yuan, X., Borkor, E., Williams, I. y Yu, H. (2015). Developing abuse cases based on

threat modeling and attack patterns. Journal of Software, 10, pp. 491-498.

https://www.jsoftware.us/vol10/41-E024.pdf

Desarrollo de Software Seguro 29

Tema 3. Ideas clave
© Universidad Internacional de La Rioja (UNIR)
 A fondo

Implementación simplificada del proceso SDL

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

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

Este documento describe los conceptos básicos del Microsoft Security Development

Lifecycle (SDL) y las actividades de seguridad individuales en cada una de sus fases.

Desarrollo de Software Seguro 30

Tema 3. A fondo
© Universidad Internacional de La Rioja (UNIR)
 A fondo

Modelos SDLC de última generación

Secappdev.org (2017, marzo 10). Secure development lifecycles (SDLC):

Introduction and process models. Bart De Win [Vídeo]. YouTube.

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

En este vídeo se expone una visión general de los modelos SDLC de última

generación con el fin de discutir sus fundamentos y piedras angulares, lo que ayuda

a comprender su alcance y diferentes conceptos. También se desarrolla la

perspectiva de los modelos de cascada y de desarrollo ágil.

Secure development lifecycles (SDLC): Introduction and process models

Accede al vídeo:

https://www.youtube.com/embed/L-gL1YQUrwg?si=Ryldo2g7EQ3IJrlQ

Desarrollo de Software Seguro 31

Tema 3. A fondo
© Universidad Internacional de La Rioja (UNIR)
 Test

1. Indica la diferencia entre los casos de uso de seguridad y los casos de abuso.

A. El caso de abuso analiza y especifica las amenazas a la seguridad,

mientras que el caso de uso de seguridad analiza y especifica los requisitos

de seguridad.

B. El criterio de éxito de un caso de abuso y un caso de uso de seguridad es

el éxito del atacante.

C. El caso de uso de seguridad es conducido por el análisis de

vulnerabilidades de activos y amenazas y el caso de abuso por los casos de

abuso de seguridad.

D. El caso de abuso y el caso de uso de seguridad son usados por el equipo

de seguridad.

2. 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 otros ataques.

B. Especifican debilidades no 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.

D. Facilitan ejemplos de ataques que no aprovechan las vulnerabilidades de

la arquitectura elegida.

3. Respecto a los casos de uso de seguridad:

A. Analizan y especifican los requisitos de seguridad funcionales.

B. Analizan y especifican las amenazas a la seguridad.

C. Realizan el análisis de vulnerabilidades de activos y amenazas.

D. Llevan a cabo el análisis forense de las actividades maliciosas.

Desarrollo de Software Seguro 32

Tema 3. Test
© Universidad Internacional de La Rioja (UNIR)
 Test

4. ¿Qué no incluye 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 servicios de seguridad.

C. Requerimientos no funcionales de seguridad, que deben especificar

propiedades que el software debe exhibir.

D. Requerimientos no funcionales de seguridad, que 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. Los requisitos de los servicios de seguridad

deben especificar:

A. Propiedades que el software debe exhibir.

B. Nivel requerido de seguridad y salvaguardas de riesgo de las funciones de

seguridad.

C. Los controles y normas que rigen los procesos de desarrollo,

implementación y operación del software.

D. La reducción o eliminación de las vulnerabilidades del software, como

validación de entradas, comprobación de límites de búfer, ejecución de

entornos aislados… El análisis de riesgo arquitectónico implica el desarrollo

de los tres siguientes pasos básicos: análisis de ambigüedad, análisis de

resistencia al ataque y análisis de debilidad.

Desarrollo de Software Seguro 33

Tema 3. Test
© Universidad Internacional de La Rioja (UNIR)
 Test

6. ¿Cuál de las siguientes respuestas es una de las perspectivas que el equipo de

desarrollo tiene que adoptar a la hora de diseñar unas pruebas de seguridad

basadas en el riesgo?

A. Perspectiva de gerencia.

B. Perspectiva del atacante.

C. Perspectiva del usuario.

D. Perspectiva del analista.

7. Indica la utilidad de los patrones de ataque en la etapa de especificación de

requisitos.

A. Proporciona ejemplos de ataques que aprovechan las vulnerabilidades de

la arquitectura elegida.

B. Pueden ser utilizados para orientar las pruebas de seguridad del software

en un contexto práctico y realista, identificando debilidades concretas con el

fin de generar casos de prueba para cada componente.

C. Permiten la selección de políticas de seguridad y configuraciones acordes

a las amenazas obtenidas de los patrones de ataque.

D. Ayudan a definir el comportamiento del sistema para prevenir o reaccionar

ante un tipo específico de ataque probable.

8. Un método sistemático para caracterizar la seguridad de un sistema, basado en

la combinación y las dependencias de las vulnerabilidades de este, que un atacante

puede aprovechar para comprometerlo, se denomina:

A. Método de ataque.

B. Patrón de ataque.

C. Árbol de ataque.

D. Modelo de ataque.

Desarrollo de Software Seguro 34

Tema 3. Test
© Universidad Internacional de La Rioja (UNIR)
 Test

9. Señala la respuesta incorrecta sobre los casos de abuso.

A. Los casos de abuso constituyen unas buenas prácticas para la obtención

de los requisitos funcionales de una aplicación, referidos a actividades que

debería realizar el sistema.

B. 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.

C. Los casos de abuso, o casos de mal uso, son un instrumento que puede

ayudar a pensar de la misma forma en que lo hacen los atacantes.

D. 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.

10. Indica en qué fase del ciclo de vida de desarrollo del software es aplicable el

modelado de ataque:

A. Especificación de requisitos.

B. Diseño del sistema.

C. Codificación.

D. Todas las anteriores.

Desarrollo de Software Seguro 35

Tema 3. Test
© Universidad Internacional de La Rioja (UNIR)