apuntesprofesort1

Tema 1 El problema de la seguridad en el software

Tema 1: El problema de la seguridad en el s o f t w a r e

Actualmente las tecnologías de seguridad red 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 ingeniería social por ejemplo, y comprometer una máquina del interior, a través de la misma podrá atacar las demás empezando por las más vulnerables. Se hace necesario por tanto el disponer de seguro que s o f t w a r e seguro

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 metodologías aplicables a los procesos de desarrollo seguro de software. Javier Bermejo Higuera

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

Figura 1. Incidentes de seguridad

© Universidad Internacional de La Rioja (UNIR)


En la figura-1 se puede observar un gráfico cualitativo en el que se muestran diversos incidentes ocurridos a lo largo de los últimos doce años en relación con su nivel de complejidad. Como se puede observar la amenaza es creciente con los años y cada vez su nivel de complejidad es mayor. mayor . La sociedad está cada vez más 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 inseguras que pueden ser explotadas por atacantes de diversa índole desde aficionados hasta organizaciones de cibercrimen o incluso estados en acciones de ciberguerra, utilizándolas como plataformas de ataque comprometiendo los sistemas y redes de la organización. Nadie quiere software defectuoso, especialmente los desarrolladores cuyo código incorrecto es el problema, en un informe de Klocwork [10] se indica que las principales causas de la aparición de vulnerabilidades son las siguientes: Tamaño excesivo y complejidad de complejidad de las aplicaciones. Mezcla de código código proveniente de varios orígenes orígenes como compras a otra compañía, reutilización de otros existentes, etc., lo que puede producir comportamientos e interacciones no esperados de los componentes del software. Integración de los componentes del

defectuosa, s o f t w a r e defectuosa,

estableciendo

relaciones de confianza inadecuadas entre ellos, etc. Debilidades y fallos en la especificación de requisitos y diseño no diseño no basados en valoraciones de riesgo y amenazas. Uso entornos de ejecución con componentes con componentes que contienen vulnerabilidades o código malicioso embebido, embebido , como pueden ser capas de middleware, sistema operativo u otros componentes COTS. No realización de pruebas seguridad basadas en riesgo. riesgo . Falta de la herramientas y un entorno de pruebas adecuados adecuados que simule adecuadamente el real de ejecución. Cambios de requisitos del requisitos del proyecto durante la etapa de codificación. Mezcla de equipos de desarrolladores, desarrolladores , entre los que podemos tener, equipos propios de desarrollos, asistencias técnicas, entidades subcontratadas, etc. Falta de conocimiento de prácticas de programación segura segura de los desarrolladores en el uso de lenguajes de programación propensos a cometer errores como C y C++ y utilización de herramientas de desarrollo inadecuadas.



No control de la cadena de suministro del software, software , lo puede dar lugar a la introducción de código malicioso en origen. No seguimiento, seguimiento, por los desarrolladores, de guías de normalizadas de estilo en la codificación. Fechas límite de entrega de entrega de proyectos inamovibles. Cambio en la codificación en codificación en base al requerimiento de nuevas funcionalidades. Tolerancia a los defectos. No tener actualizadas las aplicaciones en producción producción con los parches correspondientes, configuraciones erróneas, etc. Las aplicaciones son amenazadas y atacadas, no solo en su fase de operación, sino que también en todas las fases de su ciclo de vida [9]: Desarrollo. Desarrollo. Un desarrollador puede alterar de forma intencionada o no el software bajo desarrollo de forma que se comprometa su fiabilidad futura durante la fase de operación. Distribución e instalación. instalación. Ocurre cuando no se protege el software evitando manipulaciones antes de enviarlo o publicarlo. Del mismo modo, si el instalador del software no bastiona la plataforma en la que lo instala o la configura de forma

insegura, queda vulnerable a merced de los atacantes. Operación. Operación. Cualquier software que se ejecuta en una plataforma conectada a la red tiene sus vulnerabilidades expuestas durante su funcionamiento. El nivel de exposición variará dependiendo de si la red es privada o pública, conectada o no a Internet, y si el entorno de ejecución del software software ha sido configurado para minimizar sus vulnerabilidades. Mantenimiento o sostenimiento. sostenimiento. No publicación de parches de las vulnerabilidades detectadas en el momento oportuno o incluso introducción de código malicioso por el personal de mantenimiento en las versiones actualizadas del código. Según el informe «2011 Top Cyber Security Risks Report» [3], las vulnerabilidades detectadas en aplicaciones alcanzaron su punto máximo en el año 2006 iniciando a partir de ese año un lento declive, ver figura 2.



Esta disminución de vulnerabilidades detectadas no significa que el software sea cada vez más seguro, es una sensación de seguridad falsa, pues el número de vulnerabilidades de alta severidad está creciendo a un ritmo más rápido que los otros niveles de vulnerabilidad (CVSS1 8 a 10, clasificación definida en la OSVDB) 2. En la figura 3 se pone de manifiesto cómo el porcentaje de vulnerabilidades de alta severidad se ha incrementado en los últimos 10 años.

Figura 2. Vulnerabilidades descubiertas por OSVDB 3, 2000–2011

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

Las vulnerabilidades de alta severidad dan lugar a que un atacante pueda explotarlas rápidamente y hacerse con el control total del sistema. Su explotación requiere un conocimiento poco especializado de la aplicación al alcance, no solo de organizaciones cibercriminales, si no de cualquiera con conocimientos de informática. En el mismo informe anteriormente referido se incluye un gráfico del número de vulnerabilidades por aplicaciones (figura 4) desde el año 2005 hasta el 2011, QuickTime es de manera significativa la más 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 través de fórmulas, proporcionando un estándar para comunicar las características 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) © Universidad Internacional de La Rioja (UNIR)


Figura 4. Número de vulnerabilidades por aplicaciones desde 2005 hasta 2011

Otros aspectos importantes que influyen en el número de vulnerabilidades conocidas de una aplicación son: su complejidad, su extensión en líneas de código y el nivel exposición a los ataques, en este sentido las aplicaciones web en Internet, son las que tienen más probabilidades de ser atacadas y por tanto suelen tener mayor número de vulnerabilidades conocidas. Además erróneamente, a pesar de los datos convincentes de lo contrario, se sigue confiando que la implantación de tecnologías y dispositivos de seguridad de red como cortafuegos, sistemas de gestión y correlación de eventos (SIEM 4), sistemas de detección de intrusos, sistemas de gestión de acceso y cifrado del tráfico, etc., son medidas suficientes para proteger los sistemas de la organización. Los atacantes buscan el descubrimiento de fallos en el software relacionados con la seguridad del sistema, que den lugar a una vulnerabilidad con un impacto y riesgo asociado para la entidad propietaria. En base a lo expuesto anteriormente, se considera la necesidad que las diferentes organizaciones públicas o privadas dispongan de software fiable y resistente a los ataques, es decir de confianza, con número de vulnerabilidades explotables que sea el mínimo posible. En respuesta a lo expuesto anteriormente nace la Seguridad del

S o f t w a r e , en

el

documento de referencia [13] de SAFECode se define como: «La confianza que el software, hardware y servicios están libres de intencionadas o no intencionadas

vulnerabilidades y que funcionan conforme a lo especificado y deseado». 4

Sistema de Centralización y Monitorización de la Información de Eventos y datos infraestructura como, logs, etc. © Universidad Internacional de La Rioja (UNIR)


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

En este sentido, en base a la definición anterior y los párrafos anteriores, se puede definir la seguridad del s o f t w a r e como: El conjunto de principios de diseño y buenas prácticas a implantar en el SDLC, para detectar, prevenir y corregir los defectos de seguridad en el desarrollo y adquisición de aplicaciones, de forma que se obtenga s o f t w a r e de confianza y robusto frente ataques maliciosos, que realice solo las funciones para las que fue diseñado, que esté libre de vulnerabilidades, ya sean intencionalmente diseñadas o accidentalmente insertadas durante su ciclo de vida y se asegure su integridad, disponibilidad y confidencialidad. Hasta principios de la década anterior, la mayoría de las aplicaciones se desarrollaban sin tener en cuenta requisitos y pruebas de seguridad específicos, los desarrolladores de software no eran conscientes de las vulnerabilidades que se pueden crear al programar

y descuidaban los aspectos de seguridad, dando primacía al cumplimiento de las especificaciones funcionales, sin tener en cuenta casos en los que el software fuera maliciosamente atacado. Este proceso de desarrollo de software ofrece, aparte de los errores

no

intencionados

producidos

al

codificar

oportunidades de insertar código malicioso en el s o f t w

anteriormente

referidos,

a r e en origen.

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

5

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



Un aspecto importante de la seguridad del software es la confianza y garantía de funcionamiento conforme a su especificación y diseño y de que es lo suficientemente robusto para soportar las amenazas que puedan comprometer su funcionamiento esperado en su entorno de operación. Para conseguir lo anterior y minimizar al máximo los ataques en la capa de aplicación y por tanto en número de vulnerabilidades explotables , es necesario el incluir la seguridad desde principio en el ciclo de vida de desarrollo del s o f t w a r e (SDLC), incluyendo requisitos, casos de abuso, análisis de riesgo, análisis de código, pruebas de penetración dinámicas, etc., en este sentido es importante el aprovechamiento de las buenas prácticas de ingeniería de s o f t w a r e ya existentes.

Un beneficio importante que se obtendría de incluir un proceso sistemático que aborde la seguridad desde las primeras etapas del SDLC , sería la reducción de los costes de corrección de errores y vulnerabilidades , pues estos son más altos conforme más tarde son detectados. Acorde a lo publicado por NIST (National Institute of Standards and Technology), el coste que tiene la corrección de código o vulnerabilidades después de la publicación de una versión mediante la publicación de un parche, es hasta treinta veces mayor que su detección y corrección en etapas tempranas del desarrollo.

Figura 5. Coste relativo de corrección de vulnerabilidades en función de la etapa de desarrollo. Fuente: http://www.microsoft.com/security/sdl/learn/costeffective.aspx

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



