Apuntesprofesort 1

El problema de la seguridad
en el software

Tema 1
Tema 1: El problema de la seguridad en el softwar e
Universidad Internacional de La Rioja (UNIR)
Actualmente las tecnologas de seguridad red pueden ayudar a aliviar los
ciberataques, pero no resuelven el problema de seguridad real ya que una vez que el
ciberatacante consigue vencer esas defensas, por ingeniera social por ejemplo, y
comprometer una mquina del interior, a travs de la misma podr atacar las dems
empezando por las ms vulnerables. Se hace necesario por tanto el disponer de
softwar e seguro que funcione en un entorno agresivo y malicioso. El objetivo del
presente tema es introducir al alumno en los principales conceptos que abarca la
seguridad del software, en cuanto a los beneficios que produce, su importancia en la
seguridad global de un sistema, las propiedades de un software seguro, los ataques a
los que se tiene que enfrentar y las metodologas aplicables a los procesos de desarrollo
seguro de software.

Javier Bermejo Higuera

1.1. Introduccin al problema de la seguridad en el software

Hoy en da, los ataques cibernticos son cada vez ms frecuentes, organizados y
costosos en el dao que infligen a las administraciones pblicas, empresas privadas,
redes de transporte, redes de suministro y otras infraestructuras crticas desde la
energa a las finanzas, hasta el punto de poder llegar a ser una amenaza a la
prosperidad, la seguridad y la estabilidad de un pas.

Figura 1. Incidentes de seguridad

En la figura-1 se puede observar un grfico cualitativo en el que se muestran diversos
incidentes ocurridos a lo largo de los ltimos doce aos en relacin con su nivel de
complejidad. Como se puede observar la amenaza es creciente con los aos y cada
vez su nivel de complejidad es mayor.

La sociedad est cada vez ms vinculada al ciberespacio, un elemento importante del
mismo lo constituyen el software o las aplicaciones que proporcionan los servicios,
utilidades y funcionalidades. Sin embargo estas aplicaciones presentan defectos,
vulnerabilidades o configuraciones inseguras que pueden ser explotadas por
atacantes de diversa ndole desde aficionados hasta organizaciones de cibercrimen o
incluso estados en acciones de ciberguerra, utilizndolas como plataformas de ataque
comprometiendo los sistemas y redes de la organizacin.

Nadie quiere software defectuoso, especialmente los desarrolladores cuyo cdigo
incorrecto es el problema, en un informe de Klocwork [10] se indica que las principales
causas de la aparicin de vulnerabilidades son las siguientes:
Tamao excesivo y complejidad de las aplicaciones.
Mezcla de cdigo proveniente de varios orgenes como compras a otra
compaa, reutilizacin de otros existentes, etc., lo que puede producir
comportamientos e interacciones no esperados de los componentes del software.
Integracin de los componentes del softwar e defectuosa, estableciendo
relaciones de confianza inadecuadas entre ellos, etc.
Debilidades y fallos en la especificacin de requisitos y diseo no basados
en valoraciones de riesgo y amenazas.
Uso entornos de ejecucin con componentes que contienen vulnerabilidades
o cdigo malicioso embebido, como pueden ser capas de middleware, sistema
operativo u otros componentes COTS.
No realizacin de pruebas seguridad basadas en riesgo.
Falta de la herramientas y un entorno de pruebas adecuados que simule
adecuadamente el real de ejecucin.
Cambios de requisitos del proyecto durante la etapa de codificacin.
Mezcla de equipos de desarrolladores, entre los que podemos tener, equipos
propios de desarrollos, asistencias tcnicas, entidades subcontratadas, etc.
Falta de conocimiento de prcticas de programacin segura de los
desarrolladores en el uso de lenguajes de programacin propensos a cometer errores
como C y C++ y utilizacin de herramientas de desarrollo inadecuadas.
No control de la cadena de suministro del software, lo puede dar lugar a la
introduccin de cdigo malicioso en origen.
No seguimiento, por los desarrolladores, de guas de normalizadas de estilo
en la codificacin.
Fechas lmite de entrega de proyectos inamovibles.
Cambio en la codificacin en base al requerimiento de nuevas funcionalidades.
Tolerancia a los defectos.
No tener actualizadas las aplicaciones en produccin con los parches
correspondientes, configuraciones errneas, etc.

Las aplicaciones son amenazadas y atacadas, no solo en su fase de operacin, sino que
tambin en todas las fases de su ciclo de vida [9]:
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
operacin.

Distribucin e instalacin. 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.

Operacin. Cualquier software que se ejecuta en una plataforma conectada a la red
tiene sus vulnerabilidades expuestas durante su funcionamiento. El nivel de
exposicin variar dependiendo de si la red es privada o pblica, conectada o no a
Internet, y si el entorno de ejecucin del software ha sido configurado para
minimizar sus vulnerabilidades.

Mantenimiento o sostenimiento. No publicacin de parches de las
vulnerabilidades detectadas en el momento oportuno o incluso introduccin de
cdigo malicioso por el personal de mantenimiento en las versiones actualizadas del
cdigo.

Segn el informe 2011 Top Cyber Security Risks Report [3], las vulnerabilidades
detectadas en aplicaciones alcanzaron su punto mximo en el ao 2006 iniciando a
partir de ese ao un lento declive, ver figura 2.

Esta disminucin de vulnerabilidades detectadas no significa que el software sea cada
vez ms seguro, es una sensacin de seguridad falsa, pues el nmero de
vulnerabilidades de alta severidad est creciendo a un ritmo ms rpido que los otros
niveles de vulnerabilidad (CVSS
1
8 a 10, clasificacin definida en la OSVDB)
2
. En la
figura 3 se pone de manifiesto cmo el porcentaje de vulnerabilidades de alta severidad
se ha incrementado en los ltimos 10 aos.

Figura 2. Vulnerabilidades descubiertas por OSVDB
3
, 20002011

Figura 3. Gravedad de las vulnerabilidades OSVDB en 10 aos

Las vulnerabilidades de alta severidad dan lugar a que un atacante pueda
explotarlas rpidamente y hacerse con el control total del sistema. Su explotacin
requiere un conocimiento poco especializado de la aplicacin al alcance, no solo de
organizaciones cibercriminales, si no de cualquiera con conocimientos de informtica.
En el mismo informe anteriormente referido se incluye un grfico del nmero de
vulnerabilidades por aplicaciones (figura 4) desde el ao 2005 hasta el 2011,
QuickTime es de manera significativa la ms alta, al igual que los navegadores Web
Internet Explorer y Firefox.

1
Common Vulnerability Scoring System (CVSS). Es un sistema que categoriza la severidad de
una vulnerabilidad, de manera estricta a travs de frmulas, proporcionando un estndar para
comunicar las caractersticas y el impacto de una vulnerabilidad en el software.
2
http://osvdb.org/search/advsearch
3
Vulnerability information from the Open Source Vulnerability Database (OSVDB)

Figura 4. Nmero de vulnerabilidades por aplicaciones desde 2005 hasta 2011

Otros aspectos importantes que influyen en el nmero de vulnerabilidades conocidas
de una aplicacin son: su complejidad, su extensin en lneas de cdigo y el nivel
exposicin a los ataques, en este sentido las aplicaciones web en Internet, son las que
tienen ms probabilidades de ser atacadas y por tanto suelen tener mayor nmero de
vulnerabilidades conocidas.

Adems errneamente, a pesar de los datos convincentes de lo contrario, se sigue
confiando que la implantacin de tecnologas y dispositivos de seguridad de
red como cortafuegos, sistemas de gestin y correlacin de eventos (SIEM
4
), sistemas
de deteccin de intrusos, sistemas de gestin de acceso y cifrado del trfico, etc., son
medidas suficientes para proteger los sistemas de la organizacin. Los atacantes
buscan el descubrimiento de fallos en el software relacionados con la seguridad del
sistema, que den lugar a una vulnerabilidad con un impacto y riesgo asociado para la
entidad propietaria.

En base a lo expuesto anteriormente, se considera la necesidad que las diferentes
organizaciones pblicas o privadas dispongan de software fiable y resistente a los
ataques, es decir de confianza, con nmero de vulnerabilidades explotables
que sea el mnimo posible.

En respuesta a lo expuesto anteriormente nace la Seguridad del Softwar e, en el
documento de referencia [13] de SAFECode se define como: La confianza que el
software, hardware y servicios estn libres de intencionadas o no intencionadas
vulnerabilidades y que funcionan conforme a lo especificado y deseado.

4
Sistema de Centralizacin y Monitorizacin de la Informacin de Eventos y datos
infraestructura como, logs, etc.
El Departamento de Defensa de los Estados Unidos (DoD) [19] la define como El nivel
de confianza de que el software funciona segn lo previsto y est libre de
vulnerabilidades, ya sea intencionada o no diseada o insertada en el marco de la
software.

En este sentido, en base a la definicin anterior y los prrafos anteriores, se puede
definir la seguridad del softwar e como:

El conjunto de principios de diseo y buenas prcticas a implantar en el SDLC,
para detectar, prevenir y corregir los defectos de seguridad en el desarrollo y
adquisicin de aplicaciones, de forma que se obtenga softwar e de
confianza y robusto frente ataques maliciosos, que realice solo las
funciones para las que fue diseado, que est libre de vulnerabilidades,
ya sean intencionalmente diseadas o accidentalmente insertadas durante su
ciclo de vida y se asegure su integridad, disponibilidad y confidencialidad.

Hasta principios de la dcada anterior, la mayora de las aplicaciones se desarrollaban
sin tener en cuenta requisitos y pruebas de seguridad especficos, los desarrolladores de
software no eran conscientes de las vulnerabilidades que se pueden crear al programar
y descuidaban los aspectos de seguridad, dando primaca 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 anteriormente referidos,
oportunidades de insertar cdigo malicioso en el softwar e en origen.

Como se ha comentado anteriormente la tecnologas 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 ingeniera social por
ejemplo, y comprometer una mquina del interior a travs de la misma podr atacar a
otras de la red (pivoting) empezando por las ms vulnerables. Este es el caso de las
Amenazas Avanzadas Persistentes (APT
5
) uno de los ciberataques ms peligrosos y
dainos de hoy en da. Se hace necesario por tanto el disponer de softwar e seguro
que funcione en un entorno agresivo y malicioso.

5
Tipo sofisticado de ciberataque organizado, de rpida progresin y largo plazo, diseado
especficamente para acceder y obtener informacin de los sistemas de la organizacin objetivo.

Un aspecto importante de la seguridad del software es la confianza y garanta de
funcionamiento conforme a su especificacin y diseo y de que es lo
suficientemente robusto para soportar las amenazas que puedan comprometer su
funcionamiento esperado en su entorno de operacin.

Para conseguir lo anterior y minimizar al mximo los ataques en la capa de
aplicacin y por tanto en nmero de vulnerabilidades explotables, es
necesario el incluir la seguridad desde principio en el ciclo de vida de
desarrollo del softwar e (SDLC), incluyendo requisitos, casos de abuso, anlisis de
riesgo, anlisis de cdigo, pruebas de penetracin dinmicas, etc., en este sentido es
importante el aprovechamiento de las buenas prcticas de ingeniera de
softwar e ya existentes.

Un beneficio importante que se obtendra de incluir un proceso sistemtico que
aborde la seguridad desde las primeras etapas del SDLC, sera la reduccin
de los costes de correccin de errores y vulnerabilidades, pues estos son ms
altos conforme ms tarde son detectados. Acorde a lo publicado por NIST (National
Institute of Standards and Technology), el coste que tiene la correccin de cdigo o
vulnerabilidades despus de la publicacin de una versin mediante la publicacin de
un parche, es hasta treinta veces mayor que su deteccin y correccin en etapas
tempranas del desarrollo.

Figura 5. Coste relativo de correccin de vulnerabilidades en funcin de la etapa de
desarrollo. Fuente: http://www.microsoft.com/security/sdl/learn/costeffective.aspx

En el informe de Klocwork [10] anteriormente referido, se incluye a su vez una figura
en el coste que tiene la correccin de cdigo o vulnerabilidades despus de la
publicacin de una versin 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 deteccin de defecto tarda. Fuente: [10]

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

1.2. El ciclo de vida de una vulnerabilidad

Introduccin

Una vulnerabilidad es un fallo de programacin, configuracin o diseo que permite,
de alguna manera, a los atacantes alterar el comportamiento normal de un programa y
realizar algo malicioso como alterar informacin sensible, interrumpir o destruir una
aplicacin o tomar su control.

Se puede decir que son un subconjunto del fenmeno ms grande que constituyen los
bugs de software.

Sus fuentes se deben a:
Fallos de implementacin. Fallos provenientes de la codificacin de los diseos
del software realizados. Como ejemplos tenemos desbordamientos de bfer,
formato, condiciones de carrera, path traversal, cross-site scripting, inyeccin SQL,
etc.

Fallos de diseo. Los sistemas hardware o software contienen frecuentemente
fallos de diseo que pueden ser utilizados para realizar un ataque. Por ejemplo
TELNET no fue diseado para su uso en entornos hostiles, para eso se implement
SSH.

Fallos de configuracin. La instalacin de software por defecto implica por lo
general la instalacin de servicios que no se usan, pero que pueden presentar
debilidades que comprometan la maquina.

Vulnerabilidades:
Fallos de implementacin
Fallos de diseo
Fallos de configuracin

Figura 7. Tipos de vulnerabilidades del software

Casi todas las vulnerabilidades de seguridad provenientes de fallos de implementacin
y diseo son bugs de software, pero solamente algunos resultan ser vulnerabilidades de
seguridad. Un bug debe tener algn impacto o caractersticas relevantes para ser
considerado un error de seguridad, es decir tiene que permitir a los atacantes la
posibilidad de realizar un exploits
6
que les permita hacerse con el control de una
mquina.

6
Es una instancia particular de un ataque a un sistema informtico que aprovecha una
vulnerabilidad especfica o un conjunto de ellas.
Una vulnerabilidad se define [4], bsicamente, por cinco factores o parmetros que
deben identificarla.
Producto: productos a los que afecta, versin o conjunto de ellas.
Dnde: Componente o mdulo del programa donde se localiza la vulnerabilidad.
Causa y consecuencia: Fallo tcnico concreto que cometi el programador a la
hora de crear la aplicacin 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: Tcnica 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: deteccin de un fallo en el software que puede producirse
durante el desarrollo del mismo o una vez est en produccin.
Utilizacin: Los agentes maliciosos desarrollan el exploit adecuado para poder
lanzar ataques.
Verificacin inicial de la vulnerabilidad: una vez se recibe una notificacin de
error esta ser aceptada para su tratamiento comprobando la veracidad del error, o
bien ser rechazada por un responsable en caso de que no se pueda reproducir la
vulnerabilidad y se compruebe que la vulnerabilidad no existe.
Solucin: los programadores del producto buscan solucin en entornos
controlados.
Difusin: los medios de comunicacin dan publicidad al incidente.
Medidas: si es posible las organizaciones afectadas toman medidas para mitigar las
posibles prdidas.
Correccin y nueva verificacin: el proceso de correccin de la vulnerabilidad,
llevado a cabo por programadores, ser verificado nuevamente de manera iterativa
hasta comprobar la resolucin del error.
Bsqueda. Los tcnicos buscan vulnerabilidades similares (el ciclo vuelve a
comenzar).
Actualizacin: Los sitios no actualizados vuelven a ser vctimas.

Descubrir Utilizacin Verificacin Solucin Difusin Medidas Correccin Bsqueda Actualizar

Figura 8. Ciclo de vida una vulnerabilidad

Gestin de vulnerabilidades

Dada la gran cantidad de vulnerabilidades descubiertas se hace necesario el disponer
de estndares al objeto de poder referenciarlas unvocamente, para conocer su
gravedad de forma objetiva y obtener el conocimiento necesario para mitigarlas.

Existen varios estndares, catlogos o bases de datos, que a continuacin pasamos a
comentar:
Common Vulnerabilities and Exposures (CVE)
7
[5]. Es un diccionario o
catlogo pblico de vulnerabilidades, administrado por MITRE
8
, que normaliza su
descripcin y las organiza desde diferentes tipos de vista (vulnerabilidades Web, de
diseo, implementacin, etc.). Cada identificador CVE incluye:

o Identificador con el siguiente formato:
Nmerode cuatro cifras que identifica la vulnerabilidad en el ao.
CVE, seguidodel aoen el que se asignel cdigoa la vulnerabilidad.
CVE-2012-
4212

Figura 9. Identificador CVE
o Brece descripcin de la vulnerabilidad
o Referencias

7
http://cve.mitre.org
8
Organizacin sin nimo de lucro, de carcter pblico que trabaja en las reas de ingeniera de
sistemas, tecnologas de la informacin, concepto de operacin y modernizacin de empresas.
http://www.mitre.org/about/index.html
Common Vulnerability Scoring System (CVSS)
9
. Es bsicamente un sistema
que escalona la severidad de una vulnerabilidad, de manera estricta a travs de
frmulas, proporcionando un estndar para comunicar las caractersticas y el
impacto de una vulnerabilidad identificada con su cdigo CVE. Su modelo
cuantitativo asegura una medicin exacta y repetible a la vez que permite ver
caractersticas de vulnerabilidad subyacentes que se usaron para generar su
puntuacin. Permite organizar la priorizacin de las actividades de remediacin o
parcheo de las vulnerabilidades. En la figura se muestra el proceso de clculo de una
severidad:

Figura 10. Clculo puntuacin CVSS

El clculo se realiza en base a tres tipos de mtricas base, temporales y ambientales,
siendo las dos ltimas opcionales. En cuanto a las mtricas base se tienen dos
subconjuntos

