apuntesprofesort1

El problema de la seguridad en el software

Tema 1

Tema 1: El problema de la seguridad en el software

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

software seguro que funcione en un entorno agresivo y malicioso. El objetivo del

presente tema es introducir al alumno en los principales conceptos que abarca la

seguridad del software, en cuanto a los beneficios que produce, su importancia en la

seguridad global de un sistema, las propiedades de un software seguro, 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 software 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 (CVSS1 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 OSVDB3, 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 (SIEM4), 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 Software, 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 software 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 software 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 software 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 (APT5) uno de los ciberataques ms peligrosos y

dainos de hoy en da. Se hace necesario por tanto el disponer de software 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 software (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

software 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 exploits6 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 MITRE8, 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:

Nmero de cuatro cifras que identifica la vulnerabilidad en el ao.

CVE, seguido del ao en el que se asign el cdigo a 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 tipo de debilidadDescripcin del tipoTrminos alternativos para la debilidadDescripcin del comportamiento de la debilidadDescripcin de la debilidadProbabilidad de explotar la debilidadDescripcin de las consecuencias de la explotacinPosibles mitigacionesOtras debilidades relacionadasTaxonomas de las fuentesEjemplos de cdigo para los lenguajes/arquitecturasIdentificadores de vulnerabilidades CVE para las que ese tipo de debilidad existeReferencias

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 2514 y SANS Top 2015 y otras solo a

aplicaciones web como son OWASP Top 1016 y WASC Threat Clasification v2.017. 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 CAPEC18 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 OpenVas19, 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 software 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 software 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 aplicacinProxy reverso

Mtodos CriptogrficosControl de Acceso Autenticacin Bastionado de las aplicaciones

Bastionado del sistema operativo

AplicacinDatos

Presentacin Datos

Presentacin Datos

SSL/TLSTransporte Segment



Segmentos de redFirewall/IDS/IPSEC/VPN

Red Paquetes

Enlace Tramas

Prevencin Intrusiones Seguridad Fsica Procedimientos seguridad

Plataforma virtualizacinFsico 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 hash20, 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 Harvard22. 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 script 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 scripts 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 TLS23) 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 middleware 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 trasversal, 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 blancas24 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 software 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 software resistente

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

siguiente principio pretende aumentar la resistencia de las aplicaciones reduciendo

al mnimo la cantidad de tiempo que un componente de software

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

apuntesprofesort1

Documents