Figura 6. Efectos de la detección de defecto tardía. Fuente: [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 diseño, los ataques a los que se tiene que enfrentar y los estándares de seguridad aplicables a los procesos de desarrollo seguro de software.

1.2. El ciclo de vida de una vulnerabilidad Introducción Una vulnerabilidad es un fallo de programación, configuración o diseño que permite, de alguna manera, a los atacantes alterar el comportamiento normal de un programa y realizar algo malicioso como alterar información sensible, interrumpir o destruir una aplicación o tomar su control. Se puede decir que son un subconjunto del fenómeno más grande que constituyen los bugs de software.



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

Vulnerabilidades:

Fallos de implementa ción Fallos de diseño Fallos de configuración

Figura 7. Tipos de vulnerabilidades del software

Casi todas las vulnerabilidades de seguridad provenientes de fallos de implementación y diseño son bugs de software, pero solamente algunos resultan ser vulnerabilidades de seguridad. Un bug debe tener algún impacto o características 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 máquina.

6

Es una instancia particular de un ataque a un sistema informático que aprovecha una vulnerabilidad específica o un conjunto de ellas. © Universidad Internacional de La Rioja (UNIR)


Una vulnerabilidad se define [4], básicamente, por cinco factores o parámetros que deben identificarla. Producto: productos a los que afecta, versión o conjunto de ellas. Dónde: Componente o módulo del programa donde se localiza la vulnerabilidad. Causa y consecuencia: Fallo técnico concreto que cometió el programador a la hora de crear la aplicación que es el origen de la vulnerabilidad. Impacto: Define la gravedad de la vulnerabilidad, indica lo que puede conseguir un atacante que la explotase. Vector: Técnica del atacante para aprovechar la vulnerabilidad se le conoce como «vector de ataque».

El ciclo de vida de una vulnerabilidad El ciclo de vida de una vulnerabilidad consta de las siguientes fases: Descubrimiento: detección de un fallo en el software que puede producirse durante el desarrollo del mismo o una vez está en producción. Utilización: Los agentes maliciosos desarrollan el exploit adecuado para poder lanzar ataques. Verificación inicial de la vulnerabilidad: una vez se recibe una notificación de error esta será aceptada para su tratamiento comprobando 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. Solución: los programadores del producto buscan solución en entornos controlados. Difusión: los medios de comunicación dan publicidad al incidente. Medidas: si es posible las organizaciones afectadas toman medidas para mitigar las posibles pérdidas. Corrección y nueva verificación: el proceso de corrección de la vulnerabilidad, llevado a cabo por programadores, será verificado nuevamente de manera iterativa hasta comprobar la resolución del error. Búsqueda. Los técnicos buscan vulnerabilidades similares (el ciclo vuelve a comenzar). Actualización: Los sitios no actualizados vuelven a ser víctimas.



Descubrir

Utilización

Verificación

Solución

Difusión

Medidas

Corrección

Búsqueda

Actualiza r

Figura 8. Ciclo de vida una vulnerabilidad

Gestión de vulnerabilidades Dada la gran cantidad de vulnerabilidades descubiertas se hace necesario el disponer de estándares al objeto de poder referenciarlas unívocamente, para conocer su gravedad de forma objetiva y obtener el conocimiento necesario para mitigarlas. Existen varios estándares, catálogos o bases de datos, que a continuación pasamos a comentar: Common Vulnerabilities and Exposures (CVE) 7 [5]. Es un diccionario o catálogo público de vulnerabilidades, administrado por MITRE 8, que normaliza su descripción y las organiza desde diferentes tipos de vista (vulnerabilidades Web, de diseño, implementación, etc.). Cada identificador CVE incluye: o

Identificador con el siguiente formato: CVE-20124212 CVE, seguidodel año en el que se asignóel códigoa la vulnerabilidad.

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

Figura 9. Identificador CVE

7

o

Brece descripción de la vulnerabilidad

o

Referencias

http://cve.mitre.org sin ánimo de lucro, de carácter público que trabaja en las áreas de ingeniería de sistemas, tecnologías de la información, concepto de operación y modernización de empresas. http://www.mitre.org/about/index.html

8 Organización



Common Vulnerability Scoring System (CVSS)9. Es básicamente un sistema que escalona la severidad de una vulnerabilidad, de manera estricta a través de fórmulas, proporcionando un estándar para comunicar las características y el impacto de una vulnerabilidad identificada con su código CVE. Su modelo cuantitativo asegura una medición exacta y repetible a la vez que permite ver características de vulnerabilidad subyacentes que se usaron para generar su puntuación. Permite organizar la priorización de las actividades de remediación o parcheo de las vulnerabilidades. En la figura se muestra el proceso de cálculo de una severidad:

Figura 10. Cálculo puntuación CVSS

El cálculo se realiza en base a tres tipos de métricas base, temporales y ambientales, siendo las dos últimas opcionales. En cuanto a las métricas base se tienen dos subconjuntos o

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

o

Impacto: confidencialidad, integridad y disponibilidad.

Vulnerability information from the Open Source Vulnerability Database (OSVDB)10. Proporciona una radiografía 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 públicas o se hayan insertado directamente en la base de datos por particulares.

9

http://nvd.nist.gov/cvss.cfm http://osvdb.org

10



Common Vulnerability Reporting Framework (CVRF). Es un formato XML que permite compartir información crítica sobre vulnerabilidades en un sistema abierto y legible por cualquier equipo. Hasta el momento no había ningún estándar para informar de vulnerabilidades de los sistemas de la Tecnologías de la Información y Comunicaciones (TIC), por lo que CVRF viene a cubrir una necesidad manifestada por los distintos actores de la industria, organismos de investigación y de la administración en cuanto a un marco común, ya que hasta ahora, cada proveedor creaba sus informes según su criterio. La disponibilidad de CVRF acelera el intercambio y procesamiento de información entre distintas plataformas. Originalmente deriva del proyecto Incident Object Description Exchange Format (IODEF), su propósito es el reemplazar los múltiples formatos previamente en uso no estándar de presentación de informes, lo que permite acelerar el intercambio de información y proceso. National Vulnerability Database (NVD) 11. Base de datos del gobierno estadounidense que permite la automatización de la gestión vulnerabilidades y la medición del nivel seguridad. Incluye bases de datos con listas de comprobación de configuraciones de seguridad de productos, defectos de seguridad del software relacionados, malas configuraciones, los nombres de producto y métricas de impacto. Contiene:

11 12

o

54337 CVE Vulnerabilidades.

o

202 Listas de comprobación de configuraciones de seguridad de productos.

o

8140 Consultas a OVAL.12

http://nvd.nist.gov/ Open Vulnerability and Assessment Languajes (OVAL). Esfuerzo de comunidad internacional para normalizar los informes de seguridad de vulnerabilidades y estado de seguridad de un sistema TIC. Incluye un lenguaje de codificación de los detalles de sistema. http://oval.mitre.org/ © Universidad Internacional de La Rioja (UNIR)


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

Proporcionar un lenguaje común para describir los defectos y debilidades de seguridad de software en la arquitectura, el diseño y codificación.

o

Proporcionar un estándar de comparación de herramientas de auditoría seguridad de software.

o

Proporcionar una línea base para la identificación de vulnerabilidades, su mitigación y los esfuerzos de prevención.

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

Figura 11.

13

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

http://cwe.mitre.org/



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

CWE: Nombre deltipode debilidad



Descripción del tipo



Términos alternativos para la debilidad



Descripción del comportamientode la debilidad



Descripción de la debilidad



Probabilidad de explotarla debilidad



Descripción de las consecuenciasd e la explotación



Posibles mitigaciones



Otras debilidades relacionadas



Taxonomías de las fuentes



Ejemplosd e códigopara los lenguajes/arquitecturas



Identificadores de vulnerabilidades CVE para las que ese tipo de debilidadexiste



Referencias



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

Clasificación de las vulnerabilidades Existen muchas clasificaciones o taxonomías de vulnerabilidades unas se adaptan a todo tipo de aplicaciones, como son MITRE Top 2514 y SANS Top 20 15 y otras solo a aplicaciones web como son OWASP Top 10 16 y WASC Threat Clasification v2.017. A continuación describimos algunas de las mencionadas.

http://cwe.mitre.org/top25/ 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/ 14 15



MITRE TOP 25. La lista es el resultado de la colaboración entre el Instituto SANS, MITRE y muchos de los mejores expertos en software de EE.UU. y Europa. Contiene los mayores errores de programación que pueden causar vulnerabilidades en el software. Es una herramienta destinada a ayudar a los programadores y auditores de seguridad del software, para prevenir este tipo de vulnerabilidades que afectan a la industria de las TIC. o

Todo tipo de aplicaciones Web y no Web.

o

Dan lugar a vulnerabilidades graves en el software.

o

Prevención, mitigación y principios de programación seguros.

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

ID

NOMBRE

[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. Extraída de [7].



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

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

o

Identificador CWE.

o

Información adicional sobre la debilidad que puede ser útil para adoptar decisiones de priorización de acciones de mitigación.

o

Breve discusión informal sobre la naturaleza de la debilidad y de sus consecuencias.

o

Los pasos que los desarrolladores pueden tomar para mitigar o eliminar las debilidades.

o

Otras entradas CWE que están relacionadas con la debilidad Top 25.

o

Entradas estándar CAPEC18 sobre los ataques que pueden llevarse a cabo con éxito contra la debilidad.

o

Enlaces con más detalles, incluyendo ejemplos de código fuente que demuestran la debilidad, métodos de detección, etc.

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

Vulnerabilidades

en

servidores,

aplicaciones

Web,

aplicaciones

comerciales/open-source. o

No tiene en cuenta las aplicaciones propietarias.

Consultar lectura complementaria para más detalle sobre la clasificación. OWASP Top 10. Su objetivo es crear conciencia sobre la seguridad en aplicaciones mediante la identificación de algunos de los riesgos más críticos que enfrentan las organizaciones.

18 Lista

de patrones comunes de ataque junto con un esquema integral y taxonomía de clasificación. © Universidad Internacional de La Rioja (UNIR)

Tema 1: El problema de la seguridad en el s o f t w a r e o

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

o

Lista ordenada por criticidad y predominio.

o

Representa una lista concisa y enfocada sobre los diez riesgos más críticos sobre seguridad en aplicaciones.

Figura 13.

OWASP TOP 10 diez riesgos más importantes en aplicaciones WEB. Extraída de [8].



WASC Threat Clasification v2.0. Es un esfuerzo de cooperación para aclarar y organizar las amenazas a la seguridad de un sitio web. Es un proyecto para desarrollar y promover estándares para la industria y su principal propósito es el crear un lenguaje consistente y las definiciones de los problemas de seguridad relacionados con las aplicaciones web. o

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

o

Describe amenazas, debilidades y ataques.

Escáneres de vulnerabilidades Este tipo de herramientas analizan los sistemas en busca de vulnerabilidades conocidas. Disponen de información sobre vulnerabilidades existentes en los sistemas operativos y aplicaciones mediante actualizadas bases de datos, que utiliza para la detección de las mismas. La herramienta más utilizada es Nessus, inicialmente de código abierto y versión gratuita, y actualmente en dos versiones, la 4.x en la que el nuevo código es cerrado, y la versión 2.x ( www.nessus.org) que continúa siendo software libre. A raíz de este cambio se crearon tres proyectos diferentes a partir de la versión libre, Sussen, Porz Wahn y OpenVas (inicialmente GNessUs). Actualmente el proyecto Porz-Wahn se unió con OpenVas19, la cual continúa 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 Básicamente se tienen dos conjuntos de propiedades que definen a un software seguro del que no lo es, las primeras son las esenciales, comunes a la seguridad de cualquier sistema, cuya ausencia afecta gravemente a la seguridad de una aplicación y un segundo conjunto, complementarias a las anteriores que no influyen en su seguridad, pero que ayudan a mejorarla en gran medida.

19

http://www.openvas.org/ © Universidad Internacional de La Rioja (UNIR)


Las principales propiedades esenciales que distinguen al software de confianza del que no es de confianza son: Integridad. Capacidad que garantiza que el código, activos manejados, configuraciones y comportamiento no pueda ser o no haya sido modificado o alterado por personas, entidades o procesos no autorizados tanto durante la fase de desarrollo como en la fase de operación . Entre las modificaciones que se pueden realizar tenemos sobreescritura, inclusión de puertas traseras, borrado, corrupción de datos, etc. Como las técnicas y mecanismos que se tienen para salvaguardar la integridad, tenemos por ejemplo: o

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

o

Uso de técnicas de cifrado para asegurar que los componentes y los datos nos son alterados o corrompidos.

o

Estricta gestión de sesiones. Uso de sistemas de monitorización de la integridad

o

Uso de firma digital.

o

Trasmisión cifrada de los datos.

o

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

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

o

Uso de arquitecturas de alta disponibilidad, con diferentes tipos de redundancias.

o

Uso de sistemas distribuidos con sistemas de réplica de información entre ellos.

o

Uso de sistemas de recuperación a través de imágenes, virtualización, etc.

Confidencialidad. Capacidad de preservar que cualquiera de sus características, activos manejados están ocultos a usuarios no autorizados, de forma que se garantice que solo las personas, entidades o procesos autorizados pueden acceder a la información.



Entre las técnicas y mecanismos que se tienen para salvaguardar la confidencialidad, tenemos por ejemplo: o

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

o

Tráfico de relleno.

o

Técnicas de control de acceso a los sistemas basado en roles.

o

El cifrado de la información y de las comunicaciones.

Figura 14. Propiedades esenciales de la seguridad del software

Un ejemplo de ataque podría ser uno de desbordamiento del buffer (buffer overflow) consiguiendo el control total de la máquina, pudiendo violar las tres propiedades anteriores al poder robar información del sistema, cuantas de usuario, corromper ficheros del sistema e incluso apagar la máquina y borrar los ficheros necesarios para que no vuelva a arrancar. Estas tres primeras serían las propiedades fundamentales esenciales mínimas que debería disponer todo software, a las que habría que añadir las siguientes complementarias: Fiabilidad. Capacidad del software de funcionar de la forma esperada en todas las situaciones a la que estará expuesto en su entorno de funcionamiento, es decir que la posibilidad de que un agente malicioso pueda alterar la ejecución o resultado de una manera favorable para el atacante está significativamente reducida o eliminada.



En este sentido en el documento de referencia [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

Batería de ataques lanzados contra el software.

o

Entradas y salidas del software (señales, ficheros de datos, texto, etc.) que hayan sido comprometidas.

o

Interfaces del software a otras entidades que hayan sido comprometidas.

o

Ejecución del software en un ambiente donde es atacado.

Autenticación. Capacidad que permite a un software garantizar que una persona, entidad o proceso es quien dice ser o bien que garantiza la fuente de la que proceden los datos. Trazabilidad. Capacidad que garantiza la posibilidad de imputar las acciones relacionadas en un

s o f t w a r 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 daños ocasionados por fallos causados por ataques de vulnerabilidades explotable del mismo, recuperarse lo más rápido posible de ellos y reanudar su operación en o por encima de cierto nivel mínimo predefinido de servicio aceptable en un tiempo oportuno. 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 sistemáticamente con estas propiedades en todas las condiciones. Estos incluyen : Principios de diseño y buenas prácticas de desarrollo. desarrollo . Las prácticas utilizadas para desarrollar el software y los principios de diseño que lo rigen. En el apartado posterior se desarrolla ampliamente este punto. Herramientas de desarrollo. desarrollo . El lenguaje de programación, bibliotecas y herramientas de desarrollo utilizadas para diseñar, implementar y probar el software, y la forma en que fueron utilizados por los desarrolladores.

Componentes adquiridos. adquiridos. Tanto los componentes de software comercial como libre en cuanto como fueron evaluados, seleccionados, e integrados. Configuraciones desplegadas. desplegadas. Cómo el software se configuró durante la instalación en su entorno de producción. Ambiente de operación. operación. La naturaleza y configuración de las protecciones proporcionadas por el entorno de ejecución o producción.



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

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

La adopción de estos principios de diseño constituye una base fundamental de las técnicas de programación segura que segura que se verán más adelante en el tema 3, tanto para la protección de aplicaciones Web, normalmente más expuestas a los ciberataques al estar desplegadas masivamente en Internet, como otras más tradicionales del tipo cliente-servidor. Las principales prácticas y principios de diseño tener en cuenta serían: Defensa en profundidad. profundidad. Simplicidad del diseño. diseño. Mínimo privilegio. privilegio. Separación de privilegios. privilegios. Separación de dominios. dominios. Separación código, ejecutables y datos configuración y programa. programa . Entorno de producción o ejecución inseguro. inseguro. Registro de eventos de seguridad. seguridad . Fallar de forma segura. segura . Diseño de s o f t w a r e resistente. resistente. La seguridad por oscuridad es un error. error . Seguridad por defecto. defecto.



Defensa en profundidad Uno de los principios más importantes de una estrategia defensiva defensiva efectiva es la «Defensa en Profundidad», se define en la guía CCN-STIC-400 [18] como: «Estrategia de protección consistente en introducir múltiples capas de seguridad, que permitan reducir la probabilidad de compromiso en caso de que una de las capas falle y en el peor de los casos minimizar el impacto ». La arquitectura del software y hardware de base que constituirá el entorno de ejecución donde la aplicación vaya a ser instalada debería contar con una variedad de servicios de seguridad y protecciones que reduzcan y dificulten la probabilidad de que una acción maliciosa alcance el software, ya que se minimiza la exposición de las propias vulnerabilidades al mundo exterior, se reduce la visibilidad externa de los componentes confiables principales y se aíslan los componentes no confiables de forma que su ejecución se vea limitada y sus malos comportamientos no afecten o amenacen la operación confiable de los demás. El aislamiento significa que el software o componente no confiable dispone de recursos específicos para su ejecución como memoria, espacio en disco duro, interfaz de red virtual, etc., en un entorno aislado. Para su implementación i mplementación se suelen utilizar máquinas virtuales que además pueden proporcionar otras características que ayudan a mejorar la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte para la restauración de imágenes, etc. Objetivo: Objetivo: introducir múltiples capas de seguridad para reducir la probabilidad de compromiso del sistema. Este principio, propone un enfoque defensivo, 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 seguridad a implementar en cada capa podrán variar en función del entorno de operación del sistema, sin embargo el principio base o general permanece inalterable, por ejemplo para las capas siguientes tendríamos: Capa de aplicación : Dispositivos de nivel de aplicación como cortafuegos, proxy reverso, y sistemas de prevención de intrusiones de host que que

bloqueen las entradas maliciosas conocidas y problemáticas antes de que

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

Datos

Aplicac Apl icación ión

Datos

Presentación

Datos

Presentación

Segment

Transporte

Cortafuegos Cortafuegos de ap licación Proxy reve reve rso Métodos Criptográficos Criptográficos Control de Acceso Acceso Aute nticación Bastionado de las aplicaciones aplicaciones Bastionado del sistema operativo

SSL/TLS



Paquetes

Red

Tramas

Enlace

Bits

Físico

Segmentos de red Firewall/IDS/IPSEC/VPN

Prevención Intrusiones Seguridad Física Procedimientos se guridad Plataforma virtualización

Figura 16. Propiedades seguridad del software

El principio fundamental detrás de este concepto, es el de dificultar las acciones del atacante a través de las diferentes medidas de seguridad aplicadas a cada una de las capas de forma que los diferentes sensores que tengan nuestro sistema detecten las actividades maliciosas. Cuando una capa se vea comprometida, las medidas de detección, de reacción y de recuperación nos permitirán reaccionar, disminuyendo la probabilidad de que otras capas se vean comprometidas, evitando así, que la seguridad del servicio en su conjunto se vea burlada, disminuyendo por tanto el riesgo. Otro aspecto importante es la verificación de la cadena de suministros mediante la comprobación de los hash 20, código de firma, aplicados al código ejecutable mediante la validación de la integridad de la misma en el momento de la entrega, la instalación o en tiempo de ejecución, para determinar: o

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

o

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

En la figura siguiente se puede observar un ejemplo del uso de arquitecturas de protección.

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 función hash sobre el contenido distribuido asegurando así la integridad. A esto se le suele llamar checksum criptográfico debido a que es un checksum que requiere el uso de funciones hash criptográficas para que sea difícil generar otros ficheros falsos que tengan el mismo valor hash. Otro ejemplo de uso esta tecnología para verificar la integridad es calcular y guardar el valor hash de archivos para poder verificar posteriormente que nadie (Ej. un virus) los ha modificado. http://es.wikipedia.org



Elevado nº No tráfico cifrado, falsos positivos gran volumen

Amenaza real,

Ataques exteriores, identificar problemas de configuración

Figura 17. Uso de arquitecturas de protección

Simplicidad del diseño La realización de un diseño tan simple como sea posible y la redacción de unas especificaciones del mismo fácilmente comprensibles y simples es una forma de obtener un nivel de seguridad mayor pues será menos probable que el desarrollador incluya debilidades y vulnerabilidades e incluso se haga más fácil el análisis de su descubrimiento y su verificación y validación. Algunas de las opciones específicas de diseño del software que lo simplifican son [13]: Limitar el número de estados posibles en el software. Favorecer procesos deterministas sobre los no deterministas. Utilice una sola tarea en lugar de realizar múltiples tareas siempre que sea práctico. El uso de técnicas de sondeo en lugar de interrupciones. Diseñar los componentes del software con el conjunto mínimo de características y capacidades que se requieran para realizar sus tareas en el sistema. La descomposición en subsistemas o componentes de un programa debería adaptarse a su descomposición funcional, permitiendo una asignación uno a uno de los segmentos de programa a sus fines previstos. Desacoplar

los

componentes

y

procesos

para

minimizar

las

interdependencias entre ellos, impedirá que un fallo o anomalía en un componente o proceso afecte a los estados de otros.



Este desacoplamiento se logra: o

Implementando funcionalidades modulares en el programa en unidades discretas de procesamiento autónomas.

o

Establecer barreras para impedir la comunicación de entre los componentes que no deben interactuar por diseño.

o

Asignar espacio de memoria restringido a solo lectura o solo escritura para los procesos, para evitar que todos los componentes, menos los explícitamente autorizados, cambien los valores de los datos.

o

Favorecer el uso de funciones débilmente 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 ejecución para la realización 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 características o funciones innecesarias. Si el diseño incluye componentes COTS o del software libre con trozos de código latente o muerto, funciones innecesarias o no documentadas, el diseño debe incluir contenedores para aislar los segmentos de código no utilizados para prevenir el acceso a los mismos durante su ejecución. Otro aspecto importante en la simplicidad del diseño es que la especificación del mismo debe ser totalmente trazable para determinar si el diseño fácilmente satisface todas sus necesidades, incluyendo las relativas a los requisitos de seguridad. Esta trazabilidad debe ser atrás hacia adelante y viceversa, es decir: Trazabilidad hacia adelante un requisito y su correspondencia en el diseño. Trazabilidad hacia atrás desde el diseño al requisito origen. Trazabilidad hacia adelante desde el diseño y su correspondencia en el código implementado. Trazabilidad hacia atrás desde el código a la parte del diseño correspondiente. Como podemos ver el implementar arquitecturas complejas, cuando se puede resolver el diseño de forma simple, puede afectar negativamente a la seguridad del sistema.



Objetivo: Reducir la complejidad del diseño para minimizar el número de vulnerabilidades explotables por el atacante y debilidades en el sistema.

Mínimo privilegio De acuerdo con el Software Assurance CBK [18] se define el mínimo privilegio como: Mínimo privilegio es un principio según el cual se concede a cada entidad (usuario, proceso o dispositivo) el conjunto más restrictivo de privilegios necesarios para el desempeño de sus tareas autorizadas. La aplicación de este principio limita el daño que puede resultar de un accidente, error o el uso no autorizado de un sistema. También reduce el número de interacciones potenciales entre los procesos privilegiados o programas, por lo que se minimiza la probabilidad de ocurrencia de usos maliciosos de privilegios, no deseados o inapropiados. Una de la principales razones por la que es necesario que una entidad se ejecute con los mínimos privilegios posibles, es debido a que si un ciberatacante consigue comprometer una máquina o es capaz de inyectar código malicioso en un proceso del sistema este se debería ejecutar con los mismos privilegios que tuviera el usuario en la máquina o el proceso. Este principio requiere que el diseñador realice una lista de las entidades de software con los recursos que utiliza y las tareas que debe realizar en el sistema, 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: Aplicación de derechos de administrador. Por ejemplo una conexión de lectura a una base de datos con derechos de administrador. Instalación de aplicaciones y servicios con el usuario de administrador . Puede implicar que si un ciberatacante explota una vulnerabilidad de la aplicación, obtendría 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 ejecución, etc.). Servicios y procesos con privilegios por tiempo indefinido. Cada entidad debe tener el privilegio necesario para realizar una tarea determinada sólo el tiempo necesario para completarla, ejecutándose normalmente con una cuenta de usuario restringido. Objetivo: lo que no está expresamente permitido está prohibido.

Separación de privilegios Es un principio relacionado con el anterior «mínimo privilegio» que esto implica la asignación a las diferentes entidades de un rol, que básicamente implica lo siguiente: Asignación de un subconjunto de funciones o tareas de todas las que ofrece el sistema. Acceso a los datos necesarios que debe gestionar para llevar a cabo su función en base a una serie de roles definidos. Se evita así que todas las entidades sean capaces de acceder a la totalidad o llevar a cabo todas las funciones del sistema con privilegios de «superusuario» y por tanto que ninguna entidad tenga todos los privilegios necesarios para modificar, sobrescribir, borrar o destruir todos los componentes y recursos 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 código de los formularios HTML.



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

Separación de dominios Es un principio que en unión con los dos anteriores, «mínimo privilegio» y «separación de privilegios y roles», que permite minimizar la probabilidad de que actores maliciosos obtengan fácilmente acceso a las ubicaciones de memoria u objetos de datos del sistema, mediante la utilización de técnicas de compartimentación de los usuarios, procesos y datos de forma que las entidades: Solo deben ser capaces de realizar las tareas que son absolutamente necesarias. Llevarlas a cabo solamente con los datos que tenga permiso de acceso. Utilizar el espacio de memoria y disco que tenga asignado para la ejecución de esas funciones. Objetivo: minimizar la probabilidad de que actores maliciosos obtengan fácilmente acceso a las ubicaciones de memoria u objetos de datos del sistema. El aislar las entidades de confianza en su área propia de ejecución (con recursos dedicados a esa área de ejecución) de otras menos confiables (procesadores de texto, software de descarga, etc.), permite reducir al mínimo su exposición a otras entidades e

interfaces externas susceptibles de ser atacadas por agentes maliciosos. Las técnicas que tenemos para llevar a cabo lo anterior: Sistema operativo confiable. Máquinas virtuales. Además pueden proporcionar otras características que ayudan a mejorar la fiabilidad, confiabilidad y resistencia como el balanceo de carga, soporte para la restauración de imágenes, etc. Funciones sandboxing de lenguajes de programación como Java, Perl, .NET (Code Access Security), etc. Sistemas Unix: chroot jails. Trusted processor modules (TPM) 21. 21 Es

el nombre de una especificación publicada que detalla un criptoprocesador seguro que puede almacenar claves criptográficas que protejan la información y las implementaciones de esta especificación, a menudo llamado el «chip TPM» o «dispositivo de seguridad TPM». http://en.wikipedia.org



Separación código, ejecutables y datos configuración y programa Este principio pretende reducir la probabilidad de que un ciberatacante que haya accedido a los datos del programa fácilmente pueda localizar y acceder a los archivos ejecutables y datos de configuración del mismo, lo que le daría la posibilidad de manipular el funcionamiento del sistema a su interés e incluso el escalado de privilegios. La mayoría de las técnicas de separación de los datos de programa y configuración y archivos ejecutables se realizan en la plataforma de ejecución (procesador más sistema operativo). A continuación vemos las más principales [13]: Utilizar plataformas con arquitectura Harvard 22. Asegura que los datos de programa y datos de control se almacenan en dos segmentos de memoria físicamente 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 explícita de otros programas o entidades para poder leerlos. Los datos de configuración del programa solo deben poder ser leídos y modificados por el administrador. Excepción de configuración de una aplicación cliente o un navegador web donde los datos de preferencias del usuario están expresamente destinados a ser configurados por él. En este caso, al usuario debe permitírsele leer y escribir dichos datos a través de interfaz de preferencias con una configuración especialmente diseñada. Los datos utilizados por un

s c r i p t

en un servidor Web deben ser

colocados fuera de árbol de documentos del mismo. La mezcla de datos HTML y código JavaScript puede constituir una vulnerabilidad explotable mediante técnicas de ataque como Cross Site Scripting (XSS). Prohibir a los programas y

escribir scr ip ts

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 físicamente separados para las instrucciones y para los datos (en oposición a la Arquitectura de von Neumann). http://es.wikipedia.org © Universidad Internacional de La Rioja (UNIR)


Almacenar los archivos de datos, configuración 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 producción no debe ser leído por cualquier persona.

o

Los usuarios solo deben tener concedidos privilegios de ejecutar el programa.

Los programas y scripts que están configurados para ejecutarse como servidor Web de usuario «nobody (debe suprimirse) deben ser modificados para funcionar »

bajo un nombre de usuario específico. Cifrar todos los archivos ejecutables e implementar un módulo de decodificación que se ejecute como parte del inicio del programa para desencriptarlos al iniciar su funcionamiento. Incluir técnicas de cifrado de archivos y la firma digital o almacenamiento en un servidor de datos externos con conexión cifrada (por ejemplo mediante SSL o TLS23) para aislar los datos de configuración del software de la manipulación y eliminación, si las técnicas de control de acceso al sistema no son lo suficientemente fuertes. Ello requerirá que el software incluya la lógica de cifrado para descifrar y validar la firma del archivo de configuración al inicio del programa. Implantar clonado de sistemas como medida de recuperación, desde un servidor remoto (que guardaría las imágenes y los datos de configuración) mediante una red de comunicaciones fuera de banda específica y cifrada. Objetivo: reducir la probabilidad de que un ciberatacante que haya accedido a los datos del programa fácilmente pueda localizar y acceder a los archivos ejecutables y datos de configuración del programa.

23 Secure Sockets Layer (SSL) o

Transport Layer Security (TLS) © Universidad Internacional de La Rioja (UNIR)


Entorno de producción o ejecución inseguro Asumir que todos los componentes del entorno de producción y sistemas externos son inseguros o no confiables, con ello se pretende reducir la exposición de los componentes del software a agentes potencialmente maliciosos que hayan podido penetrar en el perímetro de defensa (los límites lo constituyen los cortafuegos) de la organización y comprometer una máquina desde la que puedan expandirse e iniciar otros ataques a otras pertenecientes a la red (pivoting). El software debe ser diseñado con una mínima dependencia de los datos externos, se debe tener control completo sobre cualquier fuente de entrada de datos, tanto los proporcionados por la plataforma de ejecución como de sistemas externos, debiendo validar todos los datos provenientes de las diferentes fuentes del entorno antes de utilizarlos, pues implican una posibilidad de ataque. Hay que realizar una descomposición del sistema en sus componentes principales y realizar una lista de las diferentes fuentes de datos externas , entre las que podemos tener las siguientes: Llamadas a sistema operativo. Se deben evitar realizándolas a través de middleware o API’s.

Llamadas a otros programas en la capa de aplicación. Llamadas a una capa de m i d d l e w

a r e intermedia.

API’s a los recursos del sistema. Las aplicaciones que utilizan las API no deberían 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 validación de los datos de entrada, el confiar en la fuente que las originó hace a la aplicación vulnerable a ataques originados en el cliente al modificar los datos en el origen o durante su transporte. Los atacantes pueden manipular diferentes tipos de datos de entrada con el propósito de encontrar vías de compromiso de la aplicación.



Todos los tipos de entrada deber ser validados y verificados mediante pruebas específicas. Entre los diferentes tipos de entradas a las aplicaciones tenemos [13]: Parámetros de línea 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). Parámetros HTTP GET. Campos de formulario (especialmente los ocultos). Las listas de selección, 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 comprobación de los datos de entrada, la mayoría para aplicaciones Web, tenemos: Desbordamientos de Búfer (buffer overflow): heap, stack, entero y off-by-one. Revelación

de

información: indexación

información, p a t h

de

directorio,

fuga

de

, localización de recursos predecibles. tr asver sal

Inyección de comandos: ataques de formato de cadena, comandos de sistema operativo, cross-site scripting (XSS). Inyección de código SSI inyección SQL, HTTP splitting. Contenidos mal formados. Servicios Web: aparte de los anteriores tenemos, inyección XML, explotación de interfaces de administración no protegidos.



Para evitar este tipo de vulnerabilidades se deben aplicar una serie de principios de validación de las entradas, entre los que tenemos [13]: Centralizar la lógica de validación de las entradas. Asegúrese que la validación de la entrada no puede ser evitada. Confiar en “listas blancas” 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 validación. Validar todas las entradas de usuario incluidas las realizadas a través de proxies y agentes que actúen 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 sólo ocho caracteres numéricos, 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 política) a emitirlas. Definir reacciones significativas a errores de validación de entrada. El rechazo a entradas mal formadas o fallidas es uno de los más frecuentes. Validar los datos de de salida de la aplicación antes de mostrarlos al usuario o redirigirlos a otro sistema. Objetivo: evitar vulnerabilidades aplicando una serie de principios de validación de las entradas.