o Explotabilidad: vectores de acceso, complejidad de acceso y autenticacin.
o Impacto: confidencialidad, integridad y disponibilidad.

Vulnerability information from the Open Source Vulnerability Database
(OSVDB)
10
. Proporciona una radiografa excelente de las vulnerabilidades
existentes, particularmente para aplicaciones software. Sin embargo, debido a la
naturaleza de los informes vulnerabilidad, OSVDB solo puede contar con las
vulnerabilidades que se hagan pblicas o se hayan insertado directamente en la base
de datos por particulares.

9
http://nvd.nist.gov/cvss.cfm
10
http://osvdb.org
Common Vulnerability Reporting Framework (CVRF). Es un formato XML
que permite compartir informacin crtica sobre vulnerabilidades en un sistema
abierto y legible por cualquier equipo. Hasta el momento no haba ningn estndar
para informar de vulnerabilidades de los sistemas de la Tecnologas de la
Informacin y Comunicaciones (TIC), por lo que CVRF viene a cubrir una necesidad
manifestada por los distintos actores de la industria, organismos de investigacin y
de la administracin en cuanto a un marco comn, ya que hasta ahora, cada
proveedor creaba sus informes segn su criterio. La disponibilidad de CVRF acelera
el intercambio y procesamiento de informacin entre distintas plataformas.

Originalmente deriva del proyecto Incident Object Description Exchange Format
(IODEF), su propsito es el reemplazar los mltiples formatos previamente en uso
no estndar de presentacin de informes, lo que permite acelerar el intercambio de
informacin y proceso.

National Vulnerability Database (NVD)
11
. Base de datos del gobierno
estadounidense que permite la automatizacin de la gestin vulnerabilidades y la
medicin del nivel seguridad. Incluye bases de datos con listas de comprobacin de
configuraciones de seguridad de productos, defectos de seguridad del software
relacionados, malas configuraciones, los nombres de producto y mtricas de
impacto. Contiene:

o 54337 CVE Vulnerabilidades.
o 202 Listas de comprobacin de configuraciones de seguridad de productos.
o 8140 Consultas a OVAL.
12

11
http://nvd.nist.gov/
12
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 codificacin de los detalles de sistema.
http://oval.mitre.org/
Common Weakness Enumeration (CWE)
13
. Estndar International y de libre
uso que ofrece un conjunto unificado de debilidades o defectos de software
medibles, que permite un anlisis, descripcin, seleccin y uso de herramientas de
auditora de seguridad de software y servicios que pueden encontrar debilidades en
el cdigo fuente y sistemas, as como una mejor comprensin y gestin de los puntos
dbiles de un software relacionados con la arquitectura y el diseo. Sus principales
objetivos son:

o Proporcionar un lenguaje comn para describir los defectos y debilidades de
seguridad de software en la arquitectura, el diseo y codificacin.
o Proporcionar un estndar de comparacin de herramientas de auditora
seguridad de software.
o Proporcionar una lnea base para la identificacin de vulnerabilidades, su
mitigacin y los esfuerzos de prevencin.

En la figura siguiente se puede ver un diagrama de contexto de las diferentes
organizaciones y estndares que usan CWE.

Figura 11. Diagrama de contexto de CWE. Fuente: http://cwe.mitre.org/

13
http://cwe.mitre.org/

Incluye los siguientes tipos de debilidades del software: desbordamientos del bfer,
formato de cadenas, estructura y problemas de validacin, errores de ruta, interfaz
de usuario, autenticacin, gestin de recursos, manipulacin de datos, verificacin
de datos, inyeccin de cdigo, etc.

Cada identificador CWE incluye los siguientes campos de informacin:

Nombre del tipode debilidad
Descripcin del tipo
Trminos alternativos para la debilidad
Descripcin del comportamientode la debilidad
Descripcin de la debilidad
Probabilidad de explotar la debilidad
Descripcin de las consecuencias de la explotacin
Posibles mitigaciones
Otras debilidades relacionadas
Taxonomas de las fuentes
Ejemplos de cdigopara los lenguajes/arquitecturas
Identificadores de vulnerabilidades CVEpara las que ese tipode debilidad existe
Referencias
CWE:

Figura 12. Campos de informacin de cada entrada CWE

Clasificacin de las vulnerabilidades

Existen muchas clasificaciones o taxonomas de vulnerabilidades unas se adaptan a
todo tipo de aplicaciones, como son MITRE Top 25
14
y SANS Top 20
15
y otras solo a
aplicaciones web como son OWASP Top 10
16
y WASC Threat Clasification v2.0
17
. A
continuacin describimos algunas de las mencionadas.

14
http://cwe.mitre.org/top25/
15
http://www.sans.org/top20/
16
http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf
17
http://www.webappsec.org/projects/threat/
MITRE TOP 25. La lista es el resultado de la colaboracin entre el Instituto SANS,
MITRE y muchos de los mejores expertos en software de EE.UU. y Europa.
Contiene los mayores errores de programacin 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 Prevencin, mitigacin y principios de programacin seguros.

