Tema 1. El Problema de La Seguridad en El Software

Tema 1
Seguridad en el Software
El problema de la
seguridad en el software
Índice
Esquema 3
Ideas clave 4
1.1. Introducción y objetivos 4
1.2. Introducción al problema de la seguridad en el
software 4
1.3. Vulnerabilidades y su clasificación 12
1.4. Propiedades software seguro 21
© Universidad Internacional de La Rioja (UNIR)
1.5. Principios de diseño seguridad del software 26

1.6. Tipos de S-SDLC 46
1.7. Metodologías y estándares 50
1.8. Referencias bibliográficas 54
A fondo 58
Test 61
El problema de la seguridad en el software
Introducción al problema de la
seguridad en el software
Vulnerabilidades y su Propiedades software Principios de diseño Metodologías

Tipos de S-SDLC
clasificación seguro seguridad del software estándares
Esenciales: Defensa en Seguridad del software

Ciclo de vida de una profundidad Ciclos de vida de
Confidencialidad versus aseguramiento
vulnerabilidad software seguro
Integridad Simplicidad diseño de la calidad
Disponibilidad
Mínimo privilegio
Gestión de Estándares de calidad y
Separación privilegios
vulnerabilidades seguridad del software
Complementarias: Separación dominios
Fiabilidad
Autenticación
Separación código,
Clasificación de las Trazabilidad entorno ejecución
vulnerabilidades Robustez inseguro, registros
Resiliencia eventos seguridad
Tolerancia
Fallar de forma segura,
Escáneres de diseño SW resistente,
vulnerabilidades seguridad por
oscuridad y defecto
Tema 1. Esquema
Esquema
3
Ideas clave
1.1. Introducción y objetivos
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 esta podrá atacar las
demás empezando por las más vulnerables. Se hace necesario, por tanto, disponer
de software seguro que funcione en un entorno agresivo y malicioso.
Los objetivos del presente tema son los siguientes:
 Introducir al alumno en los principales conceptos que abarca la Seguridad del

Software en cuanto a los beneficios que produce y su importancia en la seguridad
global de un sistema.
 Estudiar las propiedades de un software seguro.
 Estudiar los principios de diseño seguro a tener en cuenta en la arquitectura y
diseño de cualquier aplicación.
 Introducir una serie de 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
4
Tema 1. Ideas clave
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.
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.
5
Tema 1. Ideas clave
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.
 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.
6
Tema 1. Ideas clave
 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
código malicioso por el personal de mantenimiento en las versiones actualizadas

del código.
7
Tema 1. Ideas clave
Las vulnerabilidades de alta severidad (CVSS 8 a 10, clasificación definida en la OSVDB)
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.
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.
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 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.
8
Tema 1. Ideas clave
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 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.
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
9
Tema 1. Ideas clave
que el ciberatacante consigue vencer esas defensas, por ejemplo, mediante ingeniería
social, y comprometer una máquina del interior, a través de esta 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 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.
10
Tema 1. Ideas clave
Figura 2. Coste relativo de corrección de vulnerabilidades en función de la etapa de desarrollo. Fuente:
https://www.qualys.com/docs/2018/qsc/las-vegas/qsc18-day2-23-operationalizing-web-application-security-
imaginex.pdf
La empresa Microsoft, una de las primeras empresas en aplicar un modelo S-SDLC,

presentó los siguientes datos al año de tener implantado el citado modelo (Caro,
2016):
 75 % de las vulnerabilidades están relacionadas con las aplicaciones.

 Alrededor de un 40-50 % de reducción en el número de vulnerabilidades tras la
implantación de un S-SDLC en el primer año (un 75-80 % sobre vulnerabilidades
críticas).
 Una reducción de un 50 % en el número de vulnerabilidades implica una reducción
de un 75 % en los costes de gestión de la configuración y respuesta a incidentes.
Figura 3. Datos empresa Microsoft. Fuente: Caro (2016).
11
Tema 1. Ideas clave
1.3. Vulnerabilidades y su clasificación
Se define vulnerabilidad como un fallo de programación, configuración o diseño que