Registro de eventos de seguridad Tradicionalmente los sistemas de auditoría se dedicaban solo a grabar las acciones realizadas por los usuarios del mismo. Sin embargo actualmente es necesario dotar a las aplicaciones 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 detección de intrusiones. Una lista blanca, lista de aprobación ó whitelist en Inglés es una lista o registro de entidades que, por una razón u otra, pueden obtener algún privilegio particular, servicio, movilidad, acceso o reconocimiento. Por el contrario la lista negra o blacklisting es la compilación que identifica a quienes serán denegados, no reconocidos u obstaculizados. http://es.wikipedia.org

24



Las principales diferencias que distinguen los sistemas con registros de auditoría de seguridad de registro de los registros de eventos estándar son: El tipo de información capturada en el registro de auditoría: eventos de seguridad. Capacidad de gestión de los incidentes relacionados con los eventos de seguridad. Posibilidad de que los eventos de seguridad registrados en la aplicación o sistema, puedan ser utilizados en procesos reactivos después de la ocurrencia de un incidente. El nivel de protección de integridad aplicado a los registros de auditoría, para evitar que sean intencionadamente o inadvertidamente eliminados, dañados o alterados. Suelen incluirse las siguientes medidas: o

Medidas de autenticación de los actores que interactúan 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

Comprobación 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 propósito de este principio es el reducir la probabilidad de que un fallo en el software, pueda saltarse los mecanismos de seguridad de la aplicación, dejándolo en un

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



