El problema de la seguridad en el software

[1.1] ¿Cómo estudiar este tema?

[1.2] Introducción al problema de la seguridad en el software

[1.3] Vulnerabilidades y su clasificación

[1.4] Propiedades software seguro

[1.5] Principios de diseño seguridad del software

[1.6] Tipos de S-SDLC

[1.7] Metodologías y estándares

[1.8] Referencias bibliográficas

1 TEMA
 Problemas de la seguridad del software

Los pilares de la
Vulnerabilidades Principios de diseño seguridad del Metodología y
Tipos de S-SDLC seguridad del
y su clasificación software estándares
software
Esquema

Ciclo de vida de una Defensa en Se paración Se guridad de l

Ciclos de vida de Gestión del

TEMA 1 – Esquema
vulne rabilidad profundidad código, e ntorno software ve rsus
software se guro conocimie nto
Gestión de Simplicidad de e jecución ase guramie nto

vulne rabilidade s dise ño inse guro, de la calidad

Aplicación a
re gistros Gestión del Estándare s de
Clasificación de Mínimo me todología
eventos rie sgo calidad y
vulne rabilidade s privile gio ágile s
se guridad se guridad de l
Estándare s de Se paración
Bue nas software
vulne rabilidade s privile gios Fallar de forma
prácticas de

2
Se paración se gura Amenazas a la se guridad de l
dominios Dise ño SW seguridad del software software
resistente,
Se guridad por
Propiedades Perspectiva
oscuridad y
software seguro atacante
defecto
Tipos atacante s
Esenciales:
Confide ncialidad
Inte gridad
Disponibilidad

Complementarias:
Fiabilidad
Aute nticación

© Universidad Internacional de La Rioja (UNIR)

Trazabilidad
Seguridad en el Software

Robuste z
Re silie ncia
Tole rancia
 Seguridad en el Software

Ideas clave

1.1. ¿Cómo estudiar este tema?

Actualmente las tecnologías de seguridad red pueden ayudar a aliviar y mitigar los
ciberataques, pero no resuelven el problema de seguridad real ya que una vez que el
ciberatacante consigue vencer esas defensas, por ejemplo, mediante ingeniería social, y
comprometer una máquina del interior, a través de la misma podrá atacar las demás
empezando por las más vulnerables. Se hace necesario, por tanto, el disponer de
software seguro que funcione en un entorno agresivo y malicioso.

El objetivo del presente tema es introducir al alumno en los principales conceptos que
abarca la seguridad del software en cuanto a los beneficios que produce, su
importancia en la seguridad global de un sistema, las propiedades de un software
seguro, sus principios de diseño, los ataques a los que se tiene que enfrentar y los
estándares de seguridad aplicables a los procesos de desarrollo seguro de
software.

1.2. Introducción al problema de la seguridad en el software

Hoy en día, los ataques cibernéticos son cada vez más frecuentes, organizados y
costosos en el daño que infligen a las administraciones públicas, empresas privadas,
redes de transporte, redes de suministro y otras infraestructuras críticas desde la
energía a las finanzas, hasta el punto de poder llegar a ser una amenaza a la
prosperidad, la seguridad y la estabilidad de un país.

En la figura-1 se puede observar un gráfico cualitativo en el que se muestran diversos

incidentes ocurridos a lo largo de los últimos doce años en relación con su nivel de
complejidad. Como se puede observar la amenaza es creciente con los años y cada
vez su nivel de complejidad es mayor.

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

 Seguridad en el Software

Figura 1. Incidentes de seguridad.

La sociedad está cada vez más vinculada al ciberespacio, un elemento importante del
mismo lo constituye el software o las aplicaciones que proporcionan los servicios,
utilidades y funcionalidades. Sin embargo, estas aplicaciones presentan defectos,
debilidades de diseño o configuraciones inseguras que originan
vulnerabilidades pueden ser explotadas por atacantes de diversa índole desde
aficionados hasta organizaciones de cibercrimen o incluso estados en acciones de
ciberguerra, utilizándolas como plataformas de ataque comprometiendo los sistemas y
redes de la organización.

Nadie quiere software defectuoso, especialmente los desarrolladores, cuyo código

incorrecto es el problema. En un informe de Klocwork (2004) se indica que las
principales causas de la aparición de vulnerabilidades son las siguientes:

» Tamaño excesivo y complejidad de las aplicaciones.

» Mezcla de código proveniente de varios orígenes como compras a otra
compañía, reutilización de otros existentes, etc., lo que puede producir
comportamientos e interacciones no esperados de los componentes del software.
» Integración de los componentes del software defectuosa, estableciendo
relaciones de confianza inadecuadas entre ellos, etc.
» Debilidades y fallos en la especificación de requisitos y diseño no basados
en valoraciones de riesgo y amenazas.
» No realización de pruebas seguridad basadas en riesgo.

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

 Seguridad en el Software

» Uso entornos de ejecución con componentes que contienen vulnerabilidades

o código malicioso embebido, como pueden ser capas de middleware, sistema
operativo u otros componentes COTS.
» Falta de herramientas y un entorno de pruebas adecuados que simule
adecuadamente el real de ejecución.
» Cambios de requisitos del proyecto durante la etapa de codificación.
» Mezcla de equipos de desarrolladores, entre los que podemos tener, equipos
propios de desarrollos, asistencias técnicas, entidades subcontratadas, etc.
» Falta de conocimiento de prácticas de programación segura de los
desarrolladores en el uso de lenguajes de programación propensos a cometer errores
como C y C++ y utilización de herramientas de desarrollo inadecuadas.
» No control de la cadena de suministro del software, lo puede dar lugar a la
introducción de código malicioso en origen.
» No seguimiento, por los desarrolladores, de guías de normalizadas de estilo en
la codificación.
» Fechas límite de entrega de proyectos inamovibles.
» Cambio en la codificación en base al requerimiento de nuevas funcionalidades.
» Tolerancia a los defectos.
» No tener actualizadas las aplicaciones en producción con los parches
correspondientes, configuraciones erróneas, etc.

Las aplicaciones son amenazadas y atacadas, no solo en su fase de operación, sino que
también en todas las fases de su ciclo de vida (Goertzel. 2009):

» Desarrollo. Un desarrollador puede alterar de forma intencionada o no el software bajo

desarrollo de forma que se comprometa su fiabilidad futura durante la fase de operación.
» Distribución e instalación. Ocurre cuando no se protege el software evitando
manipulaciones antes de enviarlo o publicarlo. Del mismo modo, si el instalador del
software no bastiona la plataforma en la que lo instala o la configura de forma
insegura, queda vulnerable a merced de los atacantes.
» Operación. Cualquier software que se ejecuta en una plataforma conectada a la red
tiene sus vulnerabilidades expuestas durante su funcionamiento. El nivel de
exposición variará dependiendo de si la red es privada o pública, conectada o no a
Internet, y si el entorno de ejecución del software ha sido configurado para
minimizar sus vulnerabilidades.
» Mantenimiento o sostenimiento. No publicación de parches de las
vulnerabilidades detectadas en el momento oportuno o incluso introducción de

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

 Seguridad en el Software

código malicioso por el personal de mantenimiento en las versiones actualizadas del

código.

Según el informe 2011 Top Cyber Security Risks Report, las vulnerabilidades
detectadas en aplicaciones alcanzaron su punto máximo en el año 2006 iniciando a
partir de ese año un lento declive, como vemos en la figura siguiente:

Figura 2. Vulnerabilidades descubiertas por OSVDB (Vulnerability information from the Open Source
Vulnerability Database), 2000–2011. Fuente: [Link]

Esta disminución de vulnerabilidades detectadas no significa que el software sea cada

vez más seguro, es una sensación de seguridad falsa, pues el número de
vulnerabilidades de alta severidad está creciendo a un ritmo más rápido que los otros
niveles de vulnerabilidad (CVSS 8 a 10, clasificación definida en la OSVDB ─
[Link] ─). En la figura 3 se pone de manifiesto cómo el porcentaje de
vulnerabilidades de alta severidad se ha incrementado en los últimos 10 años.

Common Vulnerability Scoring System (CVSS). Es un sistema que categoriza la

severidad de una vulnerabilidad, de manera estricta a través de fórmulas,
proporcionando un estándar para comunicar las características y el impacto de una
vulnerabilidad en el software.

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

 Seguridad en el Software

Figura 3. Gravedad de las vulnerabilidades OSVDB en 10 años. Fuente: [Link]

Las vulnerabilidades de alta severidad dan lugar a que un atacante pueda

explotarlas rápidamente y hacerse con el control total del sistema. Su explotación
requiere un conocimiento poco especializado de la aplicación al alcance, no solo de
organizaciones cibercriminales, si no de cualquiera con conocimientos de informática.

En el informe HP Security Research del año 2015, se incluye un gráfico que muestra la
vulnerabilidades descubiertas durante el año 2014, en él se indica que la aplicación más
explotada fue Internet Explorer debido a la vulnerabilidad CVE-2014-0322 del tipo use
affter free, es decir, uso de la memoria después de liberarla, del producto Adobe Flash
El exploit fue visto por primera vez en la operación SnowMan, dirigido a entidades del
gobierno de Estados Unidos y sus compañías de defensa.

Figura 4. Vulnerabilidades descubiertas en el año 2014.

Otros aspectos importantes que influyen en el número de vulnerabilidades conocidas

de una aplicación son: su complejidad, su extensión en líneas de código y el nivel
exposición a los ataques, en este sentido las aplicaciones web en Internet, son las que

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

 Seguridad en el Software

tienen más probabilidades de ser atacadas y, por tanto, suelen tener mayor número de
vulnerabilidades conocidas.

Además, a pesar de los datos convincentes de lo contrario, erróneamente se sigue

confiando en que la implantación de tecnologías y dispositivos de seguridad
de red como cortafuegos, sistemas de gestión y correlación de eventos (SIEM─
Sistema de Centralización y Monitorización de la Información de Eventos y datos
infraestructura como, logs, etc.─), sistemas de detección de intrusos, sistemas de
gestión de acceso y cifrado del tráfico, etc., son medidas suficientes para proteger
los sistemas de la organización. Los atacantes buscan el descubrimiento de fallos en el
software relacionados con la seguridad del sistema, que den lugar a una vulnerabilidad
explotable.

En base a lo expuesto anteriormente, se considera necesario que las diferentes

organizaciones públicas o privadas dispongan de software fiable y resistente a los
ataques, es decir de confianza, con número de vulnerabilidades explotables
que sea el mínimo posible.

En respuesta a lo expuesto anteriormente nace la Seguridad del Software, en el

documento de referencia de SAFECode se define como: «La confianza que el software,
hardware y servicios están libres de vulnerabilidades intencionadas o no intencionadas
y que funcionan conforme a lo especificado y deseado» (SafeCode, 2011).

El Departamento de Defensa de los Estados Unidos (DoD) la define como «El nivel de
confianza de que el software funciona según lo previsto y está libre de vulnerabilidades,
ya sean intencionada o no, diseñada o insertada en el marco de su ciclo de vida de
desarrollo».

En este sentido, en base a la definición anterior y los párrafos anteriores, 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 y se asegure su
integridad, disponibilidad y confidencialidad».

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

 Seguridad en el Software

Hasta principios de la década anterior, la mayoría de las aplicaciones se desarrollaban

sin tener en cuenta requisitos y pruebas de seguridad específicos. Los desarrolladores
de software no eran conscientes de las vulnerabilidades que se pueden crear al
programar y descuidaban los aspectos de seguridad, dando primacía al cumplimiento
de las especificaciones funcionales, sin tener en cuenta casos en los que el software
fuera maliciosamente atacado. Este proceso de desarrollo de software ofrece, aparte de
los errores no intencionados producidos al codificar, oportunidades de insertar
código malicioso en el software en origen.

Como se ha comentado anteriormente, las tecnologías de seguridad red pueden ayudar