permite, de alguna manera, a los atacantes, de alguna manera, alterar el
comportamiento normal de un programa y realizar algo malicioso como alterar
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 (errores de programación) y flaws (errores de diseño) del
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 4. Tipos de vulnerabilidades del software.
12
Tema 1. Ideas clave
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.
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 de este 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.
13
Tema 1. Ideas clave
 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.
Descubrir Utilización Verificación Solución Difusión Medidas Corrección Búsqueda Actualizar
Figura 5. 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 6. Riesgo de una vulnerabilidad en función del tiempo. Fuente: Alert Logic (2014).
14
Tema 1. Ideas clave
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.
Existen varios estándares, catálogos o bases de datos, que a continuación pasamos a

comentar:
 Common Vulnerabilities and Exposures (CVE). 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:
• 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 7. Identificador CVE.

• Breve descripción de la vulnerabilidad.

• Referencias.
15
Tema 1. Ideas clave
 Common Vulnerability Scoring System (CVSS). 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.
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 8. 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
• Explotabilidad: vectores de acceso, complejidad de acceso y autenticación.

• Impacto: confidencialidad, integridad y disponibilidad.
Existe una página web donde se puede realizar el cálculo de la severidad de una
vulnerabilidad conforme al estándar CBSS.
16
Tema 1. Ideas clave
 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.
 National Vulnerability Database (NVD). 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.