Algunas de las características específicas del diseño que minimizan la probabilidad de que el software pase a un estado inseguro son: Implementar temporizadores tipo « w a t c h d o g » 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 lógica de control de excepciones, para cuando la aplicación falle, registre un evento con error (que no proporcione al atacante información sensible del sistema y le posibilite buscar otros fallos parecidos para obtener más información), implemente un umbral en el que se establezca un punto de no retorno del cual no es posible recuperarse pues se estaría 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 información técnica que pudiera ser utilizada por un ciberatacante. El

s o f t w a r e siempre

debe comenzar y terminar su ejecución en un

estado seguro. Los cambios de estado siempre deben ser deliberados y nunca accidentales, sobre todo a estados vulnerables. Evitar problemas de sincronización y secuenciación, causados por el uso compartido de información de estado (sobre todo en tiempo real). Usar para ello enclavamientos (secciones críticas, mecanismos de sincronización) para hacer cumplir las secuencias de acciones o eventos, de modo que no pueda ocurrir accidentalmente o exista una condición indeseable o fuera de secuencia. Objetivo: reducir la probabilidad de que un fallo en el software, pueda saltarse los mecanismos de seguridad de la aplicación, dejándolo en un modo de fallo inseguro vulnerable a los ataques.

Diseño de s o f t w a r 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 mínimo la cantidad de tiempo que un componente de

soft w a r e

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



Algunas de las características de diseño que aumentarán la resistencia del software incluyen [13]: Capacidad de autocontrol y de limitar el uso de los recursos. Uso de técnicas de monitorización que permita al software detectar cualquier anomalía y error antes de crear una vulnerabilidad explotable. Detección de estados anómalos cuando ocurra un error, el controlador de excepciones debe devolver al software a un estado seguro conocido. Proporcionar una realimentación que permita que todos los supuestos y modelos en los que el programa tome decisiones sean validados antes de ejecutarlas. Aprovechar cualquier redundancia y funciones de recuperación rápida a nivel sistema, como copias de seguridad automáticas, arquitecturas de alta disponibilidad y almacenamiento y restauración de imágenes. Uso de plataformas virtuales que proporcionan ayuda a mejorar la fiabilidad, confiabilidad y resistencia, con técnicas como balanceo de carga, soporte para la restauración de imágenes, etc. Uso de técnicas de recuperación que incluyan el uso de estructuras de datos robustos, alteración dinámica de los controles de flujo y tolerancia al error para que pueda seguir funcionando de forma fiable en presencia de un número bastante grande de errores de entrada del usuario. Determinar la cantidad de información 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 mínimo la cantidad de tiempo que el componente de un software defectuoso o fallido sigue siendo incapaz de protegerse de los ataques.



La seguridad por oscuridad: error Una de las asunciones que se debe realizar a la hora de diseñar una aplicación, es que el atacante obtendrá con el tiempo acceso a todos los diseños y todo el código fuente de la misma. La seguridad por oscuridad es un mecanismo de defensa que consiste en ocultar en la aplicación información sobre la misma para sea difícil 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 válido usarla como una pequeña parte de una estrategia general de «defensa en profundidad» para confundir y dificultar las actividades de ataque de un intruso. A continuación se muestran algunos ejemplos de seguridad por oscuridad, que pueden constituir un error: Guardar información en archivos binarios. Un ciberatacante con conocimientos de ingeniería inversa podría obtener dicha información. Capetas ocultas en un servidor Web, con herramientas de análisis forense se podría acceder a ellas fácilmente. Incluso podría tener activado por error la opción de listado de directorios del servidor, con lo que un ciberatacante podría visualizarlos completamente. Falsa sensación 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». Criptografía privada. No es conveniente confiar en cualquier algoritmo que no es de conocimiento público y no ha sido analizado ampliamente, dado que al no haber una verdadera prueba matemática sólida de la seguridad de la mayoría de los algoritmos criptográficos, se consideran de confianza cuando un número suficiente de personas han pasado mucho tiempo tratando de romperlo y no lo han logrado. Ejemplo la criptografía 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 información para comprometer la seguridad de una aplicación.

Seguridad por defecto Uno de los principios de seguridad cuyo cumplimiento exige el Real Decreto 3/2010 [22], de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, es el de la seguridad por defecto. En su artículo 19 indica lo siguiente: Los sistemas deben diseñarse y configurarse de forma que garanticen la seguridad por defecto: a. El sistema proporcionará la mínima funcionalidad requerida para que la organización solo alcance sus objetivos, y no alcance ninguna otra funcionalidad adicional. b. Las funciones de operación, administración y registro de actividad serán las mínimas necesarias, y se asegurará que solo son accesibles por las personas, o desde emplazamientos o equipos, autorizados, pudiendo exigirse en su caso restricciones de horario y puntos de acceso facultados. c. En un sistema de explotación se eliminarán o desactivarán, mediante el control de la configuración, las funciones que no sean de interés, sean innecesarias e, incluso, aquellas que sean inadecuadas al fin que se persigue. d. El uso ordinario del sistema ha de ser sencillo y seguro, de forma que una utilización insegura requiera de un acto consciente por parte del usuario. De la lectura del artículo anterior se desprende que el principal objetivo del principio de seguridad por defecto es el de minimizar la superficie de ataque de cualquier aplicación o sistema TIC, deshabilitando aquellos servicios y elementos no necesarios y activando solo los necesarios.



Normalmente cuando se instala o pone en producción una aplicación o servicio, se activan o instalan servicios que no se usan normalmente que pueden suponer un punto potencial de entrada para los atacantes. Se debe elegir los componentes que van a ser utilizados de forma explícita por los usuarios e instalarlos y configurarlos de forma segura. Hay que minimizar los puntos vulnerables de la aplicación o sistemas pues amenazan su seguridad global por muy securizado que se tenga el resto. Por la tanto hay que controlar los puntos de entrada que: Entradas y salidas de red. Número de puertos abiertos. Puntos de entrada a la aplicación, autenticados o no autenticados, locales o remotos y privilegios administrativos necesarios. Número de servicios. Desactivar los instalados por defectos no usados. Número de servicios con privilegios elevados. Número de cuentas de usuario administrador. Estado de las listas de control de acceso a directorios y ficheros. Control de cuentas de usuario y claves de acceso por defecto a servicios. Contenido dinámico de páginas Web. Varias organizaciones, como el National Institute of Standards and Technology (NIST), la Agencia de Seguridad Nacional (NSA) y el Centro Criptológico Nacional (CCN), han publicado guías de seguridad de configuración y scripts para productos COTS populares y de software libre que incluye la eliminación o restricción de servicios, usuarios, permisos y software innecesario. El bastionado de sistemas es un proceso necesario en el marco de cualquier proyecto que contemple la aplicación de controles de seguridad sobre los sistemas TIC que tiene como principio implementar todas las medidas de seguridad a nivel técnico posibles para proteger un sistema sin que pierda la funcionalidad para la que fue destinado. Habrá casos, en los que surjan conflictos que no se puedan superar, estos deben ser cuidadosamente documentados para proporcionar una justificación de la renuncia a los requisitos de configuración de seguridad que impidan el correcto funcionamiento del software. Objetivo: reducir la superficie de ataque de una aplicación o sistema.



Resumen En el presente apartado se ha realizado un estudio de los diferentes principios de seguridad a tener en cuenta en el diseño y desarrollo de aplicaciones seguras, que nos ayudaran a proteger y disponer de aplicaciones seguras con un mínimo de vulnerabilidades. Como resumen se muestra un gráfico que sintetiza el objetivo de cada principio. Principio

Objetivo

Defensa en

Introducir múltiples capas de seguridad para reducir la

profundidad

probabilidad de compromiso del sistema.

Reducir la complejidad del diseño para minimizar el número de Simplicidad del diseño vulnerabilidades explotables por el atacante y debilidades en el sistema. Mínimo privilegio Separación de privilegios Separación de

Lo que no está expresamente permitido está prohibido. Asignación a las diferentes entidades de un rol que implique el acceso a un subconjunto de funciones o tareas y a los datos necesarios. Minimizar la probabilidad de que actores maliciosos obtengan

dominios

fácilmente acceso a las ubicaciones de memoria u objetos de datos en el sistema.

Separación código, ejecutables y datos

Reducir la probabilidad de que un ciberatacante que haya accedido a los datos del programa fácilmente pueda localizar y

configuración y programa

acceder a los archivos ejecutables y datos de configuración del programa.

Entorno de producción o

Evitar vulnerabilidades aplicando una serie de principios de validación de las entradas.

ejecución inseguro Registro de eventos de seguridad Fallar de forma segura

Generar eventos (logs) de seguridad, para garantizar las acciones realizadas por un ciberatacante se observan y registran Reducir la probabilidad de que un fallo en el software, pueda saltarse los mecanismos de seguridad de la aplicación, dejándolo en un modo de fallo inseguro vulnerable a los ataques.

Diseño de software resistente La seguridad por oscuridad: error Seguridad por defecto

Reducir al mínimo la cantidad de tiempo que un componente de un software defectuoso o fallido sigue siendo incapaz de protegerse de los ataques. Concienciarse de que la seguridad por oscuridad es un mecanismo de defensa que puede proporcionar a un atacante información para comprometer la seguridad de una aplicación. Reducir la superficie de ataque de una aplicación o sistema. Tabla 2 Objetivos Principios de seguridad



1.5. Amenazas a la seguridad del software Introducción Las aplicaciones, tal y como se expuso en la introducción del presente tema, son amenazadas y atacadas, no solo en su fase de operación, sino que también en todas las fases de su ciclo de vida. 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 mínimo posible de vulnerabilidades explotables. Para conseguir que el desarrollo de una aplicación posea las propiedades y principios de diseño del software seguro presentados en los apartados anteriores, se necesita que el personal de diseño y desarrollo desarrollen dos perspectivas:

Defensor

El equipo trabaja p ara construir un software con las propiedades d e seguridad necesarias para que sea más resistente a los ataques y minimizar las debilidades y vulnerabilidad

Atacante

El equipo se esfuerza por comprender la naturaleza exacta de la ame naza a la que le software es probable que se enfrente con e l fin de concentrar los esfuerzos de fensivos

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 características [12]: Resistencia. Capacidad del software para evitar que un atacante le realice un ataque. La más grave de las tres características, sin embargo es a menudo el más difícil de lograr, ya que implica minimizar las debilidades explotables en todos los niveles de abstracción, desde la arquitectura hasta la implementación 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 daños ocasionados por fallos causados por ataques de vulnerabilidades explotable que el software no pudo resistir o tolerar y recuperarse lo más rápido posible de ellos.

Tolerancia y resistencia al ataque son el resultado de efectivas decisiones de arquitectura y diseño más que de implementación.

Motivación perspectiva y tipos de atacantes El principal desafío en el desarrollo de software seguro, se debe a que es mucho más fácil encontrar vulnerabilidades en el

s o f t w a r e , que

es hacer software seguro.

La perspectiva del ciberatacante, básicamente consiste en buscar vulnerabilidades en el software bajo la perspectiva de afuera hacia adentro, requiere primero comprender

la tipología y motivaciones que hay detrás de los ataques a fin de entender realmente los riesgos asociados y analizar el

s o f t w a r e de

la manera que lo harían

para atacarlo. Esto proporcionará al equipo de diseño y desarrollo una mejor comprensión de cómo el s o f t w a r 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 introducción, las amenazas al software están presentes a lo largo de todo su ciclo de vida, durante su desarrollo y despliegue debidas principalmente a atacantes internos y durante la operación a atacantes externos (todos los demás 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 taxonomía o

tipología actualizada de los ciberatacantes, caracterizándolos por la gravedad de su amenaza y dividiéndolos por categorías en términos de motivaciones, capacidades, triggers, métodos y tendencias. En la siguiente tabla se muestra un resumen de la

misma.


Tema 1: El problema de la seguridad en el s o f t w a r e Tipo

Intenciones

Scriptkiddies

Curiosidad, notoriedad Notoriedad, a veces económicos

Ciber-Punk

Internos

Petty theft

Greyhat

Criminales Profesionales

Hacktivistas

Estados

Habilidades

Recursos

Métodos

Tendencias

Aleatorio

Bajas. Novatos

Escasos, sin equipos especializados

Herramientas y script libres de Internet

No son capaces de hacer daños a sistemas protegidos

Objetivos de tipo militar o gubernamenta l

Medias. Con conocimientos de sistemas operativos y programación

Poseen equipos especializados, fórums y grupos de Hackers

Herramientas y script libres modificadas para sus usos.

Búsqueda de notoriedad. Para financiarse roban tarjetas de crédito o fraudes

Evento negativos

Alto, con y conocimientos especializados

Accesos privilegiados e información de los sistemas

Accesos privilegiado para robos de información, fraude, sabotaje

Actualmente están en declive frente a los atacantes externos

Económicos

Ninguno en especial, búsqueda de dinero

Medias. Aprenden determinadas habilidades para los ataques sin estar interesados en la tecnología

Poseen equipos especializados

Spam, fraudes de tarjetas de crédito, robo de identidad mediante scripts crimeware.

Los vectores de ataque ha vuelto más accesible para los no técnicos Petty Thief

Curiosidad, notoriedad

Prefieren objetivos que constituyen un desafío o contienen información sensible

Altas, a veces incluso muy especializados

Tienden a trabajar solos, pero pueden aprovechar el conocimiento y herramientas de compañeros

Explotar más vulnerabilidad es conocidas o 0-day

Por lo general no causan daños importantes. Una excepción es el caso Wikileaks

Emplean una gran cantidad de métodos y desarrollan vectores de ataque phishing, spam, botnets, Man-in-theBrowser y key loggers Explotan vulnerabilidad es para tener acceso a los datos confidenciales que luego publican. Otro método preferido es el DDoS Actúan de manera encubierta en Internet. Las metodologías suelen combinar técnicas de ingeniería social y spearphishing, trojanos , etc.

El uso de botnets para robar información financiera está en aumento, así como el espionaje industrial y el robo de identidad

Venganza. económicos

Económicos

Notoriedad, venganza

Venganza, espionaje, económicos

Triggers

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.

Cualquier insulto real o percibido de su ideología

Niveles de habilidad varían ampliamente, tienden a tener un núcleo de miembros con altos conocimientos técnicos.

Recursos monetarios limitados. Gran cantidad de miembros. Se tiene acceso a mucha información especializada

Los ataques entre estados son provocados por conflictos geopolíticos.

Alto. Los Estados pueden tener acceso a habilidades y conocimiento de toda una nación.

Tabla 3

Un Estado tiene acceso a más fondos, mejor equipo e inteligencia

Taxonomía Ciberatacantes

Están al borde entre la desobediencia civil y terrorismo

Los Estados están cada vez más presentes en Internet. Muchos países tienen comandos cibernéticos.



En cuanto a los tipos de ataques o incidentes de seguridad, tomando como referencia la taxonomía anterior y la presentada en el trabajo de Zulima Ortiz y Francisco Galindo « Hacia una Taxonomía de Incidentes de Seguridad en Internet » [27] basada en procesos y orientación al evento, en la que se realiza una actualización de esta última con nuevos tipos de hakers presentados en la tabla 3 y los diferentes tipos de objetivos. El equipo de desarrollo y diseño podría usarla para determinar qué categorías de ciberatacantes son más propensos a atacar la futura aplicación, al objeto de evaluar las futuras amenazas y riesgo al que va a estar expuesto y poder priorizar las defensas contra los métodos utilizados por estas categorías. Como aclaración resumo los principales conceptos de esta taxonomía: 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 acción emprendida por un usuario, es decir existen eventos válidos sobre un sistema. Acción. Se define como un paso tomado por un usuario o un proceso para alcanzar un resultado. Blanco. Se define como una entidad lógica de cómputo o de red (cuenta, proceso o dato) o una entidad física (componente, ordenador, red o interred) objetivo del ciberataque.

Ataque. Una serie de medidas adoptadas por un atacante para obtener un resultado sin autorización. 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 taxonomía del incidente completo.



En el presente apartado se presentan varios modelos de ciclo de vida S-SDLC con prácticas de seguridad incluidas, que se pueden aplicar independientemente del tipo de modelo: ciclo de vida en espiral, extreme programming, etc. Además, algunos métodos estándar de desarrollo han demostrado que aumentan la probabilidad de que el software producido por ellos será seguro. Debido a la popularidad actual de los

métodos ágiles, es importante el estudiar los problemas de seguridad que surgen cuando se utiliza este tipo de ciclos de vida. Los equipos de desarrollo que utilizan metodologías seguras en el SDLC, casi inmediatamente perciben una mejora en su capacidad para detectar y eliminar vulnerabilidades y debilidades en el software que producen, antes de que entren en un proceso de distribución e instalación. Esta mejora se pondrá de manifiesto conforme el software pase sus controles de seguridad (revisiones de diseño y código de seguridad, análisis de fallos de inyección, pruebas de penetración, análisis de vulnerabilidades, etc.). Los elementos clave de un proceso de S-SDLC 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 diseño, errores de codificación, interfaces no especificadas, etc.). Como controles de salida incluyen revisiones paritarias, revisión de requisitos y diseño, revisiones de código, pruebas de seguridad y auditorías de seguridad. Principios y prácticas seguras de s o f t w a r e . Todos los procesos de desarrollo y sus artefactos deben ser conforme a los principios de diseño seguro y buenas prácticas de diseño, estudiados en el párrafo anterior y posteriormente en el tema 2. Requisitos adecuados. La especificación 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, evaluación, restricciones operativas, etc., para garantizar la fiabilidad, confiabilidad y capacidad de recuperación del software.



Arquitectura y diseño adecuados: Revisiones de la arquitectura y diseño 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 ejecución del software.

o

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

o

Plataforma de ejecución hardware y software adecuada para que la aplicación: – Actúe 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 podrían derivarse de los errores o

fallos provocados por el mal uso y abuso (este último podría ser caracterizado por patrones de ataque que se manifiestan como errores o anomalías 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 activación de funciones de código (inactivo) que no están expresamente destinados a ser ejecutadas, durante su funcionamiento.

Codificación segura. Incluye la adopción de prácticas de codificación seguras y estándares de programación. Durante todo el proceso de codificación se deben realizar de forma iterativa análisis de seguridad estática de código al objeto de encontrar problemas de seguridad y eliminarlos antes de liberarlo a la unidad de pruebas e integración. Integración de forma segura de los módulos y componentes del s o f t w a r e :

o

Garantizar que todas las interfaces de programación y llamadas a procedimientos son intrínsecamente seguras y se han incluido mecanismos de seguridad necesarios.



o

Reducir al mínimo la exposición al exterior de los componentes de alto riesgo y vulnerabilidades conocidas. Las pruebas de seguridad en la etapa de integración 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. Inclusión de revisiones y casos de pruebas orientadas a la seguridad durante todo el SDLC. Los planes de pruebas, realizados en la etapa de diseño, deben incluir escenarios con condiciones anormales y hostiles de ejecución y criterios de prueba que permitan determinar si el

s o f t w a r e cumple

con sus

requisitos de fiabilidad, confiabilidad y fiabilidad. Despliegue y distribución segura. Incluye: o

Desinfección completa de ejecutables, antes de la transferencia al sitio de descarga o medios de distribución, para evitar la inclusión de software malicioso en el mismo, datos incrustados sensibles, puertas traseras del desarrollador, etc.

o

Distribución a través de canales de comunicación seguros que protejan adecuadamente al software aplicando firmas digitales y mecanismos para evitar la manipulación o instalación no autorizada.

o

Ajustes

predeterminados

de

configuración

máximamente

restrictivos,

documentados en una guía de configuración lo suficientemente detallada para permitir al instalador tomar decisiones en base al riesgo de realizar configuraciones menos restrictivas si es necesario o

Documentación de instalación, 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 aplicación, gestión de sus vulnerabilidades, emisión de parches y su distribución a los clientes para que los apliquen y lo mantengan, evitando la exposición innecesaria de sus vulnerabilidades.



Herramientas de apoyo al desarrollo. Incluye herramientas y plataformas de desarrollo, pruebas e implantación que mejoran la seguridad de los artefactos producidos y las prácticas seguras aplicadas en todo el S-SDLC. Gestión de configuración de sistemas y procesos. Gestión de configuración versiones, control de cambios de los artefactos de desarrollo (código fuente, especificaciones, resultados de pruebas, etc.) como medida preventiva contra la manipulación de sus artefactos por agentes maliciosos. Conocimientos de seguridad de los desarrolladores. El conocimiento que los desarrolladores necesitan sobre principios y prácticas de ingeniería de seguridad de software.

Gestión segura del proyecto y compromiso de la alta dirección . La alta dirección de la organización debe comprometerse a proporcionar un apoyo adecuado (en términos de recursos, el tiempo, las prioridades de negocio y cambios de cultura organizacional) en la adopción y el uso constante de los procesos y prácticas de software seguras. En los siguientes apartados se introduce la metodología S-SDLC McGraw’s Seven Touchpoints por ser la tomada como base para la realización del tema 2 y se nombran otras existentes y se referencian otras metodologías actualmente en uso por diferentes organizaciones.

McGraw’s 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 prácticas de seguridad a aplicar a los artefactos de cada fase del desarrollo.



En esencia, el proceso se centra en la incorporación de las siguientes prácticas ordenadas por orden de importancia: Revisión de código Análisis de riesgo arquitectónico Pruebas de penetración Pruebas de seguridad basados en riesgo Casos de abuso Requisitos de seguridad Operaciones de seguridad Revisión externa Además de las siete prácticas se identifica una octava, el análisis externo, en el que un equipo de analistas externos a la organización y por tanto al equipo de desarrollo del software, realiza revisiones de seguridad independientes, evaluaciones y pruebas del

diseño del software y la implementación. La figura siguiente, muestra el de ciclo de vida de desarrollo de software seguro S-SDLC en el que se especifican las actividades y pruebas de seguridad a efectuar en cada fase del mismo.

8. Revisión externa 5. Casos de abuso

4. Pruebas 1. Revisión 6. Requisitos 2. Análisis de basadas en código seguridad riesgos riesgo

Requisitos Casos de abuso

Arquitectura Diseño

Plan de pruebas

Codificación

2. Análisis riesgos

3. Pruebas 7. Ope raciones penetración Seguridad

Pruebas y resultados

Realimentación de producción

Figura 20. McGraw’s Seven Touchpoints. Extraída de [7].



Este orden descrito no se adecuará perfectamente a todas las organizaciones. De hecho, el orden refleja el trabajo desarrollado en años de experiencia de McGraw al aplicar estas prácticas en empresas desarrolladoras de software. Por esa razón, la revisión de código viene antes de análisis de riesgos arquitectónico. Hay que resaltar que estas actividades hay que repetirlas a lo largo del ciclo de vida lo que supone un ciclo continuo en la ejecución de las distintas actividades de seguridad: Conforme se descubren nuevas amenazas y vulnerabilidades, se tienen nuevos riesgos que dan lugar a un nuevo caso de abuso y un nuevo análisis de riesgos. Cambios en el sistema con nuevos componentes de software ó hardware, implica el rehacer el análisis de riesgos y revisar el código de los nuevos componentes software. Nuevos defectos de implementación que modifican las especificaciones ó del sistema implican nuevas revisiones de código y as pruebas de seguridad.

Otras metodologías Microsoft Trustworthy Computing SDL25. 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 Model32.

http://www.microsoft.com/security/sdl/ 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 31http://www128.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 25

26



Metodologías agiles Los métodos ágiles se caracterizan por lograr la satisfacción del cliente a través de entregas rápidas y frecuentes de software utilizable (es decir, iteraciones cortas). Se caracteriza por utilizar un modelo de desarrollo iterativo, con aceptación de cambios en los requisitos finales, integración del cliente en el proceso de desarrollo, desarrollo paralelo de varias versiones y equipos de la organización autónomos. Es un modelo que no sigue el método tradicional lineal: requisitos, diseño, codificación, pruebas, despliegue y operación y mantenimiento. Se caracteriza por el «Manifiesto Ágil»

cuyo

único

objetivo

principal

es:

producir

s o f t w a r e

correcto

funcionalmente lo más rápido posible. Por esta razón, los métodos ágiles evitan ciertas actividades del ciclo de vida: Análisis de impacto en la seguridad, tras cambios en un requisito funcional. No involucran directamente en la producción de software, la documentación y validación necesarias en la mayoría de las evaluaciones de seguridad. Las prácticas de seguridad no se puede llevar a cabo por los miembros del equipo de desarrollo, simultáneamente con otras actividades del ciclo de vida. Requieren conocimientos especializados más allá de lo esperado de los miembros del equipo de desarrollo. Los métodos ágiles no tienen en cuenta la inclusión de expertos en seguridad. Centrarse en cualquier otro objetivo que no sea la producción de software correcto de forma rápida. Es difícil incorporar otros objetivos no funcionales, tales como la fiabilidad, confiabilidad y capacidad de recuperación. El utilizar métodos ágiles para desarrollar software seguro requiere dar cabida a la inclusión necesaria de prácticas 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 separación de funciones, privilegios mínimos y control de acceso basado en roles. Mucha discusión y debate se ha producido respecto a si es posible que los proyectos de software utilicen los métodos ágiles para producir software seguro, en la tabla

siguiente se resume, para cada principio básico en el Manifiesto Ágil [9], su contribución u obstrucción al desarrollo de un software seguro.


Tema 1: El problema de la seguridad en el s o f t w a r e Nº

1

2

3 4 5 6

7

8

9

Principio Prioridad principal es satisfacer al cliente. Esto se debe lograr de forma temprana y continua a través de entrega de software utilizable. Se permite el cambio de requisitos, incluso en la fase más tardía del proceso de desarrollo de procesos. Ventaja competitiva.

Producción de frecuentes entregas de software . Idealmente, varías a la semanas. Se da preferencia a la reducción de los tiempos de entrega. El proyecto es construido en base al compromiso, motivación y participación de sus componentes Los clientes, gerentes y desarrolladores deben colaborar diariamente, durante todo el desarrollo del proyecto. Los desarrolladores deben tener el medio ambiente y apoyo que necesitan. La dirección y el cliente confían en el trabajo hecho por los desarrolladores. La forma más eficiente y eficaz método de transmitir información a los componentes de un equipo de desarrollo es a través de la comunicación cara a cara. La producción de programas útiles es la principal medida del éxito.

10

La agilidad se ve reforzada por la continua atención a la excelencia técnica y buen diseño.

11

Sencillez, que se define como el arte de maximizar la cantidad de trabajo no realizado, es esencial para el éxito de proyectos de

Implicación

Obstructiva

Obstructiva

Obstructiva

Neutral

Neutral

Neutral

Obstructiva

Obstructiva

Explicación A menos que el cliente muestre una sensibilidad muy alta por la seguridad, se obviarán las pruebas de seguridad y si se hacen, no se les asigna tiempo suficiente para especificar, verificar y probar los requisitos de seguridad. A menos que el cliente esté dispuesto a permitir la ampliación 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. A menos que el cliente de mayor prioridad a la seguridad que a la necesidad de entregas rápidas. Podría ser obstructiva si los componentes del proyecto ignoran las prioridades de seguridad. Podría 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 Podría ser contributivo si el ambiente de desarrollo incluye herramientas, plataformas, procesos y prácticas destinadas producir software seguro A menos que los desarrolladores estén fuertemente comprometidos y sean capaces de aplicar prácticas de seguridad, herramientas y hitos de control en el ciclo de vida. El proceso de garantía de la seguridad del software se basa en la documentación de las evidencias para que poder ser evaluadas independientemente por expertos externos al equipo de desarrollo del proyecto.

Si la validez del software se mira solo desde el punto de vista de funcionalidades, no se Obstructiva permitirá la realización de escaneos de vulnerabilidades, pruebas de penetración, o cualquier otra prueba de seguridad. Especialmente cuando «la excelencia técnica y buen diseño» reflejan una fuerte Contributiva experiencia en el compromiso de asegurar el desarrollo de software Si la sencillez es una característica tanto del diseño como del código del software , será Contributiva más fácil de analizar su seguridad.

software

Tabla 4 Principios Manifiesto Ágil y su relación con la Seguridad del Software



1.7. Los pilares de la seguridad del software Introducción Gary McGraw en su libro « Software Security: Building Security In » [16] propone un método o proceso para ayudar a solucionar el problema de la seguridad del s o f t w a r 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): Gestión del riesgo Buenas prácticas de seguridad Gestión del Conocimiento La aplicación 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 se guridad del s of t w