a aliviar los ataques, pero no resuelven el problema de seguridad real, ya que
una vez que el ciberatacante consigue vencer esas defensas, por ingeniería social, por
ejemplo, mediante ingeniería social, y comprometer una máquina del interior, a través
de la misma podrá atacar a otras de la red (pivoting) empezando por las más
vulnerables. Este es el caso de las Amenazas Avanzadas Persistentes (APT) uno de los
ciberataques más peligrosos y dañinos de hoy en día. Se hace necesario por tanto el
disponer de software seguro que funcione en un entorno agresivo y
malicioso.

APT
Tipo sofisticado de ciberataque organizado, de rápida progresión y largo plazo,
diseñado específicamente para acceder y obtener información de los sistemas de la
organización objetivo.

Un aspecto importante de la seguridad del software es la confianza y garantía de

funcionamiento conforme a su especificación y diseño y de que es lo
suficientemente robusto para soportar las amenazas que puedan comprometer su
funcionamiento esperado en su entorno de operación.

Para conseguir lo anterior y minimizar al máximo los ataques en la capa de

aplicación y, por tanto, en número de vulnerabilidades explotables, es
necesario el incluir la seguridad desde principio en el ciclo de vida de
desarrollo del software (SDLC), incluyendo requisitos, casos de abuso, análisis de
riesgo, análisis de código, pruebas de penetración dinámicas, etc. En este sentido es
importante el aprovechamiento de las buenas prácticas de ingeniería de
software ya existentes.

Un beneficio importante que se obtendría de incluir un proceso sistemático que

aborde la seguridad desde las primeras etapas del SDLC, sería la reducción

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

 Seguridad en el Software

de los costes de corrección de errores y vulnerabilidades, pues estos son más

altos conforme más tarde son detectados. Acorde a lo publicado por NIST (National
Institute of Standards and Technology), el coste que tiene la corrección de código o
vulnerabilidades después de la publicación de una versión es hasta treinta veces
mayor que su detección y corrección en etapas tempranas del desarrollo.

Figura 5. Coste relativo de corrección de vulnerabilidades en función de la etapa de desarrollo. Fuente:

[Link]

En el informe de Klocwork (2004), se incluye a su vez una figura en el coste que tiene la
corrección de código o vulnerabilidades después de la publicación de una versión es
incluso 100 veces mayor. Se basan en ratios desarrollados por Barry Boehm de la
Universidad del Sur de California.

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

 Seguridad en el Software

Figura 6. Efectos de la detección de defecto tardía. Fuente: Klocwork Inc. (2004).

1.3. Vulnerabilidades y su clasificación

Una vulnerabilidad es un fallo de programación, configuración o diseño que permite,

de alguna manera, a los atacantes alterar el comportamiento normal de un programa y
realizar algo malicioso como alterar o robar información sensible, interrumpir o
destruir una aplicación o tomar su control.

Se puede decir que son un subconjunto del fenómeno más grande que constituyen los
bugs de software.

TEMA 1 – Ideas clave 11 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Sus fuentes se deben a:

» Fallos de implementación. Fallos provenientes de la codificación de los diseños

del software realizados. Como ejemplos tenemos desbordamientos de búfer,
formato, condiciones de carrera, path traversal, cross-site scripting, inyección SQL,
etc.
» Fallos de diseño. Los sistemas hardware o software contienen frecuentemente
fallos de diseño o debilidades (flaws) que pueden ser utilizados para realizar un
ataque. Por ejemplo, TELNET no fue diseñado para su uso en entornos hostiles, para
eso se implementó SSH.
» Fallos de configuración. La instalación de software por defecto implica por lo
general la instalación de servicios que no se usan, pero que pueden presentar
debilidades que comprometan la máquina.

Tipos de vulnerabilidades del software

Fallos de implementación

Fallos de diseño

Fallos de configuración

Figura 7. Tipos de vulnerabilidades del software.

Casi todos los fallos que se producen en un software provienen de fallos de

implementación y diseño, pero solamente algunos resultan ser vulnerabilidades de
seguridad. Un fallo debe tener algún impacto o característica relevante para ser
considerado un error de seguridad, es decir tiene que permitir a los atacantes la
posibilidad de lanzar un exploits que les permita hacerse con el control de un sistema.

Exploits
Es una instancia particular de un ataque a un sistema informático que aprovecha una
vulnerabilidad específica o un conjunto de ellas.

TEMA 1 – Ideas clave 12 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Una vulnerabilidad se define (INTECO, 2011), básicamente, por cinco factores o

parámetros que deben identificarla.

» Producto: productos a los que afecta, versión o conjunto de ellas.

» Dónde: Componente o módulo del programa donde se localiza la vulnerabilidad.
» Causa y consecuencia: Fallo técnico concreto que cometió el programador a la
hora de crear la aplicación que es el origen de la vulnerabilidad.
» Impacto: Define la gravedad de la vulnerabilidad, indica lo que puede conseguir un
atacante que la explotase.
» Vector: Técnica del atacante para aprovechar la vulnerabilidad se le conoce como
«vector de ataque».

El ciclo de vida de una vulnerabilidad

El ciclo de vida de una vulnerabilidad consta de las siguientes fases:

» Descubrimiento: detección de un fallo en el software que puede producirse

durante el desarrollo del mismo o una vez está en producción.
» Utilización: Los agentes maliciosos desarrollan el exploit adecuado para poder
lanzar ataques.
» Verificación inicial de la vulnerabilidad: una vez se recibe una notificación de
error esta será aceptada para su tratamiento comprobando su veracidad, o bien será
rechazada en caso de que no se pueda reproducirse y se compruebe no existe.
» Solución: los programadores del software buscan solución en entornos
controlados.
» Difusión: los medios de comunicación dan publicidad al incidente.
» Medidas: si es posible las organizaciones afectadas toman medidas para mitigar las
posibles pérdidas.
» Corrección y nueva verificación: el proceso de corrección de la vulnerabilidad,
llevado a cabo por programadores, será verificado nuevamente de manera iterativa
hasta comprobar la resolución del error.
» Búsqueda. Los técnicos buscan vulnerabilidades similares (el ciclo vuelve a
comenzar).
» Actualización: Los sitios no actualizados vuelven a ser víctimas.

TEMA 1 – Ideas clave 13 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Descubrir Utilización Verificación Solución Difusión Medidas Corrección Búsqueda Actualizar

Figura 8. Ciclo de vida una vulnerabilidad.

En la siguiente figura se muestra una gráfica que representa el riesgo en función de los
tiempos tardados en parchear la vulnerabilidad de una aplicación, como se puede
observar el riesgo aumenta de forma muy rápida desde que se descubre la
vulnerabilidad hasta que se parchea.

Figura 9. Riesgo de una vulnerabilidad en función del tiempo. Fuente:

[Link]

Gestión de vulnerabilidades

Dada la gran cantidad de vulnerabilidades descubiertas se hace necesario el disponer

de estándares que permitan referenciarlas unívocamente, para poder conocer su
gravedad de forma objetiva y obtener el conocimiento necesario para mitigarlas.

TEMA 1 – Ideas clave 14 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Existen varios estándares, catálogos o bases de datos, que a continuación pasamos a

comentar:

