Tema1 Seguridad en El Software

El problema de la seguridad en el
software
[1.1] ¿Cómo estudiar este tema?
[1.2] Introducción al problema de la seguridad en el software
[1.3] Vulnerabilidades y su clasificación
[1.4] Propiedades software seguro
[1.5] Referencias
TEMA
El problema de la seguridad del software
Esquema
TEMA 1 – Esquema
Introducción al problema de Vulnerabilidades y su Propiedades software seguro
seguridad del software clasificación
Ciclo de vida de una vulnerabilidad Esenciales:

Confidencialidad
Integridad
Gestión de vulnerabilidades Disponibilidad
Clasificación de vulnerabilidades Complementarias:

Fiabilidad
Escáneres de vulnerabilidades
Autenticación
Trazabilidad
Robustez
Resiliencia
Tolerancia
© Universidad Internacional de La Rioja (UNIR)

Seguridad en el Software
Ideas clave
1.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que te presentamos a continuación.
Actualmente las tecnologías de seguridad red pueden ayudar a aliviar y mitigar los
ciberataques, pero no resuelven el problema de seguridad real ya que una vez que el
ciberatacante consigue vencer esas defensas, por ejemplo mediante ingeniería social, y
comprometer una máquina del interior, a través de la misma podrá atacar las demás
empezando por las más vulnerables. Se hace necesario por tanto, el disponer de software
seguro que funcione en un entorno agresivo y malicioso.
El objetivo del presente tema es introducir al alumno en los principales conceptos que
abarca la seguridad del software, en cuanto a los beneficios que produce, su
importancia en la seguridad global de un sistema, las vulnerabilidades como principal
fuente de inseguridad en el software y propiedades de un software seguro.
1.2. Introducción al problema de la seguridad en el software
Hoy en día, los ataques cibernéticos son cada vez más frecuentes, organizados y
costosos en el daño que infligen a las administraciones públicas, empresas privadas,
redes de transporte, redes de suministro y otras infraestructuras críticas desde la energía
a las finanzas, hasta el punto de poder llegar a ser una amenaza a la prosperidad, la
seguridad y la estabilidad de un país.
En la figura-1 se puede observar un gráfico cualitativo en el que se muestran diversos

incidentes ocurridos a lo largo de los últimos doce años en relación con su nivel de
complejidad. Como se puede observar la amenaza es creciente con los años y cada
vez su nivel de complejidad es mayor.
TEMA 1 – Ideas clave © Universidad Internacional de La Rioja (UNIR)

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

incorrecto es el problema. En un informe de Klocwork (2004) se indica que las
principales causas de la aparición de vulnerabilidades son las siguientes:
» Tamaño excesivo y complejidad de las aplicaciones.

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

» 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 la herramientas y un entorno de pruebas adecuados que simule
adecuadamente el real de ejecución.
» Cambios de requisitos del proyecto durante la etapa de codificación.
» Mezcla de equipos de desarrolladores, entre los que podemos tener, equipos
propios de desarrollos, asistencias técnicas, entidades subcontratadas, etc.
» Falta de conocimiento de prácticas de programación segura de los
desarrolladores en el uso de lenguajes de programación propensos a cometer errores
como C y C++ y utilización de herramientas de desarrollo inadecuadas.
» No control de la cadena de suministro del software, lo puede dar lugar a la
introducción de código malicioso en origen.
» No seguimiento, por los desarrolladores, de guías de normalizadas de estilo en
la codificación.
» Fechas límite de entrega de proyectos inamovibles.
» Cambio en la codificación en base al requerimiento de nuevas funcionalidades.
» Tolerancia a los defectos.
» No tener actualizadas las aplicaciones en producción con los parches
correspondientes, configuraciones erróneas, etc.
Las aplicaciones son amenazadas y atacadas, no solo en su fase de operación, sino que
también en todas las fases de su ciclo de vida (Goertzel. 2009):
» Desarrollo. Un desarrollador puede alterar de forma intencionada o no el software bajo

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

» Mantenimiento o sostenimiento. No publicación de parches de las

vulnerabilidades detectadas en el momento oportuno o incluso introducción de
código malicioso por el personal de mantenimiento en las versiones actualizadas del
código.
Según el informe «2011 Top Cyber Security Risks Report», las vulnerabilidades
detectadas en aplicaciones alcanzaron su punto máximo en el año 2006 iniciando a partir
de ese año un lento declive, como vemos en la figura 2.
Figura 2. Vulnerabilidades descubiertas por OSVDB (Vulnerability information from the Open Source
Vulnerability Database), 2000–2011.
Esta disminución de vulnerabilidades detectadas no significa que el software sea cada

