En Profundidad - El problema de la seguridad del software

Boletín de observación tecnológica en Defensa 49

El problema de la seguridad del software Autor: Cte. Javier Bermejo Higuera, Responsable de la Unidad de Ingeniería y Seguridad del CESTIC, MINISDEF; Cap. Juan Ramón Bermejo Higuera, Investigador seguridad TIC, INTA. Palabras clave: software, security, abuse case, static analysis, dynamic analysis, risk analysis, security requirement, attack pattern, review, SDLC, risk based tests. Metas tecnológicas relacionadas: MT 6.5.1; MT 6.5.2. Introducción Hoy en día, los ataques cibernéticos son cada vez más frecuentes, están más organizados y resultan más cos-tosos por el daño que infligen a las administraciones públicas, empresas privadas, redes de transporte, redes de suministro y otras infraestructuras críticas desde la energía a las finan-zas, hasta el punto de poder llegar a ser una amenaza a la prosperidad, la seguridad y la estabilidad de un país. En la figura 1 se puede observar un gráfico cualitativo en el que se mues-tran diversos incidentes ocurridos a lo largo de los últimos quince años en relación con su nivel de compleji-dad. Como se aprecia, la amenaza es creciente con los años y cada vez su nivel de complejidad es más elevado. La sociedad actual está cada vez más En Profundidad vinculada al ciberespacio. Un elemen-to importante del mismo lo constitu-yen el software o las aplicaciones que proporcionan los servicios, utilidades y funcionalidades. Sin embargo es-tas aplicaciones presentan defectos, vulnerabilidades o configuraciones inseguras que pueden ser explotadas por atacantes de diversa índole, des-de aficionados hasta organizaciones de cibercrimen o incluso estados en acciones de ciberguerra, utilizándolas como plataformas de ataque compro-metiendo los sistemas y redes de la organización. La cada vez más consolidada intro-ducción de dispositivos móviles no ha hecho más que multiplicar el nú-mero de elementos, incrementando enormemente la superficie de vulne-rabilidad con multitud de aplicaciones que la gente se baja sin demasiadas precauciones y sin una conciencia de la seguridad muy sólida, elevando ex-ponencialmente los riesgos debido a la conectividad global. El problema de la peguridad del poftware Nadie quiere software defectuoso e inseguro, especialmente los desa-rrolladores cuyo código desarrollado contiene vulnerabilidades derivadas de errores cometidos y desconoci-miento de prácticas de seguridad, pero la realidad desborda con creces los mejores deseos. Las vulnerabili-dades vienen derivadas de una serie de causas posibles que hacen que el software resulte inseguro como se pone de manifiesto en el informe de Klocwork 3: • Tamaño excesivo y complejidad de las aplicaciones. • Mezcla de código proveniente de varios orígenes como compras a otra compañía y reutilización de otros existentes, lo que puede pro-ducir comportamientos e interac-ciones no esperados de los com-ponentes del software. • Defectuosa integración de los componentes del software, esta-bleciendo relaciones de confianza inadecuadas entre ellos, etc. • Debilidades y fallos en la especi-ficación de requisitos y diseño no basados en valoraciones de riesgo y amenazas. • Uso de entornos de ejecución con componentes que contienen vul-nerabilidades o código malicioso embebido, como pueden ser ca-pas de middleware, sistema ope-rativo u otros componentes COTS. • No ejecución de pruebas de segu-ridad basadas en riesgo. • Falta de las herramientas y un en-torno de pruebas apropiado que simule adecuadamente el entorno real de ejecución. • Cambios de requisitos del proyec-to durante la etapa de codificación. • Mezcla de equipos de desarrolla-dores, entre los que pueden haber equipos propios de desarrollos, asistencias técnicas, entidades subcontratadas, etc. • Falta de conocimiento de prácticas de programación segura de los de-sarrolladores en el uso de lengua-jes de programación propensos a cometer errores como C y C++ y utilización de herramientas de de-sarrollo inadecuadas. • No controlar la cadena de suminis-tro del software, lo cual puede dar lugar a la introducción de código malicioso en origen. • No seguir, por parte de los desa-rrolladores, las guías normalizadas Fig. 1. Incidentes de seguridad. (Fuente propia). 22 Boletín de Observación Tecnológica en Defensa n.º 49. Primer trimestre 2016


Boletín de observación tecnológica en Defensa 49
To see the actual publication please follow the link above