Open Vulnerability and Assessment Languages (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.
 Common Weakness Enumeration (CWE). 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:
• Proporcionar un lenguaje común para describir los defectos y debilidades de

seguridad de software en su arquitectura, diseño y codificación.
17
Tema 1. Ideas clave
• Proporcionar un estándar de comparación de herramientas de auditoría
seguridad de software.
• Proporcionar una línea base para la identificación de vulnerabilidades, su
mitigación y los esfuerzos de prevención.
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 error.

• Descripción del error.
• Términos alternativos.
• Descripción técnica del error.
• Probabilidad de explotar el error.
• Descripción de las consecuencias de la explotación.
• Posibles mitigaciones.
• Otros errores relacionados.
• Taxonomía 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 9. Campos de información de cada entrada CWE.
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 otras solo a aplicaciones web,
como son OWASP Top 10 y WASC Threat Clasification v2.0. A continuación,
describimos algunas de las mencionadas.
18
Tema 1. Ideas clave
Consulta aquí más información sobre las diferentes clasificaciones:
 MITRE Top 25: http://cwe.mitre.org/top25/
 OWASP Top 10: https://owasp.org/www-project-top-ten/
 WASC Threat Classification v2.0: http://www.webappsec.org/projects/threat/
 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 EE.UU. 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.
• Todo tipo de aplicaciones web y no web.
• Dan lugar a vulnerabilidades graves en el software.
• Prevención, mitigación y principios de programación seguros.
En la siguiente tabla se pueden consultar las 25 principales vulnerabilidades:
Rank Id Nombre Score

[1] CWE-119 Improper Restriction of Operations within the Bounds of a 75.56
Memory Buffer.
[2] CWE-79 Improper Neutralization of Input During Web Page 45.69
Generation ('Cross-site Scripting').
[3] CWE-20 Improper Input Validation. 43.61
[4] CWE-200 Information Exposure. 32.12
[5] CWE-125 Out-of-bounds Read. 26.53
[6] CWE-89 Improper Neutralization of Special Elements used in an SQL 24.54
Command ('SQL Injection').
[7] CWE-416 Use After Free. 17.94
[8] CWE-190 Integer Overflow or Wraparound. 17.35

[9] CWE-352 Cross-Site Request Forgery (CSRF). 15.54
[10] CWE-22 Improper Limitation of a Pathname to a Restricted Directory 14.10
('Path Traversal').
[11] CWE-78 Improper Neutralization of Special Elements used in an OS 11.47
Command ('OS Command Injection').
19
Tema 1. Ideas clave
[12] CWE-787 Out-of-bounds Write. 11.08
[13] CWE-287 Improper Authentication. 10.78
[14] CWE-476 NULL Pointer Dereference. 9.74
[15] CWE-732 Incorrect Permission Assignment for Critical Resource. 6.33
[16] CWE-434 Unrestricted Upload of File with Dangerous Type. 5.50
[17] CWE-611 Improper Restriction of XML External Entity Reference. 5.48
[18] CWE-94 Improper Control of Generation of Code ('Code Injection'). 5.36
[19] CWE-798 Use of Hard-coded Credentials. 5.12
[20] CWE-400 Uncontrolled Resource Consumption. 5.04
[21] CWE-772 Missing Release of Resource after Effective Lifetime. 5.04
[22] CWE-426 Untrusted Search Path. 4.40
[23] CWE-502 Deserialization of Untrusted Data. 4.30
[24] CWE-269 Improper Privilege Management. 4.23
[25] CWE-295 Improper Certificate Validation. 4.06
Tabla 1. Veinticinco vulnerabilidades MITRE TOP 25. Fuente: MITRE (2019).
Para cada entrada de la tabla se proporciona la siguiente información:

• Clasificación. La clasificación de la debilidad CVSS.
• Identificador CWE.
• Información adicional sobre la debilidad que puede ser útil para adoptar
decisiones de priorización de acciones de mitigación.
• Breve discusión informal sobre la naturaleza de la debilidad y de sus
consecuencias.
• Los pasos que los desarrolladores pueden tomar para mitigar o eliminar las
debilidades.
• Otras entradas CWE que están relacionadas con la debilidad Top 25.
• 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.
• Enlaces con más detalles, incluyendo ejemplos de código fuente que

demuestran la debilidad, métodos de detección, etc.
20
Tema 1. Ideas clave
 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.
• Las 10 vulnerabilidades de seguridad más críticas en aplicaciones web.
• Lista ordenada por criticidad y predominio.
• 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:

https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf
 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.
• Unificación y organización de las amenazas de seguridad Web.
• Describe amenazas, debilidades y ataques.
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.
21
Tema 1. Ideas clave
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:
• Identificación del modo de trasmisión y procesado de los datos por la

aplicación.
• Uso de técnicas de cifrado para asegurar que los componentes y los datos no
son alterados o corrompidos.
• Estricta gestión de sesiones.
• Uso de sistemas de monitorización de la integridad
• Uso de firma digital.
• Trasmisión cifrada de los datos.
 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 estos. Entre las técnicas y mecanismos que se tienen para
salvaguardar la disponibilidad, tenemos, por ejemplo:
• Análisis de qué servicios e información es crítica y el modo de tenerlos

disponibles.
• Uso de arquitecturas de alta disponibilidad, con diferentes tipos de
redundancias.
• Uso de sistemas distribuidos con sistemas de réplica de información entre ellos.
• Uso de sistemas de recuperación a través de imágenes, virtualización, etc.
22
Tema 1. Ideas clave
 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:
• Clasificación de las aplicaciones y servicios en base a su criticidad.

• Tráfico de relleno.
• Técnicas de control de acceso a los sistemas basado en roles.
• El cifrado de la información y de las comunicaciones.
Integri-
Confiden dad
-cialidad
Disponi
-bilidad
Seguridad del software
Figura 10. 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
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.
23
Tema 1. Ideas clave
 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 (Mead y Woody, 2016) se indica

la necesidad de comprobar el comportamiento del software bajo una gran
variedad de condiciones, que al menos deben ser las siguientes:
• Batería de ataques lanzados contra el software.

• Entradas y salidas del software (señales, ficheros de datos, texto, etc.) que
puedan ser comprometidas.
• Interfaces del software a otras entidades que puedan ser comprometidas.
• 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 de este
y recuperarse reanudando su operación en o por encima de cierto nivel mínimo
predefinido de servicio aceptable en tiempo oportuno.
 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.
24
Tema 1. Ideas clave
Las propiedades que distinguen al software de confianza se ilustran en la figura
siguiente.
Integridad
Confidencialidad Disponibilidad
Resiliencia
SEGURIDAD Fiabilidad
DEL
SOFTWARE
Robustez Autenticación
Trazabilidad Tolerancia
Figura 11. Propiedades seguridad del software.
Existe una serie de factores que influyen en la probabilidad de que un software sea
consistente con las propiedades anteriormente mostradas (Mead y Woody, 2016)
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.
 Ambiente de operación. La naturaleza y configuración de las protecciones
proporcionadas por el entorno de ejecución o producción.
25
Tema 1. Ideas clave
 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 de este.
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 generalmente coinciden 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.
26
Tema 1. Ideas clave
 La seguridad por oscuridad es un error.
 Seguridad por defecto.
Defensa en profundidad
Uno de los principios más importantes de una estrategia defensiva efectiva es la

«Defensa en Profundidad», que se define en la guía CCN-STIC-400 (CCN, 2013) 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.
27
Tema 1. Ideas clave
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 Nombre Amenazas Controles

 Debilidades de diseño.  Cortafuegos de aplicaciones.
 Errores de programación.  Proxy reversos.
 Malware.  IDS Host, antivirus.
 Intrusiones.  S-SDLC.
 Análisis estático de código.

7 Aplicación
 Análisis de riesgo
arquitectónico.
 Bastionado.
 Validación de entradas.
 Poítica de contraseñas.
 Fuga de información.  Cifrado datos sensibles.
 Divulgación de contenido.  RBAC.

6 Presentación
 Sistemas de prevención de
perdidas de datos (DLP).
 Bypass de autenticación.  Fuertes controles de
 Identificadores débiles de autenticación.
sesión.  Control de acceso.
 Spoofing.  Sesión única y aleatoria.
5 Sesión  MITM.  Generación de ID con funciones
 Robo de credenciales. criptográficas.

 Divulgación de datos.  Cifrado de la transmisión y el
 Ataques de fuerza bruta. almacenamiento.

 Niveles de bloqueo de cuentas.
 Pérdida de paquetes.  Cortafuegos Stateful inspection.
 Figerprinting.  TLS.
4 Transporte
 Enumeración.  Monitorización de puertos.
 Apertura de puertos.  Control flujo.
28
Tema 1. Ideas clave
 Spoofing de las rutas y  Cortafuegos de filtrado de
direcciones IP. paquetes.
 Suplantación de identidad.  ACLs, 802.1X, NAC, Kerberos,
SSH.
 Bastionado equipos de red para
3 Red evitar ataques ARP, DHCP, etc.

 Monitoreo tráfico de red
(broadcast).
 IDS/IPS.
 IPSec.
 SIEM.
 Spoofing de dirección MAC.  Filtrado de MAC.
 Bypass de VLAN.  Firewalls.
2 Enlace  Errores Spanning Tree.  Segmentación VLAN.
 Ataques inalámbricos.  Wireless con autentificación y
cifrado fuertes.
 Accidentes naturales  Virtualización.
(inundación, pérdidas  Sistemas en alta disponibilidad.
energía eléctrica, etc.).  Sistemas de detección de

 Robo e intrusiones físicas. intrusiones físicas, sitemas de
 Keyloggers y otros control de acceso.
interceptores de datos.  CCTV.
 Redundancias en los sistemas de

1 Físico
alimentación eléctrica
(generadores externos).
 Sistemas de alimentación
ininterrumpida.
 Blindajes electromagnéticos.
 Sistemas de protección contra
incendios.
 Ataques a la  Politicas Seguridad de la
confidencialidad, ingenieria Información.
social.  Organización de la seguridad.

0 Normativa
 Procedimientos y estándares.
 Formación y concienciación en
seguridad.
Tabla 2. Principio de Defensa en Profundidad.
29
Tema 1. Ideas clave
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 esta 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.
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: https://es.wikipedia.org/wiki/Funci%C3%B3n_hash).
Simplicidad del diseño

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

especificaciones de este 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
30
Tema 1. Ideas clave
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.
Algunas de las opciones específicas de diseño del software que lo simplifican son
(Mead y Woody, 2016):
 Limitar el número de estados posibles en el software.

 Favorecer procesos deterministas sobre los no deterministas.
 Se debe evitar la funcionalidad innecesaria o los mecanismos de seguridad
innecesarios.
 Utilizar 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.
 Facilidad de uso. Por ejemplo, Single Sign On (SSO) es un buen ejemplo que ilustra
la simplificación de la autenticación de usuario.
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.
31
Tema 1. Ideas clave
Objetivo: reducir la complejidad del diseño para minimizar el número de
vulnerabilidades explotables por el atacante y debilidades en el sistema.
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.
La programación modular ayuda a implementar menos privilegios, además de hacer

que el código sea más legible, reutilizable y fácil de mantener. Cada unidad de código
(clase, método, etc.) tiene un único propósito y las operaciones que puede realizar
están limitadas solo a las que está diseñado.
32
Tema 1. Ideas clave
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.
 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.
33
Tema 1. Ideas clave
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.
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).
34
Tema 1. Ideas clave
TPM: es el nombre de una especificación publicada que detalla un
criptoprocesador seguro que puede almacenar claves de cifrado para
proteger información, así como el nombre general de las implementaciones
de dicha especificación, frecuentemente llamadas el «chip TPM» o
«dispositivo de seguridad TPM». (Fuente:
https://es.wikipedia.org/wiki/M%C3%B3dulo_de_plataforma_de_confianz
a).
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 de este, 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:
 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.
 Los datos utilizados por un script en un servidor Web deben ser colocados fuera