a r e :

Gestión de riesgos Buenas prácticas Gestión 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 aplicación 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 más seguro y confiable. Lo anterior requiere el

utilizar recursos de aseguramiento de la información, de entendimiento del contexto de operación y herramientas de auditoría que tienen por objeto ayudar a los desarrolladores, arquitectos y probadores de software a verificar la calidad, fiabilidad y seguridad del s o f t w a r e que producen o adquieren.



Gestión de riesgos Todos los desarrollos de software en lo que respecta a su seguridad, deberían seguir un enfoque de gestión 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 técnicas de análisis y con la gestión del mismo se pueden mitigar gran parte de los problemas de seguridad futuros del

s o f t w a r e ,

aunque se debe tener en cuenta que los riesgos cambiarán

inevitablemente a lo largo de todo el SDLC. Así mismo la evaluación de riesgos también puede ayudar a priorizar y enfocar recursos. Marco gestión de riesgos

Pruebas basad as en riesgo

Análisis d e riesgos


Arqui tectura Diseño

Codificación e integración

Pruebas

Análisis d e riesgos

Distribución y despliegue

Operación y mantenimiento

REALIMENTACIÓN

Figura 22. Gestión de riesgos a lo largo del SDLC

Durante el ciclo de vida de desarrollo del software, se debe emplear una combinación de métodos y técnicas de análisis y un marco de gestión general de riesgos. Después de una evaluación inicial de riesgos, evaluaciones más específicas, por ejemplo en la etapa de diseño 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 análisis puede identificar consecuencias potencialmente peligrosas de un ataque con éxito sobre el software, mientras que hacia atrás puede determinar si la hipótesis de un ataque es creíble. En la figura-23 se presenta las diferentes actividades relacionadas con el análisis y gestión de riesgos a realizar en las diferentes fases y durante todo el SDLC:

Gestión de riesgos Todo el ciclo de vida

Análisis de riesgos

Requisitos

Diseño y arquitectura

Verificación y valid ación

Figura 23. Actividades de gestión y análisis de ries gos a lo largo del SDLC

Requisitos, al realizar el análisis 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 función de los requisitos generales y de seguridad, configurando la arquitectura en función de las salvaguardas elegidas para protegerlo lo que implica el modelado de amenazas y análisis de la seguridad del diseño. Verificación y validación, que implica la planificación y realización de pruebas basadas en riesgo y análisis de los riegos obtenidos de sus resultados. Ciclo de vida completo, que implica el establecimiento de un proceso de gestión de riesgos para poder realizar el seguimiento y mitigación del riesgo como una actividad más, Gary McGraw en [16] lo denomina «Marco de gestión de riesgos».



Las medidas de seguridad adicionales descubiertas durante la realización del diseño, implementación, pruebas y producción deberían incorporarse de nuevo en la especificación 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 gestión. Finalmente una vez haya entrado en producción, análisis periódicos pueden asegurar el funcionamiento dentro de niveles aceptables de riesgo o determinar los cambios a realizar en la especificación de requisitos, diseño o implementación para mitigar o eliminar los riesgos nuevos o hacer frente a nuevos tipos de amenazas. La información utilizada durante un proceso de evaluación de riesgos de seguridad incluye: La naturaleza de las amenazas al software. Identificación 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 métodos o metodologías de análisis de riesgos que se pueden aplicar al desarrollo de software: MAGERIT. Ministerio de Administraciones Públicas de España MAP su herramienta de análisis de riesgos asociada PILAR oficial en la OTAN (Organización del Tratado del Atlántico Norte) y en la Administración pública española. 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 © Universidad Internacional de La Rioja (UNIR)


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 SelfEvaluation Tool). National Institute on Standards and Technology (NIST) 34. OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation). SEI de la Universidad Carnegie Mellon35. 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. Metodología de evaluación 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 párrafos anteriores, de un proceso continuo de gestión de riesgos que abarque todo el ciclo de vida del

s o f t w a r e ,

en [16] se establece un marco de gestión que permite a una

organización 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.

http://csrc.nist.gov/archive/asset/asset_description.html 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/ 34 35



Medición e Informes 1

2 Identificación de riesgos negocio y técnicos

Comprensión de contexto de l negocio

3

4

Sintetizar y ord enar los riesgos

Definir estrategia mitigación riesgos

Contexto de l negocio 5 Retroalimentación de producción

Figura 24. Marco gestión de riesgos. Extraída de [16]

La aplicación del proceso de gestión 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 gestión son las actividades medición y métricas establecidas para gestionar mejor los riesgos operativos y técnicos, pues permite tomar decisiones objetivas en materia de desarrollo del software y mejorar los procesos internos de desarrollo. El marco de gestión de riesgos propuesto en [16] se compone de las cinco etapas fundamentales, mostradas en la figura-25: Entender el contexto de negocio. La gestión de riesgos, está profundamente afectada por los objetivos del negocio, prioridades y circunstancias, por tanto la primera etapa de la gestión de riesgos del software implica la adquisición del conocimiento sobre su situación, organización, sistemas de información, etc., con el propósito de identificar más fácilmente los riesgos técnicos. Identificar los riesgos del negocio y técnicos. Consiste básicamente en el descubrimiento y descripción de riesgos de negocio y técnicos y su trazabilidad ecuánime a los objetivos de la organización, de tal forma que su impacto sea cuantificado y descrito en términos 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 técnico a gestionar y mitigar.



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

Métricas impactos riesgos de negocio: Se cuantifican de forma económica o impacto en la gestión: coste económico, pérdida de cuota de mercado, costes de reparación, publicidad negativa, etc.

o

Métricas impactos riesgos técnicos: Se cuantifican en términos de la disponibilidad, integridad y confidencialidad de los servicios TIC que soportan el objetivo de negocio: tiempo del sistema caído, accesos no autorizados, robos de información, etc.

Sintetizar y priorizar los riesgos, produciendo una lista priorizada. Consiste en la priorización de los riesgos técnicos identificados en la fase anterior, en función de la importancia de los objetivos y activos afectados y los recursos disponibles para su mitigación. o

Métricas probabilidad o frecuencia de riesgo, usuarios afectados, severidad del riesgo, explotabilidad, relación de aparición de riesgos y mitigados en el tiempo, reproducibilidad, probabilidad de descubrimiento, etc. RIESGO = IMPACTO x PROBABILIDAD de OCURRENCIA

Definir la estrategia de mitigación de riesgos. En base a la lista priorizada de riesgos obtenida, la siguiente tarea es desarrollar una estrategia de mitigación, en base a una serie de parámetros como son: coste, tiempo de reparación, viabilidad y proceso de validación. o

Métricas retorno de la inversión, efectividad de los métodos en términos de impacto económico, porcentaje de riesgo cubierto y residual, etc.

Realizar las correcciones necesarias, aplicar salvaguardas y validarlas . Una vez desarrollada la estrategia de mitigación, se debe realizar la corrección de componentes del sistema con defectos arquitectónicos en el diseño, colisiones de requisitos, errores de autenticación, errores de cifrado, problemas en pruebas etc. conforme a la prioridad marcada.



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

Métricas tanto por ciento de completitud contra la estrategia de mitigación de riesgo, progreso de mitigación de riesgos, riesgos residuales, calidad.

Otro marco de gestión de riesgos en el desarrollado por Microsoft en [29], en la siguiente figura mostramos un resumen. Definición del proyecto Definición de limitaciones Espe cificación de requisitos



Requisitos

 

La valoración y e l análisis de los procesos de seguridad Revisión de la organización de la seguridad Valoración de activos y ame naza s Análisis de vulnerabilidades Análisis de riesgos y plan de mitigación 



Planeamiento

  

Desarrollo de medidas de seguridad Pruebas de componentes Verifica ción de la calid ad de las contramedidas 

Codificación

 

Pruebas de las contramedid as de seguridad Planificación y uso de los medios de prueba Detección de nuevos fallos y bugs 

Pruebas



Políticas de se guridad corporativas, centralizadas y d e sitio Despliegue d e contramed idas y componentes de seguridad Análisis de riesgos y lecciones aprendidas 

Despliegue y operación





Figura 25. Marco gestión de riesgos de Microsoft