En la siguiente tabla se pueden consultar las 25 principales vulnerabilidades:
RANK ID NOMBRE
[1] CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL
Injection')
[2] CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS
Command Injection')
[3] CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
[4] CWE-79 Improper Neutralization of Input During Web Page Generation ('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)
[13] CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('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
Tabla 1
Veinticinco vulnerabilidades MITRE TOP 25. Extrada de [7].
Para cada entrada de la tabla se proporciona la siguiente informacin:

o Clasificacin. La clasificacin de la debilidad CVSS.
o Identificador CWE.
o Informacin adicional sobre la debilidad que puede ser til para adoptar
decisiones de priorizacin de acciones de mitigacin.
o Breve discusin 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 estn relacionadas con la debilidad Top 25.
o Entradas estndar CAPEC
18
sobre los ataques que pueden llevarse a cabo con
xito contra la debilidad.
o Enlaces con ms detalles, incluyendo ejemplos de cdigo fuente que demuestran
la debilidad, mtodos de deteccin, etc.

SANS Top 20. Es una lista de vulnerabilidades que requieren solucin inmediata.
Es el resultado de un proceso que reuni a docenas de expertos lderes en seguridad.
Incluye instrucciones paso a paso y notas para informacin adicional tiles para
corregir los defectos de seguridad. Se actualiza la lista y las instrucciones en la
medida que ms amenazas sean identificadas.

o Vulnerabilidades en servidores, aplicaciones Web, aplicaciones
comerciales/open-source.
o No tiene en cuenta las aplicaciones propietarias.

Consultar lectura complementaria para ms detalle sobre la clasificacin.

OWASP Top 10. Su objetivo es crear conciencia sobre la seguridad en aplicaciones
mediante la identificacin de algunos de los riesgos ms crticos que enfrentan las
organizaciones.

18
Lista de patrones comunes de ataque junto con un esquema integral y taxonoma de
clasificacin.
o Las 10 vulnerabilidades de seguridad ms crticas en aplicaciones Web.
o Lista ordenada por criticidad y predominio.
o Representa una lista concisa y enfocada sobre los diez riesgos ms crticos sobre
seguridad en aplicaciones.

Figura 13. OWASP TOP 10 diez riesgos ms importantes en aplicaciones WEB.
Extrada de [8].

WASC Threat Clasification v2.0. Es un esfuerzo de cooperacin para aclarar y
organizar las amenazas a la seguridad de un sitio web. Es un proyecto para
desarrollar y promover estndares para la industria y su principal propsito es el
crear un lenguaje consistente y las definiciones de los problemas de seguridad
relacionados con las aplicaciones web.

o Unificacin y organizacin de las amenazas de seguridad Web.
o Describe amenazas, debilidades y ataques.

Escneres de vulnerabilidades

Este tipo de herramientas analizan los sistemas en busca de vulnerabilidades
conocidas. Disponen de informacin sobre vulnerabilidades existentes en los sistemas
operativos y aplicaciones mediante actualizadas bases de datos, que utiliza para la
deteccin de las mismas.

La herramienta ms utilizada es Nessus, inicialmente de cdigo abierto y versin
gratuita, y actualmente en dos versiones, la 4.x en la que el nuevo cdigo es cerrado, y
la versin 2.x (www.nessus.org) que contina siendo software libre. A raz de este
cambio se crearon tres proyectos diferentes a partir de la versin libre, Sussen, Porz-
Wahn y OpenVas (inicialmente GNessUs). Actualmente el proyecto Porz-Wahn se uni
con OpenVas
19
, la cual contina actualizando versiones para las distintas distribuciones
de GNU/Linux. Otras herramientas de extendido uso son ISS Real Secure, Nmap y
Retina.

1.3. Propiedades de un software seguro

Bsicamente 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 aplicacin y un
segundo conjunto, complementarias a las anteriores que no influyen en su
seguridad, pero que ayudan a mejorarla en gran medida.

19
http://www.openvas.org/
Las principales propiedades esenciales que distinguen al software de confianza
del que no es de confianza son:
Integridad. Capacidad que garantiza que el cdigo, 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 operacin. Entre las modificaciones
que se pueden realizar tenemos sobreescritura, inclusin de puertas traseras,
borrado, corrupcin de datos, etc. Como las tcnicas y mecanismos que se tienen
para salvaguardar la integridad, tenemos por ejemplo:

o Identificacin del modo de trasmisin y procesado de los datos por la aplicacin.
o Uso de tcnicas de cifrado para asegurar que los componentes y los datos nos son
alterados o corrompidos.
o Estricta gestin de sesiones.
o Uso de sistemas de monitorizacin de la integridad
o Uso de firma digital.
o Trasmisin 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 informacin y a los recursos o servicios que la manejan, conforme a las
especificaciones de los mismos. Entre las tcnicas y mecanismos que se tienen para
salvaguardar la disponibilidad, tenemos por ejemplo:

o Anlisis de qu servicios e informacin es crtica 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 rplica de informacin entre ellos.
o Uso de sistemas de recuperacin a travs de imgenes, virtualizacin, etc.

Confidencialidad. Capacidad de preservar que cualquiera de sus caractersticas,
activos manejados estn ocultos a usuarios no autorizados, de forma que se
garantice que solo las personas, entidades o procesos autorizados pueden acceder a
la informacin.

Entre las tcnicas y mecanismos que se tienen para salvaguardar la
confidencialidad, tenemos por ejemplo:

o Clasificacin de las aplicaciones y servicios en base a su criticidad.
o Trfico de relleno.
o Tcnicas de control de acceso a los sistemas basado en roles.
o El cifrado de la informacin y de las comunicaciones.

Figura 14. Propiedades esenciales de la seguridad del software

Un ejemplo de ataque podra ser uno de desbordamiento del buffer (buffer overflow)
consiguiendo el control total de la mquina, pudiendo violar las tres propiedades
anteriores al poder robar informacin del sistema, cuantas de usuario, corromper
ficheros del sistema e incluso apagar la mquina y borrar los ficheros necesarios
para que no vuelva a arrancar.

Estas tres primeras seran las propiedades fundamentales esenciales mnimas que
debera disponer todo software, a las que habra que aadir 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 ejecucin o resultado de una manera favorable para el atacante est
significativamente reducida o eliminada.

En este sentido en el documento de referencia [12], 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 Batera de ataques lanzados contra el software.
o Entradas y salidas del software (seales, ficheros de datos, texto, etc.) que hayan
sido comprometidas.
o Interfaces del software a otras entidades que hayan sido comprometidas.
o Ejecucin del software en un ambiente donde es atacado.

Autenticacin. 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 softwar e a la persona, entidad o proceso que la ha
originado.

Robustez. Capacidad de resistencia y tolerancia a los ataques realizados por
los agentes maliciosos (malware, hackers, etc.).

Resiliencia. Capacidad del software de aislar, contener y limitar los daos
ocasionados por fallos causados por ataques de vulnerabilidades explotable del
mismo, recuperarse lo ms rpido posible de ellos y reanudar su
operacin en o por encima de cierto nivel mnimo predefinido de servicio
aceptable en un 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.

Figura 15. Propiedades seguridad del software

Existen una serie de factores [13] influyen en la probabilidad de que un software sea
consistente con la propiedades anteriormente mostradas, probable es exponer
sistemticamente con estas propiedades en todas las condiciones. Estos incluyen:
Principios de diseo y buenas prcticas de desarrollo. Las prcticas
utilizadas para desarrollar el software y los principios de diseo que lo rigen. En el
apartado posterior se desarrolla ampliamente este punto.

Herramientas de desarrollo. El lenguaje de programacin, bibliotecas y
herramientas de desarrollo utilizadas para disear, 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. Cmo el software se configur durante la
instalacin en su entorno de produccin.

Ambiente de operacin. La naturaleza y configuracin de las protecciones
proporcionadas por el entorno de ejecucin o produccin.

Conocimiento Profesional. El nivel de concienciacin y conocimiento de
seguridad que los analistas, diseadores, desarrolladores, probadores y
mantenedores del software, o su falta del mismo.

1.4. Principios de diseo seguridad del software

Introduccin

Existe una gran cantidad de bibliografa relativa a temas de seguridad en los que se
suele comentar los principios de seguridad que han de regir todo diseo, algunos de
ellos estn ms enfocados a las configuraciones de los dispositivos de seguridad de red,
la mayora de ellos se solapan y normalmente coinciden generalmente siendo por tanto
anlogos, en este sentido se selecciona como referencia para la realizacin de este
apartado los documentos Enhancing the Development Life Cycle to Produce Secure
Software [13] y Writing Secure Code [14].

La adopcin de estos principios de diseo constituye una base fundamental de las
tcnicas de programacin segura que se vern ms adelante en el tema 3, tanto
para la proteccin de aplicaciones Web, normalmente ms expuestas a los ciberataques
al estar desplegadas masivamente en Internet, como otras ms tradicionales del tipo
cliente-servidor. Las principales prcticas y principios de diseo tener en cuenta seran:
Defensa en profundidad.
Simplicidad del diseo.
Mnimo privilegio.
Separacin de privilegios.
Separacin de dominios.
Separacin cdigo, ejecutables y datos configuracin y programa.
Entorno de produccin o ejecucin inseguro.
Registro de eventos de seguridad.
Fallar de forma segura.
Diseo de softwar e resistente.
La seguridad por oscuridad es un error.
Seguridad por defecto.

Defensa en profundidad

Uno de los principios ms importantes de una estrategia defensiva efectiva es la
Defensa en Profundidad, se define en la gua CCN-STIC-400 [18] como: Estrategia
de proteccin consistente en introducir mltiples 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
ejecucin donde la aplicacin vaya a ser instalada debera contar con una variedad de
servicios de seguridad y protecciones que reduzcan y dificulten la probabilidad de que
una accin maliciosa alcance el software, ya que se minimiza la exposicin de las
propias vulnerabilidades al mundo exterior, se reduce la visibilidad externa de los
componentes confiables principales y se aslan los componentes no confiables de
forma que su ejecucin se vea limitada y sus malos comportamientos no afecten o
amenacen la operacin confiable de los dems.

El aislamiento significa que el software o componente no confiable dispone de recursos
especficos para su ejecucin como memoria, espacio en disco duro, interfaz de red
virtual, etc., en un entorno aislado. Para su implementacin se suelen utilizar mquinas
virtuales que adems pueden proporcionar otras caractersticas que ayudan a mejorar
la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte para la
restauracin de imgenes, etc.

Objetivo: introducir mltiples capas de seguridad para reducir la probabilidad de
compromiso del sistema.

Este principio, propone un enfoque defensivo, que implanta protecciones o
mecanismos de seguridad en todos los niveles del sistema o capas del modelo Open
Systems Interconnection (OSI).

Las medidas de seguridad a implementar en cada capa podrn variar en funcin del
entorno de operacin del sistema, sin embargo el principio base o general permanece
inalterable, por ejemplo para las capas siguientes tendramos:

Capa de aplicacin: Dispositivos de nivel de aplicacin como
cortafuegos, proxy reverso, y sistemas de prevencin de intrusiones de
host que bloqueen las entradas maliciosas conocidas y problemticas antes de que
llegue al software. Otros mecanismos son mtodos de encriptacin, control de
acceso, autenticacin, bastionados de aplicaciones, etc.

Capa de transporte: Mecanismos de cifrado como Socket Secure Layer (SSL) o
Transport Layer Security (TLS).

Capa de red: Dispositivos de seguridad de red como cortafuegos, sistemas de
proteccin de intrusiones (IDS/IPS) a nivel de red, sistemas de gestin y correlacin
de eventos de infraestructura (SIEM), etc. que protejan y dificulten las
acciones de los ciberatacantes.

Capa fsica: Plataformas virtuales sandboxes que proporcionan un entorno
aislado de ejecucin para los componentes no confiables evitando que sus
malos comportamientos posibles de afectar a los componentes confiables. As
mismo pueden proporcionar arquitecturas de alta disponibilidad y sistemas de
recuperacin completa de las mquinas. Mantenimiento de los equipos de
comunicaciones y proceso de datos en salas construidas en base a requisitos de
seguridad estructural para evitar intrusiones y emanaciones, sistemas de extincin
automtica de incendios, sensores de humedad, sistemas de control de accesos, etc.

Cortafuegos de aplicacin
Proxy reverso
Mtodos Criptogrficos
Control de Acceso Autenticacin
Bastionado de las aplicaciones
Bastionado del sistema operativo
Aplicacin Datos
Presentacin Datos
Presentacin Datos

SSL/TLS Transporte Segment

Segmentos de red
Firewall/IDS/IPSEC/VPN
Red Paquetes

Enlace Tramas

Prevencin Intrusiones Seguridad
Fsica Procedimientos seguridad
Plataforma virtualizacin
Fsico Bits

Figura 16. Propiedades seguridad del software

El principio fundamental detrs de este concepto, es el de dificultar las acciones
del atacante a travs de las diferentes medidas de seguridad aplicadas a cada una de
las capas de forma que los diferentes sensores que tengan nuestro sistema detecten
las actividades maliciosas. Cuando una capa se vea comprometida, las medidas de
deteccin, de reaccin y de recuperacin nos permitirn 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 verificacin de la cadena de suministros mediante la
comprobacin de los hash
20
, cdigo de firma, aplicados al cdigo ejecutable
mediante la validacin de la integridad de la misma en el momento de la
entrega, la instalacin o en tiempo de ejecucin, para determinar:
o Si el cdigo se origin a partir de una fuente de confianza.
o Si la integridad del cdigo de se ha visto comprometida.

En la figura siguiente se puede observar un ejemplo del uso de arquitecturas de
proteccin.

20
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
funcin hash sobre el contenido distribuido asegurando as la integridad. A esto se le suele
llamar checksum criptogrfico debido a que es un checksum que requiere el uso de funciones
hash criptogrficas para que sea difcil generar otros ficheros falsos que tengan el mismo valor
hash. Otro ejemplo de uso esta tecnologa 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. http://es.wikipedia.org

Ataques exteriores,
identificar problemas
de configuracin
No trfico cifrado,
gran volumen
Elevado n
falsos positivos
Amenaza real,

Figura 17. Uso de arquitecturas de proteccin

Simplicidad del diseo

La realizacin de un diseo tan simple como sea posible y la redaccin de unas
especificaciones del mismo fcilmente comprensibles y simples es una forma de
obtener un nivel de seguridad mayor pues ser menos probable que el desarrollador
incluya debilidades y vulnerabilidades e incluso se haga ms fcil el anlisis de su
descubrimiento y su verificacin y validacin.

Algunas de las opciones especficas de diseo del software que lo simplifican son [13]:
Limitar el nmero de estados posibles en el software.
Favorecer procesos deterministas sobre los no deterministas.
Utilice una sola tarea en lugar de realizar mltiples tareas siempre que sea
prctico.
El uso de tcnicas de sondeo en lugar de interrupciones.
Disear los componentes del software con el conjunto mnimo de
caractersticas y capacidades que se requieran para realizar sus tareas en el
sistema.
La descomposicin en subsistemas o componentes de un programa debera
adaptarse a su descomposicin funcional, permitiendo una asignacin 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 anomala en un
componente o proceso afecte a los estados de otros.

Este desacoplamiento se logra:
o Implementando funcionalidades modulares en el programa en unidades discretas
de procesamiento autnomas.
o Establecer barreras para impedir la comunicacin de entre los componentes que
no deben interactuar por diseo.
o Asignar espacio de memoria restringido a solo lectura o solo escritura para los
procesos, para evitar que todos los componentes, menos los explcitamente
autorizados, cambien los valores de los datos.
o Favorecer el uso de funciones dbilmente acopladas frente a las fuertemente
acopladas.
o Evitar las dependencias de los procesos con el tiempo (establecer un marco de
tiempo
o Evitar secuencias invariantes de procesamiento que permitan un solo un camino
de ejecucin para la realizacin de su tarea. Dichas secuencias pueden ser
explotadas por un ciberatacante para provocar inesperados eventos e
interacciones (que no sean los definidos en la secuencia de procesamiento
invariable).

No implementar caractersticas o funciones innecesarias. Si el diseo
incluye componentes COTS o del software libre con trozos de cdigo latente o
muerto, funciones innecesarias o no documentadas, el diseo debe incluir
contenedores para aislar los segmentos de cdigo no utilizados para prevenir el
acceso a los mismos durante su ejecucin.

Otro aspecto importante en la simplicidad del diseo es que la especificacin del mismo
debe ser totalmente trazable para determinar si el diseo fcilmente satisface todas sus
necesidades, incluyendo las relativas a los requisitos de seguridad. Esta
trazabilidad debe ser atrs hacia adelante y viceversa, es decir:
Trazabilidad hacia adelante un requisito y su correspondencia en el diseo.
Trazabilidad hacia atrs desde el diseo al requisito origen.
Trazabilidad hacia adelante desde el diseo y su correspondencia en el cdigo
implementado.
Trazabilidad hacia atrs desde el cdigo a la parte del diseo correspondiente.

Como podemos ver el implementar arquitecturas complejas, cuando se puede
resolver el diseo de forma simple, puede afectar negativamente a la
seguridad del sistema.
Objetivo: Reducir la complejidad del diseo para minimizar el nmero de
vulnerabilidades explotables por el atacante y debilidades en el sistema.

Mnimo privilegio

De acuerdo con el Software Assurance CBK [18] se define el mnimo privilegio como:

Mnimo privilegio es un principio segn el cual se concede a cada entidad
(usuario, proceso o dispositivo) el conjunto ms restrictivo de privilegios
necesarios para el desempeo de sus tareas autorizadas. La aplicacin de
este principio limita el dao que puede resultar de un accidente, error o el uso
no autorizado de un sistema. Tambin reduce el nmero 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 la principales razones por la que es necesario que una entidad se ejecute con los
mnimos privilegios posibles, es debido a que si un ciberatacante consigue
comprometer una mquina o es capaz de inyectar cdigo malicioso en un proceso del
sistema este se debera ejecutar con los mismos privilegios que tuviera el usuario en la
mquina o el proceso.

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

Aplicacin de derechos de administrador. Por ejemplo una conexin de
lectura a una base de datos con derechos de administrador.

Instalacin de aplicaciones y servicios con el usuario de administrador.
Puede implicar que si un ciberatacante explota una vulnerabilidad de la aplicacin,
obtendra los privilegios de administrador.

Usuarios con derechos de administrador. Se debe planificar para cada
usuario del sistema que aplicaciones, servicios, ficheros van a acceder y con qu
derechos (escritura, lectura, borrado ejecucin, etc.).

Servicios y procesos con privilegios por tiempo indefinido. Cada entidad
debe tener el privilegio necesario para realizar una tarea determinada slo el tiempo
necesario para completarla, ejecutndose normalmente con una cuenta de usuario
restringido.

Objetivo: lo que no est expresamente permitido est prohibido.

Separacin de privilegios

Es un principio relacionado con el anterior mnimo privilegio que esto implica la
asignacin a las diferentes entidades de un rol, que bsicamente implica lo siguiente:
Asignacin 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 funcin
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 que lo integran o el
sistema como un todo. 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
cdigo de los formularios HTML.

Objetivo: asignacin a las diferentes entidades de un rol que implique el acceso a un
subconjunto de funciones o tareas y a los datos necesarios.

Separacin de dominios

Es un principio que en unin con los dos anteriores, mnimo privilegio y separacin
de privilegios y roles, que permite minimizar la probabilidad de que actores
maliciosos obtengan fcilmente acceso a las ubicaciones de memoria u objetos de datos
del sistema, mediante la utilizacin de tcnicas de compartimentacin 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 ejecucin de esas
funciones.

Objetivo: minimizar la probabilidad de que actores maliciosos obtengan fcilmente
acceso a las ubicaciones de memoria u objetos de datos del sistema.

El aislar las entidades de confianza en su rea propia de ejecucin (con recursos
dedicados a esa rea de ejecucin) de otras menos confiables (procesadores de texto,
software de descarga, etc.), permite reducir al mnimo su exposicin a otras entidades e
interfaces externas susceptibles de ser atacadas por agentes maliciosos.

Las tcnicas que tenemos para llevar a cabo lo anterior:
Sistema operativo confiable.
Mquinas virtuales. Adems pueden proporcionar otras caractersticas que ayudan a
mejorar la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte
para la restauracin de imgenes, etc.
Funciones sandboxing de lenguajes de programacin como Java, Perl, .NET (Code
Access Security), etc.
Sistemas Unix: chroot jails.
Trusted processor modules (TPM)
21
.

21
Es el nombre de una especificacin publicada que detalla un criptoprocesador seguro que
puede almacenar claves criptogrficas que protejan la informacin y las implementaciones de
esta especificacin, a menudo llamado el chip TPM o dispositivo de seguridad TPM.
http://en.wikipedia.org

Separacin cdigo, ejecutables y datos configuracin y programa

Este principio pretende reducir la probabilidad de que un ciberatacante que
haya accedido a los datos del programa fcilmente pueda localizar y
acceder a los archivos ejecutables y datos de configuracin del mismo, lo
que le dara la posibilidad de manipular el funcionamiento del sistema a su inters e
incluso el escalado de privilegios.

La mayora de las tcnicas de separacin de los datos de programa y configuracin y
archivos ejecutables se realizan en la plataforma de ejecucin (procesador ms sistema
operativo). A continuacin vemos las ms principales [13]:
Utilizar plataformas con arquitectura Harvard
22
. Asegura que los datos de
programa y datos de control se almacenan en dos segmentos de
memoria fsicamente separados.

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
explcita de otros programas o entidades para poder leerlos.

Los datos de configuracin del programa solo deben poder ser ledos y
modificados por el administrador. Excepcin de configuracin de una
aplicacin cliente o un navegador web donde los datos de preferencias del usuario
estn expresamente destinados a ser configurados por l. En este caso, al usuario
debe permitrsele leer y escribir dichos datos a travs de interfaz de preferencias con
una configuracin especialmente diseada.

Los datos utilizados por un scr i pt en un servidor Web deben ser
colocados fuera de rbol de documentos del mismo. La mezcla de datos
HTML y cdigo JavaScript puede constituir una vulnerabilidad explotable mediante
tcnicas de ataque como Cross Site Scripting (XSS).

Prohibir a los programas y scr i pts escribir archivos en directorios
escribibles como el de UNIX/TMP. Todos los directorios que los programas
necesitan escribir deben configurarse para que solo lo sean por ellos mismos.

22
Arquitectura Harvard hace referencia a las arquitecturas de computadoras que utilizaban
dispositivos de almacenamiento fsicamente separados para las instrucciones y para los datos
(en oposicin a la Arquitectura de von Neumann). http://es.wikipedia.org
Almacenar los archivos de datos, configuracin y programas ejecutables
en los directorios separados del sistema de archivos.

o Un programa ejecutable o script no debe ser escribible por nadie excepto el
administrador (y el instalador si es necesario).
o Un archivo en un entorno de produccin no debe ser ledo por cualquier persona.
o Los usuarios solo deben tener concedidos privilegios de ejecutar el programa.

Los programas y scripts que estn configurados para ejecutarse como servidor Web
de usuario nobody (debe suprimirse) deben ser modificados para funcionar
bajo un nombre de usuario especfico.

Cifrar todos los archivos ejecutables e implementar un mdulo de
decodificacin que se ejecute como parte del inicio del programa para
desencriptarlos al iniciar su funcionamiento.

Incluir tcnicas de cifrado de archivos y la firma digital o
almacenamiento en un servidor de datos externos con conexin cifrada (por
ejemplo mediante SSL o TLS
23
) para aislar los datos de configuracin del software
de la manipulacin y eliminacin, si las tcnicas de control de acceso al sistema no
son lo suficientemente fuertes. Ello requerir que el software incluya la lgica de
cifrado para descifrar y validar la firma del archivo de configuracin al inicio del
programa.

Implantar clonado de sistemas como medida de recuperacin, desde un
servidor remoto (que guardara las imgenes y los datos de configuracin) mediante
una red de comunicaciones fuera de banda especfica y cifrada.

Objetivo: reducir la probabilidad de que un ciberatacante que haya accedido a los
datos del programa fcilmente pueda localizar y acceder a los archivos ejecutables y
datos de configuracin del programa.

23
Secure Sockets Layer (SSL) o Transport Layer Security (TLS)
Entorno de produccin o ejecucin inseguro

Asumir que todos los componentes del entorno de produccin y sistemas externos son
inseguros o no confiables, con ello se pretende reducir la exposicin de los
componentes del software a agentes potencialmente maliciosos que hayan podido
penetrar en el permetro de defensa (los lmites lo constituyen los cortafuegos) de la
organizacin y comprometer una mquina desde la que puedan expandirse e iniciar
otros ataques a otras pertenecientes a la red (pivoting).

El software debe ser diseado con una mnima dependencia de los datos
externos, se debe tener control completo sobre cualquier fuente de entrada de datos,
tanto los proporcionados por la plataforma de ejecucin 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 descomposicin 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 realizndolas a travs de
middleware o APIs.
Llamadas a otros programas en la capa de aplicacin.
Llamadas a una capa de mi ddleware intermedia.
APIs a los recursos del sistema. Las aplicaciones que utilizan las API no
deberan ser utilizados por usuarios humanos.
Referencias a objetos del sistema. Por ejemplo, las recuperaciones y referencias
a nombre de archivo se deben realizar con la ruta completa del recurso del sistema
para eliminar la posibilidad de ser redireccionado a otro directorio en el que se
almacena un caballo de Troya.
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 validacin de los datos de entrada, el confiar en la fuente que las
origin hace a la aplicacin 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 propsito de encontrar vas de compromiso
de la aplicacin.
Todos los tipos de entrada deber ser validados y verificados mediante
pruebas especficas. Entre los diferentes tipos de entradas a las aplicaciones
tenemos [13]:
Parmetros de lnea de comandos.
Variables de entorno.
Localizadores de recursos universales (direcciones URL) e identificadores (URI).
Referencias a nombres de archivo.
Subida contenido de archivos.
Importaciones de archivos planos.
Cabeceras Hyper Text Transfer Protocol (HTTP).
Parmetros HTTP GET.
Campos de formulario (especialmente los ocultos).
Las listas de seleccin, listas desplegables.
Cookies.
Comunicaciones mediante Java applets.

Los tipo de aplicaciones mas mas 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 comprobacin de los datos de entrada,
la mayora para aplicaciones Web, tenemos:
Desbordamientos de Bfer (buffer overflow): heap, stack, entero y off-by-one.
Revelacin de informacin: indexacin de directorio, fuga de
informacin, path tr asver sal, localizacin de recursos predecibles.
Inyeccin de comandos: ataques de formato de cadena, comandos de sistema
operativo, cross-site scripting (XSS).
Inyeccin de cdigo SSI inyeccin SQL, HTTP splitting.
Contenidos mal formados.
Servicios Web: aparte de los anteriores tenemos, inyeccin XML, explotacin de
interfaces de administracin no protegidos.

Para evitar este tipo de vulnerabilidades se deben aplicar una serie de principios de
validacin de las entradas, entre los que tenemos [13]:
Centralizar la lgica de validacin de las entradas.
Asegrese que la validacin de la entrada no puede ser evitada.
Confiar en listas blancas
24
validadas y filtrar las listas de negras.
Utilice las "listas negras" para filtrado preliminares al objeto de reducir la cantidad
de datos que deben someterse a validacin.
Validar todas las entradas de usuario incluidas las realizadas a travs de
proxies y agentes que acten en nombre de los usuarios. Se debe validar al menos
longitud correcta, el formato y la sintaxis. Ejemplo si se trata de un DNI contenga
slo ocho caracteres numricos, cualquier otra entrada deber ser rechazada.
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
poltica) a emitirlas.
Definir reacciones significativas a errores de validacin de entrada. El
rechazo a entradas mal formadas o fallidas es uno de los ms frecuentes.
Validar los datos de de salida de la aplicacin antes de mostrarlos al usuario o
redirigirlos a otro sistema.

Objetivo: evitar vulnerabilidades aplicando una serie de principios de validacin de las
entradas.

Registro de eventos de seguridad

Tradicionalmente los sistemas de auditora se dedicaban solo a grabar las acciones
realizadas por los usuarios del mismo. Sin embargo actualmente es necesario dotar a
las aplicaciones o sistemas de la capacidad de generar eventos (logs) de seguridad, para
garantizar que todas las acciones realizadas por un ciberatacante 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 deteccin de intrusiones.

24
Una lista blanca, lista de aprobacin whitelist en Ingls es una lista o registro de
entidades que, por una razn u otra, pueden obtener algn privilegio particular, servicio,
movilidad, acceso o reconocimiento. Por el contrario la lista negra o blacklisting es la
compilacin que identifica a quienes sern denegados, no reconocidos u obstaculizados.
http://es.wikipedia.org
Las principales diferencias que distinguen los sistemas con registros de auditora de
seguridad de registro de los registros de eventos estndar son:
El tipo de informacin capturada en el registro de auditora: eventos de
seguridad.
Capacidad de gestin de los incidentes relacionados con los eventos de
seguridad.
Posibilidad de que los eventos de seguridad registrados en la aplicacin o sistema,
puedan ser utilizados en procesos reactivos despus de la ocurrencia de un
incidente.
El nivel de proteccin de integridad aplicado a los registros de auditora, para
evitar que sean intencionadamente o inadvertidamente eliminados, daados o
alterados. Suelen incluirse las siguientes medidas:

o Medidas de autenticacin de los actores que interactan con el sistema sea
humano o de cualquier otro tipo, preferentemente de tipo fuerte mediante
certificados.
o Medidas de no repudio, basadas normalmente en firma digital.
o Comprobacin de integridad mediante, aplicaciones de algoritmos de hash.

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

Fallar de forma segura

El propsito de este principio es el reducir la probabilidad de que un fallo en el
software, pueda saltarse los mecanismos de seguridad de la aplicacin, dejndolo en un
estado de fallo inseguro vulnerable a los ataques. Es imposible implementar una
aplicacin perfecta que nunca falle, la solucin consiste en saber en todo momento cul
es su estado y tener implementado un mecanismo en caso que falle.

Algunas de las caractersticas especficas del diseo que minimizan la probabilidad de
que el software pase a un estado inseguro son:
Implementar temporizadores tipo watchdog que comprueben el estado de
los procesos sujetos a errores, como conexiones y operaciones a bases de datos,
llamadas a funciones, componentes distribuidos, etc.

Implementar una lgica de control de excepciones, para cuando la
aplicacin falle, registre un evento con error (que no proporcione al atacante
informacin sensible del sistema y le posibilite buscar otros fallos parecidos para
obtener ms informacin), implemente un umbral en el que se establezca un punto
de no retorno del cual no es posible recuperarse pues se estara en un estado
vulnerable de fallo seguro e intente tomar acciones correctivas antes de que el fallo
ocurra. El registro del error permitir al personal de mantenimiento investigar sus
causas y mostrar un mensaje al usuario con instrucciones a realizar sin desvelar
informacin tcnica que pudiera ser utilizada por un ciberatacante.

El softwar e siempre debe comenzar y terminar su ejecucin en un
estado seguro. Los cambios de estado siempre deben ser deliberados y nunca
accidentales, sobre todo a estados vulnerables.

Evitar problemas de sincronizacin y secuenciacin, causados por el uso
compartido de informacin de estado (sobre todo en tiempo real). Usar para ello
enclavamientos (secciones crticas, mecanismos de sincronizacin) para hacer
cumplir las secuencias de acciones o eventos, de modo que no pueda ocurrir
accidentalmente o exista una condicin indeseable o fuera de secuencia.

Objetivo: reducir la probabilidad de que un fallo en el software, pueda saltarse los
mecanismos de seguridad de la aplicacin, dejndolo en un modo de fallo inseguro
vulnerable a los ataques.

Diseo de softwar e 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 mnimo la cantidad de tiempo que un componente de softwar e
defectuoso o fallido sigue siendo incapaz de protegerse de los ataques.
Algunas de las caractersticas de diseo que aumentarn la resistencia del software
incluyen [13]:
Capacidad de autocontrol y de limitar el uso de los recursos.

Uso de tcnicas de monitorizacin que permita al software detectar cualquier
anomala y error antes de crear una vulnerabilidad explotable.

Deteccin de estados anmalos cuando ocurra un error, el controlador de
excepciones debe devolver al software a un estado seguro conocido.

Proporcionar una realimentacin 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 recuperacin rpida a nivel
sistema, como copias de seguridad automticas, arquitecturas de alta disponibilidad
y almacenamiento y restauracin de imgenes.

Uso de plataformas virtuales que proporcionan ayuda a mejorar la fiabilidad,
confiabilidad y resistencia, con tcnicas como balanceo de carga, soporte para la
restauracin de imgenes, etc.

Uso de tcnicas de recuperacin que incluyan el uso de estructuras de datos
robustos, alteracin dinmica de los controles de flujo y tolerancia al error para que
pueda seguir funcionando de forma fiable en presencia de un nmero bastante
grande de errores de entrada del usuario.

Determinar la cantidad de informacin a proporcionar en los mensajes
de error para ayudar a los usuarios a corregir sus propios errores, frente a la
amenaza del ciberatacantes capaces de aprovechar el conocimiento que obtienen de
un error informativo.

Objetivo: reducir al mnimo 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 disear una aplicacin, es que el
atacante obtendr con el tiempo acceso a todos los diseos y todo el cdigo
fuente de la misma. La seguridad por oscuridad es un mecanismo de defensa
que consiste en ocultar en la aplicacin informacin sobre la misma para
sea difcil de obtener, pero que en poder de un atacante puede proporcionarle un
medio para comprometerla.

Howard y LeBlanc en el documento de referencia [14], no aconsejan que nunca se
dependa de la seguridad por oscuridad solamente indican que es vlido usarla como
una pequea parte de una estrategia general de defensa en profundidad
para confundir y dificultar las actividades de ataque de un intruso. A continuacin se
muestran algunos ejemplos de seguridad por oscuridad, que pueden constituir un
error:
Guardar informacin en archivos binarios. Un ciberatacante con
conocimientos de ingeniera inversa podra obtener dicha informacin.
Capetas ocultas en un servidor Web, con herramientas de anlisis forense se
podra acceder a ellas fcilmente. Incluso podra tener activado por error la opcin
de listado de directorios del servidor, con lo que un ciberatacante podra
visualizarlos completamente.
Falsa sensacin de seguridad de que el software que se ejecuta en un servidor
en una red dedicada pueda guardar secretos o no ser comprometido. Actualmente se
han dado casos de intrusiones en este tipo de redes como el caso Stuxnet.
Criptografa privada. No es conveniente confiar en cualquier algoritmo que no es
de conocimiento pblico y no ha sido analizado ampliamente, dado que al no haber
una verdadera prueba matemtica slida de la seguridad de la mayora de los
algoritmos criptogrficos, se consideran de confianza cuando un nmero suficiente
de personas han pasado mucho tiempo tratando de romperlo y no lo han logrado.
Ejemplo la criptografa de GSM, al principio era secreta pero cuando se supo el
algoritmo que utilizaba se lleg a romper.
Cambio del nombre del usuario administrador en un servidor con sistema
operativo de Microsoft para evitar que sea atacado. Existen herramientas que
pueden obtener el nombre de usuario del administrador directamente del
identificador.
Objetivo: concienciarse de que la seguridad por oscuridad es un mecanismo de
defensa que puede proporcionar a un atacante informacin para comprometer la
seguridad de una aplicacin.

Seguridad por defecto

Uno de los principios de seguridad cuyo cumplimiento exige el Real Decreto 3/2010
[22], de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el mbito
de la Administracin Electrnica, es el de la seguridad por defecto. En su artculo 19
indica lo siguiente:

Los sistemas deben disearse y configurarse de forma que garanticen la
seguridad por defecto:
a. El sistema proporcionar la mnima funcionalidad requerida para que la
organizacin solo alcance sus objetivos, y no alcance ninguna otra
funcionalidad adicional.

b. Las funciones de operacin, administracin y registro de actividad sern las
mnimas necesarias, y se asegurar que solo son accesibles por las personas,
o desde emplazamientos o equipos, autorizados, pudiendo exigirse en su
caso restricciones de horario y puntos de acceso facultados.

c. En un sistema de explotacin se eliminarn o desactivarn, mediante el
control de la configuracin, las funciones que no sean de inters, sean
innecesarias e, incluso, aquellas que sean inadecuadas al fin que se
persigue.

d. El uso ordinario del sistema ha de ser sencillo y seguro, de forma que una
utilizacin insegura requiera de un acto consciente por parte del usuario.

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

Normalmente cuando se instala o pone en produccin una aplicacin 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 explcita por los usuarios e instalarlos y configurarlos de forma
segura. Hay que minimizar los puntos vulnerables de la aplicacin o sistemas pues
amenazan su seguridad global por muy securizado que se tenga el resto. Por la tanto
hay que controlar los puntos de entrada que:
Entradas y salidas de red.
Nmero de puertos abiertos.
Puntos de entrada a la aplicacin, autenticados o no autenticados, locales o remotos
y privilegios administrativos necesarios.
Nmero de servicios. Desactivar los instalados por defectos no usados.
Nmero de servicios con privilegios elevados.
Nmero 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 dinmico de pginas Web.

Varias organizaciones, como el National Institute of Standards and Technology (NIST),
la Agencia de Seguridad Nacional (NSA) y el Centro Criptolgico Nacional (CCN), han
publicado guas de seguridad de configuracin y scripts para productos COTS
populares y de software libre que incluye la eliminacin o restriccin de servicios,
usuarios, permisos y software innecesario.

El bastionado de sistemas es un proceso necesario en el marco de
cualquier proyecto que contemple la aplicacin de controles de seguridad
sobre los sistemas TIC que tiene como principio implementar todas las medidas de
seguridad a nivel tcnico 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 justificacin de la renuncia a los requisitos de configuracin de
seguridad que impidan el correcto funcionamiento del software.

Objetivo: reducir la superficie de ataque de una aplicacin o sistema.

Resumen

En el presente apartado se ha realizado un estudio de los diferentes principios de
seguridad a tener en cuenta en el diseo y desarrollo de aplicaciones seguras, que nos
ayudaran a proteger y disponer de aplicaciones seguras con un mnimo de
vulnerabilidades. Como resumen se muestra un grfico que sintetiza el objetivo de cada
principio.
Principio Objetivo
Defensa en
profundidad
Introducir mltiples capas de seguridad para reducir la
probabilidad de compromiso del sistema.
Simplicidad del diseo
Reducir la complejidad del diseo para minimizar el nmero de
vulnerabilidades explotables por el atacante y debilidades en el
sistema.
Mnimo privilegio Lo que no est expresamente permitido est prohibido.
Separacin de
privilegios
Asignacin a las diferentes entidades de un rol que implique el
acceso a un subconjunto de funciones o tareas y a los datos
necesarios.
Separacin de
dominios
Minimizar la probabilidad de que actores maliciosos obtengan
fcilmente acceso a las ubicaciones de memoria u objetos de
datos en el sistema.
Separacin cdigo,
ejecutables y datos
configuracin y
programa
Reducir la probabilidad de que un ciberatacante que haya
accedido a los datos del programa fcilmente pueda localizar y
acceder a los archivos ejecutables y datos de configuracin del
programa.
Entorno de
produccin o
ejecucin inseguro
Evitar vulnerabilidades aplicando una serie de principios de
validacin de las entradas.
Registro de eventos de
seguridad
Generar eventos (logs) de seguridad, para garantizar las acciones
realizadas por un ciberatacante se observan y registran
Fallar de forma segura
Reducir la probabilidad de que un fallo en el software, pueda
saltarse los mecanismos de seguridad de la aplicacin, dejndolo
en un modo de fallo inseguro vulnerable a los ataques.
Diseo de software
resistente
Reducir al mnimo la cantidad de tiempo que un componente de
un software defectuoso o fallido sigue siendo incapaz de
protegerse de los ataques.
La seguridad por
oscuridad: error
Concienciarse de que la seguridad por oscuridad es un
mecanismo de defensa que puede proporcionar a un atacante
informacin para comprometer la seguridad de una aplicacin.
Seguridad por defecto Reducir la superficie de ataque de una aplicacin o sistema.
Tabla 2
Objetivos Principios de seguridad
1.5. Amenazas a la seguridad del software

Introduccin

Las aplicaciones, tal y como se expuso en la introduccin del presente tema, son
amenazadas y atacadas, no solo en su fase de operacin, sino que tambin en todas las
fases de su ciclo de vida.

El principal objetivo de la seguridad del software es el mantener sus propiedades
de seguridad frente a los ataques realizados por personal malicioso sobre
sus componentes y poseer el mnimo posible de vulnerabilidades
explotables. Para conseguir que el desarrollo de una aplicacin posea las propiedades
y principios de diseo del software seguro presentados en los apartados anteriores, se
necesita que el personal de diseo y desarrollo desarrollen dos perspectivas:

Defensor
El equipo trabaja para construir un software
con las propiedades de seguridad necesarias
para que sea ms resistente a los ataques y
minimizar las debilidades y vulnerabilidad
Atacante
El equipo se esfuerza por comprender la
naturaleza exacta de la amenaza a la que le
software es probable que se enfrente con el
fin de concentrar los esfuerzos defensivos

Figura 18. Perspectivas de modelado

La habilidad de un software para mantener sus propiedades de seguridad y de
funcionar frente a un ataque se puede dividir en tres caractersticas [12]:
Resistencia. Capacidad del software para evitar que un atacante le realice un
ataque. La ms grave de las tres caractersticas, sin embargo es a menudo el ms
difcil de lograr, ya que implica minimizar las debilidades explotables en
todos los niveles de abstraccin, desde la arquitectura hasta la implementacin
detallada y despliegue.

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.

Resiliencia. Capacidad del software para aislar, contener y limitar los daos
ocasionados por fallos causados por ataques de vulnerabilidades explotable que el
software no pudo resistir o tolerar y recuperarse lo ms rpido posible de ellos.

Tolerancia y resistencia al ataque son el resultado de efectivas decisiones de
arquitectura y diseo ms que de implementacin.

Motivacin perspectiva y tipos de atacantes

El principal desafo en el desarrollo de software seguro, se debe a que es mucho ms
fcil encontrar vulnerabilidades en el softwar e, que es hacer software seguro.
La perspectiva del ciberatacante, bsicamente consiste en buscar vulnerabilidades en el
software bajo la perspectiva de afuera hacia adentro, requiere primero comprender
la tipologa y motivaciones que hay detrs de los ataques a fin de entender
realmente los riesgos asociados y analizar el softwar e de la manera que lo haran
para atacarlo. Esto proporcionar al equipo de diseo y desarrollo una mejor
comprensin de cmo el softwar e es probable que sea atacado y por tanto les
ayudar a mejorarlo y securizarlo contra un ataque.

Tal y como se ha comentado en la introduccin, las amenazas al software estn
presentes a lo largo de todo su ciclo de vida, durante su desarrollo y despliegue
debidas principalmente a atacantes internos y durante la operacin a
atacantes externos (todos los dems tipos).

En el trabajo An Updated Taxonomy for Characterizing Hackers According to Their
Threat Properties Sara L.N. RaId y Jens M. Pedersen [28] presentan una taxonoma o
tipologa actualizada de los ciberatacantes, caracterizndolos por la gravedad de su
amenaza y dividindolos por categoras en trminos de motivaciones, capacidades,
triggers, mtodos y tendencias. En la siguiente tabla se muestra un resumen de la
misma.

Tipo Intenciones Triggers Habilidades Recursos Mtodos Tendencias
Scriptkiddies
Curiosidad,
notoriedad
Aleatorio Bajas. Novatos
Escasos, sin
equipos
especializados
Herramientas
y script libres
de Internet
No son capaces
de hacer daos a
sistemas
protegidos
Ciber-Punk
Notoriedad,
a veces
econmicos
Objetivos de
tipo militar o
gubernamenta
l
Medias. Con
conocimientos
de sistemas
operativos y
programacin
Poseen
equipos
especializados,
frums y
grupos de
Hackers
Herramientas
y script libres
modificadas
para sus usos.
Bsqueda de
notoriedad.
Para financiarse
roban tarjetas de
crdito o fraudes
Internos
Venganza.
econmicos
Evento
negativos
Alto, con y
conocimientos
especializados
Accesos
privilegiados e
informacin
de los sistemas
Accesos
privilegiado
para robos de
informacin,
fraude,
sabotaje
Actualmente
estn en declive
frente a los
atacantes
externos
Petty theft Econmicos
Ninguno en
especial,
bsqueda de
dinero
Medias.
Aprenden
determinadas
habilidades
para los
ataques sin
estar
interesados en
la tecnologa
Poseen
equipos
especializados
Spam, fraudes
de tarjetas de
crdito, robo
de identidad
mediante
scripts
crimeware.
Los vectores de
ataque ha vuelto
ms accesible
para los no
tcnicos
Petty Thief
Greyhat
Curiosidad,
notoriedad
Prefieren
objetivos que
constituyen un
desafo o
contienen
informacin
sensible
Altas, a veces
incluso muy
especializados
Tienden a
trabajar solos,
pero pueden
aprovechar el
conocimiento
y
herramientas
de
compaeros
Explotar ms
vulnerabilidad
es conocidas o
0-day

Por lo general no
causan daos
importantes.
Una excepcin
es el caso
Wikileaks

Criminales
Profesionales
Econmicos
Analizan
beneficios
frente a los
riesgos antes
de atacar.
Objetivo
negocio viable.
Muy alto,
incluyendo las
habilidades
especializadas
Empresas
estructuradas
con equipos,
habilidades
especializadas
y los recursos
necesarios.
Emplean una
gran cantidad
de mtodos y
desarrollan
vectores de
ataque
phishing,
spam, botnets,
Man-in-the-
Browser y key
loggers
El uso de
botnets para
robar
informacin
financiera est
en aumento, as
como el
espionaje
industrial y el
robo de
identidad
Hacktivistas
Notoriedad,
venganza
Cualquier
insulto real o
percibido de
su ideologa
Niveles de
habilidad
varan
ampliamente,
tienden a
tener un
ncleo de
miembros con
altos
conocimientos
tcnicos.
Recursos
monetarios
limitados.
Gran cantidad
de miembros.
Se tiene acceso
a mucha
informacin
especializada
Explotan
vulnerabilidad
es para tener
acceso a los
datos
confidenciales
que luego
publican.
Otro mtodo
preferido es el
DDoS
Estn al borde
entre la
desobediencia
civil y
terrorismo

Estados
Venganza,
espionaje,
econmicos
Los ataques
entre estados
son
provocados
por conflictos
geopolticos.
Alto. Los
Estados
pueden tener
acceso a
habilidades y
conocimiento
de toda una
nacin.
Un Estado
tiene acceso a
ms fondos,
mejor equipo e
inteligencia

Actan de
manera
encubierta en
Internet. Las
metodologas
suelen
combinar
tcnicas de
ingeniera
social y
spearphishing,
trojanos , etc.
Los Estados
estn cada vez
ms presentes
en Internet.
Muchos pases
tienen
comandos
cibernticos.
Tabla 3
Taxonoma Ciberatacantes

En cuanto a los tipos de ataques o incidentes de seguridad, tomando como referencia la
taxonoma anterior y la presentada en el trabajo de Zulima Ortiz y Francisco Galindo
Hacia una Taxonoma de Incidentes de Seguridad en Internet [27] basada en
procesos y orientacin al evento, en la que se realiza una actualizacin de esta
ltima con nuevos tipos de hakers presentados en la tabla 3 y los diferentes tipos de
objetivos.

El equipo de desarrollo y diseo podra usarla para determinar qu categoras de
ciberatacantes son ms propensos a atacar la futura aplicacin, al objeto de evaluar las
futuras amenazas y riesgo al que va a estar expuesto y poder priorizar las defensas
contra los mtodos utilizados por estas categoras. Como aclaracin resumo los
principales conceptos de esta taxonoma:
Eventos. Un evento se define como un cambio discreto de estado de un sistema o
dispositivo. Este cambio de estado es el resultado de una accin emprendida por un
usuario, es decir existen eventos vlidos sobre un sistema.

Accin. Se define como un paso tomado por un usuario o un proceso para alcanzar
un resultado.

Blanco. Se define como una entidad lgica de cmputo o de red (cuenta, proceso o
dato) o una entidad fsica (componente, ordenador, red o interred) objetivo del
ciberataque.

Ataque. Una serie de medidas adoptadas por un atacante para obtener un resultado
sin autorizacin.

Incidente. Un grupo de ataques que se pueden distinguir de otros ataques debido a
la peculiaridad de los atacantes, ataques, objetivos, lugares y tiempos.

En la figura siguiente se presente la taxonoma del incidente completo.
Atacantes
Script Kiddies
Ciber-punk
Internos
Petty Thieves
Greyhat
Cibercriminales
Hacktivistas
Estados
Herramientas
Ataque fsico
Intercambio
informacin
Comandos de
usuario
Script o
programas
Agentes
autnomos
Caja de
herramientas
Herramientas
distribuidas
Toma de
datos
Vulnerabilidad
Diseo
Implementacin
Configuracin
Acciones
Footprinting
Escaneo
Enumeracin
Autenticacin
Ataque
(exploit)
Inundacin
(flood)
Bypass
Spoof
Leer
Copiar
Robar
Blanco
Cuentas
Procesos
Datos
Ordenadores
Red
Interred
Resultado
no
autorizado
Incremento
acceso
Difusin
informacin
Negacin de
informacin
Denegacin
de servicio
Robo de
recursos
Objetivo
Cambio de
estatus
Polticos
Econmicos
Dao
Espionaje
Notoriedad
Curiosidad
Eventos
Ataque
Incidente

Figura 19. Taxonoma de incidentes. Adaptada de [27]

1.6. Tipos de S-SDLC

Introduccin

Las organizaciones deben insertar buenas prcticas de seguridad en el
proceso de desarrollo de softwar e al objeto de obtener softwar e ms
seguro o confiable, bien adoptando una metodologa segura de desarrollo que
proporcione un marco integrado de mejora de la seguridad, como los
presentadas en este apartado, o a travs de la evolucin y mejora de sus actuales
practicas de seguridad.
Estas metodologas no modifican las actividades tradicionales de SDLC, insertan
nuevas actividades con el objetivo de reducir el nmero de debilidades y
vulnerabilidades en el software, a este nuevo ciclo de vida con buenas prcticas
de seguridad incluidas lo denominaremos S-SDLC.

En el presente apartado se presentan varios modelos de ciclo de vida S-SDLC con
prcticas de seguridad incluidas, que se pueden aplicar independientemente del tipo de
modelo: ciclo de vida en espiral, extreme programming, etc. Adems, algunos mtodos
estndar de desarrollo han demostrado que aumentan la probabilidad de que el
software producido por ellos ser seguro. Debido a la popularidad actual de los
mtodos giles, es importante el estudiar los problemas de seguridad que surgen
cuando se utiliza este tipo de ciclos de vida.

Los equipos de desarrollo que utilizan metodologas seguras en el SDLC, casi
inmediatamente perciben una mejora en su capacidad para detectar y
eliminar vulnerabilidades y debilidades en el software que producen, antes de
que entren en un proceso de distribucin e instalacin. Esta mejora se pondr de
manifiesto conforme el software pase sus controles de seguridad (revisiones de diseo
y cdigo de seguridad, anlisis de fallos de inyeccin, pruebas de penetracin, anlisis
de vulnerabilidades, etc.).

Los elementos clave de un proceso de S-SDLC son [9]:
Hitos de control en las fases del SDLC. Se debe incluir hitos de control al
finalizar cada fase del SDLC, para comprobar la calidad y cumplimento con
los requerimientos del proyecto y verificar la ausencia de problemas inaceptables
en los artefactos desarrollados entregables de la misma (por ejemplo, requisitos
inadecuados o inexistentes, malas decisiones de diseo, errores de codificacin,
interfaces no especificadas, etc.). Como controles de salida incluyen revisiones
paritarias, revisin de requisitos y diseo, revisiones de cdigo, pruebas de
seguridad y auditoras de seguridad.

Principios y prcticas seguras de softwar e. Todos los procesos de desarrollo y
sus artefactos deben ser conforme a los principios de diseo seguro y buenas
prcticas de diseo, estudiados en el prrafo anterior y posteriormente en el tema
2.

Requisitos adecuados. La especificacin de requisitos incluye requisitos
adecuados y completos a las restricciones de funcionamiento del software,
comportamiento negativo y requisitos no funcionales relacionados con los procesos
de desarrollo, evaluacin, restricciones operativas, etc., para garantizar la fiabilidad,
confiabilidad y capacidad de recuperacin del software.

Arquitectura y diseo adecuados: Revisiones de la arquitectura y diseo del
software para asegurarse de que:

o Son correctas suposiciones del desarrollador acerca de todos los posibles cambios
que puedan producirse en el entorno de ejecucin del software.

o Son correctas suposiciones del desarrollador acerca de todos los cambios de
estado posibles en el software.

o Plataforma de ejecucin hardware y software adecuada para que la aplicacin:

Acte de una forma fiable y confiable en su entorno operativo hostil.
Utilice nicamente interfaces apropiadas y seguras con los componentes y
servicios, consolas de administrador y usuarios.
Anticipar todos los cambios de estado que podran derivarse de los errores o
fallos provocados por el mal uso y abuso (este ltimo podra ser
caracterizado por patrones de ataque que se manifiestan como
errores o anomalas en los flujos de entrada).

o Anticipar y abordar posibles problemas de seguridad asociadas con los
componentes COTS y de software libre, como pudieran ser determinadas
configuraciones para impedir la inadvertida o intencional maliciosa activacin de
funciones de cdigo (inactivo) que no estn expresamente destinados
a ser ejecutadas, durante su funcionamiento.

Codificacin segura. Incluye la adopcin de prcticas de codificacin seguras y
estndares de programacin. Durante todo el proceso de codificacin se deben
realizar de forma iterativa anlisis de seguridad esttica de cdigo al objeto de
encontrar problemas de seguridad y eliminarlos antes de liberarlo a la unidad de
pruebas e integracin.

Integracin de forma segura de los mdulos y componentes del
softwar e:

o Garantizar que todas las interfaces de programacin y llamadas a procedimientos
son intrnsecamente seguras y se han incluido mecanismos de seguridad
necesarios.

o Reducir al mnimo la exposicin al exterior de los componentes de alto
riesgo y vulnerabilidades conocidas. Las pruebas de seguridad en la etapa de
integracin deben centrarse en obtener una buena idea de las conductas
inesperadas no seguras o vulnerabilidades que pueden surgir debido a las
interacciones entre los componentes.

Pruebas de seguridad. Inclusin de revisiones y casos de pruebas orientadas a la
seguridad durante todo el SDLC. Los planes de pruebas, realizados en la etapa de
diseo, deben incluir escenarios con condiciones anormales y hostiles de ejecucin y
criterios de prueba que permitan determinar si el softwar e cumple con sus
requisitos de fiabilidad, confiabilidad y fiabilidad.

Despliegue y distribucin segura. Incluye:

o Desinfeccin completa de ejecutables, antes de la transferencia al sitio de
descarga o medios de distribucin, para evitar la inclusin de software malicioso
en el mismo, datos incrustados sensibles, puertas traseras del desarrollador, etc.

o Distribucin a travs de canales de comunicacin seguros que protejan
adecuadamente al software aplicando firmas digitales y mecanismos para evitar
la manipulacin o instalacin no autorizada.

o Ajustes predeterminados de configuracin mximamente restrictivos,
documentados en una gua de configuracin lo suficientemente detallada para
permitir al instalador tomar decisiones en base al riesgo de realizar
configuraciones menos restrictivas si es necesario

o Documentacin de instalacin, usuario y administrador legible y precisa en la que
se expliquen claramente todas las restricciones necesarias y los elementos de
seguridad del software.
Sostenimiento seguro. Incluye el mantenimiento de la aplicacin, gestin de sus
vulnerabilidades, emisin de parches y su distribucin a los clientes para que los
apliquen y lo mantengan, evitando la exposicin innecesaria de sus vulnerabilidades.

Herramientas de apoyo al desarrollo. Incluye herramientas y plataformas de
desarrollo, pruebas e implantacin que mejoran la seguridad de los artefactos
producidos y las prcticas seguras aplicadas en todo el S-SDLC.

Gestin de configuracin de sistemas y procesos. Gestin de configuracin
versiones, control de cambios de los artefactos de desarrollo (cdigo fuente,
especificaciones, resultados de pruebas, etc.) como medida preventiva contra la
manipulacin de sus artefactos por agentes maliciosos.

Conocimientos de seguridad de los desarrolladores. El conocimiento que los
desarrolladores necesitan sobre principios y prcticas de ingeniera de seguridad de
software.

Gestin segura del proyecto y compromiso de la alta direccin. La alta
direccin de la organizacin debe comprometerse a proporcionar un apoyo
adecuado (en trminos de recursos, el tiempo, las prioridades de negocio y cambios
de cultura organizacional) en la adopcin y el uso constante de los procesos y
prcticas de software seguras.

En los siguientes apartados se introduce la metodologa S-SDLC McGraws Seven
Touchpoints por ser la tomada como base para la realizacin del tema 2 y se nombran
otras existentes y se referencian otras metodologas actualmente en uso por diferentes
organizaciones.

McGraws Seven Touchpoints

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

En esencia, el proceso se centra en la incorporacin de las siguientes prcticas
ordenadas por orden de importancia:
Revisin de cdigo
Anlisis de riesgo arquitectnico
Pruebas de penetracin
Pruebas de seguridad basados en riesgo
Casos de abuso
Requisitos de seguridad
Operaciones de seguridad
Revisin externa

Adems de las siete prcticas se identifica una octava, el anlisis externo, en el que
un equipo de analistas externos a la organizacin y por tanto al equipo de desarrollo del
software, realiza revisiones de seguridad independientes, evaluaciones y pruebas del
diseo del software y la implementacin. La figura siguiente, muestra el de ciclo de
vida de desarrollo de software seguro S-SDLC en el que se especifican las actividades y
pruebas de seguridad a efectuar en cada fase del mismo.
1. Revisin
cdigo
2. Anlisis
riesgos
4. Pruebas
basadas en
riesgo
3. Pruebas
penetracin
Requisitos
Casos de
abuso
Arquitectura
Diseo
Plan de
pruebas
Codificacin
Pruebas y
resultados
Realimentacin
de produccin
7. Operaciones
Seguridad
2. Anlisis de
riesgos
5. Casos
de abuso
6. Requisitos
seguridad
8. Revisin
externa

Figura 20. McGraws Seven Touchpoints. Extrada de [7].

Este orden descrito no se adecuar perfectamente a todas las organizaciones. De hecho,
el orden refleja el trabajo desarrollado en aos de experiencia de McGraw al aplicar
estas prcticas en empresas desarrolladoras de software. Por esa razn, la revisin de
cdigo viene antes de anlisis de riesgos arquitectnico. Hay que resaltar que estas
actividades hay que repetirlas a lo largo del ciclo de vida lo que supone un ciclo
continuo en la ejecucin 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 anlisis de riesgos.
Cambios en el sistema con nuevos componentes de software hardware, implica el
rehacer el anlisis de riesgos y revisar el cdigo de los nuevos componentes software.
Nuevos defectos de implementacin que modifican las especificaciones del sistema
implican nuevas revisiones de cdigo y as pruebas de seguridad.

Otras metodologas

Microsoft Trustworthy Computing SDL
25
.
CLASP: Comprehensive Lightweight Application Security Process
26
.
Team Software Process (TSP)
27
.
Oracle Software Security Assurance
28
.
Appropriate and Effective Guidance in Information Security (AEGIS)
29
.
Rational Unified Process-Secure (RUPSec)
30
.
Secure Software Development Model (SSDM)
31
.
Waterfall-Based Software Security Engineering Process Model
32
.

25
http://www.microsoft.com/security/sdl/
26
http://www.owasp.org/index.php/Category:OWASP_CLASP_Project
27
http://www.cert.org/secure-coding/secure.html
28
http://www.oracle.com/us/support/assurance/index.html
29
http://www.softeng.ox.ac.uk/personal/Ivan.Flechais/downloads/icges.pdf
30
http://dl.acm.org/citation.cfm?id=1090946.1091271
31
http://www-
128.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_
TP026B.pdf
32
http://www.asq.org/pub/sqp/past/vol9_issue1/sqpv9i1schneider.pdf

Metodologas agiles

Los mtodos giles se caracterizan por lograr la satisfaccin del cliente a travs de
entregas rpidas y frecuentes de software utilizable (es decir, iteraciones cortas). Se
caracteriza por utilizar un modelo de desarrollo iterativo, con aceptacin de cambios en
los requisitos finales, integracin del cliente en el proceso de desarrollo, desarrollo
paralelo de varias versiones y equipos de la organizacin autnomos.

Es un modelo que no sigue el mtodo tradicional lineal: requisitos, diseo, codificacin,
pruebas, despliegue y operacin y mantenimiento. Se caracteriza por el Manifiesto
gil cuyo nico objetivo principal es: producir softwar e correcto
funcionalmente lo ms rpido posible.

Por esta razn, los mtodos giles evitan ciertas actividades del ciclo de vida:
Anlisis de impacto en la seguridad, tras cambios en un requisito funcional.
No involucran directamente en la produccin de software, la documentacin y
validacin necesarias en la mayora de las evaluaciones de seguridad.
Las prcticas de seguridad no se puede llevar a cabo por los miembros del equipo de
desarrollo, simultneamente con otras actividades del ciclo de vida.
Requieren conocimientos especializados ms all de lo esperado de los miembros
del equipo de desarrollo. Los mtodos giles no tienen en cuenta la
inclusin de expertos en seguridad.
Centrarse en cualquier otro objetivo que no sea la produccin de software correcto
de forma rpida. Es difcil incorporar otros objetivos no funcionales, tales
como la fiabilidad, confiabilidad y capacidad de recuperacin.
El utilizar mtodos giles para desarrollar software seguro requiere dar cabida a la
inclusin necesaria de prcticas de seguridad y puntos de control.
Restricciones de acceso a los desarrolladores que trabajan en el proyecto, se asume
que todos los desarrolladores son dignos de confianza, y deben tener igualdad de
acceso a todos los desarrollos y artefactos del software, en contra de los
principios de seguridad, como separacin de funciones, privilegios
mnimos y control de acceso basado en roles.

Mucha discusin y debate se ha producido respecto a si es posible que los proyectos de
software utilicen los mtodos giles para producir software seguro, en la tabla
siguiente se resume, para cada principio bsico en el Manifiesto gil [9], su
contribucin u obstruccin al desarrollo de un software seguro.
N Principio Implicacin Explicacin
1
Prioridad principal es satisfacer
al cliente. Esto se debe lograr de
forma temprana y continua a
travs de entrega de software
utilizable.
Obstructiva
A menos que el cliente muestre una
sensibilidad muy alta por la seguridad, se
obviarn las pruebas de seguridad y si se
hacen, no se les asigna tiempo suficiente para
especificar, verificar y probar los requisitos
de seguridad.
2
Se permite el cambio de
requisitos, incluso en la fase ms
tarda del proceso de desarrollo
de procesos. Ventaja competitiva. Obstructiva
A menos que el cliente est dispuesto a
permitir la ampliacin del tiempo necesario
para evaluar el impacto en la seguridad del
software de cada nuevo requerimiento o
cambio y cambiar las restricciones de
seguridad y mitigaciones de riesgo asociados
con cada requisito funcional.
3
Produccin de frecuentes
entregas de software.
Idealmente, varas a la semanas.
Se da preferencia a la reduccin
de los tiempos de entrega.
Obstructiva
A menos que el cliente de mayor prioridad a
la seguridad que a la necesidad de entregas
rpidas.
4
El proyecto es construido en base
al compromiso, motivacin y
participacin de sus componentes
Neutral
Podra ser obstructiva si los componentes del
proyecto ignoran las prioridades de
seguridad.
5
Los clientes, gerentes y
desarrolladores deben colaborar
diariamente, durante todo el
desarrollo del proyecto.
Neutral
Podra ser contributivo si el equipo de
desarrollo contara con expertos de seguridad
y el equipo del cliente incluye la seguridad
como una de sus prioridades
6
Los desarrolladores deben tener
el medio ambiente y apoyo que
necesitan.
Neutral
Podra ser contributivo si el ambiente de
desarrollo incluye herramientas, plataformas,
procesos y prcticas destinadas producir
software seguro
7
La direccin y el cliente confan
en el trabajo hecho por los
desarrolladores. Obstructiva
A menos que los desarrolladores estn
fuertemente comprometidos y sean capaces
de aplicar prcticas de seguridad,
herramientas y hitos de control en el ciclo de
vida.
8
La forma ms eficiente y eficaz
mtodo de transmitir
informacin a los componentes
de un equipo de desarrollo es a
travs de la comunicacin cara a
cara.
Obstructiva
El proceso de garanta de la seguridad del
software se basa en la documentacin de las
evidencias para que poder ser evaluadas
independientemente por expertos externos al
equipo de desarrollo del proyecto.
9
La produccin de programas
tiles es la principal medida del
xito. Obstructiva
Si la validez del software se mira solo desde
el punto de vista de funcionalidades, no se
permitir la realizacin de escaneos de
vulnerabilidades, pruebas de penetracin, o
cualquier otra prueba de seguridad.
10
La agilidad se ve reforzada por la
continua atencin a la excelencia
tcnica y buen diseo.
Contributiva
Especialmente cuando la excelencia tcnica
y buen diseo reflejan una fuerte
experiencia en el compromiso de asegurar el
desarrollo de software
11
Sencillez, que se define como el
arte de maximizar la cantidad de
trabajo no realizado, es esencial
para el xito de proyectos de
software
Contributiva
Si la sencillez es una caracterstica tanto del
diseo como del cdigo del software, ser
ms fcil de analizar su seguridad.
Tabla 4
Principios Manifiesto gil y su relacin con la Seguridad del Software

1.7. Los pilares de la seguridad del software

Introduccin

Gary McGraw en su libro Software Security: Building Security In [16] propone un
mtodo o proceso para ayudar a solucionar el problema de la seguridad del
softwar e en las organizaciones que realizan desarrollos, que requiere un cambio
cultural de sus desarrolladores en lo que respecta sobre todo en lo relativo a NO
anteponer la seguridad respecto de la funcionalidad, independiente del
modelo o tipo del ciclo de vida del software que se est utilizando y basado en tres
pilares fundamentales (figura-21):
Gestin del riesgo
Buenas prcticas de seguridad
Gestin del Conocimiento

La aplicacin de los tres pilares anteriores provocar una mejora paulatina y gradual de
la seguridad de las aplicaciones desarrolladas, de forma efectiva, abordable y rentable.

Pilares de seguridad del software:
Gestin de riesgos
Buenas prcticas
Gestin del conocimiento

Figura 21. Pilares de seguridad de software. Adaptada de [16]

Los mecanismos y servicios de seguridad de red de las TIC ya no protegen
suficientemente una aplicacin de los diferentes riesgos y amenazas a los a que est
expuesta, se hace por tanto necesario el mejorar el Ciclo de Vida de Desarrollo de
Software para producir un software ms seguro y confiable. Lo anterior requiere el
utilizar recursos de aseguramiento de la informacin, de entendimiento del contexto de
operacin y herramientas de auditora que tienen por objeto ayudar a los
desarrolladores, arquitectos y probadores de software a verificar la calidad,
fiabilidad y seguridad del softwar e que producen o adquieren.

Gestin de riesgos

Todos los desarrollos de software en lo que respecta a su seguridad, deberan seguir un
enfoque de gestin de riesgos al objeto de identificar prioridades, asignar recursos y
determinar vulnerabilidades, amenazas a las que se va enfrentar, impactos,
probabilidades y las salvaguardas necesarias para protegerse de las mismas.
Identificando el riesgo mediante tcnicas de anlisis y con la gestin del
mismo se pueden mitigar gran parte de los problemas de seguridad futuros
del softwar e, aunque se debe tener en cuenta que los riesgos cambiarn
inevitablemente a lo largo de todo el SDLC. As mismo la evaluacin de riesgos tambin
puede ayudar a priorizar y enfocar recursos.

Marco gestin de riesgos
Pruebas
basadas en
riesgo
Requisitos
Casos de
abuso
Arquitectura
Diseo
Codificacin
e
integracin
Pruebas
Distribucin
y despliegue
Operacin y
mantenimiento
REALIMENTACIN
Anlisis de
riesgos
Anlisis de
riesgos

Figura 22. Gestin de riesgos a lo largo del SDLC

Durante el ciclo de vida de desarrollo del software, se debe emplear una
combinacin de mtodos y tcnicas de anlisis y un marco de gestin
general de riesgos. Despus de una evaluacin inicial de riesgos, evaluaciones ms
especficas, por ejemplo en la etapa de diseo y arquitectura, pueden determinar qu
componentes del software contribuyen con mayor riesgo, cuales contribuyen a
evitarlos y qu medidas de seguridad deben implementarse para mitigarlos.
El anlisis puede identificar consecuencias potencialmente peligrosas de un ataque con
xito sobre el software, mientras que hacia atrs puede determinar si la hiptesis de un
ataque es creble. En la figura-23 se presenta las diferentes actividades relacionadas con
el anlisis y gestin de riesgos a realizar en las diferentes fases y durante todo el SDLC:

Gestinderiesgos
Todo
el
ciclo
de
vida
Anlisis de riesgos
Requisitos
Diseo y
arquitectura
Verificacin
y validacin

Figura 23. Actividades de gestin y anlisis de riesgos a lo largo del SDLC

Requisitos, al realizar el anlisis y obtener los requisitos de seguridad se han
obtenido bastantes conclusiones acerca de los activos del sistema y del impacto que
los posibles ataques pueden causar, en este sentido tal y como se manifest en el
apartado anterior es de gran utilidad, que los ingenieros de desarrollo
aprendan a pensar como un atacante para poder construir un software
resistente con capacidad de tolerar y recuperarse en caso de ataque.

Arquitectura, en esta fase se especifican todos los activos hardware y software del
sistema en funcin de los requisitos generales y de seguridad, configurando la
arquitectura en funcin de las salvaguardas elegidas para protegerlo lo que implica
el modelado de amenazas y anlisis de la seguridad del diseo.

Verificacin y validacin, que implica la planificacin y realizacin de pruebas
basadas en riesgo y anlisis de los riegos obtenidos de sus resultados.

Ciclo de vida completo, que implica el establecimiento de un proceso de gestin
de riesgos para poder realizar el seguimiento y mitigacin del riesgo como una
actividad ms, Gary McGraw en [16] lo denomina Marco de gestin de
riesgos.

Las medidas de seguridad adicionales descubiertas durante la realizacin del diseo,
implementacin, pruebas y produccin deberan incorporarse de nuevo en la
especificacin de requisitos. Vulnerabilidades seguridad encontradas durante las
pruebas deben ser analizadas para determinar si se origin en el sistema desarrollado o
en el software de base que lo soporta, de forma que sus causas puedan ser corregidas
para eliminar o mitigar su riesgo asociado, en base a una estrategia definida en el
marco de gestin.

Finalmente una vez haya entrado en produccin, anlisis peridicos pueden asegurar el
funcionamiento dentro de niveles aceptables de riesgo o determinar los cambios a
realizar en la especificacin de requisitos, diseo o implementacin para
mitigar o eliminar los riesgos nuevos o hacer frente a nuevos tipos de amenazas. La
informacin utilizada durante un proceso de evaluacin de riesgos de seguridad
incluye:
La naturaleza de las amenazas al software.
Identificacin de todos los activos.
Patrones de ataque.
El tipo de vulnerabilidades que se tienen.
Las salvaguardas necesarias para evitar las amenazas, mitigar los ataques y reducir
las vulnerabilidades.
Impacto o consecuencias del ataque.

Existen varios mtodos o metodologas de anlisis de riesgos que se pueden
aplicar al desarrollo de software:
MAGERIT. Ministerio de Administraciones Pblicas de Espaa MAP su
herramienta de anlisis de riesgos asociada PILAR oficial en la OTAN (Organizacin
del Tratado del Atlntico Norte) y en la Administracin pblica espaola.

Security Risk Management Guide, de Microsoft
33
.

ACSM/SAR (Adaptive Countermeasure Selection Mechanism/Security Adequacy
Review) de SUN.

CIGITAL's architectural risk analysis Process.

33
http://www.microsoft.com/en-us/download/details.aspx?id=6232
European Union-funded Consultative Objective Risk Analysis System (CORAS) and
Research Council of Norway-funded Model-Driven Development and Analysis of
Secure Information Systems (SECURIS). ASSET (Automated Security Self-
Evaluation Tool). National Institute on Standards and Technology (NIST)
34
.

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation). SEI de
la Universidad Carnegie Mellon
35
.

COBIT (Control Objectives for Information and Related Technology) from
Information Systems Audit and Control Association (ISACA)
36
.

PTA Technologies' Calculative Threat Modeling Methodology (CTMM).

Trike. Metodologa de evaluacin de amenazas
37
.

NASA Reducing Software Risk program's Software Security Assessment Instrument
(SSAI).

CRAMM. CCTA Risk Analysis and Management Method. Siemens' and Insight
Consulting's Central Computer and Telecommunications Agency (CCTA)
38
.

En cuanto a la necesidad, tal y como se ha comentado en prrafos anteriores, de un
proceso continuo de gestin de riesgos que abarque todo el ciclo de vida
del softwar e, en [16] se establece un marco de gestin que permite a una
organizacin el identificar, clasificar, comprender y realizar un seguimiento
de los riesgos en el tiempo en el que un proyecto software se desarrolla. En la figura
siguiente se puede ver un diagrama de dicho marco.

34
http://csrc.nist.gov/archive/asset/asset_description.html
35
http://www.sei.cmu.edu/library/abstracts/reports/99tr017.cfm
36
http://www.isaca.org/Education/COBIT-Education/Pages/default.aspx
37
http://www.octotrike.org/
38
http://www.cramm.com/

Comprensin
de contexto
del negocio
Identificacin
de riesgos
negocio y
tcnicos
Sintetizar y
ordenar los
riesgos
Definir
estrategia
mitigacin
riesgos
1 2 3 4
Medicin e Informes
Retroalimentacin
de produccin
5
Contexto del negocio

Figura 24. Marco gestin de riesgos. Extrada de [16]

La aplicacin del proceso de gestin de riesgo, tal y como se indica en la figura-25, se
debe realizar en paralelo a las actividades normales del SDLC. Una actividad
importante de este proceso de gestin son las actividades medicin y mtricas
establecidas para gestionar mejor los riesgos operativos y tcnicos, pues permite tomar
decisiones objetivas en materia de desarrollo del software y mejorar los procesos
internos de desarrollo.

El marco de gestin de riesgos propuesto en [16] se compone de las cinco etapas
fundamentales, mostradas en la figura-25:
Entender el contexto de negocio. La gestin de riesgos, est profundamente
afectada por los objetivos del negocio, prioridades y circunstancias, por tanto la
primera etapa de la gestin de riesgos del software implica la adquisicin del
conocimiento sobre su situacin, organizacin, sistemas de informacin, etc., con el
propsito de identificar ms fcilmente los riesgos tcnicos.

Identificar los riesgos del negocio y tcnicos. Consiste bsicamente en el
descubrimiento y descripcin de riesgos de negocio y tcnicos y su trazabilidad
ecunime a los objetivos de la organizacin, de tal forma que su impacto sea
cuantificado y descrito en trminos de negocio. Los requisitos de seguridad deben
partir de los objetivos del negocio y estar asociado a un riesgo de negocio y esta a su
vez a un riesgo tcnico a gestionar y mitigar.

El impacto de cada uno de los tipos se riesgos de miden de diferente forma:

o Mtricas impactos riesgos de negocio: Se cuantifican de forma econmica o
impacto en la gestin: coste econmico, prdida de cuota de mercado, costes de
reparacin, publicidad negativa, etc.

o Mtricas impactos riesgos tcnicos: Se cuantifican en trminos de la
disponibilidad, integridad y confidencialidad de los servicios TIC que soportan el
objetivo de negocio: tiempo del sistema cado, accesos no autorizados, robos de
informacin, etc.

Sintetizar y priorizar los riesgos, produciendo una lista priorizada.
Consiste en la priorizacin de los riesgos tcnicos identificados en la fase anterior, en
funcin de la importancia de los objetivos y activos afectados y los recursos
disponibles para su mitigacin.

o Mtricas probabilidad o frecuencia de riesgo, usuarios afectados, severidad del
riesgo, explotabilidad, relacin de aparicin de riesgos y mitigados en el tiempo,
reproducibilidad, probabilidad de descubrimiento, etc.

RIESGO = IMPACTO x PROBABILIDAD de OCURRENCIA

Definir la estrategia de mitigacin de riesgos. En base a la lista priorizada de
riesgos obtenida, la siguiente tarea es desarrollar una estrategia de
mitigacin, en base a una serie de parmetros como son: coste, tiempo de
reparacin, viabilidad y proceso de validacin.

o Mtricas retorno de la inversin, efectividad de los mtodos en trminos de
impacto econmico, porcentaje de riesgo cubierto y residual, etc.

Realizar las correcciones necesarias, aplicar salvaguardas y validarlas.
Una vez desarrollada la estrategia de mitigacin, se debe realizar la correccin de
componentes del sistema con defectos arquitectnicos en el diseo, colisiones de
requisitos, errores de autenticacin, errores de cifrado, problemas en pruebas etc.
conforme a la prioridad marcada.

Posteriormente las correcciones realizadas deben ser validadas, mediante un
proceso de validacin repetible, medible y comprobable para verificar que los riesgos
han sido correctamente mitigados por la mejora del componente y que la estrategia
de mitigacin de riesgo funciona.

o Mtricas tanto por ciento de completitud contra la estrategia de mitigacin de
riesgo, progreso de mitigacin de riesgos, riesgos residuales, calidad.

Otro marco de gestin de riesgos en el desarrollado por Microsoft en [29], en la
siguiente figura mostramos un resumen.
Definicin del proyecto
Definicin de limitaciones
Especificacin de requisitos
Requisitos
La valoracin y el anlisis de los
procesos de seguridad
Revisin de la organizacin de la
seguridad
Valoracin de activos y amenazas
Anlisis de vulnerabilidades
Anlisis de riesgos y plan de
mitigacin
Planeamiento
Desarrollo de medidas de
seguridad
Pruebas de componentes
Verificacin de la calidad de las
contramedidas
Codificacin
Pruebas
Polticas de seguridad
corporativas, centralizadas y de
sitio
Despliegue de contramedidas y
componentes de seguridad
Anlisis de riesgos y lecciones
aprendidas
Despliegue y
operacin
Pruebas de las contramedidas de
seguridad
Planificacin y uso de los medios
de prueba
Deteccin de nuevos fallos y bugs

Figura 25. Marco gestin de riesgos de Microsoft

Un aspecto importante de la gestin de riesgos es el establecer un marco de
mtricas de medida que nos pueda dar una idea de cul es el estado de la seguridad
del mi sistema o del software, en concreto se debe medir la informacin sobre riesgos y
su estado durante todas las fases del ciclo de vida. En la referencia [16] se propone la
siguiente serie de medidas a realizar mostradas en la siguiente tabla:

MEDIDAS A REALIZAR EN LA GESTIN DE RIESGOS
Riesgos excepcionales por prioridad.
Riesgos identificados por prioridad.
Riesgos residuales por tipo.
Riesgos identificados por tipo.
Riesgos residuales por subtipo.
Riesgos identificados por subtipo.
Porcentaje del estado de mitigacin del riesgo.
Mitigacin de riesgo por prioridad: porcentaje resueltas y residuales.
Mitigacin de riesgo por prioridad: porcentaje resueltas y residuales.
Nmero de riesgos residuales por impacto econmico.
Nmero de riesgos identificados por impacto econmico.
Nmero de riesgos identificados sin mitigacin definida por prioridad.
Nmero de riesgos identificados sin mitigacin definida por tipo.
Ratio de descubrimiento de riesgo por prioridad.
Ratio de descubrimiento de riesgo por tipo.
Ratio de mitigacin de riesgo por prioridad.
Ratio de mitigacin de riesgo por tipo.
Nmero de riesgos residuales por impacto calculado.
Tabla 5
Medidas gestin de riesgos

Mejores prcticas de seguridad del softwar e

La seguridad del softwar e es algo ms que la eliminacin de las vulnerabilidades y
la realizacin de pruebas de penetracin. Un aspecto importante de la misma, es la
adopcin por los gerentes de un enfoque sistmico para incorporar principios de
buenas prcticas de Seguridad del Softwar e touchpoi nt en su Ciclo de
Vida de Desarrollo de Software, para lograr el doble objetivo de producir sistemas
con softwar e ms seguro y poder verificar su seguridad, a este nuevo ciclo
de vida le denominaremos ciclo de vida del softwar e seguro S-SDLC.
4. Anlisis de
riesgos
7. Revisin
cdigo
11.
Revisin
externa
6. Pruebas
basadas en
riesgo
1. Modelado
de ataques
Requisitos
Casos de
abuso
Arquitectura
Diseo
Codificacin
e
integracin
Pruebas
Distribucin
y despliegue
Operacin y
mantenimiento
8.
Configuracin
segura
2. Casos
de abuso
3. Ing.
Requisitos
seguridad
5. Patrones
de diseo
9. Test
penetracin
10.
Operaciones
seguridad
REALIMENTACIN

Figura 26. Mejores prcticas de seguridad del software en el SDLC. Adaptada de [16]

La figura anterior, propone un ciclo de vida de desarrollo de software SDLC en cascada
basado en el modelo de McGraw [16], para otro tipo como los iterativos sera similar,
donde se especifican las actividades y pruebas de seguridad a efectuar en cada fase del
mismo, en el siguiente apartado se muestran diferentes tipos de S-SDLC adoptados por
diferentes empresas y organizaciones. A continuacin se enumeran esas actividades o
mejores prcticas de Seguridad del Software tomando como referencia las definidas en
[16] al que se le aaden otras (en el tema 2 se desarrollan en mayor profundidad estas
prcticas):
Casos de abuso. Constituyen otra forma de representar la mentalidad del atacante
en base a la descripcin del comportamiento del sistema bajo un ataque. El diseo
de casos de abuso requiere explcita cobertura de lo que debera ser
protegido, de quin y por cunto tiempo.

Ingeniera requisitos de seguridad. La seguridad de un sistema y el software
que lo soporta debe especificarse en base a unos requisitos de obligada
implementacin y trazabilidad durante todas las fases del diseo. Estos requisitos
pueden ser extrados del anlisis de riesgo realizado, los casos de uso y abuso.

Anlisis de riesgo arquitectnico. Es una necesidad en la etapa de arquitectura
y diseo la realizacin de un anlisis del riesgo arquitectnico que documente los
posibles riesgos de la arquitectura y diseo e identifiquen las posibles amenazas.

Patrones de diseo. Son soluciones generales repetibles a un problema de
ingeniera de software recurrente, destinadas a obtener un software menos
vulnerable y un diseo ms resistente y tolerante a los ataques, normalmente se
limitan a funciones y controles de seguridad a nivel del sistema, comunicaciones e
informacin.

Pruebas de seguridad basados en riesgo. Consiste en el planeamiento y
realizacin de pruebas de verificacin y validacin de los diferentes componentes y
del sistema completo, en base al conocimiento de la arquitectura del software, los
resultados del anlisis del riesgo, casos de abuso y patrones de ataque como forma
de incluir la mentalidad del atacante, al objeto de comprobar el estado de seguridad
y la no ocurrencia de funcionamientos incorrectos.

Modelado de ataques. Los patrones de ataque constituyen un mecanismo o
medio para capturar y representar la perspectiva y conocimiento del ciberatacante
con el suficiente detalle acerca de cmo los ataques se llevan a cabo y los mtodos
ms frecuentes de explotacin (exploit) y tcnicas usadas para comprometer el
software.

Revisin de cdigo. La revisin de cdigo es una de las actividades de
seguridad ms importantes a realizar durante el SDLC, pues puede
destapar alrededor del 55% de los problemas de la seguridad. las herramientas
estticas de anlisis de cdigo de fuente pueden descubrir a nivel del cdigo fallos de
implementacin y vulnerabilidades comunes. Sin embargo aunque es una prctica
muy importante no es suficiente pues por ejemplo, lo problemas arquitectnicos son
muy difciles e incluso imposibles de encontrar revisando solamente el cdigo, sobre
todo los que tienen cientos de miles de lneas de cdigo. Lo anterior implica que
el combinar la revisin de cdigo y anlisis de riesgos arquitectnico
aumenta en gran medida la seguridad del softwar e.

Test penetracin. Son pruebas cuyo principal objetivo es obtener una idea de
cmo se comporta el software en su entorno de ejecucin final, siempre que se
realicen en un entorno que simule perfectamente el entono de produccin donde la
aplicacin o sistema prestar sus servicios y que el software presente su arquitectura
final. Son extremadamente tiles especialmente si precede de un anlisis de riesgo
arquitectnico y plan de pruebas basadas en riesgo. Un fallo en este tipo de pruebas,
realizadas con herramientas de prueba dinmicas de seguridad en tiempo de
ejecucin, significa que el sistema o el software es deficiente.

Operaciones de Seguridad. Como se ha indicado anteriormente un principio de
diseo importante para la seguridad es la defensa en profundidad, el sistema
hay que protegerlo como un todo, por un lado hay que minimizar al mximo sus
vulnerabilidades y disearlo de forma resistente para que sea de confianza, por otro
hay que securizar su entorno de ejecucin y de red al objeto de que la va de ataque
al mismo se deba a su interaccin con el software de base (sistema operativo,
gestores de base de datos, etc.) y que las acciones maliciosas se puedan detectar en
base al trfico de red. En todo esto proceso son fundamentales las habilidades,
experiencia adquirida de ataques producidos y conocimiento del personal de
administracin de la red, sistemas y seguridad.

Revisin externa. La revisin de la seguridad de los sistemas es conveniente que,
aparte de la realizada por el personal interno, se realice por otro externo ajeno al
equipo de diseo y desarrollo pues aporta otra visin de la seguridad del sistema y
del riesgo y contribuye a mejorar la seguridad al descubrir amenazas y riesgos
residuales existentes, que pueden pasar desapercibidos al equipo interno. Una vez
finalizados, en funcin de los resultados obtenidos habr incluso que revisar el
anlisis de riesgos y su gestin, incorporar nuevas amenazas e incluso modificar las
especificaciones del sistema.

Al igual que la gestin de riesgos, las actividades o buenas prcticas presentadas
anteriormente hay que realizarlas de forma continua a lo largo de las
diferentes iteraciones del ciclo de vida, conforme se descubren nuevas amenazas,
se introducen cambios o nuevos componentes, se reparan defectos o bugs detectados,
hay que rehacer el anlisis de riesgos con nuevos casos de abuso asociados, e
incluso se pude llegar a tener que modificar las especificaciones del sistema.

Gestin del conocimiento

Se puede definir el conocimiento como:

Conjunto de informacin de contexto obtenida de la experiencia o el aprendizaje de la
puesta en prctica de procesos y procedimientos para alcanzar ciertos objetivos
prcticos, se trata de la posesin y acumulacin de mltiples datos relacionados entre
ellos, que poseen un valor cualitativo mayor que por s solos, que proporcionan
informacin que se puede incorporar en el desarrollo o mejora de nuevos productos y
procesos.

Aparte de la generacin del conocimiento, para ponerlo en valor es necesario
gestionarlo, una de las actividades ms importante hoy en da en las organizaciones es
la gestin de conocimiento, bsicamente consiste en los procesos que la
planifican, controlan, recogen, transfieren, aseguran, aplican o usan y administran de
una forma sistemtica la informacin obtenida de la actividad diaria de la organizacin,
junto con los sistemas o programas diseados para gestionar el uso de ese
conocimiento, al objeto de perfeccionar la ejecucin de los procesos de la
organizacin.

En lo relativo a la seguridad del software, la gestin del conocimiento es cclica y su
principal papel es condensar y difundir las buenas prcticas de seguridad del software,
los principios de seguridad del diseo y disciplinas de codificacin, para conseguir
software ms seguro y confiable. En el documento de referencia [16] se indica que el
conocimiento aplicado a la seguridad del software abarca tres reas:
Conocimiento descriptivo. Ofrece consejos sobre lo que hacer o evitar cuando se
construye software seguro. Abarca tres catlogos:

o Principios. Un principio es una declaracin de la sabidura que se deriva de la
experiencia. Los principios son tiles tanto para el diagnstico de fallos de la
arquitectura de softwar e como para la prctica de una buena
ingeniera de seguridad.

o Gua. Una gua es una recomendacin sobre qu hacer o evitar durante el
desarrollo de software, se describen en el plano semntico y pueden ayudar a
descubrir defectos arquitectnicos y de la aplicacin. Existen directrices para un
contexto tcnico especfico (por ejemplo, J2EE, NET, etc.).
o Reglas. Es una recomendacin sobre qu hacer o evitar durante el desarrollo de
software, que se describe en el plano de la sintaxis, que puede ser verificada a
travs de anlisis lxico o anlisis constructivo de software (fuente o binario) y
pueden ayudar a descubrir errores de implementacin. Existen reglas para
lenguajes de programacin especficos (por ejemplo, C, C + +, PHP, Java, etc.).

Conocimiento diagnstico. Ayudan a reconocer y familiarizarse con problemas
comunes que se derivan en ataques contra la seguridad, muy til para los analistas
de seguridad. Incluye tres catlogos de conocimiento:

o Patrones de ataque. Los patrones de ataque constituyen un mecanismo o
medio para capturar y representar la perspectiva y conocimiento del
ciberatacante con el suficiente detalle acerca de cmo los ataques se llevan a cabo
y los mtodos ms frecuentes de explotacin (exploit) y tcnicas usadas para
comprometer el software.

o Exploi ts. Es una instancia particular de un ataque a un sistema informtico que
aprovecha una vulnerabilidad especfica o un conjunto de ellas.

o Vulnerabilidades. Es un fallo de programacin, configuracin o diseo que
permite, de alguna manera, a los atacantes alterar el comportamiento normal de
un programa y realizar algo malicioso como alterar informacin sensible,
interrumpir o destruir una aplicacin o tomar su control.
Conocimiento
seguridad del softwar e
Conocimiento
diagnstico
Conocimiento
histrico
Conocimiento
descriptivo
Principios
Guas
Reglas
Requisitos y diseo y
arquitectura
Requisitos
Diseo arquitectura
Codificacin
Codificacin
Patrones de
ataque
Exploit
Vulnerabilidades
Requisitos, diseo
Plan de pruebas y test
penetracin
Pruebas: test de penetracin
Produccin
Diseo arquitectura y software
Codificacin, test de
penetracin y produccin
Catlogos
Diseo de software y
arquitectura

Figura 27. Catalogo del conocimiento de la seguridad del software

Conocimiento histrico. Incluye el conocimiento de catlogos de riesgos
histricos y, en algunos casos, vulnerabilidades p.ej., la coleccin en el CVE.
El conocimiento de seguridad de software es conveniente aplicarlos en todas las
fases del SDLC y una forma eficaz de hacerlo es emplear las mejores prcticas de
seguridad de software touchpoints tal y como se puede ver en la figura 31. Por
ejemplo, las reglas son sumamente tiles para el anlisis esttico y actividades de
inspeccin de cdigo.
1. Revisin
cdigo
2. Anlisis
riesgos
4. Pruebas
basadas en
riesgo
3. Pruebas
penetracin
Requisitos
Casos de
abuso
Arquitectura
Diseo
Plan de
pruebas
Codificacin
Pruebas y
resultados
Realimentacin
de produccin
7. Operaciones
Seguridad
2. Anlisis de
riesgos
5. Casos
de abuso
6. Requisitos
seguridad
8. Revisin
externa
Principios
Guas
Riesgos
histricos
Patrones
ataque
Reglas
Vulnerabilidades
Exploits

Figura 28. Relacin de los catlogos conocimiento de seguridad de software y las mejores
prcticas de seguridad de software. Extrada de [16]

Otro aspecto importante es la formacin del equipo de diseo, anlisis, integracin y
desarrollo, pues todos los procesos, prcticas, tecnologas y herramientas de seguridad
del software sern de poca utilidad si el personal responsable ponerlos en prctica y
usarlas no disponen de los conocimientos necesarios. En este sentido algunas
organizaciones han establecido programas de certificacin profesionales para
desarrolladores de software que disponen pruebas que evalan y certifican los
conocimientos en desarrollo de software seguro.

Esta formacin debera incluir como mnimo en su alcance especificacin, diseo e
implementacin de software confiable, modelado de ataques, anlisis de
vulnerabilidades, debilidades de la arquitectura y diseo. A continuacin se muestra
una lista de las certificaciones internacionales profesionales disponibles en el mbito de
la seguridad del software.

Certified Secure Software Lifecycle Professional (CSSLP)
39
. Es una
certificacin CISSP que abarca una visin integral de todo el proceso de desarrollo
de software. Al igual que el CISSP, la CSSLP evala la amplitud de conocimiento en
vez de profundizar en una zona determinada.

SANS Software Security Institute
40
GIAC Secure Programmer certifications.

International Council of Electronic Commerce Consultants (EC-Council) Certified.
Secure Programmer (CSP) and Certified Secure Application Developer
(CSAD)
41
certifications.

International Institute of Training, Assessment, and Certification Certified
Secure Software Engineering Professional certification.

En Espaa tenemos:
Mster Universitario en Seguridad informtica Universidad Internacional de
la Rioja (UNIR)
42
.

1.8. Metodologas y estndares

Introduccin

Las metodologas y estndares, consisten bsicamente en guas de comportamiento
especficas destinadas a aplicar una poltica o polticas. Su aplicacin a la
seguridad del software consiste en el desarrollo de procesos que implementen tcnicas
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
estndar de aseguramiento de la calidad de softwar e y un estndar de
seguridad.

39
https://www.isc2.org/csslp-certification.aspx
40
http://software-security.sans.org/
41
http://www.eccouncil.org/ecsp/index.htm
42
http://www.unir.net/master-online-seguridad-informatica.aspx
Las organizaciones relacionadas con normas internacionales sobre seguridad de la
informacin son:
International Organization for Standardization (ISO).
International Electrotechnical Commission (IEC).
National Institute of Standards and Technology (NIST).

A continuacin se realiza una descripcin resumida de los estndares ms 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 aclaracin de las diferencias entre seguridad del software versus
aseguramiento de la calidad.

Seguridad del softwar e ver sus aseguramiento de la calidad

Antes de comenzar con las actividades y medidas de seguridad a integrar en el SDLC, es
conveniente aclarar las principales diferencias entre aseguramiento de la calidad y
seguridad del software:
Aseguramiento de la Calidad su principal objetivo es hacer que el software
funcione correctamente conforme a las especificaciones del mismo.
Seguridad del softwar e tiene por objetivo que tanto el software como su entorno
de ejecucin presenten el mnimo 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 tambin en trminos de amenazas, las
principales de la calidad son internas no intencionadas debidas a errores o
descuidos, es decir la presencia de defectos en el software que pongan en peligro su
capacidad de funcionar correctamente y de manera previsible.

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

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, diseo y verificacin de la seguridad del software, en base a los
riesgos estimados de forma que el proceso de garanta de calidad incorporare algunas
actividades de su gestin y nuevos procedimientos relacionados con la seguridad.

Estndares de aseguramiento de la calidad

Estndares de calidad

o ISO/IEC JTC1 SC7. Ingeniera de software y de sistemas.
o ISO 9126. Calidad del producto.
o ISO 14598. Evaluacin de productos de software.
o ISO 12119. Requerimientos de calidad y prueba de COTS.
o ISO 15939. Proceso de medicin de software.
o ISO 9000. Familia de normas son normas de calidad establecidas por la ISO.
UNE-EN ISO 9000. Sistemas de gestin de la calidad. Fundamentos y
vocabulario (ISO 9000:2000).
UNE-EN 150 9000. Sistemas de gestin de la calidad. Requisitos (ISO
9001:2000).
UNE-EN 150 9000. Sistemas de gestin de la calidad. Directrices para la mejora
del desempeo (ISO 9004:2000).

Modelos calidad del softwar e

o El CMM - CMMI (Capability Maturity Model) es un modelo de calidad del
software que clasifica a las organizaciones en cinco niveles en funcin de la
madurez de los procesos que se realizan para producir software. Establece un
conjunto de prcticas o procesos clave agrupados en reas con un conjunto de
buenas prcticas:

Definidas en un procedimiento registrado.
Provistas de los recursos y conocimiento necesarios.
Ejecutadas de un modo sistmico, universal y uniforme.
Medidas.
Verificadas.
En la siguiente tabla se puede ver el alcance de dichos niveles.

NIVEL
MADUREZ
ALCANCE
Nivel 1 Inicial. Empresas que no tienen procesos.
Nivel 2
Repetible. El proyecto es gestionado y controlado durante
el desarrollo del mismo.
Nivel 3
Definido. Gestin e ingeniera de proyectos est
establecida, documentada y existen mtricas de
consecucin de objetivos.
Nivel 4
Definido. Proyectos usan objetivos medibles para alcanzar
las necesidades de los clientes y la organizacin.
Nivel 5
Gestionado. Los procesos de los proyectos y organizacin
orientados a la mejora de las actividades.
Tabla 6
Alcance niveles CMM-CMMI

o ISO/IEC 12207. Modelos de Ciclos de Vida del Software, define los procesos del
ciclo de vida adquisicin, suministro, mantenimiento y operacin de los sistemas
de software.

o ISO/IEC 15504 SPICE (Software Process Improvement and Capability
Determination). Modelo para la mejora y evaluacin de los procesos de desarrollo
y mantenimiento de sistemas y productos de software

Estndares de Seguridad

ISO / IEC 15026: 2006. Norma que incorpora un caso de seguridad para
asegurar que los objetos del software expuestos a posibles amenazas son de
confianza, es decir que garantizan todas las propiedades de seguridad (integridad,
disponibilidad y confidencialidad). El caso de seguridad se considera como un
artefacto ciclo de vida e incluye o especifica cmo debe ser definido, mantenido y
revisado todo el ciclo de vida del sistema o software. Define los siguientes procesos
del ciclo de vida:
o
Planificar las actividades de aseguramiento.
o
Establecer y mantener la seguridad.
o
Supervisar las actividades de control y de garanta.
En la figura siguiente se muestra la relacin entre las actividades del ciclo de vida de
la norma y las actividades de gestin de riesgos de seguridad a las que la norma debe
proporcionar apoyo.

Figura 29. ISO / IEC 15026 relacin entre las actividades del ciclo de vida de la norma y las
actividades de gestin de riesgos de seguridad. Extrada de [17]

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
Ingeniera de Seguridad de Sistemas es un modelo derivado del CMM y que
describe reas de ingeniera de seguridad y las caractersticas esenciales de los
procesos que deben existir en una organizacin para la mejora y evaluacin de la
madurez de la ingeniera de los procesos de seguridad utilizados para producir
productos de sistemas confiables y seguros. El alcance de los procesos incluidos en la
norma abarcan todas las actividades del ciclo de vida del sistema e ingeniera de
seguridad, incluyendo la definicin conceptual, anlisis de requisitos, diseo,
desarrollo, integracin, instalacin, operacin, mantenimiento y baja.

Actividades
gestin de
riesgos
Actividades de
medidas
2. Plan
actividades
aseguramiento
4. Monitorizar
las actividades
de
aseguramiento y
productos
3. Establecer y
mantener el
Caso Seguridad
Procesos de Gestin
Tcnicos
D
a
t
o
s

M
e
j
o
r
a

Procesos del ciclo de
vida Expectativas y
Resultados
Plan aseguramiento
Caso Seguridad
Aseguramiento
Necesidades
Plan Aseguramiento
Informacin Riesgos
Caso Seguridad
Medidas Seguridad
Medidas Seguridad
Pretende servir como:
o Herramienta de evaluacin de las prcticas de ingeniera de seguridad y mejora
continua de las mismas.
o Mecanismo o mtodo estndar de evaluacin de la capacidad de los proveedores
de ingeniera de seguridad por los clientes. Indica la necesidad mtrica, pero no
indica ninguna.
o Base para la implantacin de un mecanismo de evaluacin y certificacin El
mtodo de evaluacin se denomina SSAM (SSE-CMM Appraisal Method). Las
tcnicas de evaluacin pueden ser utilizadas en la aplicacin del modelo para la
seleccin de proveedores.

Define veintids reas de Proceso (PA) de seguridad que enmarcan los objetivos y
los mecanismos que se utilizarn para la coordinacin de las actividades de
ingeniera de seguridad con todas las dems actividades de ingeniera y equipos:

o Dominio: Once reas de procesos de ingeniera seguridad, sesenta practicas.
o Capacidad: Once reas dedicadas a la gestin de proyectos y organizacin.

Figura 30. Arquitectura del modelo SSE-CMM, norma ISO/IEC 21827:2002.
Extrada de http://www.revistasic.com/revista75/articulo05_75.htm

En la tabla siguiente se pueden ver las reas de Proceso (PA) de ingeniera
seguridad y su propsito:

AREA DE PROCESOS OBJETIVOS
1. Administrar los controles
de seguridad
Asegurar que los controles de seguridad estn
correctamente configurados y operados.
2. Evaluar el impacto
Alcanzar un entendimiento de los riesgos de seguridad
asociados con la operacin del sistema dentro de un
ambiente de operacin o produccin definido.
3. Evaluar riesgos de
seguridad
Identificar las vulnerabilidades del sistema y determinar
su potencial de explotacin.
4. Valoracin de la amenaza
Alcanzar un entendimiento de las amenazas a la seguridad
del sistema.
5. Valoracin vulnerabilidades
Alcanzar un entendimiento de las vulnerabilidades de
seguridad del sistema.
6. Construir argumentos
seguridad
Asegrese de que los artefactos y procesos de trabajo
claramente proporcionan la evidencia de que las
necesidades del cliente relativas a la seguridad se han
cumplido.
7. Coordinar la seguridad
Asegrese de que todos los miembros del equipo del
proyecto son conscientes y participan en las actividades de
ingeniera de seguridad en la medida que son necesarios
para desempear sus funciones, coordinar y comunicar
todas las decisiones y recomendaciones relacionadas con
la seguridad.
8. Monitorizacin seguridad
Deteccin y seguimiento de los incidentes internos y
externos relacionados con la seguridad, responder a los
incidentes de acuerdo con la poltica, identificar y
controlar los cambios de la poltica de seguridad en
conformidad con los objetivos de seguridad.
9. Seguridad en la entradas
Revisin de seguridad de todas entradas del sistema con
consecuencias para la seguridad, resolver los problemas de
acuerdo a los objetivos de seguridad y garantizar que todos
los miembros del equipo del proyecto entienden la
seguridad para que puedan desempear sus funciones.
Garantizar que la solucin refleja las aportaciones de
seguridad proporcionada.
10. Especificar las necesidades
de seguridad
Aplicables a todas las partes, incluido el cliente, llegar a
una comn comprensin de las necesidades de seguridad.
11. Verificar y validar la
seguridad
Asegurar que las soluciones satisfacen todas sus
necesidades de seguridad y operativas de los clientes de
seguridad.
Tabla 7
SSE-CMM reas de Procesos de ingeniera seguridad sus metas y objetivos. Extrada de [17]

Developing Software Project Life Cycle Processes Norma IEEE 1074-
2006. Norma que proporciona soporte para la priorizacin e integracin de
controles de seguridad en el software y sistemas. Incluye medidas de seguridad en el
SDLC como el anlisis de riesgos de seguridad y define un perfil de seguridad para la
evaluacin de la integridad del software, as como la documentacin necesaria para
garantizar las medidas de seguridad.
Proporciona un enfoque sistemtico para la definicin especfica de requisitos de
seguridad y produce artefactos de seguridad y calidad para cada actividad, as como
la auditora, mejora, mantenimiento de producto y del proceso de seguridad.
Tambin define la intensificacin de las actividades de capacitacin en seguridad.

Information TechnologySecurity Techniques. ISO/IEC TR 15443.
Norma gua de los profesionales de las tecnologas de seguridad en la seleccin de un
mtodo de aseguramiento cuando se especifica, selecciona o se desarrolla un servicio
de seguridad, producto o factor de entorno, como organizacin o personal. El
objetivo es comprender el tipo de garanta y los recursos necesarios para lograr un
producto final confiable, que cumpla los requisitos seguridad. El marco incluye una
clasificacin del aseguramiento y un modelo genrico del ciclo de vida para
identificar el tipo de aseguramiento necesario para el desarrollo en lo que respecta al
desarrollo del ciclo de vida. El modelo tambin demuestra cmo la garanta de la
seguridad debe ser gestionada a lo largo del ciclo de vida de desarrollo, que
requieren decisiones en cada una de sus etapas para su organizacin.

Proporciona a los administradores y otros profesionales de la seguridad
responsables de la elaboracin de un programa de garanta de seguridad, o de
desarrollo de ingeniera de seguridad un proceso o marco de direccin, que implica
el garantizar la seguridad de estos programas o desarrollos, mediante auditoras de
evaluacin (por ejemplo, ISO 9000, SSE-CMM (ISO/IEC 21827), ISO / IEC 15408-
3), u otras actividades de aseguramiento.

ISO / IEC 24772. Proyecto 22, grupo de trabajo para evitar vulnerabilidades en
lenguajes de programacin proporcionando una orientacin a los programadores
sobre cmo evitar las vulnerabilidades que se pueden introducir en el software al
utilizar ciertas caractersticas de un lenguaje de programacin seleccionado para el
desarrollo de un proyecto software, sugiriendo alternativas de patrones de
codificacin que las eviten. As mismo ayuda a elegir las herramientas de anlisis
esttico, deteccin de vulnerabilidades y orientacin de codificacin para mejorar la
eficacia en la reduccin de vulnerabilidades.

ISO/IEC 17799 Information technologySecurity techniquesCode of
practice for information security management. Referencia de la seguridad de
la informacin estndar y aceptada internacionalmente, fue desarrollada como
resultado de la demanda de la industria, el gobierno y el comercio Cdigo de
buenas prcticas para la Gestin de la Seguridad de la Informacin,
proporciona marco comn para permitir a las organizaciones desarrollar, aplicar y
medir eficazmente la gestin de la seguridad de la informacin dirigidas a los
responsables de iniciar, implantar o mantener la seguridad de una organizacin. La
seguridad de la informacin se define en el estndar como: Seguridad de la
informacin: preservacin de la confidencialidad (asegurando que solo
quienes estn autorizados pueden acceder a la informacin), integridad
(asegurando que la informacin y sus mtodos de proceso son exactos y completos)
y disponibilidad (asegurando que los usuarios autorizados tienen acceso a la
informacin y a sus activos asociados cuando lo requieran).

Su objetivo es proporcionar una base comn para desarrollar normas de seguridad
dentro de las organizaciones para proteger adecuadamente los activos de
informacin que aseguren la continuidad del negocio, siendo una prctica eficaz de
la gestin de la seguridad.

El estndar se organizan en los siguientes dominios de control o buenas prcticas
de proteccin para cubrir todos los puntos que los responsables de la gestin de la
seguridad deben tener en cuenta:
o Poltica de seguridad de la informacin. Soporte a la gestin de la poltica
de seguridad de la informacin
o Organizacin de la seguridad de la informacin. Definicin de los roles y
sus responsabilidades de cada elemento encargados de la seguridad en la
organizacin
o Gestin de activos de informacin. Clasificacin y proteccin de los activos
de la organizacin.
o Seguridad de los recursos humanos. Concienciacin de los usuarios y
reduccin de sus errores al mnimo.
o Seguridad fsica y ambiental. Evitar accesos no autorizados y proteccin
frente a incidentes o catstrofes de carcter ambiental.
o Gestin de las comunicaciones y operaciones. Proteger y asegurar las
comunicaciones y operaciones crticas de la organizacin.
o Control de accesos. Evitar accesos lgicos no autorizados a la informacin de
la organizacin.
o Adquisicin, desarrollo y mantenimiento de sistemas de informacin.
Realizacin de todas las etapas (requisitos, diseo y arquitectura,
implementacin, etc.) de un SDLC de un software o sistema incluyendo buenas
prcticas de seguridad.
o Gestin de continuidad del negocio. Implantacin de medidas organizativas
y tcnicas de recuperacin y planes de continuidad en la organizacin y gestin de
incidentes en la seguridad de la informacin.
o Conformidad. Implantar planes de auditora interna para detectar desviaciones
con respecto a la poltica de seguridad de la informacin y normas aplicables
(LOPD, etc.) valorando su nivel de adecuacin, implantacin y gestin de cada
control de la norma en la organizacin: seguridad lgica, fsica, organizativa y
legal.

Figura 31. Pirmide de los dominios de control de la seguridad de la informacin. Extrada de
http://cxo-community.com.ar/articulos/blogs/blogs-metodologia-legislacion/4811-la-leyenda-iso-
17799-la-seguridad-de-los-activos-de-informacion-parte-2.html

Dentro de cada seccin, se especifican los objetivos de los distintos controles para la
seguridad de la informacin y una gua para su implantacin, en total 36. De estos
de derivan 127 prcticas, procedimientos o mecanismos que reducen el nivel de
riesgo, aunque cada organizacin debe considerar previamente cuntos sern
realmente los aplicables segn sus propias necesidades, pues unos tienen ms
relacin con las polticas estratgicas de la organizacin, otros en actividades de
supervisin y control y los restantes aplican actividades de operacin del da a da.

La adopcin de la norma ISO 17799 proporciona diferentes ventajas a una
organizacin:
o Marco efectivo de la gestin de la seguridad.
o Aumento del nivel de seguridad los activos y sistemas de informacin de la
organizacin.
o Implantacin de procesos de mejora continua.
o Implantacin de medidas de continuidad del negocio.
o Implantacin procesos de auditora interna para obtener un estado de la
seguridad de la organizacin.

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 comn 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 superacin 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 ms fcilmente cundo
un producto cumple una serie de requisitos pues exige a los fabricantes de los
productos certificados publicar una documentacin exhaustiva sobre la seguridad de
los productos evaluados por laboratorios independientes.

En lo relativo a la seguridad del software, los niveles EAL ms altos poseen un nivel
de garanta de evaluacin que captura un conjunto especfico de requisitos de
seguridad, de los que es posible deducir algunas propiedades generales que el
software debe exhibir para alcanzarlos:

o EAL 5: El sistema debe ser semiformalmente diseado y probado basado en un
modelo formal y una presentacin semiformal de la especificacin funcional y el
diseo de alto nivel, de forma que las vulnerabilidades resistan relativamente a
los ataques de penetracin. Esta propiedad tambin se aplica al diseo de
software.
o EAL 6: Igual que EAL 5 y adems el diseo debe ser semiformalmente verificado.
Como el anterior, este establecimiento tambin debe aplicarse al diseo de
software.
o EAL 7: Igual que EAL 6, ms el diseo debe ser verificado oficialmente y
formalmente testeado. Como el anterior, este establecimiento tambin debe
aplicarse al diseo de software.

1.9. Referencias

[1]. Alexander Ivanov Sotirov (2002). Automatic vulnerability detection using static
source code analysys.

[2]. Mark G. Graff, Kenneth R. van Wyk. (2003). Secure Coding: Principles &
Practices. O'Reilly, Pub.

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

[4]. INTECO. (2011). Cuaderno de notas del Observatorio Qu son las
vulnerabilidades del software?

[5]. MITRE. (2012). CVE Introductory Brochure. A brief two-page introduction to the
CVE Initiative. Febrero 2012. Recuperado el 27 de marzo de 2013 de:
http://makingsecuritymeasurable.mitre.org/docs/cve-intro-handout.pdf

[6]. MITRE. (2012). CWE Introductory Brochure A brief two-page introduction to the
CWE initiative. Recuperado el 27 de marzo de 2013 de:
http://makingsecuritymeasurable.mitre.org/docs/cwe-intro-handout.pdf

[7]. MITRE. (2011). CWE/SANS Top 25 Most Dangerous Software Errors.
Recuperado el 27 de marzo de 2013 de:
http://www.computerworld.com.pt/media/2011/06/2011_cwe_sans_top25.pdf

[8]. OWASP TOP 10. (2010). Los diez riesgos ms importantes en aplicaciones WEB.
Edicin en espaol. Recuperado el 27 de marzo de 2013 de:
https://www.owasp.org/images/2/2d/OWASP_Top_10_-
_2010_FINAL_(spanish).pdf

[9]. Karen Mercedes Goertzel. (2009). Introduction to Software Security. Edicin en
espaol. Recuperado el 27 de marzo de 2013 de: https://buildsecurityin.us-
cert.gov/bsi/547-BSI.html

[10]. Klocwork Inc. 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.

[11]. SAFECode. (2010). Software Integrity Controls. Assurance-Based approach to
minimizing risks in the software supply chain. Recuperado el 27 de marzo de
2013 de:
http://www.safecode.org/publications/SAFECode_Software_Integrity_Controls
0610.pdf

[12]. Julia H. Allen; Sean Barnum; Robert J. Ellison; Gary McGraw; Nancy R. Mead.
(2008). Software Security Engineering: A Guide for Project Managers. Addison
Wesley Professional.

[13]. Goertzel, Karen Mercedes, Theodore Winograd. (2008). Enhancing the
Development Life Cycle to Produce Secure Software, Version 2.0. United States
Department of Defense Data and Analysis Center for Software.

[14]. Michael Howard, David LeBlanc. (2003). Writing Secure Code. Microsoft Press.

[15]. Michael Howard, Steve Lipner. (2006). The Security Development Lifecycle:
SDL: A Process for Developing Demonstrably Secure Software. Microsoft Press.

[16]. Gary McGraw. (2005). Software Security: Building Security In. Addison Wesley
Professional.

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

[18]. Gua de Seguridad de la STIC (CCN-STIC-400). Manual de Seguridad de las
Tecnologas de la Informacin y Comunicaciones. Centro Criptolgico Nacional.

[19]. Mitchell Komaroff (ASD/NII) and Kristin Baldwin (OSD/AT&L) (2005). DoD
Software Assurance Initiative. Recuperado el 27 de marzo de 2013 de:
https://acc.dau.mil/CommunityBrowser.aspx?id=25749

[20]. National Aeronautics and Space Administration (NASA) (1992). Software
Assurance Standard, Standard No. NASA-STD-2201-93. Recuperado el 27 de
marzo de 2013 de: http://www.hq.nasa.gov/office/codeq/doctree/87398.pdf

[21]. J. R. BERMEJO, G. DAZ. Estudio de Tcnicas Automticas de Anlisis de
Vulnerabilidades de Seguridad en Aplicaciones Web. UNED.

[22]. Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de
Seguridad en el mbito de la Administracin Electrnica. Recuperado el 27 de
marzo de 2013 de: http://www.boe.es/boe/dias/2010/01/29/pdfs/BOE-A-2010-
1330.pdf

[23]. Juan Luis G. Rambla, Jos Mara Alonso Cebrin. (2009). Esquema Nacional de
Seguridad con Microsoft. Microsoft Ibrica S.R.L.

[24]. MITRE. Common Attack Pattern Enumeration and Classification CAPEC A
Community Knowledge Resource for Building Secure Software. Recuperado el
27 de marzo de 2013 de: http://measurablesecurity.mitre.org/docs/capec-intro-
handout.pdf

[25]. Sean Barnum, Amit Sethi. (2007). Attack Patterns as a Knowledge Resource for
Building Secure. Software Cigital, Inc. Recuperado el 27 de marzo de 2013 de:
http://capec.mitre.org/documents/Attack_Patterns-
Knowing_Your_Enemies_in_Order_to_Defeat_Them-Paper.pdf

[26]. Mr. Sean Barnum. (2008)Common Attack Pattern Enumeration and
Classification (CAPEC) Schema Description. Department of Homeland Security
EEUU, Software Cigital. Recuperado el 27 de marzo de 2013 de:
http://capec.mitre.org/documents/documentation/CAPEC_Schema_Descriptio
n_v1.3.pdf

[27]. Zulima, Ortiz Bayon, Francisco Galindo Pulido. (2006). Hacia una Taxonoma de
Incidentes de Seguridad en Internet. Ciencias de investigacin Academia
Desarrollo.

[28]. Sara L.N. RaId, Jens M. Pedersen. (2012). An Updated Taxonomy for
Characterizing Hackers According to Their Threat Properties. Department of
Electronic Systems, Aalborg University, Denmark.

[29]. Microsoft Corporation. (2006). Understanding the Security Risk Management
Discipline. Recuperado el 27 de marzo de 2013 de:
http://www.windowsecurity.com/articles-
tutorials/misc_network_security/Microsoft-Security-Risk-Management-
Guide.html

Apuntesprofesort 1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Apuntesprofesort 1

Hochgeladen von

Copyright:

Verfügbare Formate

El problema de la seguridad

Tema 1: El problema de la seguridad en el softwar e

Tema 1: El problema de la seguridad en el softwar e

Tema 1: El problema de la seguridad en el softwar e

Tema 1: El problema de la seguridad en el softwar e

Tema 1: El problema de la seguridad en el softwar e

Das könnte Ihnen auch gefallen