de árbol de documentos de este.
 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.
35
Tema 1. Ideas clave
 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.
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
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
36
Tema 1. Ideas clave
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, K. M., Winograd, T., 2008):
 Parámetros de línea de comandos.

 Variables de entorno.
 Localizadores de recursos universales (direcciones URL) e identificadores (URI).
37
Tema 1. Ideas clave
 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, K. M., Winograd, T.,
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.
38
Tema 1. Ideas clave
 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.
 Validar los datos de salida de la aplicación antes de mostrarlos al usuario o
redirigirlos a otro sistema.
Lista blanca (en inglés, whitelist) 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
[blacklisting] es la compilación que identifica a quienes serán denegados, no
reconocidos u obstaculizados.
(Fuente: https://es.wikipedia.org/wiki/Lista_blanca).
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 de estos. 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.
39
Tema 1. Ideas clave
 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.
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.
Su objetivo es mantener la resiliencia (confidencialidad, integridad y disponibilidad)

del software por defecto para que sea seguro.
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.
40
Tema 1. Ideas clave
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
(Goertzel, Karen & Winograd., 2008):
 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.
 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 esta. 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.
41
Tema 1. Ideas clave
Ell principio de diseño abierto (open design) establece que la implementación de
salvaguardas de seguridad debe ser independiente del diseño de modo que la
revisión del mismo no comprometa la protección que ofrecen las salvaguardas. Esto
es particularmente aplicable en la criptografía, donde los mecanismos de protección
están desacoplados de las claves que se utilizan para las operaciones criptográficas,
y los algoritmos utilizados para el cifrado y descifrado están abiertos y disponibles
para que cualquier persona pueda revisarlos.
No es aconsejable depender 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.

 Contraseñas en código fuente.
 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 agente malicioso información para
comprometer la seguridad de una aplicación.
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:
42
Tema 1. Ideas clave
Los sistemas deben diseñarse y configurarse de forma que garanticen la seguridad
por defecto:
 El sistema proporcionará la mínima funcionalidad requerida para que la

organización solo alcance sus objetivos, y no alcance ninguna otra funcionalidad
adicional.
 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.
 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.
 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.
Una cadena es tan fuerte como sus eslabones más débiles. Este principio de
seguridad establece que la resistencia de su software contra los arques dependerán
en gran medida de la protección de sus componentes más débiles, ya se trate del
código, un servicio o una interfaz. Una ruptura en el eslabón más débil resultará en
una brecha de seguridad.
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
43
Tema 1. Ideas clave
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.
 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.
44
Tema 1. Ideas clave
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
Introducir múltiples capas de seguridad para reducir la probabilidad de
Defensa en profundidad
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.
Separación de Asignación a las diferentes entidades de un rol que implique el acceso

privilegios a un subconjunto de funciones o tareas y a los datos necesarios.
Minimizar la probabilidad de que actores maliciosos obtengan

Separación de dominios fácilmente acceso a las ubicaciones de memoria u objetos de datos en
el sistema.
Separación código, Reducir la probabilidad de que un ciberatacante que haya accedido a
ejecutables y datos los datos del programa fácilmente pueda localizar y acceder a los
configuración y archivos ejecutables y datos de configuración del programa.
programa
Entorno de producción Evitar vulnerabilidades aplicando una serie de principios de validación
o ejecución inseguro de las entradas.
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 saltarse
Fallar de forma segura 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 un
Diseño de software
software defectuoso o fallido sigue siendo incapaz de protegerse de los
resistente
ataques.
45
Tema 1. Ideas clave
Concienciarse de que la seguridad por oscuridad es un mecanismo de
La seguridad por
defensa que puede proporcionar a un agente malicioso información
oscuridad: error
para comprometer la seguridad de una aplicación.
Seguridad por defecto Reducir la superficie de ataque de una aplicación o sistema.
Tabla 3. 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.
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.
46
Tema 1. Ideas clave
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.
47
Tema 1. Ideas clave
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 de este.
48
Tema 1. Ideas clave
6. 4. Pruebas 1. 2. 7.
5. Casos 2. Análisis 3. Pruebas
Requisitos basadas Revisión Análisis
penetración
Operaciones
de abuso de riesgos código riesgos Seguridad
seguridad en riesgo
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 12. McGraw’s Seven Touchpoints.
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 o 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 o del
sistema implican nuevas revisiones de código y as pruebas de seguridad.
Otras metodologías
 Microsoft Trustworthy Computing SDL: https://www.microsoft.com/en-

us/securityengineering/sdl/about
 CLASP: Comprehensive Lightweight Application Security Process:
http://www.owasp.org/index.php/Category:OWASP_CLASP_Project
49
Tema 1. Ideas clave
 Team Software Process (TSP): https://resources.sei.cmu.edu/library/asset-
view.cfm?assetid=5287
 Oracle Software Security Assurance:
http://www.oracle.com/us/support/assurance/index.html
 Appropriate and Effective Guidance in Information Security (AEGIS):
http://www.cs.ox.ac.uk/files/6345/thesis_final.pdf
 Rational Unified Process-Secure (RUPSec):
https://www.researchgate.net/publication/221017730_RUPSec_An_Extension_o
n_RUP_for_Developing_Secure_Systems_-_Requirements_Discipline
 Secure Software Development Model (SSDM):
https://prezi.com/p/k4aozp24zg7o/ssdm/
 Building Security in Maturity Model (BSIMM):
http://www.bsi-mm.com/
 Software Assurance Maturity Model (OPEN SAMM):
http://www.opensamm.org
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.
50
Tema 1. Ideas clave
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 de este.
 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.
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.
51
Tema 1. Ideas clave
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.
• ISO/IEC JTC1 SC7. Ingeniería de software y de sistemas.
• ISO 9126. Calidad del producto.
• ISO 14598. Evaluación de productos de software.
• ISO 12119. Requerimientos de calidad y prueba de COTS.
• ISO 15939. Proceso de medición de software.
• ISO 9000. Familia de normas son normas de calidad establecidas por la ISO.
 Estándares de seguridad.
• ISO / IEC 15026 Systems and software engineering — Systems and software
assurance.
• System Security Engineering Capability Maturity Model (SSE-CMM Norma
ISO/IEC 21827). Desarrollado por la «International Systems Security
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.
• Norma IEEE 1074-2006, Developing Software Project Life Cycle Processes.
Developing Software Project Life Cycle Processes Norma IEEE 1074-2006.
52
Tema 1. Ideas clave
• 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.
• 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.
• 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 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:
53
Tema 1. Ideas clave
 EAL 5: El sistema debe ser semiformal mente 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 semiformal mente
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 oficial y
formalmente testeado. Como el anterior, este establecimiento también
debe aplicarse al diseño de software.
1.8. Referencias bibliográficas
Adams, H., Hoole, A. M., Kamani, S., Lemos, R., Martin, L., Mello, J., Shah, N., y
Wisseman, S. (2108). 2018 Application Security Research Update HP Security
Research. Micro Focus Fortify Software Security Research Team.
Alert Logic. (2014). Defense throughout the vulnerability life cycle with alert logic
threat and log manager.
https://www.alertlogic.com/assets/whitepapers/Defense-Throughout-the-
Vulnerability-Life-Cycle-3.pdf
Allen, J. H.; Barnum. S.; Ellison, R. J.; McGraw, G.; Mead, N. R. (2008). Software
Security Engineering: A Guide for Project Managers. Addison Wesley
Professional.
Barnum, S., y Sethi, A. (2007). Attack Patterns as a Knowledge Resource for Building
Secure. Software Cigital, Inc.
54
Tema 1. Ideas clave
Barnum, S. (2008). Common Attack Pattern Enumeration and Classification (CAPEC)
Schema Description. Department of Homeland Security EEUU. Software
Cigital.
Bermejo, J. R., Díaz, G. Estudio de Técnicas Automáticas de Análisis de

Vulnerabilidades de Seguridad en Aplicaciones Web. UNED.
Caro, A. (2016). Modelos de desarrollo de software. Catedra Viewext [Diapositivas].

http://web.fdi.ucm.es/posgrado/conferencias/AndresCaroLindo-slides.pdf
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.
Graff, M. G., y Van Wyk, K. R. (2003). Secure Coding: Principles & Practices. O'Reilly.
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.
Goertzel, K. M. (2009). Introduction to Software Security. Edición en español.
Hewlett-Packard Development Company (2011). Top Cyber Security Risks Report.
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.
INCIBE. (2011). Cuaderno de notas del Observatorio ¿Qué son las vulnerabilidades del
software?
ISO/IEC 27034-1, Information technology - Security techniques - Application security.
55
Tema 1. Ideas clave
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., Baldwin, K. (2005). DoD Software Assurance Initiative.
McGraw, G. (2005). Software Security: Building Security In. Addison Wesley

Professional.
Mead, N., y Woody, C. (2016). Cyber Security Engineering: A Practical Approach for
Systems and Software Assurance. Addison-Wesley Professional.
Microsoft Corporation. (2006). Understanding the Security Risk Management

Discipline.
MITRE. Common Attack Pattern Enumeration and Classification — CAPEC™ A

Community Knowledge Resource for Building Secure Software.
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.
MITRE. (2019). CWE/SANS Top 25 Most Dangerous Software Errors.
National Aeronautics and Space Administration (NASA) (1992). Software Assurance

Standard, Standard No. NASA-STD-2201-93.
Ortiz, Z., y Galindo, F. (2006). Hacia una Taxonomía de Incidentes de Seguridad en

Internet. Ciencias de investigación Academia Desarrollo.
56
Tema 1. Ideas clave
OWASP TOP 10. (2017). Los diez riesgos más importantes en aplicaciones WEB.
Edición en español.
Paul, Mano (2014). Official (ISC)2 guide to the CSSLP. Second Edition. CRC PRESS, ISBN
978-1-4665-7133-4.
Rald, S. L. N., y Pedersen, J. M. (2012). An Updated Taxonomy for Characterizing

Hackers According to Their Threat Properties. Department of Electronic
Systems, Aalborg University, Denmark.
Rambla, J. L. G., Alonso, J, M. (2009). Esquema Nacional de Seguridad con Microsoft.

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. (ed.). (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.
SAFECode. (2010). Software Integrity Controls. Assurance-Based approach to

minimizing risks in the software supply chain.
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.
57
Tema 1. Ideas clave
A fondo
Lección magistral I. 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.
The application of a new secure software development life cycle (S-SDLC) with agile
methodologies
De Vicente, J., Bermejo, J., Bermejo, J. R., y Sicilia, J. A. (2019). The application of a new
secure software development life cycle (S-SDLC) with agile methodologies. Electronics,
8(11).
58
Tema 1. A fondo
Artículo que propone un nuevo modelo S-SDLC aplicable a metodologías de
desarrollo ágil de software. Además, contiene un estudio del estado del arte de
modelos S-SDLC que complementa lo estudiado en la asignatura.
A systemic approach for assessing software supply-chain risk
Dorofee, A., Woody, C., Alberts, C., Creel, R., y Ellison, R. J. (2011). A systemic approach
for assessing software supply-chain risk. 44th Hawaii International Conference on System
Sciences, Kauai. https://www.us-cert.gov/bsi/articles/best-practices/acquisition/a-
systemic-approach-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.
BSIMM7 software security framework
Javved. (18 de abril de 2017). BSIMM7 Software Security_Framework [Archivo de vídeo].

https://vimeo.com/213639550
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.
59
Tema 1. A fondo
Security design reviews
Jossie. (24 de junio de 2009). Security Design Reviews [Archivo de vídeo].

http://channel9.msdn.com/Blogs/Jossie/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.
60
Tema 1. A fondo
Test
1. Indica cuál de las siguientes respuestas no es una causa de aparición de
vulnerabilidades en el software:
A. No realización de pruebas de seguridad basadas en riesgo.
B. Cambios de requisitos del proyecto durante la etapa de especificación.
C. Mezcla de código proveniente de varios orígenes.
D. Tamaño excesivo y complejidad de las aplicaciones.
2. Indica la respuesta incorrecta. Respecto al ataque a las aplicaciones durante las

diferentes fases de su ciclo de vida:
A. Distribución e instalación. Ocurre cuando el instalador del software bastiona
la plataforma en la que lo instala.
B. Desarrollo. Un desarrollador puede alterar de forma intencionada o no el
software bajo desarrollo.
C. 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.
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.
61
Tema 1. Test
3. Señala la respuesta incorrecta. Las fuentes de las vulnerabilidades se deben a:
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.
4. Señala la respuesta incorrecta. Entre las técnicas y mecanismos 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ñala la respuesta incorrecta. Algunas de las opciones específicas de diseño del

software que lo simplifican son:
A. Favorecer procesos deterministas sobre los no deterministas.
B. Limitar el número de estados posibles en el software.
C. El uso de técnicas de interrupciones en lugar de sondeo.
D. Desacoplar los componentes y procesos para minimizar las
interdependencias entre ellos.
62
Tema 1. Test
6. Para conseguir que el desarrollo de una aplicación posea las propiedades y
principios de diseño del software seguro, se necesita que el personal de diseño y
desarrollo desarrolle:
A. Perspectiva administrador.
B. Perspectiva defensor.
C. Perspectiva usuario.
D. Perspectiva atacante.
7. ¿Cómo se define la 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 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. ¿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.
63
Tema 1. Test
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.
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 estadísticas.
B. Métricas base.
C. Métricas temporales.
D. Métricas ambientales.
64
Tema 1. Test

Tema 1. El Problema de La Seguridad en El Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 1. El Problema de La Seguridad en El Software

Cargado por

Copyright:

Formatos disponibles

Tema 1

1.5. Principios de diseño seguridad del software 26

El problema de la seguridad en el software

Vulnerabilidades y su Propiedades software Principios de diseño Metodologías

Esenciales: Defensa en Seguridad del software

1.1. Introducción y objetivos

Los objetivos del presente tema son los siguientes:

 Introducir al alumno en los principales conceptos que abarca la Seguridad del

1.2. Introducción al problema de la seguridad en

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

Figura 1. Incidentes de seguridad.

Sin embargo, estas aplicaciones presentan defectos, debilidades de diseño o

incluso estados en acciones de ciberguerra, utilizándolas como plataformas de ataque

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

 Tamaño excesivo y complejidad de las aplicaciones.

 Mezcla de equipos de desarrolladores, entre los que podemos tener, equipos

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

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

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

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

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

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

En este sentido, en base a la definición y los párrafos anteriores, se puede definir la

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

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

errores no intencionados producidos al codificar, oportunidades de insertar código

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

APT: tipo sofisticado de ciberataque organizado, de rápida progresión y largo

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

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

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

Technology), el coste que tiene la corrección de código o vulnerabilidades después de la

La empresa Microsoft, una de las primeras empresas en aplicar un modelo S-SDLC,

 75 % de las vulnerabilidades están relacionadas con las aplicaciones.

Figura 3. Datos empresa Microsoft. Fuente: Caro (2016).

Se define vulnerabilidad como un fallo de programación, configuración o diseño que

Sus fuentes se deben a:

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

Tipos de vulnerabilidades del software

Figura 4. Tipos de vulnerabilidades del software.

Exploits: es una instancia particular de un ataque a un sistema informático

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

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

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

 Utilización: Los agentes maliciosos desarrollan el exploit adecuado para poder

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

Figura 5. Ciclo de vida una vulnerabilidad.

En la siguiente figura se muestra una gráfica que representa el riesgo en función de

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

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

 Common Vulnerabilities and Exposures (CVE). Es un diccionario o catálogo

Cada identificador CVE incluye:

• Identificador con el siguiente formato:

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 7. Identificador CVE.

• Breve descripción de la vulnerabilidad.

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

Figura 8. Cálculo puntuación CVSS.

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