» Common Vulnerabilities and Exposures (CVE) ([Link] Es un

diccionario o catálogo público de vulnerabilidades, administrado por MITRE, que
normaliza su descripción y las organiza desde diferentes tipos de vista
(vulnerabilidades Web, de diseño, implementación, etc.).

MITRE
Organización sin ánimo de lucro, de carácter público que trabaja en las áreas de
ingeniería de sistemas, tecnologías de la información, concepto de operación y
modernización de empresas

Cada identificador CVE incluye:

o Identificador con el siguiente formato:

CVE-2012-4212

CVE, seguido del año en el que se asignó el código a la vulnerabilidad.

Número de cuatro cifras que identifica la vulnerabilidad en el año.

Figura 10. Identificador CVE.

o Breve descripción de la vulnerabilidad.

o Referencias.

» Common Vulnerability Scoring System (CVSS) ([Link]

Es básicamente un sistema que escalona la severidad de una vulnerabilidad, de
manera estricta a través de fórmulas, proporcionando un estándar para comunicar
las características y el impacto de una vulnerabilidad identificada con su código
CVE. Su modelo cuantitativo asegura una medición exacta y repetible a la vez que
permite ver características subyacentes que se usaron para generar su puntuación.

TEMA 1 – Ideas clave 15 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Permite organizar la priorización de las actividades de remediación o parcheo de las

vulnerabilidades. En la figura se muestra el proceso de cálculo de una severidad:

Figura 11. Cálculo puntuación CVSS.

El cálculo se realiza en base a tres tipos de métricas base, temporales y ambientales,

siendo las dos últimas opcionales. En cuanto a las métricas base se tienen dos
subconjuntos

o Explotabilidad: vectores de acceso, complejidad de acceso y autenticación.

o Impacto: confidencialidad, integridad y disponibilidad.

» Vulnerability information from the Open Source Vulnerability Database

(OSVDB) ([Link] Proporciona una radiografía excelente de las
vulnerabilidades existentes, particularmente de aplicaciones. Sin embargo, debido a
la naturaleza de los informes vulnerabilidad, OSVDB solo puede contar con las
vulnerabilidades que se hagan públicas o se hayan insertado directamente en la base
de datos por particulares.

» Common Vulnerability Reporting Framework (CVRF). Es un formato XML

que permite compartir información crítica sobre vulnerabilidades en un esquema
abierto y legible por cualquier equipo. Hasta el momento no había ningún estándar
para informar de vulnerabilidades de los sistemas de la Tecnologías de la
Información y Comunicaciones (TIC), este viene a cubrir una necesidad manifestada
por los distintos actores de la industria, organismos de investigación y de la
administración en cuanto a un marco común, ya que, hasta ahora, cada proveedor
creaba sus informes según su criterio. La disponibilidad de CVRF acelera el
intercambio y procesamiento de información entre distintas plataformas.

TEMA 1 – Ideas clave 16 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Originalmente deriva del proyecto Incident Object Description Exchange Format

(IODEF), su propósito es el reemplazar los múltiples formatos previamente en uso
no estándar de presentación de informes, lo que permite acelerar el intercambio de
información y proceso.

» National Vulnerability Database (NVD) ([Link] Base de datos

del gobierno estadounidense que permite la automatización de la gestión
vulnerabilidades y la medición del nivel de riesgo. Incluye bases de datos con listas
de comprobación de configuraciones de seguridad de productos, defectos de
seguridad del software relacionados, malas configuraciones, los nombres de
producto y métricas de impacto. Contiene:

o 54337 CVE Vulnerabilidades.

o 202 listas de comprobación de configuraciones de seguridad de productos.
8140 consultas a OVAL.

Open Vulnerability and Assessment Languajes (OVAL)

Esfuerzo de comunidad internacional para normalizar los informes de seguridad de
vulnerabilidades y estado de seguridad de un sistema TIC. Incluye un lenguaje de
codificación de los detalles de sistema. [Link]

» Common Weakness Enumeration (CWE) ([Link] Estándar

International y de libre uso que ofrece un conjunto unificado de debilidades o
defectos del software medibles, que permite un análisis, descripción, selección y uso
de herramientas de auditoría de seguridad de software y servicios que pueden
encontrar debilidades en el código fuente y sistemas, así como una mejor
comprensión y gestión de los puntos débiles de un software relacionados con la
arquitectura y el diseño. Sus principales objetivos son:

o Proporcionar un lenguaje común para describir los defectos y debilidades de

seguridad de software en su arquitectura, diseño y codificación.
o Proporcionar un estándar de comparación de herramientas de auditoría
seguridad de software.
o Proporcionar una línea base para la identificación de vulnerabilidades, su
mitigación y los esfuerzos de prevención.

TEMA 1 – Ideas clave 17 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

En la figura siguiente se puede ver un diagrama de contexto de las diferentes

organizaciones y estándares que usan CWE.

Figura [Link] de contexto de CWE. Fuente: [Link]

Incluye los siguientes tipos de debilidades del software: desbordamientos del búfer,
formato de cadenas, estructura y problemas de validación, errores de ruta, interfaz
de usuario, autenticación, gestión de recursos, manipulación de datos, verificación
de datos, inyección de código, etc.

Cada identificador CWE incluye los siguientes campos de información:

CWE

• Nombre del tipo de debilidad

• Descripción del tipo
• Términos alternativos para la debilidad
• Descripción del comportamiento de la debilidad
• Descripción de la debilidad
• Probabilidad de explotar la debilidad
• Descripción de las consecuencias de la explotación
• Posibles mitigaciones
• Otras debilidades relacionadas
• Taxonomías de las fuentes
• Ejemplos de código para los lenguajes/arquitecturas
• Identificadores de vulnerabilidades CVE para las que ese tipo de debilidad existe
• Referencias

Figura 13. Campos de información de cada entrada CWE.

TEMA 1 – Ideas clave 18 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Clasificación de las vulnerabilidades

Existen muchas clasificaciones o taxonomías de vulnerabilidades unas se adaptan a

todo tipo de aplicaciones, como son MITRE Top 25 y SANS Top 20 y otras solo a
aplicaciones web como son OWASP Top 10 y WASC Threat Clasification v2.0. A
continuación describimos algunas de las mencionadas.

Consulta aquí más información sobre las diferentes clasificaciones:

» MITRE Top 25: [Link]
» SANS Top 20: [Link]
» OWASP Top 10: [Link]
» WASC Threat Classification v2.0: [Link]

» MITRE TOP 25. La lista es el resultado de la colaboración entre el Instituto SANS,

MITRE y muchos de los mejores expertos en software de [Link]. y Europa.
Contiene los mayores errores de programación que pueden causar vulnerabilidades
en el software. Es una herramienta destinada a ayudar a los programadores y
auditores de seguridad del software, para prevenir este tipo de vulnerabilidades que
afectan a la industria de las TIC.

o Todo tipo de aplicaciones Web y no Web.

o Dan lugar a vulnerabilidades graves en el software.
o Prevención, mitigación y principios de programación seguros.

En la siguiente tabla se pueden consultar las 25 principales vulnerabilidades:

RANK ID NOMBRE
Improper Neutralization of Special Elements used in an SQL
[1] CWE-89
Command ('SQL Injection')
Improper Neutralization of Special Elements used in an OS
[2] CWE-78
Command ('OS Command Injection')
Buffer Copy without Checking Size of Input ('Classic Buffer
[3] CWE-120
Overflow')
Improper Neutralization of Input During Web Page Generation
[4] CWE-79
('Cross-site Scripting')
[5] CWE-306 Missing Authentication for Critical Function
[6] CWE-862 Missing Authorization
[7] CWE-798 Use of Hard-coded Credentials
[8] CWE-311 Missing Encryption of Sensitive Data

TEMA 1 – Ideas clave 19 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

[9] CWE-434 Unrestricted Upload of File with Dangerous Type

[10] CWE-807 Reliance on Untrusted Inputs in a Security Decision
[11] CWE-250 Execution with Unnecessary Privileges
[12] CWE-352 Cross-Site Request Forgery (CSRF)
Improper Limitation of a Pathname to a Restricted Directory ('Path
[13] CWE-22
Traversal')
[14] CWE-494 Download of Code Without Integrity Check
[15] CWE-863 Incorrect Authorization
[16] CWE-829 Inclusion of Functionality from Untrusted Control Sphere
[17] CWE-732 Incorrect Permission Assignment for Critical Resource
[18] CWE-676 Use of Potentially Dangerous Function
[19] CWE-327 Use of a Broken or Risky Cryptographic Algorithm
[20] CWE-131 Incorrect Calculation of Buffer Size
[21] CWE-307 Improper Restriction of Excessive Authentication Attempts
[22] CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
[23] CWE-134 Uncontrolled Format String
[24] CWE-190 Integer Overflow or Wraparound
[25] CWE-759 Use of a One-Way Hash without a Salt
Tabla 1. Veinticinco vulnerabilidades MITRE TOP 25. Fuente: MITRE (2011).

Para cada entrada de la tabla se proporciona la siguiente información:

o Clasificación. La clasificación de la debilidad CVSS.

o Identificador CWE.
o Información adicional sobre la debilidad que puede ser útil para adoptar
decisiones de priorización de acciones de mitigación.
o Breve discusión informal sobre la naturaleza de la debilidad y de sus
consecuencias.
o Los pasos que los desarrolladores pueden tomar para mitigar o eliminar las
debilidades.
o Otras entradas CWE que están relacionadas con la debilidad Top 25.
o Entradas estándar CAPEC (lista de patrones comunes de ataque junto con un
esquema integral y taxonomía de clasificación) sobre los ataques que pueden
llevarse a cabo con éxito contra la debilidad.
o Enlaces con más detalles, incluyendo ejemplos de código fuente que demuestran
la debilidad, métodos de detección, etc.

TEMA 1 – Ideas clave 20 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» SANS Top 20. Es una lista de vulnerabilidades que requieren solución inmediata.
Es el resultado de un proceso que reunió a docenas de expertos líderes en seguridad.
Incluye instrucciones paso a paso y notas para información adicional útiles para
corregir los defectos de seguridad. Se actualiza la lista y las instrucciones en la
medida que más amenazas sean identificadas.

o Vulnerabilidades en servidores, aplicaciones web, aplicaciones comerciales/open

source.
o No tiene en cuenta las aplicaciones propietarias.

» OWASP Top 10. Su objetivo es crear conciencia sobre la seguridad de las

aplicaciones web mediante la identificación de algunos de los riesgos más críticos
que enfrentan las organizaciones.

o Las 10 vulnerabilidades de seguridad más críticas en aplicaciones web.

o Lista ordenada por criticidad y predominio.
o Representa una lista concisa y enfocada sobre los diez riesgos más críticos sobre
seguridad en aplicaciones.

Consulta en el siguiente documento los riesgos de seguridad en aplicaciones web:

[Link]

» WASC Threat Clasification v2.0. Es un esfuerzo de cooperación para aclarar y

organizar las amenazas a la seguridad de un sitio web. Es un proyecto para
desarrollar y promover estándares para la industria y su principal propósito es el
crear un lenguaje consistente y las definiciones de los problemas de seguridad
relacionados con las aplicaciones web.

o Unificación y organización de las amenazas de seguridad Web.

o Describe amenazas, debilidades y ataques.

Escáneres de vulnerabilidades

Este tipo de herramientas analizan los sistemas en busca de vulnerabilidades

conocidas. Disponen de información sobre vulnerabilidades existentes en las versiones
de los sistemas operativos y aplicaciones almacenadas y actualizadas en una base de
datos, que utiliza para la detección de las mismas.

TEMA 1 – Ideas clave 21 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

La herramienta más utilizada es Nessus, inicialmente de código abierto y versión

gratuita, y actualmente en dos versiones, la 4.x en la que el nuevo código es cerrado, y
la versión 2.x ([Link]) que continúa siendo software libre. 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 ([Link] la cual continúa actualizando versiones para
las distintas distribuciones de GNU/Linux. Otras herramientas de extendido uso son
Nexpose de Rapid 7 ([Link]/products/nexpose), ISS Real Secure, Nmap y
Retina.

1.4. Propiedades software seguro

Básicamente se tienen dos conjuntos de propiedades que definen a un software seguro

del que no lo es, las primeras son las esenciales, comunes a la seguridad de cualquier
sistema, cuya ausencia afecta gravemente a la seguridad de una aplicación y un
segundo conjunto, complementarias a las anteriores que no influyen en su
seguridad, pero que ayudan a mejorarla en gran medida.

Las principales propiedades esenciales que distinguen al software de confianza

del que no es, son:

» Integridad. Capacidad que garantiza que el código, activos manejados,

configuraciones y comportamiento no pueda ser o no haya sido modificado o
alterado por personas, entidades o procesos no autorizados tanto durante la
fase de desarrollo como en la fase de operación. Entre las modificaciones
que se pueden realizar tenemos sobreescritura, inclusión de puertas traseras,
borrado, corrupción de datos, etc. Como ejemplo de técnicas y mecanismos que se
tienen para salvaguardar la integridad, tenemos:

o Identificación del modo de trasmisión y procesado de los datos por la aplicación.

o Uso de técnicas de cifrado para asegurar que los componentes y los datos nos son
alterados o corrompidos.
o Estricta gestión de sesiones.
o Uso de sistemas de monitorización de la integridad
o Uso de firma digital.
o Trasmisión cifrada de los datos.

TEMA 1 – Ideas clave 22 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Disponibilidad. Capacidad que garantiza que el software es operativo y

accesible por personas, entidades o procesos autorizados de forma que se pueda
acceder a la información y a los recursos o servicios que la manejan, conforme a las
especificaciones de los mismos. Entre las técnicas y mecanismos que se tienen para
salvaguardar la disponibilidad, tenemos, por ejemplo:

o Análisis de qué servicios e información es crítica y el modo de tenerlos

disponibles.
o Uso de arquitecturas de alta disponibilidad, con diferentes tipos de redundancias.
o Uso de sistemas distribuidos con sistemas de réplica de información entre ellos.
o Uso de sistemas de recuperación a través de imágenes, virtualización, etc.

» Confidencialidad. Capacidad de preservar que cualquiera de sus características,

activos manejados están ocultos a usuarios no autorizados, de forma que se
garantice que solo las personas, entidades o procesos autorizados pueden acceder a
la información.

Entre las técnicas y mecanismos que se tienen para salvaguardar la

confidencialidad, tenemos, por ejemplo:

o Clasificación de las aplicaciones y servicios en base a su criticidad.

o Tráfico de relleno.
o Técnicas de control de acceso a los sistemas basado en roles.
o El cifrado de la información y de las comunicaciones.

Integri-
Confiden dad
-cialidad

Disponi
-bilidad

Seguridad del software

Figura 14. Propiedades esenciales de la seguridad del software.

Un ejemplo de ataque podría ser un desbordamiento de buffer (buffer overflow)

consiguiendo el control total de la máquina, pudiendo violar las tres propiedades

TEMA 1 – Ideas clave 23 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

anteriores al poder robar información del sistema, cuentas de usuario, corromper

ficheros del sistema e incluso apagar la máquina y borrar los ficheros necesarios
para que no vuelva a arrancar.

Estas tres primeras serían las propiedades fundamentales esenciales mínimas que
debería disponer todo software, a las que habría que añadir las siguientes
complementarias:

» Fiabilidad. Capacidad del software de funcionar de la forma esperada en

todas las situaciones a la que estará expuesto en su entorno de
funcionamiento, es decir que la posibilidad de que un agente malicioso pueda
alterar la ejecución o resultado de una manera favorable para el atacante está
significativamente reducida o eliminada.

En este sentido en el documento de referencia (Allen, J. H.; Barnum. S.; Ellison, R.

J.; McGraw, G.; Mead, N. R., 2008), se indica la necesidad de comprobar el
comportamiento del software bajo una gran variedad de condiciones entre las que al
menos deben ser las siguientes:

o Batería de ataques lanzados contra el software.

o Entradas y salidas del software (señales, ficheros de datos, texto, etc.) que
puedan ser comprometidas.
o Interfaces del software a otras entidades que puedan ser comprometidas.
o Ejecución del software en un ambiente hostil donde sea atacado.

» Autenticación. Capacidad que permite a un software garantizar que una

persona, entidad o proceso es quien dice ser o bien que garantiza la
fuente de la que proceden los datos.
» Trazabilidad. Capacidad que garantiza la posibilidad de imputar las acciones
relacionadas en un software a la persona, entidad o proceso que la ha
originado.
» Robustez. Capacidad de resistencia a los ataques realizados por los agentes
maliciosos (malware, hackers, etc.).
Resiliencia. Capacidad del software de aislar, contener y limitar los daños
ocasionados por fallos causados por la explotación de una vulnerabilidad del mismo
y recuperarse reanudando su operación en o por encima de cierto nivel
mínimo predefinido de servicio aceptable en tiempo oportuno.

TEMA 1 – Ideas clave 24 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Tolerancia. Capacidad del software para «tolerar» los errores y fallos que resultan
de ataques con éxito y seguir funcionando como si los ataques no se hubieran
producido.

Las propiedades que distinguen al software de confianza se ilustran en la figura

siguiente.

Figura 15. Propiedades seguridad del software.

Existen una serie de factores que influyen en la probabilidad de que un software sea
consistente con las propiedades anteriormente mostradas (Goertzel, K. M., Winograd,
T., 2008), estos incluyen:

» Principios de diseño y buenas prácticas de desarrollo. Las prácticas

utilizadas para desarrollar el software y los principios de diseño que lo rigen. En el
apartado posterior se desarrolla ampliamente este punto.
» Herramientas de desarrollo. El lenguaje de programación, bibliotecas y
herramientas de desarrollo utilizadas para diseñar, implementar y probar el
software, y la forma en que fueron utilizados por los desarrolladores.
» Componentes adquiridos. Tanto los componentes de software comercial como
libre en cuanto como fueron evaluados, seleccionados, e integrados.
» Configuraciones desplegadas. Cómo el software se configuró durante la
instalación en su entorno de producción.

TEMA 1 – Ideas clave 25 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Ambiente de operación. La naturaleza y configuración de las protecciones

proporcionadas por el entorno de ejecución o producción.
» Conocimiento Profesional. El nivel de concienciación y conocimiento de
seguridad que los analistas, diseñadores, desarrolladores, probadores y
mantenedores del software, o su falta del mismo.

1.5. Principios de diseño seguridad del software

Existe una gran cantidad de bibliografía relativa a temas de seguridad en los que se
suele comentar los principios de seguridad que han de regir todo diseño. Algunos de
ellos están más enfocados a las configuraciones de los dispositivos de seguridad de red,
la mayoría de ellos se solapan y normalmente coinciden generalmente siendo por tanto
análogos. En este sentido, se selecciona como referencia para la realización de este
apartado los documentos Enhancing the Development Life Cycle to Produce Secure
Software y Writing Secure Code.

La adopción de estos principios de diseño constituye una base fundamental de las

técnicas de programación segura, tanto para la protección de aplicaciones web,
normalmente más expuestas a los ciberataques al estar desplegadas masivamente en
Internet, como otras más tradicionales del tipo cliente-servidor. Las principales
prácticas y principios de diseño tener en cuenta serían:

» Defensa en profundidad.
» Simplicidad del diseño.
» Mínimo privilegio.
» Separación de privilegios.
» Separación de dominios.
» Separación código, ejecutables y datos configuración y programa.
» Entorno de producción o ejecución inseguro.
» Registro de eventos de seguridad.
» Fallar de forma segura.
» Diseño de software resistente.
» La seguridad por oscuridad es un error.
» Seguridad por defecto.

TEMA 1 – Ideas clave 26 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Defensa en profundidad

Uno de los principios más importantes de una estrategia defensiva efectiva es la

«Defensa en Profundidad», se define en la guía CCN-STIC-400 como: «Estrategia de
protección consistente en introducir múltiples capas de seguridad, que permitan
reducir la probabilidad de compromiso en caso de que una de las capas falle y en el
peor de los casos minimizar el impacto».

La arquitectura del software y hardware de base que constituirá el entorno de

ejecución donde la aplicación vaya a ser instalada debería contar con una variedad de
servicios de seguridad y protecciones que reduzcan y dificulten la probabilidad de que
una acción maliciosa alcance el software, ya que se minimiza la exposición de las
propias vulnerabilidades al mundo exterior, se reduce la visibilidad externa de los
componentes confiables principales y se aíslan los componentes no confiables de
forma que su ejecución se vea limitada y sus malos comportamientos no afecten o
amenacen la operación confiable de los demás.

El aislamiento significa que el software o componente no confiable dispone de recursos

específicos para su ejecución como memoria, espacio en disco duro, interfaz de red
virtual, etc., en un entorno aislado. Para su implementación se suelen utilizar máquinas
virtuales que además pueden proporcionar otras características que ayudan a mejorar
la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte para la
restauración de imágenes, etc.

Objetivo: introducir múltiples capas de seguridad para reducir la probabilidad de

compromiso del sistema.

Este principio, propone un enfoque defensivo, que implanta protecciones o

mecanismos de seguridad en todos los niveles del sistema o capas del modelo Open
Systems Interconnection (OSI).

Las medidas de seguridad a implementar en cada capa podrán variar en función del
entorno de operación del sistema, sin embargo, el principio base o general permanece
inalterable, por ejemplo, para las capas siguientes tendríamos:

» Capa de aplicación: Dispositivos de nivel de aplicación como cortafuegos, proxy

reverso, y sistemas de prevención de intrusiones de host que bloqueen las entradas

TEMA 1 – Ideas clave 27 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

maliciosas conocidas y problemáticas antes de que llegue al software. Otros

mecanismos son métodos de encriptación, control de acceso, autenticación,
bastionados de aplicaciones, etc.
» Capa de transporte: Mecanismos de cifrado como Socket Secure Layer (SSL) o
Transport Layer Security (TLS).
» Capa de red: Dispositivos de seguridad de red como cortafuegos, sistemas de
protección de intrusiones (IDS/IPS) a nivel de red, sistemas de gestión y correlación
de eventos de infraestructura (SIEM), etc. que protejan y dificulten las
acciones de los ciberatacantes.
» Capa física: Plataformas virtuales «sandboxes» que proporcionan un entorno
aislado de ejecución para los componentes no confiables evitando que sus
malos comportamientos posibles de afectar a los componentes confiables. Así
mismo pueden proporcionar arquitecturas de alta disponibilidad y sistemas de
recuperación completa de las máquinas. Mantenimiento de los equipos de
comunicaciones y proceso de datos en salas construidas en base a requisitos de
seguridad estructural para evitar intrusiones y emanaciones, sistemas de extinción
automática de incendios, sensores de humedad, sistemas de control de accesos, etc.

El principio fundamental detrás de este concepto es el de dificultar las acciones del

atacante a través de las diferentes medidas de seguridad aplicadas a cada una de las
capas de forma que los diferentes sensores que tenga nuestro sistema detecten las
actividades maliciosas. Cuando una capa se vea comprometida, las medidas de
detección, de reacción y de recuperación nos permitirán reaccionar, disminuyendo la
probabilidad de que otras capas se vean comprometidas, evitando así, que la seguridad
del servicio en su conjunto se vea burlada, disminuyendo por tanto el riesgo.

Otro aspecto importante es la verificación de la cadena de suministros mediante la

comprobación del hash, código de firma, aplicados al código ejecutable mediante la
validación de la integridad de la misma en el momento de la entrega, la instalación
o en tiempo de ejecución, para determinar:

» Si el código se originó a partir de una fuente de confianza.

» Si la integridad del código de se ha visto comprometida.

TEMA 1 – Ideas clave 28 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Cortafuegos de aplicación
Proxy reverso
Métodos Criptográficos
Datos Aplicación
Control de Acceso Autenticación
Bastionado de las aplicaciones
Datos Presentación Bastionado del sistema operativo

Datos Presentación

Segment Transporte SSL/TLS

Paquetes Red Segmentos de red

Firewall/IDS/IPSEC/VPN

Tramas Enlace

Prevención Intrusiones Seguridad

Bits Físico Física Procedimientos seguridad
Plataforma virtualización

Figura [Link] seguridad del software.

Prueba de la integridad de contenidos. Por ejemplo, cuando se distribuye un

contenido por la red, y se quiere estar seguro de que lo que le llega al receptor es lo que
se está emitiendo, se proporciona un valor hash del contenido de forma que ese valor
tiene que obtenerse al aplicar la función hash sobre el contenido distribuido
asegurando así la integridad. A esto se le suele llamar checksum criptográfico debido a
que es un checksum que requiere el uso de funciones hash criptográficas para que sea
difícil generar otros ficheros falsos que tengan el mismo valor hash. Otro ejemplo de
uso esta tecnología para verificar la integridad es calcular y guardar el valor hash de
archivos para poder verificar posteriormente que nadie (ej. un virus) los ha modificado.
Fuente: [Link]

Simplicidad del diseño

La realización de un diseño tan simple como sea posible y la redacción de unas

especificaciones del mismo fácilmente comprensibles y simples, es una forma de
obtener un nivel de seguridad mayor pues disminuirá la probabilidad que el equipo de
diseño y desarrollo incluya debilidades de diseño y errores de programación que
resulten en vulnerabilidades que comprometan la seguridad de la aplicación. Incluso se
hará más fácil el análisis de su descubrimiento y su verificación y validación.

TEMA 1 – Ideas clave 29 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Algunas de las opciones específicas de diseño del software que lo simplifican son [13]:

» Limitar el número de estados posibles en el software.

» Favorecer procesos deterministas sobre los no deterministas.
» Utilice una sola tarea en lugar de realizar múltiples tareas siempre que sea
práctico.
» El uso de técnicas de sondeo en lugar de interrupciones.
» Diseñar los componentes del software con el conjunto mínimo de
características y capacidades que se requieran para realizar sus tareas en el
sistema.
» La descomposición en subsistemas o componentes de un programa debería
adaptarse a su descomposición funcional, permitiendo una asignación uno a
uno de los segmentos de programa a sus fines previstos.
» Desacoplar los componentes y procesos para minimizar las
interdependencias entre ellos, impedirá que un fallo o anomalía en un
componente o proceso afecte a los estados de otros.
» No implementar características o funciones innecesarias. Si el diseño
incluye componentes COTS o del software libre con trozos de código latente o
muerto, funciones innecesarias o no documentadas, el diseño debe incluir
contenedores para aislar los segmentos de código no utilizados para prevenir el
acceso a los mismos durante su ejecución.

Como podemos ver el implementar arquitecturas complejas, cuando se puede

resolver el diseño de forma simple, puede afectar negativamente a la
seguridad del sistema.

Objetivo: reducir la complejidad del diseño para minimizar el número de

vulnerabilidades explotables por el atacante y debilidades en el sistema.

TEMA 1 – Ideas clave 30 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Mínimo privilegio

De acuerdo con el Software Assurance CBK se define el mínimo privilegio como:

Mínimo privilegio es un principio según el cual se concede a cada entidad

(usuario, proceso o dispositivo) el conjunto más restrictivo de privilegios necesarios
para el desempeño de sus tareas autorizadas. La aplicación de este principio limita
el daño que puede resultar de un accidente, error o el uso no autorizado de un
sistema. También reduce el número de interacciones potenciales entre los
procesos privilegiados o programas, por lo que se minimiza la probabilidad de
ocurrencia de usos maliciosos de privilegios, no deseados o inapropiados.

Una de las principales razones por la que es necesario que una entidad se ejecute con
los mínimos privilegios posibles, es debido a que si un ciberatacante consigue
comprometer una máquina o es capaz de inyectar código malicioso en un proceso del
sistema este se debería ejecutar con los mismos privilegios que tuviera el usuario en la
máquina o el proceso.

Este principio requiere que el diseñador realice una lista de las entidades de software
con los recursos que utiliza y las tareas que debe realizar en el sistema, especificando
para cada una los privilegios reales estrictamente necesarios. Normalmente se
suele asignar un usuario general con conjunto de privilegios que le permitirá realizar
todas las tareas, incluidas las no necesarias. Ejemplos de errores comunes son:

» Aplicación de derechos de administrador.

» Instalación de aplicaciones y servicios con el usuario de administrador.
» Usuarios con derechos de administrador.
» Servicios y procesos con privilegios por tiempo indefinido.

Objetivo: lo que no está expresamente permitido está prohibido.

Separación de privilegios

Es un principio relacionado con el anterior «mínimo privilegio» que esto implica la

asignación a las diferentes entidades de un rol de las siguientes propiedades:

» Asignación de un subconjunto de funciones o tareas de todas las que ofrece el

sistema.

TEMA 1 – Ideas clave 31 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Acceso a los datos necesarios que debe gestionar para llevar a cabo su función
en base a una serie de roles definidos.

Se evita así que todas las entidades sean capaces de acceder a la totalidad o
llevar a cabo todas las funciones del sistema con privilegios de «superusuario» y
por tanto que ninguna entidad tenga todos los privilegios necesarios para modificar,
sobrescribir, borrar o destruir todos los componentes y recursos de la aplicación. Como
ejemplo tenemos:

» Servidor web: el usuario final solo requiere la capacidad de leer el contenido

publicado e introducir datos en los formularios HTML. El administrador, por el
contrario, tiene que ser capaz de leer, escribir y eliminar contenido y modificar el
código de los formularios HTML.

Objetivo: asignación a las diferentes entidades de un rol que implique el acceso a un

subconjunto de funciones o tareas y a los datos necesarios.

Separación de dominios

Es un principio que en unión con los dos anteriores, «mínimo privilegio» y «separación
de privilegios», que permite minimizar la probabilidad de que actores maliciosos
obtengan fácilmente acceso a las ubicaciones de memoria u objetos de datos del
sistema. Para que el diseño cumpla con este principio deben utilizar de técnicas de
compartimentación de los usuarios, procesos y datos de forma que las entidades:

Solo deben ser capaces de realizar las tareas que son absolutamente necesarias.
Llevarlas a cabo solamente con los datos que tenga permiso de acceso.
Utilizar el espacio de memoria y disco que tenga asignado para la ejecución de esas
funciones.

Objetivo: minimizar la probabilidad de que actores maliciosos obtengan fácilmente

acceso a las ubicaciones de memoria u objetos de datos del sistema.

El aislar las entidades de confianza en su propia área de ejecución (con recursos

dedicados a la misma) de otras menos confiables (procesadores de texto, software de
descarga, etc.), permite reducir al mínimo su exposición a otras entidades e interfaces
externas susceptibles de ser atacadas por agentes maliciosos.

TEMA 1 – Ideas clave 32 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Las técnicas que tenemos para llevar a cabo lo anterior:

» Sistema operativo confiable.

» Máquinas virtuales. Además, pueden proporcionar otras características que ayudan
a mejorar la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte
para la restauración de imágenes, etc.
» Funciones sandboxing de lenguajes de programación como Java, Perl, .NET (Code
Access Security), etc.
» Sistemas Unix: chroot jails.
» Trusted processor modules (TPM).

TPM
Es el nombre de una especificación publicada que detalla un criptoprocesador seguro
que puede almacenar claves criptográficas que protejan la información y las
implementaciones de esta especificación, a menudo llamado el «chip TPM» o
«dispositivo de seguridad TPM». Fuente: [Link]

Separación código, ejecutables y datos configuración y programa

Este principio pretende reducir la probabilidad de que un ciberatacante que

haya accedido a los datos del programa fácilmente pueda localizar y
acceder a los archivos ejecutables y datos de configuración del mismo, lo
que le daría la posibilidad de manipular el funcionamiento del sistema a su interés e
incluso el escalado de privilegios.

La mayoría de las técnicas de separación de los datos de programa, configuración y

archivos ejecutables se realizan en la plataforma de ejecución (procesador más sistema
operativo). A continuación, vemos las más principales mostradas (Goertzel yWinograd,
, 2008):

» Utilizar plataformas con arquitectura Harvard.

» Establecer permisos de escritura y lectura de los datos de programa y sus
metadatos al programa que los creó a menos que exista una necesidad
explícita de otros programas o entidades para poder leerlos.
» Los datos de configuración del programa solo deben poder ser leídos y
modificados por el administrador.

TEMA 1 – Ideas clave 33 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Los datos utilizados por un script en un servidor Web deben ser

colocados fuera de árbol de documentos del mismo.
» Prohibir a los programas y scripts escribir archivos en directorios
escribibles como el de UNIX/TMP.
» Almacenar los archivos de datos, configuración y programas ejecutables
en los directorios separados del sistema de archivos.
» Los programas y scripts que están configurados para ejecutarse como servidor Web
de usuario «nobody» (debe suprimirse) deben ser modificados para funcionar
bajo un nombre de usuario específico.
» Cifrar todos los archivos ejecutables e implementar un módulo de
decodificación que se ejecute como parte del inicio del programa para
desencriptarlos al iniciar su funcionamiento.
» Incluir técnicas de cifrado de archivos y firma digital o almacenamiento
en un servidor de datos externos con conexión cifrada (por ejemplo, mediante
Secure Sockets Layer ─SSL─ o Transport Layer Security ─TLS─) para aislar los
datos de configuración del software de la manipulación y eliminación, en caso de
que las técnicas de control de acceso al sistema no son lo suficientemente fuertes.
Ello requerirá que el software incluya la lógica de cifrado para descifrar y validar la
firma del archivo de configuración al inicio del programa.
» Implantar clonado de sistemas como medida de recuperación, desde un
servidor remoto (que guardaría las imágenes y los datos de configuración) mediante
una red de comunicaciones fuera de banda específica y cifrada.

Arquitectura Harward
Hace referencia a las arquitecturas de computadoras que utilizaban dispositivos de
almacenamiento físicamente separados para las instrucciones y para los datos (en
oposición a la Arquitectura de von Neumann). Fuente: [Link]

Objetivo: reducir la probabilidad de que un ciberatacante que haya accedido a los

datos del programa fácilmente pueda localizar y acceder a los archivos ejecutables y
datos de configuración del programa.

Entorno de producción o ejecución inseguro

Asumir que todos los componentes del entorno de producción y sistemas externos son
inseguros o no confiables, con ello se pretende reducir la exposición de los
componentes del software a agentes potencialmente maliciosos que hayan podido

TEMA 1 – Ideas clave 34 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

penetrar en el perímetro de defensa (los límites dispositivos de protección

perimetral) de la organización y comprometer una máquina desde la que puedan
expandirse e iniciar otros ataques a otras pertenecientes a la red (pivoting).

El software debe ser diseñado con una mínima dependencia de los datos
externos, se debe tener control completo sobre cualquier fuente de entrada de datos,
tanto los proporcionados por la plataforma de ejecución como de sistemas externos,
debiendo validar todos los datos provenientes de las diferentes fuentes del
entorno antes de utilizarlos, pues implican una posibilidad de ataque.

Hay que realizar una descomposición del sistema en sus componentes principales y
realizar una lista de las diferentes fuentes de datos externas, entre las que
podemos tener las siguientes:

» Llamadas a sistema operativo. Se deben evitar realizándolas a través de

middleware o API’s.
» Llamadas a otros programas en la capa de aplicación.
» Llamadas a una capa de middleware intermedia.
» API’s a los recursos del sistema. Las aplicaciones que utilizan las API no
deberían ser utilizadas por usuarios humanos.
» Referencias a objetos del sistema.
» En aplicaciones cliente-servidor, el flujo de datos entre los mismos.
» En aplicaciones Web el flujo de datos ente el cliente y el servidor.

Gran parte de los ataques a los sistemas TIC actualmente se deben a fallos o
carencias en la validación de los datos de entrada, el confiar en la fuente que las
originó hace a la aplicación vulnerable a ataques originados en el cliente al modificar
los datos en el origen o durante su transporte. Los atacantes pueden manipular
diferentes tipos de datos de entrada con el propósito de encontrar vías de compromiso
de la aplicación.

Todos los tipos de entrada deber ser validados y verificados mediante

pruebas específicas. Entre los diferentes tipos de entradas a las aplicaciones
tenemos (Goertzel yWinograd, 2008):

» Parámetros de línea de comandos.

» Variables de entorno.

TEMA 1 – Ideas clave 35 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Localizadores de recursos universales (direcciones URL) e identificadores (URI).

» Referencias a nombres de archivo.
» Subida contenido de archivos.
» Importaciones de archivos planos.
» Cabeceras Hyper Text Transfer Protocol (HTTP).
» Parámetros HTTP GET.
» Campos de formulario (especialmente los ocultos).
» Las listas de selección, listas desplegables.
» Cookies.
» Comunicaciones mediante Java applets.

Los tipos de aplicaciones que más probabilidad presenten de sufrir este tipo de ataques
son las del tipo cliente-servidor, portales web y agentes proxy. Entre los tipos
de ataques que se pueden dar por la carencia de comprobación de los datos de entrada,
la mayoría para aplicaciones Web, tenemos:

» Desbordamientos de búfer (buffer overflow): heap, stack, entero y off-by-one.

» Revelación de información.
» Inyección de comandos.
» Inyección de código SSI inyección SQL, HTTP splitting.
» Contenidos mal formados.
» Servicios web: aparte de los anteriores tenemos, inyección XML, explotación de
interfaces de administración no protegidos.

Para evitar este tipo de vulnerabilidades se deben aplicar una serie de principios de
validación de las entradas, entre los que tenemos (Goertzel y Winograd, 2008):

» Centralizar la lógica de validación de las entradas.

» Asegúrese que la validación de la entrada no puede ser evitada.
» Confiar en «listas blancas» validadas y filtrar las «listas negras».
» Validar todas las entradas de usuario incluidas las realizadas a través de proxies y
agentes que actúen en nombre de los usuarios.
» Rechazar todos los contenidos ejecutables en las entradas provenientes de fuentes
no autorizadas.
» Verificar que los programas que solicitan las llamadas tienen derecho (por la
política) a emitirlas.
» Definir reacciones significativas a errores de validación de entrada.

TEMA 1 – Ideas clave 36 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Validar los datos de salida de la aplicación antes de mostrarlos al usuario o

redirigirlos a otro sistema.

Lista blanca
Lista de aprobación o whitelist en inglés es una lista o registro de entidades que, por una
razón u otra, pueden obtener algún privilegio particular, servicio, movilidad, acceso o
reconocimiento. Por el contrario, la lista negra o blacklisting es la compilación que
identifica a quienes serán denegados, no reconocidos u obstaculizados. Fuente:
[Link]

Objetivo: evitar vulnerabilidades aplicando una serie de principios de validación de las

entradas.

Registro de eventos de seguridad

Tradicionalmente los sistemas de auditoría se dedicaban solo a grabar las acciones

realizadas por los usuarios del mismo. Sin embargo, actualmente es necesario dotar a
las aplicaciones de la capacidad de generar eventos (logs) de seguridad, para garantizar
que todas las acciones realizadas por un agente malicioso se observan y registran,
contribuyendo a la capacidad de reconocer patrones y aislar o bloquear la fuente del
ataque de modo que se evite su éxito. En definitiva, el dotarle de cierta capacidad de
detección de intrusiones.

Las principales diferencias que distinguen los sistemas con registros de auditoría de
seguridad de registro de los registros de eventos estándar son:

» El tipo de información capturada en el registro de auditoría: eventos de

seguridad.
» Capacidad de gestión de los incidentes relacionados con los eventos de
seguridad.
» Posibilidad de que los eventos de seguridad registrados en la aplicación o sistema
puedan ser utilizados en procesos reactivos después de la ocurrencia de un
incidente.
» El nivel de protección de integridad.

TEMA 1 – Ideas clave 37 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Objetivo: generar eventos (logs) de seguridad, para garantizar las acciones realizadas
por un ciberatacante se observan y registran.

Fallar de forma segura

El propósito de este principio es el reducir la probabilidad de que un fallo en el

software pueda saltarse los mecanismos de seguridad de la aplicación, dejándolo en un
estado de fallo inseguro vulnerable a los ataques. Es imposible implementar una
aplicación perfecta que nunca falle, la solución consiste en saber en todo momento cuál
es su estado y tener implementado un mecanismo en caso de que falle.

Algunas de las características específicas del diseño que minimizan la probabilidad de

que el software pase a un estado inseguro son:

» Implementar temporizadores tipo «watchdog».

» Implementar una lógica de control de excepciones.
» El software siempre debe comenzar y terminar su ejecución en un estado seguro.
» Evitar problemas de sincronización y secuenciación.

Objetivo: reducir la probabilidad de que un fallo en el software pueda saltarse los

mecanismos de seguridad de la aplicación, dejándolo en un modo de fallo inseguro
vulnerable a los ataques.

Diseño de software resistente

Dos propiedades importantes del software seguro es la robustez y la resiliencia, el

siguiente principio pretende aumentar la resistencia de las aplicaciones reduciendo
al mínimo la cantidad de tiempo que un componente de software
defectuoso o fallido sigue siendo incapaz de protegerse de los ataques.
Algunas de las características de diseño que aumentarán la resistencia del software
incluyen:

» Capacidad de autocontrol y de limitar el uso de los recursos.

» Uso de técnicas de monitorización.
» Detección de estados anómalos.
» Proporcionar una realimentación que permita que todos los supuestos y modelos
en los que el programa tome decisiones sean validados antes de ejecutarlas.

TEMA 1 – Ideas clave 38 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Aprovechar cualquier redundancia y funciones de recuperación.

» Uso de plataformas virtuales.
» Uso de técnicas de recuperación.
» Determinar la cantidad de información a proporcionar en los mensajes
de error.

Objetivo: reducir al mínimo la cantidad de tiempo que el componente de un software

defectuoso o fallido sigue siendo incapaz de protegerse de los ataques.

La seguridad por oscuridad: error

Una de las asunciones que se debe realizar a la hora de diseñar una aplicación, es que el
atacante obtendrá con el tiempo acceso a todos los diseños y todo el código
fuente de la misma. La seguridad por oscuridad es un mecanismo de defensa
que consiste en ocultar información sobre la aplicación de forma que sea
difícil de obtener, pero que en poder de un atacante puede proporcionarle un medio
para comprometerla.

Howard y LeBlanc (2003), no aconsejan que nunca se dependa de la seguridad por

oscuridad solamente indican que es válido usarla como una pequeña parte de una
estrategia general de «defensa en profundidad» para confundir y dificultar las
actividades de ataque de un intruso. A continuación, se muestran algunos ejemplos de
seguridad por oscuridad, que pueden constituir un error:

» Guardar información en archivos binarios.

» Capetas ocultas en un servidor web.
» Falsa sensación de seguridad.
» Criptografía privada.
» Cambio del nombre del usuario «administrador».

Objetivo: concienciarse de que la seguridad por oscuridad es un mecanismo de

defensa que puede proporcionar a un atacante información para comprometer la
seguridad de una aplicación.

TEMA 1 – Ideas clave 39 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Seguridad por defecto

Uno de los principios de seguridad cuyo cumplimiento exige el Real Decreto 3/2010, de
8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la
Administración Electrónica, es el de la seguridad por defecto. En su artículo 19
indica lo siguiente:

«Los sistemas deben diseñarse y configurarse de forma que garanticen la seguridad

por defecto:

a. El sistema proporcionará la mínima funcionalidad requerida para que la

organización solo alcance sus objetivos, y no alcance ninguna otra funcionalidad
adicional.
b. Las funciones de operación, administración y registro de actividad serán las
mínimas necesarias, y se asegurará que solo son accesibles por las personas, o
desde emplazamientos o equipos, autorizados, pudiendo exigirse en su caso
restricciones de horario y puntos de acceso facultados.
c. En un sistema de explotación se eliminarán o desactivarán, mediante el control
de la configuración, las funciones que no sean de interés sean innecesarias e,
incluso, aquellas que sean inadecuadas al fin que se persigue.
d. El uso ordinario del sistema ha de ser sencillo y seguro, de forma que una
utilización insegura requiera de un acto consciente por parte del usuario».

De la lectura del artículo anterior se desprende que el principal objetivo del principio de
seguridad por defecto es el de minimizar la superficie de ataque de cualquier
aplicación o sistema TIC, deshabilitando aquellos servicios y elementos no necesarios y
activando solo los necesarios.

Normalmente cuando se instala o pone en producción una aplicación o servicio, se

activan o instalan servicios que no se usan normalmente que pueden suponer un punto
potencial de entrada para los atacantes. Se debe elegir los componentes que van a ser
utilizados de forma explícita por los usuarios e instalarlos y configurarlos de forma
segura. Hay que minimizar los puntos vulnerables de la aplicación o sistemas pues
amenazan su seguridad global por muy securizado que se tenga el resto, en concreto los
siguientes:

» Entradas y salidas de red.

» Número de puertos abiertos.
» Puntos de entrada a la aplicación, autenticados o no autenticados, locales o remotos
y privilegios administrativos necesarios.
» Número de servicios. Desactivar los instalados por defectos no usados.
» Número de servicios con privilegios elevados.

TEMA 1 – Ideas clave 40 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

» Número de cuentas de usuario administrador.

» Estado de las listas de control de acceso a directorios y ficheros.
» Control de cuentas de usuario y claves de acceso por defecto a servicios.
» Contenido dinámico de páginas web.

Varias organizaciones, como el National Institute of Standards and Technology (NIST),

la Agencia de Seguridad Nacional (NSA) y el Centro Criptológico Nacional (CCN), han
publicado guías de seguridad de configuración y scripts para productos COTS
populares y de software libre que incluye la eliminación o restricción de servicios,
usuarios, permisos y software innecesario.

El bastionado de sistemas es un proceso necesario en el marco de

cualquier proyecto que contemple la aplicación de controles de seguridad
sobre los sistemas TIC, tiene como principio implementar todas las medidas de
seguridad a nivel técnico posibles para proteger un sistema sin que pierda la
funcionalidad para la que fue destinado. Habrá casos, en los que surjan conflictos que
no se puedan superar, estos deben ser cuidadosamente documentados para
proporcionar una justificación de la renuncia a los requisitos de configuración de
seguridad que impidan el correcto funcionamiento del software.

Objetivo: reducir la superficie de ataque de una aplicación o sistema.

Resumen

En el presente apartado se ha realizado un estudio de los diferentes principios de

seguridad a tener en cuenta en el diseño y desarrollo de aplicaciones seguras, que nos
ayudaran a proteger y disponer de aplicaciones seguras con un mínimo de
vulnerabilidades. Como resumen se muestra un gráfico que sintetiza el objetivo de cada
principio.

Principio Objetivo

Defensa en Introducir múltiples capas de seguridad para reducir la

profundidad probabilidad de compromiso del sistema.

Reducir la complejidad del diseño para minimizar el número de

Simplicidad del diseño vulnerabilidades explotables por el atacante y debilidades en el
sistema.
Mínimo privilegio Lo que no está expresamente permitido está prohibido.

TEMA 1 – Ideas clave 41 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Asignación a las diferentes entidades de un rol que implique el

Separación de
acceso a un subconjunto de funciones o tareas y a los datos
privilegios
necesarios.
Minimizar la probabilidad de que actores maliciosos obtengan
Separación de
fácilmente acceso a las ubicaciones de memoria u objetos de
dominios
datos en el sistema.
Separación código, Reducir la probabilidad de que un ciberatacante que haya
ejecutables y datos accedido a los datos del programa fácilmente pueda localizar y
configuración y acceder a los archivos ejecutables y datos de configuración del
programa programa.
Entorno de
Evitar vulnerabilidades aplicando una serie de principios de
producción o
validación de las entradas.
ejecución inseguro
Registro de eventos de Generar eventos (logs) de seguridad, para garantizar las acciones
seguridad realizadas por un ciberatacante se observan y registran
Reducir la probabilidad de que un fallo en el software pueda
Fallar de forma segura saltarse los mecanismos de seguridad de la aplicación, dejándolo
en un modo de fallo inseguro vulnerable a los ataques.
Reducir al mínimo la cantidad de tiempo que un componente de
Diseño de software
un software defectuoso o fallido sigue siendo incapaz de
resistente
protegerse de los ataques.
Concienciarse de que la seguridad por oscuridad es un
La seguridad por
mecanismo de defensa que puede proporcionar a un atacante
oscuridad: error
información para comprometer la seguridad de una aplicación.

Seguridad por defecto Reducir la superficie de ataque de una aplicación o sistema.

Tabla 2. Objetivos principios de seguridad.

1.6. Tipos de S-SDLC

Introducción

Las organizaciones deben insertar buenas prácticas de seguridad en el

proceso de desarrollo de software al objeto de obtener software más
seguro o confiable. Para ello se tienen dos posibilidades, la primera adoptar una
metodología segura de desarrollo que proporcione un marco integrado de
mejora de la seguridad, como los presentadas en este apartado y la segunda la
evolución y mejora de sus actuales prácticas de seguridad.

Estas metodologías no modifican las actividades tradicionales de SDLC, insertan

nuevas actividades con el objetivo de reducir el número de debilidades y
vulnerabilidades en el software, a este nuevo ciclo de vida con buenas prácticas
de seguridad incluidas lo denominaremos S-SDLC.

TEMA 1 – Ideas clave 42 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

En el presente apartado se presentan varios modelos de ciclo de vida S-SDLC con

prácticas de seguridad incluidas, que se pueden aplicar independientemente del tipo de
modelo: ciclo de vida en espiral, extreme programming, etc. Además, algunos métodos
estándar de desarrollo han demostrado que aumentan la probabilidad de que el
software producido por ellos será seguro. Debido a la popularidad actual de los
métodos ágiles, es importante el estudiar los problemas de seguridad que surgen
cuando se utiliza este tipo de ciclos de vida.

Los equipos de desarrollo que utilizan metodologías seguras en el SDLC, casi

inmediatamente perciben una mejora en su capacidad para detectar y
eliminar errores de codificación y debilidades de diseño en el software que
producen, antes de que entren en un proceso de distribución e instalación. Esta mejora
se pondrá de manifiesto conforme el software pase sus controles de seguridad
(revisiones de diseño y código de seguridad, análisis de fallos de inyección, pruebas de
penetración, análisis de vulnerabilidades, etc.).

Los elementos clave de un proceso de S-SDLC, según Goertzel (2009), son:

» Hitos de control en las fases del SDLC.

» Principios y prácticas seguras de software.
» Requisitos adecuados.
» Arquitectura y diseño adecuados.
» Codificación segura.
» Integración de forma segura de los módulos y componentes del software:
» Pruebas de seguridad.
» Despliegue y distribución segura.
» Sostenimiento seguro.
» Herramientas de apoyo al desarrollo.
» Gestión de configuración de sistemas y procesos.
» Conocimientos de seguridad de los desarrolladores.
» Gestión segura del proyecto y compromiso de la alta dirección.

En los siguientes apartados se introduce la metodología S-SDLC McGraw’s Seven

Touchpoints por ser la tomada como base para este tema y se nombran otras existentes
y se referencian otras metodologías actualmente en uso por diferentes organizaciones.

TEMA 1 – Ideas clave 43 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

McGraw’s Seven Touchpoints

Es el modelo base tomado para el desarrollo de este tema, McGraw (2005) propone un
modelo de S-SDLC (cascada o iterativo) en el que define una serie de mejores
prácticas de seguridad a aplicar a los artefactos de cada fase del desarrollo.

En esencia, el proceso se centra en la incorporación de las siguientes prácticas

ordenadas por orden de importancia:

» Revisión de código
» Análisis de riesgo arquitectónico
» Pruebas de penetración
» Pruebas de seguridad basados en riesgo
» Casos de abuso
» Requisitos de seguridad
» Operaciones de seguridad
» Revisión externa

Además de las siete prácticas se identifica una octava, el análisis externo, en el que
un equipo de analistas externos a la organización y por tanto al equipo de desarrollo del
software, realiza revisiones de seguridad independientes, evaluaciones y pruebas del
diseño del software y la implementación. La figura siguiente, muestra el de ciclo de
vida de desarrollo de software seguro S-SDLC en el que se especifican las actividades y
pruebas de seguridad a efectuar en cada fase del mismo.

6. 4. Pruebas 1. 2. 7.
5. Casos 2. Análisis 3. Pruebas
Requisitos basadas Revisión Análisis Operaciones
de abuso de riesgos penetración
seguridad en riesgo código riesgos Seguridad

Requisitos
Arquitectura Plan de Pruebas y Realimentación de
Casos de Codificación producción
Diseño pruebas resultados
abuso

8. Revisión
externa

Figura 17. McGraw’s Seven Touchpoints.

TEMA 1 – Ideas clave 44 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Este orden descrito no se adecuará perfectamente a todas las organizaciones. De hecho,

el orden refleja el trabajo desarrollado en años de experiencia de McGraw al aplicar
estas prácticas en empresas desarrolladoras de software. Por esa razón, la revisión de
código viene antes de análisis de riesgos arquitectónico. Hay que resaltar que estas
actividades hay que repetirlas a lo largo del ciclo de vida lo que supone un ciclo
continuo en la ejecución de las distintas actividades de seguridad:

» Conforme se descubren nuevas amenazas y vulnerabilidades, se tienen nuevos

riesgos que dan lugar a un nuevo caso de abuso y un nuevo análisis de riesgos.
» Cambios en el sistema con nuevos componentes de software ó hardware, implica el
rehacer el análisis de riesgos y revisar el código de los nuevos componentes
software.
» Nuevos defectos de implementación que modifican las especificaciones ó del sistema
implican nuevas revisiones de código y as pruebas de seguridad.

Otras metodologías

» Microsoft Trustworthy Computing SDL: [Link]

» CLASP: Comprehensive Lightweight Application Security Process:
[Link]
» Team Software Process (TSP): [Link]
» Oracle Software Security Assurance:
[Link]
» Appropriate and Effective Guidance in Information Security (AEGIS):
[Link]
» Rational Unified Process-Secure (RUPSec):
[Link]
» Secure Software Development Model (SSDM):
[Link]
» Waterfall-Based Software Security Engineering Process Model:
[Link]
» Building Security in Maturity Model (BSIMM):
[Link]
» Software Assurance Maturity Model (OPEN SAMM):
[Link]

TEMA 1 – Ideas clave 45 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

1.7. Metodologías y estándares

Introducción

Las metodologías y estándares consisten básicamente en guías de comportamiento

específicas destinadas a aplicar una o varias políticas. Su aplicación a la
seguridad del software consiste en el desarrollo de procesos que implementen técnicas
de seguridad en todas las actividades que intervienen en el ciclo de vida de desarrollo
de software. Para conseguir lo anterior, las organizaciones deben implantar un
estándar de aseguramiento de la calidad de software y un estándar de
seguridad.

Las organizaciones relacionadas con normas internacionales sobre seguridad de la

información son:

» International Organization for Standardization (ISO).

» International Electrotechnical Commission (IEC).
» National Institute of Standards and Technology (NIST).

A continuación, se realiza una descripción resumida de los estándares más importantes

que las organizaciones pueden adoptar para conseguir los beneficios que suponen tener
procesos implantados de calidad y seguridad del software en todas las actividades del
SDLC, así como una aclaración de las diferencias entre seguridad del software versus
aseguramiento de la calidad.

Seguridad del software versus aseguramiento de la calidad

Antes de comenzar con las actividades y medidas de seguridad a integrar en el SDLC, es

conveniente aclarar las principales diferencias entre aseguramiento de la calidad y
seguridad del software:

» Aseguramiento de la calidad su principal objetivo es hacer que el software

funcione correctamente conforme a las especificaciones del mismo.
» Seguridad del software tiene por objetivo que tanto el software como su entorno
de ejecución presenten el mínimo de vulnerabilidades y por tanto su
superficie de ataque sea la menor posible, de forma sea confiable a pesar
de la presencia de un ambiente externo hostil con ciberataques en curso.

TEMA 1 – Ideas clave 46 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Estas diferencias se pueden caracterizar también en términos de amenazas, las

principales de la calidad son internas no intencionadas debidas a errores o
descuidos, es decir la presencia de defectos en el software que pongan en peligro su
capacidad de funcionar correctamente y de manera previsible.

Por otro lado, las amenazas a la seguridad son internas y externas e incluyen una
intención maliciosa materializada en posibles ciberataques que puedan recibir el
software o su entorno de ejecución del software cuando se tiene un comportamiento
impredecible (por cualquier razón).

En un proceso de desarrollo de software seguro, los profesionales de control de calidad

deben tener siempre en cuenta la seguridad y ser exactos y rigurosos en las
especificaciones, diseño y verificación de la seguridad del software, en base a los
riesgos estimados de forma que el proceso de garantía de calidad incorporare algunas
actividades de su gestión y nuevos procedimientos relacionados con la seguridad.

» Estándares de calidad

o ISO/IEC JTC1 SC7. Ingeniería de software y de sistemas.

o ISO 9126. Calidad del producto.
o ISO 14598. Evaluación de productos de software.
o ISO 12119. Requerimientos de calidad y prueba de COTS.
o ISO 15939. Proceso de medición de software.
o ISO 9000. Familia de normas son normas de calidad establecidas por la ISO.
– UNE-EN ISO 9000. Sistemas de gestión de la calidad. Fundamentos y
vocabulario (ISO 9000:2000).
– UNE-EN 150 9000. Sistemas de gestión de la calidad. Requisitos (ISO
9001:2000).
– UNE-EN 150 9000. Sistemas de gestión de la calidad. Directrices para la mejora
del desempeño (ISO 9004:2000).

» Estándares de seguridad

o ISO / IEC 15026 Systems and software engineering — Systems and software
assurance.
o System Security Engineering Capability Maturity Model (SSE-CMM
Norma ISO/IEC 21827). Desarrollado por la «International Systems Security

TEMA 1 – Ideas clave 47 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Engineering Association (ISSEA)», el Modelo de Capacidad y Madurez en la

Ingeniería de Seguridad de Sistemas es un modelo derivado del CMM y que
describe áreas de ingeniería de seguridad y las características esenciales de los
procesos que deben existir en una organización para la mejora y evaluación de la
madurez de la ingeniería de los procesos de seguridad utilizados para producir
productos de sistemas confiables y seguros.
o Norma IEEE 1074-2006, Developing Software Project Life Cycle Processes.
Developing Software Project Life Cycle Processes Norma IEEE 1074-2006.
o ISO / IEC 24772. Proyecto 22, grupo de trabajo para evitar vulnerabilidades en
lenguajes de programación proporcionando una orientación a los programadores
sobre cómo evitar las vulnerabilidades que se pueden introducir en el software al
utilizar ciertas características de un lenguaje de programación seleccionado para
el desarrollo de un proyecto software, sugiriendo alternativas de patrones de
codificación que las eviten. Así mismo ayuda a elegir las herramientas de análisis
estático, detección de vulnerabilidades y orientación de codificación para mejorar
la eficacia en la reducción de vulnerabilidades.
o ISO/IEC 27034-1, Information technology — Security techniques —
Application security. Norma para ayudar a las organizaciones a integrar la
seguridad en el ciclo de vida de sus aplicaciones. Proporciona:
− Los conceptos, principios, marcos, componentes y procesos.
− Mecanismos orientados a procesos para establecer los requisitos de
seguridad, evaluarlos riesgos de seguridad y seleccionar los controles de
seguridad y las medidas de verificación correspondientes.
− Directrices para establecer los criterios de aceptación en los contratos de
desarrollo, compra y asistencia técnica para la operación de las
aplicaciones.
− Mecanismos orientados a procesos para determinar, generar y recopilar las
evidencias necesarias para demostrar que las aplicaciones son confiable en
el entono de operación de destino.
− Apoyo y soporte a los conceptos especificados en la norma ISO/IEC 27001
implementando la seguridad de información bajo un enfoque de gestión de
riesgo.
− Proporciona un marco de referencia para implementar los controles de
seguridad especificados en ISO/IEC 27002 y en otras normas.
o ISO/IEC 15408, Evaluation Criteria for IT Security. The Common
Criteria. Los criterios comunes (CC) permiten comparar los resultados entre
evaluaciones de productos independientes en base a un conjunto común de

TEMA 1 – Ideas clave 48 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

requisitos funcionales para los productos hardware, software o firmware de las

TIC, estableciendo un nivel de confianza en el grado en el que el producto
satisface la funcionalidad de seguridad en base a la superación de unas pruebas
aplicadas.

Los CC contribuyen a aumentar la confianza de los que adquieran productos TIC

que incluyan en funciones de seguridad pues pueden determinar más fácilmente
cuándo un producto cumple una serie de requisitos pues exige a los fabricantes de
los productos certificados publicar una documentación exhaustiva sobre la
seguridad de los productos evaluados por laboratorios independientes.

En lo relativo a la seguridad del software, los niveles EAL más altos poseen un
nivel de garantía de evaluación que captura un conjunto específico de requisitos
de seguridad, de los que es posible deducir algunas propiedades generales que el
software debe exhibir para alcanzarlos:

‒ EAL 5: El sistema debe ser semiformalmente diseñado y probado basado en un

modelo formal y una presentación semiformal de la especificación funcional y el
diseño de alto nivel, de forma que las vulnerabilidades resistan relativamente a
los ataques de penetración. Esta propiedad también se aplica al diseño de
software.
‒ EAL 6: Igual que EAL 5 y además el diseño debe ser semiformalmente
verificado. Como el anterior, este establecimiento también debe aplicarse al
diseño de software.
‒ EAL 7: Igual que EAL 6, más el diseño debe ser verificado oficialmente y
formalmente testeado. Como el anterior, este establecimiento también debe
aplicarse al diseño de software.

TEMA 1 – Ideas clave 49 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

1.8. Referencias bibliográficas

ALERT LOGIG. (2014). Defense throughout the vulnerability life cycle with alert logic
threat and log manager. Disponible en:
[Link]

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.

Barnum, S. y Sethi, A. (2007). Attack Patterns as a Knowledge Resource for Building

Secure. Software Cigital, Inc. Disponible en:
[Link]
Knowing_Your_Enemies_in_Order_to_Defeat_Them-[Link]

Barnum, S. (2008). Common Attack Pattern Enumeration and Classification (CAPEC)

Schema Description. Department of Homeland Security EE. UU. Software Cigital.
Disponible en:
[Link]
[Link]

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.

Centro Criptológico Nacional (2013). Guía de Seguridad de la STIC (CCN-STIC-400).

Manual de Seguridad de las Tecnologías de la Información y Comunicaciones.

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:
[Link]

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

Hewlett-Packard Development Company (2011). Top Cyber Security Risks Report.

TEMA 1 – Ideas clave 50 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Hewlett-Packard Development Company, L. P. (2015). HP Security Research. Cyber

Risk Report 2015. Disponible en: [Link]
solutions/cyber-risk-report-security-vulnerability/

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.

INTEFCO. (2011). Cuaderno de notas del Observatorio ¿Qué son las vulnerabilidades
del software? Disponible en: [Link]
content/uploads/2011/08/Que_son_las_vulnerabilidades_del_-[Link]

ISO/IEC 27034-1, Information technology - Security techniques - Application security.

Klocwork Inc. (2004). Improving Software by Reducing Coding Defects Investing in

software defect detection and prevention solutions to improve software reliability,
reduce development costs, and optimize revenue opportunities.

Komaroff, M. y Baldwin, K. (2005). DoD Software Assurance Initiative. Disponible en:

[Link]
[Link]

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

Wesley Professional.

Microsoft Corporation. (2006). Understanding the Security Risk Management

Discipline.

MITRE. (2011). CWE/SANS Top 25 Most Dangerous Software Errors.

MITRE (2012). CVE Introductory Brochure. A brief two-page introduction to the CVE
Initiative.

MITRE. (2012). CWE Introductory Brochure A brief two-page introduction to the

CWE initiative.

TEMA 1 – Ideas clave 51 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

National Aeronautics and Space Administration (NASA) (1992). Software Assurance

Standard, Standard No. NASA-STD-2201-93.

OWASP TOP 10. (2013). Los diez riesgos más importantes en aplicaciones WEB.
Edición en español. Disponible en: [Link]
[Link]

Rald, S. L. N. y Pedersen, J. M. (2012). An Updated Taxonomy for Characterizing

Hackers According to Their Threat Properties. Aalborg: Department of Electronic
Systems, Aalborg University, Denmark.

Rambla, J. L. G., Alonso, J, M. (2009). Esquema Nacional de Seguridad con Microsoft.

Vizcaya: Microsoft Ibérica S.R.L.

Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de

Seguridad en el ámbito de la Administración Electrónica.

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.

SAFECode. (2010). Software Integrity Controls. Assurance-Based approach to

minimizing risks in the software supply chain. Dispobible en:
[Link]

Software Assurance Pocket Guide Series (2012). Software Assurance in Acquisition and
Contract Language. Acquisition & Outsourcing, Volume I.

Sotirov, A. I. (2002). Automatic vulnerability detection using static source code

analysys [Tesis], Tuscaloosa, Alabama.

Ortiz, Z. y Galindo, F. (2006). Hacia una Taxonomía de Incidentes de Seguridad en

Internet. Madrid: Ciencias de investigación Academia Desarrollo.

TEMA 1 – Ideas clave 52 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Lo + recomendado

Lecciones magistrales

Tipos de ciclos de desarrollo de software seguro S-SDLC

En la presente clase se presentan varios modelos de ciclo de vida S-SDLC con prácticas
de seguridad incluidas que se pueden aplicar independientemente del tipo de modelo
de ciclo de vida, en espiral, extreme programming, etc. Además, algunos métodos
estándar de desarrollo se ha
demostrado que aumentan la
probabilidad de que el software
producido por ellos será seguro y
confiable. Así mismo, debido a la
popularidad de los métodos ágiles, es
importante el estudiar los problemas
de seguridad que surgen cuando se
utilizan este tipo de ciclos de vida.

El vídeo está disponible en el aula virtual.

No dejes de leer…

The protection of information in computer systems

Documento del año 1975 que presenta conceptos de seguridad del software que siguen
siendo muy relevante en la actualidad.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]

TEMA 1 – Lo + recomendado 53 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

CWE/SANS Top 25 most dangerous software errors

El documento presenta una lista de los 25 errores en el software más dañinos,

extendidos y críticos que representan vulnerabilidades fácilmente detectables y
explotables que permiten al atacante tomar control de la máquina.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]

A systemic approach for assessing software supply-chain risk

El documento describe un enfoque sistémico para evaluar y gestionar los riesgos de

seguridad de la cadena de suministro del software.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]
assessing-software-supply-chain-risk

TEMA 1 – Lo + recomendado 54 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

No dejes de ver…

The building security in maturity model (BSIMM)

En este vídeo se da una visión general de una importante iniciativa de Seguridad del
Software llamada BSIMM y su forma de uso como una herramienta de medida para su
organización, proveedores y su combinación con otros métodos de medición de
seguridad.

Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

[Link]

TEMA 1 – Lo + recomendado 55 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Security design reviews

La seguridad no es una tarea añadida solo al final de la fase de implantación, debe

abarcar todas las fases del ciclo de vida del desarrollo de una aplicación. En este vídeo
se presenta más que suficientes razones de la importancia de las evaluaciones y
revisiones de seguridad del diseño y las diferentes prácticas de seguridad de cada una
de las fases de SDLC.

Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

[Link]

TEMA 1 – Lo + recomendado 56 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

+ Información

A fondo

Cyber risk report 2016

Informe del año 2016, realizado por la compañía HP Security research, que
proporciona una visión amplia del panorama de las vulnerabilidades del software, así
como una profunda investigación y análisis de los ataques de y tendencias. Para acceder
al artículo hay que registrarse.

Accede al documento desde el aula virtual o a través de la siguiente dirección web:

[Link]
[Link]

Secure coding: building security into the software development life cycle

Artículo de Russell L. Jones y Abhinav Rastogi que trata la inclusión de buenas

prácticas de seguridad en el ciclo de vida de desarrollo del software.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]

TEMA 1 – + Información 57 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Improving software security during development

En este artículo de Robert W. Usher se exploran las bases para la creación de software
y sistemas seguros durante su etapa de desarrollo. La seguridad del software se
relaciona directamente con los procesos de calidad.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]
security-development_384

Cuaderno de notas del observatorio: ¿qué son las vulnerabilidades del

software?

Artículo que analiza los aspectos básicos de las vulnerabilidades: por qué ocurren y
cómo gestionarlas.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]

TEMA 1 – + Información 58 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

The standard for information security vulnerability names

Artículo introductorio al formato CVE de gestión de vulnerabilidades de software.

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]

Practical measurement framework for software assurance and

information security

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

Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

[Link]
[Link]

TEMA 1 – + Información 59 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Webgrafía

Build security in home

El esfuerzo del portal expresamente apunta al problema, de ampliar y extender el

conocimiento de seguridad de software.

Accede a la página web a través del aula virtual o desde la siguiente dirección:
[Link]

Open web application security project (OWASP)

El Open application web security project (OWASP) es una organización a nivel

mundial sin ánimo de lucro, enfocada en mejorar la seguridad del software. Dispone de
gran cantidad de recursos como guías de diseño y pruebas, herramientas de test, blog,
etc.

Accede a la página web a través del aula virtual o desde la siguiente dirección:
[Link]

TEMA 1 – + Información 60 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Microsoft security developer center

Sitio web que describe las buenas prácticas de desarrollo seguro del
modelo de S-SDLC de Microsoft y sus herramientas asociadas.

Accede a la página web a través del aula virtual o desde la siguiente dirección:
[Link]

Micro Focus

Sitio web de la empresa Micro Focus con recursos 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:
[Link]

TEMA 1 – + Información 61 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

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:
[Link]

Bibliografía

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

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

Howard, M.; LeBlanc, D. (2003). Writing Secure Code. Washington: Microsoft Press.

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

Krassowski, A. and Meunier, P. (2008). Secure Software Engineering: Designing,

Writing, and Maintaining More Secure Code. Boston: Addison-Wesley.

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

Mano, P. (2014). The official (ISC)2® guide to the CSSLP. Florida: CRC Press.

TEMA 1 – + Información 62 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Mead, N. y Woody, C. (2016). Cyber Security Engineering: A Practical Approach for

Systems and Software Assurance. SEI Series in Software Engineering. EE. UU.:
Addison-Wesley Professional.

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.

TEMA 1 – + Información 63 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Actividades

Trabajo: Comparación de ciclos de vida de desarrollo de

software seguro (S-SDLC)

Como actividad puntuable para el tema 1 tendrás que seguir profundizando en los
modelos S-SDLC realizando un trabajo que contenga al menos el siguiente contenido:

» Introducción a los S-SDLC.

» Descripción resumida de los diferentes tipos de S-SDLC.
Comparación de los diferentes S-SDLC cubriendo al menos las siguientes
características:
o Actividades de Ingeniería de Requisitos.
o Actividades de diseño.
o Actividades de implementación.
o Actividades de pruebas de verificación y validación.
o Recursos.
o Uso por la empresa.
o Etc.
» Propuesta de un nuevo S-SDLC (incluir un diagrama del nuevo modelo).
» Conclusiones.

Extensión máxima de la actividad: 8 a 12 páginas, fuente Georgia 11 e interlineado 1,5.

TEMA 1 – Actividades 64 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

Test

1. Indica cuál de las siguientes respuestas no es una causa de aparición de

vulnerabilidades en el software:
A. No seguimiento, por los desarrolladores, de guías de normalizadas de estilo en
la codificación.
B. Desarrollo de las aplicaciones por una asistencia técnica o entidades
subcontratadas.
C. No realización de pruebas de seguridad basadas en riesgo.
D. No control de la cadena de suministro del software, lo que puede dar lugar a la
introducción de código malicioso en origen.

2. Indica las respuestas no correctas respecto al ataque a las aplicaciones durante las
diferentes fases de su ciclo de vida:
A. Desarrollo: un desarrollador puede alterar de forma intencionada o no el
software bajo desarrollo.
B. Distribución e instalación: ocurre cuando el instalador del software bastiona la
plataforma en la que lo instala.
C. Operación: cualquier software que se ejecuta en una plataforma conectada a la
red tiene sus vulnerabilidades expuestas durante su funcionamiento, excepto si
está protegido por dispositivos de protección de la infraestructura de red.
D. Mantenimiento o sostenimiento: no publicación de parches de las
vulnerabilidades detectadas en el momento oportuno o incluso introducción de
código malicioso por el personal de mantenimiento en las versiones actualizadas
del código.

3. Las fuentes de las vulnerabilidades se deben a (indicar la incorrecta):

A. Fallos provenientes de la codificación de los diseños del software realizados.
B. Fallos provenientes de la cadena de distribución del software.
C. Los sistemas hardware o software contienen frecuentemente fallos de diseño
que pueden ser utilizados para realizar un ataque.
D. La instalación de software por defecto implica por lo general la instalación de
servicios que no se usan, pero que pueden presentar debilidades que
comprometan la máquina.

TEMA 1 – Test 65 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

4. Señalar la incorrecta. Entre las técnicas y mecanismos que se tienen para

salvaguardar la integridad. Tenemos, por ejemplo:
A. Identificación del modo de trasmisión y procesado de los datos por la
aplicación.
B. Uso de arquitecturas de alta disponibilidad, con diferentes tipos de
redundancias.
C. Uso de firma digital.
D. Estricta gestión de sesiones

5. Señalar las respuestas correctas. Algunas de las opciones específicas de diseño del
software que lo simplifican son:
A. Limitar el número de estados posibles en el software.
B. Aplicación de derechos de administrador.
C. Diseñar los componentes del software con el conjunto mínimo de características
y capacidades que se requieran para realizar sus tareas en el sistema.
D. Acceso a los datos necesarios que debe gestionar para llevar a cabo su función
en base a una serie de roles definidos.

6. Señalar las respuestas correctas. Para conseguir que el desarrollo de una aplicación
posea las propiedades y principios de diseño del software seguro presentados en los
apartados anteriores, se necesita que el personal de diseño y desarrollo desarrollen
dos perspectivas:
A. Perspectiva administrador.
B. Perspectiva atacante.
C. Perspectiva usuario.
D. Perspectiva defensor.

TEMA 1 – Test 66 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

7. Señala la respuesta correcta. Como se define resiliencia:

A. Capacidad de resistencia y tolerancia a los ataques realizados por los agentes
maliciosos (malware, hackers, etc.).
B. Capacidad que garantiza la posibilidad de imputar las acciones relacionadas en
un software a la persona, entidad o proceso que la ha originado.
C. Capacidad del software de para aislar, contener y limitar los daños
ocasionados por fallos causados por ataques de vulnerabilidades explotable del
mismo, recuperarse lo más rápido posible de ellos y reanudar su operación en o
por encima de cierto nivel mínimo predefinido de servicio aceptable en un tiempo
oportuno.
D. Capacidad del software para «tolerar» los errores y fallos que resultan de
ataques con éxito y seguir funcionando como si los ataques no se hubieran
producido.

8. Indica la respuesta correcta. A qué principio de diseño le corresponde la siguiente

afirmación: «Estrategia de protección consistente en introducir múltiples capas de
seguridad, que permitan reducir la probabilidad de compromiso en caso de que una de
las capas falle y en el peor de los casos minimizar el impacto».
A. Seguridad por defecto.
B. Separación de privilegios.
C. Separación de dominios.
D. Defensa en profundidad.

9. Señala la práctica de seguridad a la que corresponde la siguiente afirmación. «Son

soluciones generales repetibles a un problema de ingeniería de software recurrente,
destinadas a obtener un software menos vulnerable y un diseño más resistente y
tolerante a los ataques, normalmente se limitan a funciones y controles de seguridad
a nivel del sistema, comunicaciones e información».
A. Test de Penetración.
B. Revisión de código.
C. Casos de abuso.
D. Patrones de diseño.

TEMA 1 – Test 67 © Universidad Internacional de La Rioja (UNIR)

 Seguridad en el Software

10. Señala la respuesta incorrecta. El cálculo de código CVSS se realiza en base a tres
tipos de métricas ambientales:
A. Métricas base.
B. Métricas estadísticas.
C. Métricas temporales.
D. Métricas ambientales.

TEMA 1 – Test 68 © Universidad Internacional de La Rioja (UNIR)