vez más seguro, es una sensación de seguridad falsa, pues el número de
vulnerabilidades de alta severidad está creciendo a un ritmo más rápido que los otros
niveles de vulnerabilidad (CVSS 8 a 10, clasificación definida en la OSVDB ─
http://osvdb.org/ ─). En la figura 3 se pone de manifiesto cómo el porcentaje de
vulnerabilidades de alta severidad se ha incrementado en los últimos 10 años.
Common Vulnerability Scoring System (CVSS). Es un sistema que categoriza la severidad

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

Figura 3. Gravedad de las vulnerabilidades OSVDB en 10 años.
Las vulnerabilidades de alta severidad dan lugar a que un atacante pueda

explotarlas rápidamente y hacerse con el control total del sistema. Su explotación
requiere un conocimiento poco especializado de la aplicación al alcance, no solo de
organizaciones cibercriminales, si no de cualquiera con conocimientos de informática.
En el informe HP Security Research del año 2015, se incluye un gráfico que muestra la
vulnerabilidades descubiertas durante el año 2014, en él se indica que la aplicación más
explotada fue Internet Explorer debido a la vulnerabilidad CVE-2014-0322 del tipo use
affter free, es decir, uso de la memoria después de liberarla, del producto Adobe Flash
El exploit fue visto por primera vez en la operación SnowMan, dirigido a entidades del
gobierno de Estados Unidos y sus compañías de defensa.
Figura 4. Vulnerabilidades descubiertas en el año 2014.
Otros aspectos importantes que influyen en el número de vulnerabilidades conocidas de

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

probabilidades de ser atacadas y, por tanto, suelen tener mayor número de

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

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

organizaciones públicas o privadas dispongan de software fiable y resistente a los
ataques, es decir de confianza, con número de vulnerabilidades explotables que
sea el mínimo posible.
En respuesta a lo expuesto anteriormente nace la Seguridad del Software, en el

documento de referencia de SAFECode se define como: «La confianza que el software,
hardware y servicios están libres de vulnerabilidades intencionadas o no intencionadas
y que funcionan conforme a lo especificado y deseado» (SafeCode, 2011).
El Departamento de Defensa de los Estados Unidos (DoD) la define como «El nivel de
confianza de que el software funciona según lo previsto y está libre de vulnerabilidades,
ya sean intencionada o no, diseñada o insertada en el marco de su ciclo de vida de
desarrollo».
En este sentido, en base a la definición anterior y los párrafos anteriores, se puede definir
la seguridad del software como:
«El conjunto de principios de diseño y buenas prácticas a implantar en el SDLC,

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

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

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

a aliviar los ataques, pero no resuelven el problema de seguridad real, ya que una
vez que el ciberatacante consigue vencer esas defensas, por ingeniería social por ejemplo,
mediante ingeniería social, y comprometer una máquina del interior, a través de la
misma podrá atacar a otras de la red (pivoting) empezando por las más vulnerables. Este
es el caso de las Amenazas Avanzadas Persistentes (APT) uno de los ciberataques más
peligrosos y dañinos de hoy en día. Se hace necesario por tanto el disponer de
software seguro que funcione en un entorno agresivo y malicioso.
APT
Tipo sofisticado de ciberataque organizado, de rápida progresión y largo plazo,
diseñado específicamente para acceder y obtener información de los sistemas de la
organización objetivo.
Un aspecto importante de la seguridad del software es la confianza y garantía de

funcionamiento conforme a su especificación y diseño y de que es lo
suficientemente robusto para soportar las amenazas que puedan comprometer su
funcionamiento esperado en su entorno de operación.
Para conseguir lo anterior y minimizar al máximo los ataques en la capa de

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

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

aborde la seguridad desde las primeras etapas del SDLC, sería la reducción
de los costes de corrección de errores y vulnerabilidades, pues estos son más
altos conforme más tarde son detectados. Acorde a lo publicado por NIST (National
Institute of Standards and Technology), el coste que tiene la corrección de código o
vulnerabilidades después de la publicación de una versión, es hasta treinta veces
mayor que su detección y corrección en etapas tempranas del desarrollo.
Figura 5. Coste relativo de corrección de vulnerabilidades en función de la etapa de desarrollo. Fuente:

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

Figura 6. Efectos de la detección de defecto tardía. Fuente: Klocwork Inc. (2004).
1.3. Vulnerabilidades y su clasificación
Vulnerabilidad
Es 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 de 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
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 del mismo o una vez está en producción.
» Utilización: Los agentes maliciosos desarrollan el exploit adecuado para poder
lanzar ataques.
» Verificación inicial de la vulnerabilidad: una vez se recibe una notificación de error
esta será aceptada para su tratamiento comprobando su veracidad, o bien será
rechazada en caso de que no se pueda reproducirse y se compruebe no existe.
» Solución: los programadores del software buscan solución en entornos controlados.
» Difusión: los medios de comunicación dan publicidad al incidente.
» Medidas: si es posible las organizaciones afectadas toman medidas para mitigar las
posibles pérdidas.
» Corrección y nueva verificación: el proceso de corrección de la vulnerabilidad,
llevado a cabo por programadores, será verificado nuevamente de manera iterativa
hasta comprobar la resolución del error.
» Búsqueda. Los técnicos buscan vulnerabilidades similares (el ciclo vuelve a
comenzar).
» Actualización: Los sitios no actualizados vuelven a ser víctimas.
Descubrir Utilización Verificación Solución Difusión Medidas Corrección Búsqueda Actualizar
Figura 7. Ciclo de vida una vulnerabilidad.
En la siguiente figura se muestra un 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 8. Riesgo de una vulnerabilidad en función del tiempo. Fuente:

http://resources.computerworld.com/ccd/assets/61660/detail
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) (http://cve.mitre.org). Es un

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

MITRE
Organización sin ánimo de lucro, de carácter público que trabaja en las áreas de
ingeniería de sistemas, tecnologías de la información, concepto de operación y
modernización de empresas
Cada identificador CVE incluye:
o Identificador con el siguiente formato:
CVE-2012-4212
CVE, seguido del año en el que se asignó el código a la vulnerabilidad.
Número de cuatro cifras que identifica la vulnerabilidad en el año.
Figura 9. Identificador CVE
o Breve descripción de la vulnerabilidad.

o Referencias.
» Common Vulnerability Scoring System (CVSS) (http://nvd.nist.gov/cvss.cfm).

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 10. Cálculo puntuación CVSS.
El cálculo se realiza en base a tres tipos de métricas base, temporales y ambientales,

siendo las dos últimas opcionales. En cuanto a las métricas base se tienen dos
subconjuntos
o Explotabilidad: vectores de acceso, complejidad de acceso y autenticación.

o Impacto: confidencialidad, integridad y disponibilidad.
» Vulnerability information from the Open Source Vulnerability Database

(OSVDB) (http://osvdb.org). Proporciona una radiografía excelente de las
vulnerabilidades existentes, particularmente de aplicaciones. Sin embargo, debido a
la naturaleza de los informes vulnerabilidad, OSVDB solo puede contar con las
vulnerabilidades que se hagan públicas o se hayan insertado directamente en la base
de datos por particulares.
» Common Vulnerability Reporting Framework (CVRF). Es un formato XML
que permite compartir información crítica sobre vulnerabilidades en un esquema
abierto y legible por cualquier equipo. Hasta el momento no había ningún estándar
para informar de vulnerabilidades de los sistemas de la Tecnologías de la Información
y Comunicaciones (TIC), este viene a cubrir una necesidad manifestada por los
distintos actores de la industria, organismos de investigación y de la administración
en cuanto a un marco común, ya que hasta ahora, cada proveedor creaba sus informes
según su criterio. La disponibilidad de CVRF acelera el intercambio y procesamiento
de información entre distintas plataformas.
Originalmente deriva del proyecto Incident Object Description Exchange Format
(IODEF), su propósito es el reemplazar los múltiples formatos previamente en uso no
estándar de presentación de informes, lo que permite acelerar el intercambio de
información y proceso.

» National Vulnerability Database (NVD) (http://nvd.nist.gov/). Base de datos

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

o 202 Listas de comprobación de configuraciones de seguridad de productos.
8140 Consultas a OVAL.
Open Vulnerability and Assessment Languajes (OVAL)

Esfuerzo de comunidad internacional para normalizar los informes de seguridad de
vulnerabilidades y estado de seguridad de un sistema TIC. Incluye un lenguaje de
codificación de los detalles de sistema. http://oval.mitre.org/
» Common Weakness Enumeration (CWE) (http://cwe.mitre.org/). Estándar

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

seguridad de software en su arquitectura, diseño y codificación.
o Proporcionar un estándar de comparación de herramientas de auditoría seguridad
de software.
o Proporcionar una línea base para la identificación de vulnerabilidades, su
mitigación y los esfuerzos de prevención.
En la figura siguiente se puede ver un diagrama de contexto de las diferentes

organizaciones y estándares que usan CWE.

Figura 11. Diagrama de contexto de CWE. Fuente: http://cwe.mitre.org/
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:
Figura 12. 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 SANS Top 20 y otras solo a aplicaciones
web como son OWASP Top 10 y WASC Threat Clasification v2.0. A continuación
describimos algunas de las mencionadas.
Consulta aquí más información sobre las diferentes clasificaciones:

» MITRE Top 25: http://cwe.mitre.org/top25/
» SANS Top 20: http://www.sans.org/top20/
» OWASP Top 10: http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf
» WASC Threat Clasification 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.
o Todo tipo de aplicaciones Web y no Web.

o Dan lugar a vulnerabilidades graves en el software.
o Prevención, mitigación y principios de programación seguros.
En la siguiente tabla se pueden consultar las 25 principales vulnerabilidades:
RANK ID NOMBRE
Improper Neutralization of Special Elements used in an SQL
[1] CWE-89
Command ('SQL Injection')
Improper Neutralization of Special Elements used in an OS
[2] CWE-78
Command ('OS Command Injection')
Buffer Copy without Checking Size of Input ('Classic Buffer
[3] CWE-120
Overflow')
Improper Neutralization of Input During Web Page Generation
[4] CWE-79
('Cross-site Scripting')
[5] CWE-306 Missing Authentication for Critical Function
[6] CWE-862 Missing Authorization
[7] CWE-798 Use of Hard-coded Credentials
[8] CWE-311 Missing Encryption of Sensitive Data

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

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

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

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

source.
o No tiene en cuenta las aplicaciones propietarias.
» OWASP Top 10. Su objetivo es crear conciencia sobre la seguridad de las

aplicaciones web mediante la identificación de algunos de los riesgos más críticos que
enfrentan las organizaciones.
o Las 10 vulnerabilidades de seguridad más críticas en aplicaciones web.

o Lista ordenada por criticidad y predominio.
o Representa una lista concisa y enfocada sobre los diez riesgos más críticos sobre
seguridad en aplicaciones.
Consulta en la página 6 del siguiente documento los riesgos de seguridad en aplicaciones

web:
https://www.owasp.org/images/2/2d/OWASP_Top_10_-_2010_FINAL_(spanish).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.
o Unificación y organización de las amenazas de seguridad Web.

o Describe amenazas, debilidades y ataques.
Escáneres de vulnerabilidades
Este tipo de herramientas analizan los sistemas en busca de vulnerabilidades conocidas.

Disponen de información sobre vulnerabilidades existentes en las versiones de los

sistemas operativos y aplicaciones almacenadas y actualizadas en una base de datos, que

utiliza para la detección de las mismas.
La herramienta más utilizada es Nessus, inicialmente de código abierto y versión

gratuita, y actualmente en dos versiones, la 4.x en la que el nuevo código es cerrado, y la
versión 2.x (www.nessus.org) que continúa siendo software libre. A raíz de este cambio
se crearon tres proyectos diferentes a partir de la versión libre, Sussen, Porz-Wahn y
OpenVas (inicialmente GNessUs). Actualmente el proyecto Porz-Wahn se unió con
OpenVas (http://www.openvas.org/), la cual continúa actualizando versiones para las
distintas distribuciones de GNU/Linux. Otras herramientas de extendido uso son
Nexpose de Rapid 7 (www.rapid7.com/products/nexpose), ISS Real Secure, Nmap y
Retina.
1.4. Propiedades software seguro
Básicamente se tienen dos conjuntos de propiedades que definen a un software seguro

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

que no es, son:
» Integridad. Capacidad que garantiza que el código, activos manejados,

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

o Uso de técnicas de cifrado para asegurar que los componentes y los datos nos son
alterados o corrompidos.
o Estricta gestión de sesiones.

o Uso de sistemas de monitorización de la integridad

o Uso de firma digital.
o Trasmisión cifrada de los datos.
» Disponibilidad. Capacidad que garantiza que el software es operativo y

accesible por personas, entidades o procesos autorizados de forma que se pueda
acceder a la información y a los recursos o servicios que la manejan, conforme a las
especificaciones de los mismos. Entre las técnicas y mecanismos que se tienen para
salvaguardar la disponibilidad, tenemos por ejemplo:
o Análisis de qué servicios e información es crítica y el modo de tenerlos disponibles.

o Uso de arquitecturas de alta disponibilidad, con diferentes tipos de redundancias.
o Uso de sistemas distribuidos con sistemas de réplica de información entre ellos.
o Uso de sistemas de recuperación a través de imágenes, virtualización, etc.
» Confidencialidad. Capacidad de preservar que cualquiera de sus características,

activos manejados están ocultos a usuarios no autorizados, de forma que se
garantice que solo las personas, entidades o procesos autorizados pueden acceder a la
información.
Entre las técnicas y mecanismos que se tienen para salvaguardar la

confidencialidad, tenemos por ejemplo:
o Clasificación de las aplicaciones y servicios en base a su criticidad.

o Tráfico de relleno.
o Técnicas de control de acceso a los sistemas basado en roles.
o El cifrado de la información y de las comunicaciones.
Figura 13. 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:
» Fiabilidad. Capacidad del software de funcionar de la forma esperada en

todas las situaciones a la que estará expuesto en su entorno de
funcionamiento, es decir que la posibilidad de que un agente malicioso pueda
alterar la ejecución o resultado de una manera favorable para el atacante está
significativamente reducida o eliminada.
En este sentido en el documento de referencia (Allen, J. H.; Barnum. S.; Ellison, R. J.;
McGraw, G.; Mead, N. R., 2008), se indica la necesidad de comprobar el
comportamiento del software bajo una gran variedad de condiciones entre las que al
menos deben ser las siguientes:
o Batería de ataques lanzados contra el software.

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

persona, entidad o proceso es quien dice ser o bien que garantiza la fuente
de la que proceden los datos.
» Trazabilidad. Capacidad que garantiza la posibilidad de imputar las acciones
relacionadas en un software a la persona, entidad o proceso que la ha
originado.
» Robustez. Capacidad de resistencia a los ataques realizados por los agentes
maliciosos (malware, hackers, etc.).

Resiliencia. Capacidad del software de aislar, contener y limitar los daños

ocasionados por fallos causados por la explotación de una vulnerabilidad del mismo
y recuperarse reanudando su operación en o por encima de cierto nivel
mínimo predefinido de servicio aceptable en tiempo oportuno.
» Tolerancia. Capacidad del software para «tolerar» los errores y fallos que resultan
de ataques con éxito y seguir funcionando como si los ataques no se hubieran
producido.
Las propiedades que distinguen al software de confianza se ilustran en la figura

siguiente.
Integridad
Confidencialidad Disponibilidad
Resiliencia
SEGURIDAD Fiabilidad
DEL
SOFTWARE
Robustez Autenticación
Trazabilidad Tolerancia
Figura 14. Propiedades seguridad del software.
Existen una serie de factores que influyen en la probabilidad de que un software sea
consistente con las propiedades anteriormente mostradas (Goertzel, K. M., Winograd,
T., 2008), estos incluyen:
» Principios de diseño y buenas prácticas de desarrollo. Las prácticas

utilizadas para desarrollar el software y los principios de diseño que lo rigen. En el
apartado posterior se desarrolla ampliamente este punto.
» Herramientas de desarrollo. El lenguaje de programación, bibliotecas y
herramientas de desarrollo utilizadas para diseñar, implementar y probar el software,
y la forma en que fueron utilizados por los desarrolladores.

» Componentes adquiridos. Tanto los componentes de software comercial como

libre en cuanto como fueron evaluados, seleccionados, e integrados.
» Configuraciones desplegadas. Cómo el software se configuró durante la
instalación en su entorno de producción.
» Ambiente de operación. La naturaleza y configuración de las protecciones
proporcionadas por el entorno de ejecución o producción.
» Conocimiento Profesional. El nivel de concienciación y conocimiento de
seguridad que los analistas, diseñadores, desarrolladores, probadores y
mantenedores del software, o su falta del mismo.
1.5. Referencias
Sotirov, A. I. (2002). Automatic vulnerability detection using static source code

analysys.
Graff, M. G., Van Wyk, K. R. (2003). Secure Coding: Principles & Practices. O'Reilly.
Hewlett-Packard Development Company (2011). Top Cyber Security Risks Report.
INCIBE. (2011). Cuaderno de notas del Observatorio ¿Qué son las vulnerabilidades del
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. (2011). CWE/SANS Top 25 Most Dangerous Software Errors.

OWASP TOP 10. (2013). Los diez riesgos más importantes en aplicaciones WEB.
Edición en español.
Goertzel, K. M. (2009). Introduction to Software Security. Edición en español.

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

minimizing risks in the software supply chain.
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.
Goertzel, K. M., 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.
Howard, M., LeBlanc, D. (2003). Writing Secure Code. Microsoft Press.
Howard, M., Lipner, S. (2006). The Security Development Lifecycle: SDL: A Process for
Developing Demonstrably Secure Software. Microsoft Press.
McGraw, G. (2005). Software Security: Building Security In. Addison Wesley

Professional.
Redwine Jr., S. T. (Editor). (2006). Software Assurance: A Guide to the Common Body
of Knowledge to Produce, Acquire, and Sustain Secure Software Version 1.1. US
Department of Homeland Security.
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.
Komaroff, M., Baldwin, K. (2005). DoD Software Assurance Initiative.
National Aeronautics and Space Administration (NASA) (1992). Software Assurance

Standard, Standard No. NASA-STD-2201-93.
Bermejo, J. R., Díaz, G. Estudio de Técnicas Automáticas de Análisis de

Vulnerabilidades de Seguridad en Aplicaciones Web. UNED.

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.
Rambla, J. L. G., Alonso, J, M. (2009). Esquema Nacional de Seguridad con Microsoft.

Microsoft Ibérica S.R.L.
MITRE. Common Attack Pattern Enumeration and Classification — CAPEC™ A

Community Knowledge Resource for Building Secure Software.
Barnum, S., Sethi, A. (2007). Attack Patterns as a Knowledge Resource for Building
Secure. Software Cigital, Inc.
Barnum, S. (2008). Common Attack Pattern Enumeration and Classification (CAPEC)

Schema Description. Department of Homeland Security EEUU. Software Cigital.
Ortiz, Z., Galindo, F. (2006). Hacia una Taxonomía de Incidentes de Seguridad en

Internet. Ciencias de investigación Academia Desarrollo.
Rald, S. L. N., Pedersen, J. M. (2012). An Updated Taxonomy for Characterizing

Hackers According to Their Threat Properties. Department of Electronic Systems,
Aalborg University, Denmark.
Microsoft Corporation. (2006). Understanding the Security Risk Management

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

Report 2015. Recuperado de http://www8.hp.com/us/en/software-solutions/cyber-
risk-report-security-vulnerability/
ALERT LOGIG. (2014). Defense throughout the vulnerability life cycle with alert logic
threat and log manager. Recuperado de
http://resources.computerworld.com/ccd/assets/61660/detail
Software Assurance Pocket Guide Series (2012). Software Assurance in Acquisition and
Contract Language. Acquisition & Outsourcing, Volume I.
ISO/IEC 27034-1, Information technology - Security techniques - Application security.

Lo + recomendado
Lecciones magistrales
Los pilares de la seguridad del software
En esta lección magistral se profundiza en el estudio de la seguridad del software

presentando los tres pilares de la seguridad del software: gestión del riesgo, buenas
prácticas de seguridad y gestión del conocimiento.
La lección magistral está disponible en el aula virtual.
No dejes de leer…
Protection of Information in Computer Systems
El documento del año 1975 que presenta conceptos de seguridad del software que siguen
siendo muy relevantes en la actualidad.
Accede al artículo desde el aula virtual o a través de la siguiente dirección web:

http://web.mit.edu/Saltzer/www/publications/protection/
TEMA 1 – Lo + recomendado © Universidad Internacional de La Rioja (UNIR)

2011 CWE/SANS Top 25 Most Dangerous Software Errors
El documento presenta una lista de los 25 errores en el software más dañinos, extendidos
y críticos que representan vulnerabilidades fácilmente detectables y explotables que
permiten al atacante tomar control de la máquina.

http://cwe.mitre.org/top25/
No dejes de ver…
BSIMM: The Building Security in Maturity Model
En este vídeo se da una visión general de una

importante iniciativa de la seguridad del
software llamada BSIMM y su forma de uso
como una herramienta de medida para su
organización, proveedores y su combinación
con otros métodos de medición de seguridad.
Accede al vídeo desde el aula virtual o a través de la siguiente dirección web:

https://vimeo.com/99350519
TEMA 1 – Lo + recomendado © Universidad Internacional de La Rioja (UNIR)

+ Información
A fondo
Hewlett Packard Development Company, L.P. HP Security Research. Cyber

Risk Report 2015
Informe de año 2015 que proporciona una visión amplia del panorama de las
vulnerabilidades del software, así como una profunda investigación y análisis de los
ataques de y tendencias.

http://www8.hp.com/us/en/software-solutions/cyber-risk-report-security-
vulnerability/
Improving Software Security During Development
En este artículo se exploran las bases para la creación de software y sistemas seguros
durante su etapa de desarrollo. La seguridad del software se relaciona directamente con
los procesos de calidad.

http://www.sans.org/reading_room/whitepapers/securecode/improving-software-
security-development_384
Cuaderno de notas del Observatorio ¿Qué son las vulnerabilidades del

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

http://www.egov.ufsc.br/portal/sites/default/files/vulnerabilidades_notasobs.pdf
TEMA 1 – + Información © Universidad Internacional de La Rioja (UNIR)

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

http://makingsecuritymeasurable.mitre.org/docs/cve-intro-handout.pdf
CWE Introductory Brochure
Artículo introductorio al formato CWE de gestión de debilidades y vulnerabilidades del

software.

http://makingsecuritymeasurable.mitre.org/docs/cwe-intro-handout.pdf
Practical Measurement Framework for Software Assurance and

Information Security
Documento de métricas de medidas de seguridad del software e información que

proporciona un método para medir la eficacia de las medidas de seguridad a nivel
organizacional programa o proyecto.

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

Enlaces relacionados
Build Security In
El U.S. Department of Homeland Security, DHS, desarrolla un portal de seguridad de

software, junto con el Instituto de Ingeniería de Software de Carnegie Mellon y Cigital.
Este portal ayuda a proporcionar un conjunto común, accesible, bien organizado de
información de prácticas de seguridad de software. El esfuerzo del portal expresamente
apunta al problema, de ampliar y extender el conocimiento de seguridad de software.
Accede a la página desde el aula virtual o a través de la siguiente dirección web:

https://buildsecurityin.us-cert.gov/bsi/home.html
Microsoft Security Developer Center
Sitio web que describe las buenas prácticas de desarrollo seguro de modelo de S-SDLC
de Microsoft y sus herramientas asociadas.

https://www.microsoft.com/en-us/sdl/default.aspx

Secure Software Inc. Resources.
Sitio web de la empresa HP con recursos y artículos sobre seguridad del software.

http://www8.hp.com/us/en/software-solutions/software.html?compURI=1214365
Micro Focus
Sitio web de la empresa Micro Focus con recursos y artículos sobre seguridad del
software.

http://www8.hp.com/us/en/software-solutions/software.html?compURI=1214365
Synopsys
Sitio web de la empresa SYNOPSYS creada partir de la empresa CIGITAL Inc. con
recursos, libros, vídeos y artículos sobre seguridad del software.

https://resources.synopsys.com/

SysAdmin, Audit, Networking, and Security (SANS) Reading Room
Sitio web del Instituto SANS con gran Caridad de artículos, ver las secciones:
Application/Database Sec, Best Practices, Auditing & Assessment, Malicious Code,
Scripting Tips, Securing Code y Threats/Vulnerabilities.

http://www.sans.org/reading_room/
Bibliografía
Allen, J. H.; Barnum. S.; Ellison, R. J.; McGraw, G.; Mead, N. R. (2008). Software
Security Engineering: A Guide for Project Managers. Addison Wesley Professional.
Krassowski, A. y Meunier, P. (2008). Secure Software Engineering: Designing, Writing,

and Maintaining More Secure Code. Addison-Wesley.
Nancy R. Mead, Carol Woody (2016). Cyber Security Engineering: A Practical Approach
for Systems and Software Assurance. SEI Series in Software Engineering. Addison-
Wesley Professional.
Mano Paul (2014). The official (ISC)2® guide to the CSSLP. CRC Press.
McGraw, G. (2003). Building Secure Software: A Difficult But Critical Step in Protecting
Your Business. Cigital, Inc.
McGraw, G. (2005). Software Security: Building Security In. Addison Wesley

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

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

vulnerabilidades en el software.
A. No seguimiento, por los desarrolladores, de guías de normalizadas de estilo en
la codificación.
B. Desarrollo de las aplicaciones por una asistencia técnica o entidades
subcontratadas.
C. No realización de pruebas seguridad basadas en riesgo.
D. No control de la cadena de suministro del software, lo puede dar lugar a la
introducción de código malicioso en origen.
2. Indica las respuestas no correctas respecto del ataque a las aplicaciones durante las
diferentes fases de su ciclo de vida.
A. Desarrollo. Un desarrollador puede alterar de forma intencionada o no el
software bajo desarrollo.
B. Distribución e instalación. Ocurre cuando el instalador del software bastiona la
plataforma en la que lo instala.
C. Operación. Cualquier software que se ejecuta en una plataforma conectada a la
red tiene sus vulnerabilidades expuestas durante su funcionamiento, excepto si
está protegido por dispositivos de protección de la infraestructura de red.
D. Mantenimiento o sostenimiento. No publicación de parches de las
vulnerabilidades detectadas en el momento oportuno o incluso introducción de
código malicioso por el personal de mantenimiento en las versiones actualizadas
del código
3. Las fuentes de las vulnerabilidades se deben a (indica la incorrecta):

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

4. Señala la incorrecta. Entre las técnicas y mecanismos que se tienen para salvaguardar
la integridad, tenemos por ejemplo:
A. Identificación del modo de trasmisión y procesado de los datos por la aplicación.
B. Uso de arquitecturas de alta disponibilidad, con diferentes tipos de
redundancias.
C. Uso de firma digital.
D. Estricta gestión de sesiones.
5. Señala la respuesta correcta. ¿Cuál de los siguientes mecanismos de seguridad

protegen de forma más adecuada a las aplicaciones?
A. Cortafuegos de nueva generación.
B. Inclusión de prácticas de seguridad en el SDLC.
C. Sistemas de gestión y correlación de eventos (SIEM).
D. Sistemas de detección de intrusos.
6. Señala la respuesta incorrecta. Se puede definir la seguridad del software como:

A. La confianza que el software, hardware y servicios están libres de intencionadas
o no intencionadas vulnerabilidades y que funcionan conforme a lo especificado y
deseado
B. El nivel de confianza de que el software funciona según lo previsto y está libre
de vulnerabilidades, ya sea intencionada o no diseñada o insertada en el marco del
software.
C. 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
D. Ninguna de las anteriores.
7. Señala la respuesta correcta. Un fallo de desbordamientos de búfer es:

A. Fallos de implementación.
B. Fallos de diseño.
C. Fallos de implantación.
D. Fallos de configuración

8. Señala la respuesta correcta. ¿Cuál es el momento de más riesgo en el ciclo de vida de

una vulnerabilidad?
A. Cuando se aplica el parche.
B. Cuando se difunde la existencia del exploit.
C. Actualización: Los sitios no actualizados vuelven a ser víctimas.
D. Verificación inicial de la vulnerabilidad.
9. Señala la respuesta correcta. ¿Cuál es la siguiente propiedad de seguridad: capacidad

que garantiza la posibilidad de imputar las acciones relacionadas en un software a la
persona, entidad o proceso que la ha originado?
A. Robustez.
B. Resiliencia.
C. Autenticación.
D. Trazabilidad.
10. Señala las respuestas correctas. ¿En qué fases modelo de ciclo de vida, según
McGraw, es aplicable el catálogo conocimiento de seguridad exploit?
A. Codificación.
B. Pruebas y resultados.
C. Realimentación de producción.
D. Plan de pruebas.

Tema1 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

Tema1 Seguridad en El Software

Cargado por

Copyright:

Formatos disponibles

El problema de la seguridad en el

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

[1.3] Vulnerabilidades y su clasificación

[1.4] Propiedades software seguro

Ciclo de vida de una vulnerabilidad Esenciales:

Clasificación de vulnerabilidades Complementarias:

© Universidad Internacional de La Rioja (UNIR)

1.1. ¿Cómo estudiar este tema?

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

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

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

Figura 1. Incidentes de seguridad.

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

» Tamaño excesivo y complejidad de las aplicaciones.

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

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

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

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

» Mantenimiento o sostenimiento. No publicación de parches de las

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

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

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

Figura 3. Gravedad de las vulnerabilidades OSVDB en 10 años.

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

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

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

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

probabilidades de ser atacadas y, por tanto, suelen tener mayor número 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

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

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

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

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

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

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

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

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

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

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

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

1.3. Vulnerabilidades y su clasificación

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

Sus fuentes se deben a:

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

Tipos de vulnerabilidades del software

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

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

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

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

» Impacto: Define la gravedad de la vulnerabilidad, indica lo que puede conseguir un

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

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

Figura 7. Ciclo de vida una vulnerabilidad.

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

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

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

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

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

» Common Vulnerabilities and Exposures (CVE) (http://cve.mitre.org). Es un