Un aspecto importante de la gestión de riesgos es el establecer un marco de métricas de medida que nos pueda dar una idea de cuál es el estado de la seguridad del mi sistema o del software, en concreto se debe medir la información 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 GESTIÓN 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 mitigación del riesgo. Mitigación de riesgo por prioridad: porcentaje resueltas y residuales. Mitigación de riesgo por prioridad: porcentaje resueltas y residuales. Número de riesgos residuales por impacto económico. Número de riesgos identificados por impacto económico. Número de riesgos identificados sin mitigación definida por prioridad. Número de riesgos identificados sin mitigación definida por tipo. Ratio de descubrimiento de riesgo por prioridad. Ratio de descubrimiento de riesgo por tipo. Ratio de mitigación de riesgo por prioridad. Ratio de mitigación de riesgo por tipo. Número de riesgos residuales por impacto calculado. Tabla 5 Medidas gestión de riesgos

Mejores prácticas de seguridad del s o f t w a r e La seguridad del s o f t w a r e es algo más que la eliminación de las vulnerabilidades y la realización de pruebas de penetración. Un aspecto importante de la misma, es la adopción por los gerentes de un enfoque sistémico para incorporar principios de buenas prácticas de Seguridad del

» S o f t w a r e «t o u c h p o i n t

en su Ciclo de

Vida de Desarrollo de Software, para lograr el doble objetivo de producir sistemas con s o f t w a r e más seguro y poder verificar su seguridad, a este nuevo ciclo de vida le denominaremos ciclo de vida del s o f t w a r e seguro S-SDLC.



7. Revisión 8. 5. Patrone s código Configuración de diseño segura 11. 1. Mode lado 3. Ing. 6. Pruebas Revisión 2. Casos 4. Análisis de 9. Test de ataques Requisitos basadas en externa de abuso riesgos penetración seguridad riesgo 10. Operaciones seguridad


Arqui tectura Diseño

Codificación e integración

Pruebas

Distribución y de spl iegue

Operación y mantenimiento

REALIMENTACIÓN

Figura 26. Mejores prácticas 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 sería 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 continuación se enumeran esas actividades o mejores prácticas de Seguridad del Software tomando como referencia las definidas en [16] al que se le añaden otras (en el tema 2 se desarrollan en mayor profundidad estas prácticas): Casos de abuso. Constituyen otra forma de representar la mentalidad del atacante en base a la descripción del comportamiento del sistema bajo un ataque. El diseño de casos de abuso requiere explícita cobertura de lo que debería ser protegido, de quién y por cuánto tiempo. Ingeniería requisitos de seguridad. La seguridad de un sistema y el software que lo soporta debe especificarse en base a unos requisitos de obligada implementación y trazabilidad durante todas las fases del diseño. Estos requisitos pueden ser extraídos del análisis de riesgo realizado, los casos de uso y abuso.



Análisis de riesgo arquitectónico. Es una necesidad en la etapa de arquitectura y diseño la realización de un análisis del riesgo arquitectónico que documente los posibles riesgos de la arquitectura y diseño e identifiquen las posibles amenazas. Patrones de diseño. Son soluciones generales repetibles a un problema de ingeniería de software recurrente, destinadas a obtener un software menos vulnerable y un diseño más resistente y tolerante a los ataques, normalmente se limitan a funciones y controles de seguridad a nivel del sistema, comunicaciones e información. Pruebas de seguridad basados en riesgo. Consiste en el planeamiento y realización de pruebas de verificación y validación de los diferentes componentes y del sistema completo, en base al conocimiento de la arquitectura del software, los resultados del análisis 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 cómo los ataques se llevan a cabo y los métodos más frecuentes de explotación ( exploit ) y técnicas usadas para comprometer el software.

Revisión de código. La revisión de código es una de las actividades de seguridad más importantes a realizar durante el SDLC , pues puede destapar alrededor del 55% de los problemas de la seguridad. las herramientas estáticas de análisis de código de fuente pueden descubrir a nivel del código fallos de implementación y vulnerabilidades comunes. Sin embargo aunque es una práctica muy importante no es suficiente pues por ejemplo, lo problemas arquitectónicos son muy difíciles e incluso imposibles de encontrar revisando solamente el código, sobre todo los que tienen cientos de miles de líneas de código. Lo anterior implica que el combinar la revisión de código y análisis de riesgos arquitectónico aumenta en gran medida la seguridad del s o f t w a r e .



Test penetración. Son pruebas cuyo principal objetivo es obtener una idea de cómo se comporta el software en su entorno de ejecución final, siempre que se realicen en un entorno que simule perfectamente el entono de producción donde la aplicación o sistema prestará sus servicios y que el software presente su arquitectura final. Son extremadamente útiles especialmente si precede de un análisis de riesgo arquitectónico y plan de pruebas basadas en riesgo. Un fallo en este tipo de pruebas, realizadas con herramientas de prueba dinámicas de seguridad en tiempo de ejecución, significa que el sistema o el software es deficiente. Operaciones de Seguridad. Como se ha indicado anteriormente un principio de diseño importante para la seguridad es la « defensa en profundidad» , el sistema hay que protegerlo como un todo, por un lado hay que minimizar al máximo sus vulnerabilidades y diseñarlo de forma resistente para que sea de confianza, por otro hay que securizar su entorno de ejecución y de red al objeto de que la vía de ataque al mismo se deba a su interacción con el software de base (sistema operativo, gestores de base de datos, etc.) y que las acciones maliciosas se puedan detectar en base al tráfico de red. En todo esto proceso son fundamentales las habilidades, experiencia adquirida de ataques producidos y conocimiento del personal de administración de la red, sistemas y seguridad. Revisión externa. La revisión 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 diseño y desarrollo pues aporta otra visión 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 función de los resultados obtenidos habrá incluso que revisar el análisis de riesgos y su gestión, incorporar nuevas amenazas e incluso modificar las especificaciones del sistema. Al igual que la gestión de riesgos, las actividades o buenas prácticas 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 análisis de riesgos con nuevos casos de abuso asociados, e incluso se pude llegar a tener que modificar las especificaciones del sistema.



Gestión del conocimiento Se puede definir el conocimiento como: Conjunto de información de contexto obtenida de la experiencia o el aprendizaje de la puesta en práctica de procesos y procedimientos para alcanzar ciertos objetivos prácticos, se trata de la posesión y acumulación de múltiples datos relacionados entre ellos, que poseen un valor cualitativo mayor que por sí solos, que proporcionan información que se puede incorporar en el desarrollo o mejora de nuevos productos y procesos. Aparte de la generación del conocimiento, para ponerlo en valor es necesario gestionarlo, una de las actividades más importante hoy en día en las organizaciones es la «gestión de conocimiento», básicamente consiste en los procesos que la planifican, controlan, recogen, transfieren, aseguran, aplican o usan y administran de una forma sistemática la información obtenida de la actividad diaria de la organización, junto con los sistemas o programas diseñados para gestionar el uso de ese conocimiento, al objeto de perfeccionar la ejecución de los procesos de la organización. En lo relativo a la seguridad del software, la gestión del conocimiento es cíclica y su principal papel es condensar y difundir las buenas prácticas de seguridad del software, los principios de seguridad del diseño y disciplinas de codificación, para conseguir software más 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 catálogos: o

Principios. Un principio es una declaración de la sabiduría que se deriva de la experiencia. Los principios son útiles tanto para el diagnóstico de fallos de la arquitectura de

s o f t w a r e como

para la práctica de una buena

ingeniería de seguridad. o

Guía. Una guía es una recomendación sobre qué hacer o evitar durante el desarrollo de software, se describen en el plano semántico y pueden ayudar a descubrir defectos arquitectónicos y de la aplicación. Existen directrices para un contexto técnico específico (por ejemplo, J2EE, NET, etc.).



Reglas. Es una recomendación sobre qué hacer o evitar durante el desarrollo de software, que se describe en el plano de la sintaxis, que puede ser verificada a través de análisis léxico o análisis constructivo de software (fuente o binario) y pueden ayudar a descubrir errores de implementación. Existen reglas para lenguajes de programación específicos (por ejemplo, C, C + +, PHP, Java, etc.).

Conocimiento diagnóstico. 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 catálogos 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 cómo los ataques se llevan a cabo y los métodos más frecuentes de explotación ( exploit ) y técnicas usadas para comprometer el software.

o

E x p l o i t s . Es

una instancia particular de un ataque a un sistema informático que

aprovecha una vulnerabilidad específica o un conjunto de ellas. o

Vulnerabilidades. Es un fallo de programación, configuración o diseño que permite, de alguna manera, a los atacantes alterar el comportamiento normal de un programa y realizar algo malicioso como alterar información sensible, interrumpir o destruir una aplicación o tomar su control.



Conocimiento seguridad del s o f t w a r e

Conocimiento descriptivo

Conocimiento diagnóstico

Conocimiento histórico

Principios

Requisitos y d iseño y arquitectura

Guías

Requisitos Diseño arquitectura Codificación

Reglas

Codificación

Patrones de ataque

Requisitos, dise ño Plan d e prue bas y test penetración

Exploit

Pruebas: test de penetración Producción

Vulnerab ilida des

Diseño arquitec tura y software Cod ificación, test de pene tración y producción

Catálogos

Diseño d e software y arquitectura

Figura 27. Catalogo del conocimiento de la seguridad del software

Conocimiento histórico. Incluye el conocimiento de catálogos de riesgos históricos y, en algunos casos, vulnerabilidades p.ej., la colección 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 prácticas de seguridad de software «touchpoints» tal y como se puede ver en la figura 31. Por ejemplo, las reglas son sumamente útiles para el análisis estático y actividades de inspección de código.



Riesgos históricos

Guías

Patrones ataque

Reglas Vulnerabilidades

Principios

Exploits

8. Re visión externa 5. Casos de abuso

4. Pruebas 1. Revisión 6. Re quisitos 2. Análisis d e basadas en código seguridad riesgos riesgo


Arquitectura Diseño

Plan de pruebas

Codificación

2. Análisis riesgos

3. Pruebas 7. Operaciones penetración Seguridad

Pruebas y resultados

Realimentación de producción

Figura 28. Relación de los catálogos conocimiento de seguridad de software y las mejores prácticas de seguridad de software. Extraída de [16]

Otro aspecto importante es la formación del equipo de diseño, análisis, integración y desarrollo, pues todos los procesos, prácticas, tecnologías y herramientas de seguridad del software serán de poca utilidad si el personal responsable ponerlos en práctica y usarlas no disponen de los conocimientos necesarios. En este sentido algunas organizaciones han establecido programas de certificación profesionales para desarrolladores de software que disponen pruebas que evalúan y certifican los conocimientos en desarrollo de software seguro. Esta formación debería incluir como mínimo en su alcance especificación, diseño e implementación de software confiable, modelado de ataques, análisis de vulnerabilidades, debilidades de la arquitectura y diseño. A continuación 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 certificación CISSP que abarca una visión integral de todo el proceso de desarrollo de software. Al igual que el CISSP, la CSSLP evalúa 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 España tenemos: Máster Universitario en Seguridad informática Universidad Internacional de la Rioja (UNIR)42.

1.8. Metodologías y estándares Introducción Las metodologías y estándares, consisten básicamente en guías de comportamiento específicas destinadas a aplicar una política o políticas. Su aplicación a la seguridad del software consiste en el desarrollo de procesos que implementen técnicas de seguridad en todas las actividades que intervienen en el ciclo de vida de desarrollo de software. Para conseguir lo anterior, las organizaciones deben implantar un estándar de aseguramiento de la calidad de

s o f t w a r e y

un estándar de

seguridad.

https://www.isc2.org/csslp-certification.aspx http://software-security.sans.org/ 41 http://www.eccouncil.org/ecsp/index.htm 42 http://www.unir.net/master-online-seguridad-informatica.aspx 39

40



Las organizaciones relacionadas con normas internacionales sobre seguridad de la información son: International Organization for Standardization (ISO). International Electrotechnical Commission (IEC). National Institute of Standards and Technology (NIST). A continuación se realiza una descripción resumida de los estándares más importantes que las organizaciones pueden adoptar para conseguir los beneficios que suponen tener procesos implantados de calidad y seguridad del software en todas las actividades del SDLC, así como una aclaración de las diferencias entre seguridad del software versus aseguramiento de la calidad.

Seguridad del s o f t w a r e v e r s u s 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 s o f t w a r e tiene por objetivo que tanto el software como su entorno de ejecución presenten el mínimo de vulnerabilidades y por tanto su superficie de ataque sea la menor posible, de forma sea confiable a pesar de la presencia de un ambiente externo hostil con ciberataques en curso. Estas diferencias se pueden caracterizar también en términos de amenazas, las principales de la calidad son internas no intencionadas debidas a errores o descuidos, es decir la presencia de defectos en el software que pongan en peligro su capacidad de funcionar correctamente y de manera previsible. Por otro lado las amenazas a la seguridad son internas y externas e incluyen una intención maliciosa materializada en posibles ciberataques que puedan recibir el software o su entorno de ejecución del software cuando se tiene un comportamiento

impredecible (por cualquier razón).



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

Estándares de aseguramiento de la calidad Estándares de calidad o

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

o

ISO 9126. Calidad del producto.

o

ISO 14598. Evaluación de productos de software. ISO 12119. Requerimientos de calidad y prueba de COTS.

o

ISO 15939. Proceso de medición de software.

o

ISO 9000. Familia de normas son normas de calidad establecidas por la ISO.

o

– UNE-EN ISO 9000. Sistemas de gestión de la calidad. Fundamentos y

vocabulario (ISO 9000:2000). – UNE-EN 150 9000. Sistemas de gestión de la calidad. Requisitos (ISO

9001:2000). – UNE-EN 150 9000. Sistemas de gestión de la calidad. Directrices para la mejora

del desempeño (ISO 9004:2000). Modelos calidad del s o f t w a r e o

El CMM - CMMI (Capability Maturity Model) es un modelo de calidad del software que clasifica a las organizaciones en cinco niveles en función de la

