Las vulnerabilidades son fallas en un sistema informático que debilitan la seguridad general del sistema.
A pesar de las intenciones de lograr una corrección total, prácticamente todo el hardware y el software contienen errores que hacen que el sistema no se comporte como se espera. Si el error puede permitir a un atacante comprometer la confidencialidad, la integridad o la disponibilidad de los recursos del sistema, se denomina vulnerabilidad. Las prácticas de desarrollo de software inseguras , así como los factores de diseño como la complejidad, pueden aumentar la carga de vulnerabilidades. Existen diferentes tipos, más comunes en diferentes componentes, como hardware, sistemas operativos y aplicaciones.
La gestión de vulnerabilidades es un proceso que incluye la identificación de sistemas y la priorización de los más importantes, la búsqueda de vulnerabilidades y la adopción de medidas para proteger el sistema. La gestión de vulnerabilidades suele ser una combinación de remediación (reparación de la vulnerabilidad), mitigación (incremento de la dificultad o reducción del peligro de las vulnerabilidades) y aceptación de riesgos que no son económicos o prácticos de eliminar. Las vulnerabilidades pueden calificarse según el riesgo de acuerdo con el Sistema de puntuación de vulnerabilidades comunes u otros sistemas, y añadirse a bases de datos de vulnerabilidades. A fecha de 2023 [update], hay más de 20 millones de vulnerabilidades catalogadas en la base de datos de vulnerabilidades y exposiciones comunes (CVE).
Una vulnerabilidad se inicia cuando se introduce en el hardware o software. Se activa y se puede explotar cuando el software o hardware que contiene la vulnerabilidad está en funcionamiento. La vulnerabilidad puede ser descubierta por el proveedor o por un tercero. Revelar la vulnerabilidad (como un parche o de otra manera) está asociado con un mayor riesgo de vulneración porque los atacantes suelen actuar más rápido que los parches que se lanzan. Independientemente de si se lanza un parche para remediar la vulnerabilidad, su ciclo de vida eventualmente terminará cuando el sistema, o versiones anteriores del mismo, dejen de usarse.
A pesar del objetivo de los desarrolladores de entregar un producto que funcione completamente como se esperaba, prácticamente todo el software y hardware contiene errores. [1] Si un error crea un riesgo de seguridad, se denomina vulnerabilidad. [2] [3] [4] A menudo se lanzan parches de software para corregir vulnerabilidades identificadas, pero las que permanecen desconocidas ( días cero ), así como las que no han sido parcheadas, siguen siendo responsables de la explotación. [5] Las vulnerabilidades varían en su capacidad de ser explotadas por actores maliciosos, [2] y el riesgo real depende de la naturaleza de la vulnerabilidad, así como del valor del sistema circundante. [6] Aunque algunas vulnerabilidades solo se pueden utilizar para ataques de denegación de servicio , las más peligrosas permiten al atacante inyectar y ejecutar su propio código (llamado malware ), sin que el usuario sea consciente de ello. [2] Solo una minoría de vulnerabilidades permiten la escalada de privilegios , que es necesaria para ataques más graves. [7] Sin una vulnerabilidad, el exploit no puede obtener acceso. [8] También es posible que el malware se instale directamente, sin un exploit, si el atacante utiliza ingeniería social o implanta el malware en un software legítimo que se descarga deliberadamente. [9]
Los factores de diseño fundamentales que pueden aumentar la carga de vulnerabilidades incluyen:
Algunas prácticas de desarrollo de software pueden afectar el riesgo de que se introduzcan vulnerabilidades en una base de código. La falta de conocimiento sobre el desarrollo seguro de software o la presión excesiva para entregar funciones rápidamente pueden dar lugar a que se introduzcan vulnerabilidades evitables en el código de producción, especialmente si la seguridad no es una prioridad en la cultura de la empresa . Esto puede dar lugar a vulnerabilidades no deseadas. Cuanto más complejo sea el sistema, más fácil será que las vulnerabilidades pasen desapercibidas. Algunas vulnerabilidades se plantan deliberadamente, lo que podría deberse a cualquier motivo, desde un empleado descontento que vende el acceso a piratas informáticos hasta sofisticados esquemas patrocinados por el estado para introducir vulnerabilidades en el software. [14] Las revisiones de código inadecuadas pueden dar lugar a errores que se pasan por alto, pero también existen herramientas de análisis de código estático que se pueden utilizar como parte de las revisiones de código y que pueden encontrar algunas vulnerabilidades. [15]
DevOps , un flujo de trabajo de desarrollo que enfatiza las pruebas y la implementación automatizadas para acelerar la implementación de nuevas características, a menudo requiere que a muchos desarrolladores se les otorgue acceso para cambiar configuraciones, lo que puede llevar a la inclusión deliberada o inadvertida de vulnerabilidades. [16] La compartimentación de dependencias, que a menudo es parte de los flujos de trabajo de DevOps, puede reducir la superficie de ataque al reducir las dependencias a solo lo necesario. [17] Si se utiliza software como servicio , en lugar del hardware y software propios de la organización, la organización depende del proveedor de servicios en la nube para prevenir vulnerabilidades. [18]
La Base de Datos Nacional de Vulnerabilidad clasifica las vulnerabilidades en ocho causas fundamentales que pueden superponerse, entre ellas: [19]
Los errores de seguridad deliberados pueden introducirse durante o después de la fabricación y hacer que el circuito integrado no se comporte como se espera en determinadas circunstancias específicas. Probar errores de seguridad en el hardware es bastante difícil debido al tiempo limitado y a la complejidad de los chips del siglo XXI [22] , mientras que la globalización del diseño y la fabricación ha aumentado la posibilidad de que estos errores sean introducidos por actores maliciosos [23] .
Aunque las vulnerabilidades de los sistemas operativos varían según el sistema operativo que se utilice, un problema común son los errores de escalada de privilegios que permiten al atacante obtener más acceso del que se le debería permitir. Los sistemas operativos de código abierto como Linux y Android tienen un código fuente de libre acceso y permiten que cualquiera contribuya, lo que podría permitir la introducción de vulnerabilidades. Sin embargo, las mismas vulnerabilidades también ocurren en sistemas operativos propietarios como Microsoft Windows y los sistemas operativos de Apple . [24] Todos los proveedores de sistemas operativos de buena reputación proporcionan parches con regularidad. [25]
Las aplicaciones cliente-servidor se descargan en las computadoras de los usuarios finales y, por lo general, se actualizan con menos frecuencia que las aplicaciones web. A diferencia de las aplicaciones web, interactúan directamente con el sistema operativo del usuario . Las vulnerabilidades comunes en estas aplicaciones incluyen: [26]
Las aplicaciones web se ejecutan en muchos sitios web. Debido a que son inherentemente menos seguras que otras aplicaciones, son una fuente importante de violaciones de datos y otros incidentes de seguridad. [27] [28] Pueden incluir:
Los ataques utilizados contra vulnerabilidades en aplicaciones web incluyen:
Hay poca evidencia sobre la efectividad y la relación costo-beneficio de las diferentes medidas de prevención de ciberataques. [31] Aunque estimar el riesgo de un ataque no es sencillo, el tiempo medio de vulneración y el costo esperado pueden considerarse para determinar la prioridad para remediar o mitigar una vulnerabilidad identificada y si es rentable hacerlo. [32] Aunque la atención a la seguridad puede reducir el riesgo de ataque, lograr una seguridad perfecta para un sistema complejo es imposible, y muchas medidas de seguridad tienen desventajas inaceptables en términos de costo o usabilidad. [33] Por ejemplo, reducir la complejidad y la funcionalidad del sistema es eficaz para reducir la superficie de ataque . [34]
Una gestión de vulnerabilidades exitosa generalmente implica una combinación de remediación (cerrar una vulnerabilidad), mitigación (aumentar la dificultad y reducir las consecuencias de las vulnerabilidades) y aceptar un cierto riesgo residual. A menudo se utiliza una estrategia de defensa en profundidad para múltiples barreras contra los ataques. [35] Algunas organizaciones escanean solo las vulnerabilidades de mayor riesgo, ya que esto permite la priorización en el contexto de la falta de recursos para solucionar cada vulnerabilidad. [36] Es probable que el aumento de los gastos tenga rendimientos decrecientes . [32]
La remediación corrige las vulnerabilidades, por ejemplo, descargando un parche de software . [37] Los escáneres de vulnerabilidad de software normalmente no pueden detectar vulnerabilidades de día cero, pero son más eficaces para encontrar vulnerabilidades conocidas basándose en una base de datos. Estos sistemas pueden encontrar algunas vulnerabilidades conocidas y recomendar correcciones, como un parche. [38] [39] Sin embargo, tienen limitaciones que incluyen falsos positivos . [37]
Las vulnerabilidades solo se pueden explotar cuando están activas (el software en el que están integradas se está ejecutando activamente en el sistema). [40] Antes de que el código que contiene la vulnerabilidad se configure para ejecutarse en el sistema, se lo considera portador. [41] Las vulnerabilidades latentes pueden ejecutarse, pero no lo están en ese momento. El software que contiene vulnerabilidades latentes y portadoras a veces se puede desinstalar o deshabilitar, eliminando el riesgo. [42] Las vulnerabilidades activas, si se distinguen de los otros tipos, se pueden priorizar para aplicar parches. [40]
La mitigación de vulnerabilidades son medidas que no cierran la vulnerabilidad, pero hacen que sea más difícil explotarla o reducen las consecuencias de un ataque. [43] Reducir la superficie de ataque , en particular para las partes del sistema con acceso de root (administrador), y cerrar las oportunidades para que los exploits se aprovechen de los privilegios es una estrategia común para reducir el daño que puede causar un ciberataque. [37] Si no hay un parche disponible para el software de terceros, puede ser posible deshabilitar temporalmente el software. [44]
Una prueba de penetración intenta entrar en el sistema a través de un exploit para ver si el sistema es inseguro. [45] Si una prueba de penetración falla, no significa necesariamente que el sistema sea seguro. [46] Algunas pruebas de penetración se pueden realizar con software automatizado que prueba vulnerabilidades conocidas frente a exploits existentes. [47] Otras pruebas de penetración las realizan hackers capacitados. Muchas empresas prefieren subcontratar este trabajo, ya que simula un ataque externo. [46]
El ciclo de vida de una vulnerabilidad comienza cuando se introducen vulnerabilidades en el hardware o el software. [48] La detección de vulnerabilidades puede ser realizada por el proveedor del software o por un tercero. En este último caso, se considera más ético revelar inmediatamente la vulnerabilidad al proveedor para que pueda ser reparada. [49] Las agencias gubernamentales o de inteligencia compran vulnerabilidades que no han sido divulgadas públicamente y pueden usarlas en un ataque, almacenarlas o notificar al proveedor. [50] A partir de 2013, los Cinco Ojos (Estados Unidos, Reino Unido, Canadá, Australia y Nueva Zelanda) capturaron la pluralidad del mercado y otros compradores importantes incluyeron a Rusia, India, Brasil, Malasia, Singapur, Corea del Norte e Irán. [51] Los grupos criminales organizados también compran vulnerabilidades, aunque por lo general prefieren kits de explotación . [52]
Incluso las vulnerabilidades que son conocidas públicamente o que están parcheadas suelen ser explotables durante un período prolongado. [53] [54] Los parches de seguridad pueden tardar meses en desarrollarse, [55] o pueden no desarrollarse nunca. [54] Un parche puede tener efectos negativos en la funcionalidad del software [54] y los usuarios pueden necesitar probar el parche para confirmar la funcionalidad y la compatibilidad. [56] Las organizaciones más grandes pueden no identificar y parchar todas las dependencias, mientras que las empresas más pequeñas y los usuarios personales pueden no instalar los parches. [54] Las investigaciones sugieren que el riesgo de ciberataque aumenta si la vulnerabilidad se hace pública o se lanza un parche. [57] Los ciberdelincuentes pueden aplicar ingeniería inversa al parche para encontrar la vulnerabilidad subyacente y desarrollar exploits, [58] a menudo más rápido de lo que los usuarios instalan el parche. [57]
Las vulnerabilidades se vuelven obsoletas cuando el software o las versiones vulnerables dejan de usarse. [49] Esto puede llevar un período de tiempo prolongado; en particular, puede que no sea posible reemplazar el software industrial incluso si el fabricante deja de brindarle soporte. [59]
Una escala que se utiliza habitualmente para evaluar la gravedad de las vulnerabilidades es la especificación de código abierto Common Vulnerability Scoring System (CVSS). El CVSS evalúa la posibilidad de explotar la vulnerabilidad y comprometer la confidencialidad, disponibilidad e integridad de los datos. También tiene en cuenta cómo se podría utilizar la vulnerabilidad y qué tan compleja debería ser la explotación. La cantidad de acceso necesario para la explotación y si podría llevarse a cabo sin interacción del usuario también se tienen en cuenta en la puntuación general. [60] [61]
Alguien que descubre una vulnerabilidad puede divulgarla inmediatamente ( divulgación completa ) o esperar hasta que se haya desarrollado un parche ( divulgación responsable o divulgación coordinada). El primer enfoque es elogiado por su transparencia, pero el inconveniente es que es probable que el riesgo de ataque aumente después de la divulgación sin un parche disponible. [62] Algunos proveedores pagan recompensas por errores a quienes les informan vulnerabilidades. [63] [64] No todas las empresas responden positivamente a las divulgaciones, ya que pueden causar responsabilidad legal y sobrecarga operativa. [65] No existe ninguna ley que exija la divulgación de vulnerabilidades. [66] Si un tercero descubre una vulnerabilidad que no la divulga al proveedor o al público, se denomina vulnerabilidad de día cero , a menudo considerada el tipo más peligroso porque existen menos defensas. [67]
El conjunto de datos de vulnerabilidad más utilizado es Common Vulnerabilities and Exposures (CVE), mantenido por Mitre Corporation . [68] A partir de 2023 [update], tiene más de 20 millones de entradas. [38] Esta información se comparte en otras bases de datos, incluida la Base de datos nacional de vulnerabilidades de los Estados Unidos , [68] donde a cada vulnerabilidad se le asigna una puntuación de riesgo utilizando el Sistema de puntuación de vulnerabilidades comunes (CVSS), el esquema de enumeración de plataforma común (CPE) y la Enumeración de debilidades comunes . [ cita requerida ] CVE y otras bases de datos normalmente no rastrean vulnerabilidades en productos de software como servicio . [38] El envío de un CVE es voluntario para las empresas que descubrieron una vulnerabilidad. [66]
El proveedor de software generalmente no es legalmente responsable del costo si se utiliza una vulnerabilidad en un ataque, lo que crea un incentivo para fabricar software más barato pero menos seguro. [69] Algunas empresas están cubiertas por leyes, como PCI , HIPAA y Sarbanes-Oxley , que imponen requisitos legales sobre la gestión de vulnerabilidades. [70]
Medios relacionados con Vulnerabilidad (informática) en Wikimedia Commons