madurez de los procesos que se realizan para producir software. Establece un conjunto de prácticas o procesos clave agrupados en áreas con un conjunto de buenas prácticas: – Definidas en un procedimiento registrado. – Provistas de los recursos y conocimiento necesarios. – Ejecutadas de un modo sistémico, universal y uniforme. – Medidas. – Verificadas.



En la siguiente tabla se puede ver el alcance de dichos niveles. NIVEL MADUREZ Nivel 1 Nivel 2

ALCANCE Inicial. Empresas que no tienen procesos. Repetible. El proyecto es gestionado y controlado durante el desarrollo del mismo. Definido. Gestión e ingeniería de proyectos está

Nivel 3

establecida, documentada y existen métricas de consecución de objetivos.

Nivel 4 Nivel 5

Definido. Proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Gestionado. Los procesos de los proyectos y organización orientados a la mejora de las actividades. Tabla 6

o

Alcance niveles CMM-CMMI

ISO/IEC 12207. Modelos de Ciclos de Vida del Software, define los procesos del ciclo de vida adquisición, suministro, mantenimiento y operación de los sistemas de software.

o

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

Estándares 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 cómo 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 garantía.



En la figura siguiente se muestra la relación entre las actividades del ciclo de vida de la norma y las actividades de gestión de riesgos de seguridad a las que la norma debe proporcionar apoyo. Procesos de Gestión Técnicos Aseguramiento Necesidades Información Riesgos

2. Plan actividades ase uramiento

Caso Seguridad

Plan aseguramiento

Plan Aseguramiento a r o j e M s o t a D

Actividades gestión de riesgos

Procesos del ciclo de vida Expectativas y Resultados

3. Establecer y mantener el Caso Seguridad Medidas Seguridad

Actividades de medidas

Medidas Seguridad

Caso Seguridad 4. Monitorizar las actividades de aseguramiento y productos

Figura 29. ISO / IEC 15026 relación entre las actividades del ciclo de vida de la norma y las actividades de gestión de riesgos de seguridad. Extraída 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 Ingeniería de Seguridad de Sistemas es un modelo derivado del CMM y que describe áreas de ingeniería de seguridad y las características esenciales de los procesos que deben existir en una organización para la mejora y evaluación de la madurez de la ingeniería de los procesos de seguridad utilizados para producir productos de sistemas confiables y seguros. El alcance de los procesos incluidos en la norma abarcan todas las actividades del ciclo de vida del sistema e ingeniería de seguridad, incluyendo la definición conceptual, análisis de requisitos, diseño, desarrollo, integración, instalación, operación, mantenimiento y baja.



Pretende servir como: o

Herramienta de evaluación de las prácticas de ingeniería de seguridad y mejora continua de las mismas.

o

Mecanismo o método estándar de evaluación de la capacidad de los proveedores de ingeniería de seguridad por los clientes. Indica la necesidad métrica, pero no indica ninguna.

o

Base para la implantación de un mecanismo de evaluación y certificación El método de evaluación se denomina SSAM (SSE-CMM Appraisal Method). Las técnicas de evaluación pueden ser utilizadas en la aplicación del modelo para la selección de proveedores.

Define veintidós Áreas de Proceso (PA) de seguridad que enmarcan los objetivos y los mecanismos que se utilizarán para la coordinación de las actividades de ingeniería de seguridad con todas las demás actividades de ingeniería y equipos: o

Dominio: Once áreas de procesos de ingeniería seguridad, sesenta practicas.

o

Capacidad: Once áreas dedicadas a la gestión de proyectos y organización.

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



En la tabla siguiente se pueden ver las Áreas de Proceso (PA) de ingeniería seguridad y su propósito: AREA DE PROCESOS

OBJETIVOS

1. Administrar los controles de seguridad

Asegurar que los controles de seguridad correctamente configurados y operados.

2. Evaluar el impacto

Alcanzar un entendimiento de los riesgos de seguridad asociados con la operación del sistema dentro de un ambiente de operación o producción definido.

3. Evaluar riesgos de seguridad

estén

Identificar las vulnerabilidades del sistema y determinar su potencial de explotación.

Alcanzar un entendimiento de las amenazas a la seguridad del sistema. 5. Valoración vulnerabilidades Alcanzar un entendimiento de las vulnerabilidades de seguridad del sistema. Asegúrese de que los artefactos y procesos de trabajo 6. Construir argumentos claramente proporcionan la evidencia de que las seguridad necesidades del cliente relativas a la seguridad se han cumplido. Asegúrese de que todos los miembros del equipo del proyecto son conscientes y participan en las actividades de ingeniería de seguridad en la medida que son necesarios 7. Coordinar la seguridad para desempeñar sus funciones, coordinar y comunicar todas las decisiones y recomendaciones relacionadas con la seguridad. Detección y seguimiento de los incidentes internos y externos relacionados con la seguridad, responder a los 8. Monitorización seguridad incidentes de acuerdo con la política, identificar y controlar los cambios de la política de seguridad en conformidad con los objetivos de seguridad. Revisión 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 9. Seguridad en la entradas los miembros del equipo del proyecto entienden la seguridad para que puedan desempeñar sus funciones. Garantizar que la solución refleja las aportaciones de seguridad proporcionada. 10.Especificar las necesidades Aplicables a todas las partes, incluido el cliente, llegar a de seguridad una común comprensión de las necesidades de seguridad. 4. Valoración de la amenaza

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 ingeniería seguridad sus metas y objetivos. Extraída de [17]

Developing Software Project Life Cycle Processes Norma IEEE 10742006. Norma que proporciona soporte para la priorización e integración de controles de seguridad en el software y sistemas. Incluye medidas de seguridad en el SDLC como el análisis de riesgos de seguridad y define un perfil de seguridad para la evaluación de la integridad del software, así como la documentación necesaria para garantizar las medidas de seguridad.



Proporciona un enfoque sistemático para la definición específica de requisitos de seguridad y produce artefactos de seguridad y calidad para cada actividad, así como la auditoría, mejora, mantenimiento de producto y del proceso de seguridad. También define la intensificación de las actividades de capacitación en seguridad. Information Technology—Security Techniques. ISO/IEC TR 15443. Norma guía de los profesionales de las tecnologías de seguridad en la selección de un método de aseguramiento cuando se especifica, selecciona o se desarrolla un servicio de seguridad, producto o factor de entorno, como organización o personal. El objetivo es comprender el tipo de garantía y los recursos necesarios para lograr un producto final confiable, que cumpla los requisitos seguridad. El marco incluye una clasificación del aseguramiento y un modelo genérico 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 también demuestra cómo la garantía 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 organización. Proporciona a los administradores y otros profesionales de la seguridad responsables de la elaboración de un programa de garantía de seguridad, o de desarrollo de ingeniería de seguridad un proceso o marco de dirección, que implica el garantizar la seguridad de estos programas o desarrollos, mediante auditorías de evaluación (por ejemplo, ISO 9000, SSE-CMM (ISO/IEC 21827), ISO / IEC 154083), u otras actividades de aseguramiento. ISO / IEC 24772. Proyecto 22, grupo de trabajo para evitar vulnerabilidades en lenguajes de programación proporcionando una orientación a los programadores sobre cómo evitar las vulnerabilidades que se pueden introducir en el software al utilizar ciertas características de un lenguaje de programación seleccionado para el desarrollo de un proyecto software, sugiriendo alternativas de patrones de codificación que las eviten. Así mismo ayuda a elegir las herramientas de análisis estático, detección de vulnerabilidades y orientación de codificación para mejorar la eficacia en la reducción de vulnerabilidades.



ISO/IEC 17799 Information technology—Security techniques—Code of practice for information security management. Referencia de la seguridad de la información estándar y aceptada internacionalmente, fue desarrollada como resultado de la demanda de la industria, el gobierno y el comercio «Código de buenas prácticas para la Gestión de la Seguridad de la Información», proporciona marco común para permitir a las organizaciones desarrollar, aplicar y medir eficazmente la gestión de la seguridad de la información dirigidas a los responsables de iniciar, implantar o mantener la seguridad de una organización. La seguridad de la información se define en el estándar como: «Seguridad de la información: preservación de la confidencialidad (asegurando que solo quienes estén autorizados pueden acceder a la información), integridad (asegurando que la información y sus métodos de proceso son exactos y completos) y disponibilidad (asegurando que los usuarios autorizados tienen acceso a la información y a sus activos asociados cuando lo requieran)». Su objetivo es proporcionar una base común para desarrollar normas de seguridad dentro de las organizaciones para proteger adecuadamente los activos de información que aseguren la continuidad del negocio, siendo una práctica eficaz de la gestión de la seguridad. El estándar se organizan en los siguientes dominios de control o buenas prácticas de protección para cubrir todos los puntos que los responsables de la gestión de la seguridad deben tener en cuenta: o

Política de seguridad de la información. Soporte a la gestión de la política de seguridad de la información

o

Organización de la seguridad de la información. Definición de los roles y sus responsabilidades de cada elemento encargados de la seguridad en la organización

o

Gestión de activos de información. Clasificación y protección de los activos de la organización.

o

Seguridad de los recursos humanos. Concienciación de los usuarios y reducción de sus errores al mínimo.

o

Seguridad física y ambiental. Evitar accesos no autorizados y protección frente a incidentes o catástrofes de carácter ambiental.

o

Gestión de las comunicaciones y operaciones. Proteger y asegurar las comunicaciones y operaciones críticas de la organización.



Control de accesos. Evitar accesos lógicos no autorizados a la información de la organización.

o

Adquisición, desarrollo y mantenimiento de sistemas de información. Realización

de

todas

las

etapas

(requisitos,

diseño

y

arquitectura,

implementación, etc.) de un SDLC de un software o sistema incluyendo buenas prácticas de seguridad. o

Gestión de continuidad del negocio. Implantación de medidas organizativas y técnicas de recuperación y planes de continuidad en la organización y gestión de incidentes en la seguridad de la información.

o

Conformidad. Implantar planes de auditoría interna para detectar desviaciones con respecto a la política de seguridad de la información y normas aplicables (LOPD, etc.) valorando su nivel de adecuación, implantación y gestión de cada control de la norma en la organización: seguridad lógica, física, organizativa y legal.

Figura 31.

Pirámide de los dominios de control de la seguridad de la información. Extraída de

http://cxo-community.com.ar/articulos/blogs/blogs-metodologia-legislacion/4811-la-leyenda-iso17799-la-seguridad-de-los-activos-de-informacion-parte-2.html

Dentro de cada sección, se especifican los objetivos de los distintos controles para la seguridad de la información y una guía para su implantación, en total 36. De estos de derivan 127 prácticas, procedimientos o mecanismos que reducen el nivel de riesgo, aunque cada organización debe considerar previamente cuántos serán realmente los aplicables según sus propias necesidades, pues unos tienen más relación con las políticas estratégicas de la organización, otros en actividades de supervisión y control y los restantes aplican actividades de operación del día a día.



La adopción de la norma ISO 17799 proporciona diferentes ventajas a una organización: o o

Marco efectivo de la gestión de la seguridad. Aumento del nivel de seguridad los activos y sistemas de información de la organización.

o

Implantación de procesos de mejora continua.

o

Implantación de medidas de continuidad del negocio.

o

Implantación procesos de auditoría interna para obtener un estado de la seguridad de la organización.

ISO/IEC 15408, Evaluation Criteria for IT Security . The Common Criteria. Los criterios comunes (CC) permiten comparar los resultados entre evaluaciones de productos independientes en base a un conjunto común de requisitos funcionales para los productos hardware, software o firmware de las TIC, estableciendo un nivel de confianza en el grado en el que el producto satisface la funcionalidad de seguridad en base a la superación de unas pruebas aplicadas. Los CC contribuyen a aumentar la confianza de los que adquieran productos TIC que incluyan en funciones de seguridad pues pueden determinar más fácilmente cuándo un producto cumple una serie de requisitos pues exige a los fabricantes de los productos certificados publicar una documentación exhaustiva sobre la seguridad de los productos evaluados por laboratorios independientes. En lo relativo a la seguridad del software, los niveles EAL más altos poseen un nivel de garantía de evaluación que captura un conjunto específico de requisitos de seguridad, de los que es posible deducir algunas propiedades generales que el software debe exhibir para alcanzarlos:

o

EAL 5: El sistema debe ser semiformalmente diseñado y probado basado en un modelo formal y una presentación semiformal de la especificación funcional y el diseño de alto nivel, de forma que las vulnerabilidades resistan relativamente a los ataques de penetración. Esta propiedad también se aplica al diseño de software.

o

EAL 6: Igual que EAL 5 y además el diseño debe ser semiformalmente verificado. Como el anterior, este establecimiento también debe aplicarse al diseño de software.



EAL 7: Igual que EAL 6, más el diseño debe ser verificado oficialmente y formalmente testeado. Como el anterior, este establecimiento también debe aplicarse al diseño de software.

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 más importantes en aplicaciones WEB . Edición

en

español.

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. Edición en español. 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]. Guía de Seguridad de la STIC (CCN-STIC-400). Manual de Seguridad de las Tecnologías de la Información y Comunicaciones . Centro Criptológico 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. DÍAZ. Estudio de Técnicas Automáticas de Análisis 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 Administración Electrónica. Recuperado el 27 de marzo de 2013 de: http://www.boe.es/boe/dias/2010/01/29/pdfs/BOE-A-20101330.pdf [23]. Juan Luis G. Rambla, José María Alonso Cebrián. (2009). Esquema Nacional de Seguridad con Microsoft . Microsoft Ibérica 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-introhandout.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_PatternsKnowing_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


apuntesprofesort1

Recommend Documents