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 software contiene errores en los que el sistema no se comporta como se esperaba. Si el error podría permitir que un atacante comprometa la confidencialidad, la integridad o la disponibilidad de los recursos del sistema, se denomina vulnerabilidad. Las prácticas inseguras de desarrollo de software , así como 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 identificar sistemas y priorizar cuáles son los más importantes, buscar vulnerabilidades y tomar medidas para proteger el sistema. La gestión de vulnerabilidades suele ser una combinación de remediación (arreglar la vulnerabilidad), mitigación (aumentar la dificultad o reducir el peligro de los exploits) y aceptar riesgos cuya eliminación no es económica ni práctica. Las vulnerabilidades se pueden calificar según el riesgo de acuerdo con el Sistema común de puntuación de vulnerabilidades u otros sistemas, y se pueden agregar a las bases de datos de vulnerabilidades. En 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 vuelve activo y explotable cuando se está ejecutando el software o hardware que contiene la vulnerabilidad. La vulnerabilidad puede ser descubierta por el proveedor o un tercero. Revelar la vulnerabilidad (como parche o de otro modo) se asocia con un mayor riesgo de compromiso porque los atacantes a menudo se mueven más rápido de lo que se implementan los parches. Independientemente de si alguna vez se lanza un parche para remediar la vulnerabilidad, su ciclo de vida eventualmente terminará cuando el sistema, o sus versiones anteriores, dejen de usarse.
A pesar del objetivo de los desarrolladores de ofrecer un producto que funcione completamente según lo previsto, prácticamente todo el software y hardware contiene errores. [1] Si un error crea un riesgo de seguridad, se denomina vulnerabilidad. [2] [3] [4] Los parches de software a menudo se lanzan para corregir vulnerabilidades identificadas, pero aquellos que permanecen desconocidos ( días cero ), así como aquellos que no han sido parcheados, aún son susceptibles de 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 sólo pueden usarse para ataques de denegación de servicio , otras más peligrosas permiten al atacante inyectar y ejecutar su propio código (llamado malware ), sin que el usuario sea consciente de ello. [2] Sólo una minoría de vulnerabilidades permite 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 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 de software seguro o la presión excesiva para entregar funciones rápidamente pueden generar vulnerabilidades evitables al ingresar al código de producción, especialmente si la cultura de la empresa no prioriza la seguridad . Esto puede provocar vulnerabilidades no deseadas. Cuanto más complejo sea el sistema, más fácil será que las vulnerabilidades pasen desapercibidas. Algunas vulnerabilidades se instalan deliberadamente, que podrían deberse a cualquier motivo, desde un empleado descontento que vende 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 provocar que se pasen errores, 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 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 funciones, a menudo requiere que muchos desarrolladores tengan acceso para cambiar las configuraciones, lo que puede llevar a la inclusión deliberada o inadvertida de vulnerabilidades. [16] Compartimentar las dependencias, que a menudo forma 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 evitar vulnerabilidades. [18]
La Base de datos nacional de vulnerabilidades clasifica las vulnerabilidades en ocho causas fundamentales que pueden superponerse, entre ellas: [19]
Se pueden introducir errores de seguridad deliberados durante o después de la fabricación y hacer que el circuito integrado no se comporte como se esperaba en determinadas circunstancias específicas. Las pruebas para detectar errores de seguridad en el hardware son bastante difíciles 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 actores maliciosos introduzcan estos errores. [23]
Aunque las vulnerabilidades del sistema operativo varían según el sistema operativo utilizado, un problema común son los errores de escalada de privilegios que permiten al atacante obtener más acceso del que debería permitirse. 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 acreditados de sistemas operativos proporcionan parches periódicamente. [25]
Las aplicaciones cliente-servidor se descargan en las computadoras del usuario final y normalmente 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 intrínsecamente menos seguras que otras aplicaciones, son una fuente importante de filtraciones de datos y otros incidentes de seguridad. [27] [28] Los tipos comunes de vulnerabilidades que se encuentran en estas aplicaciones incluyen:
Hay poca evidencia sobre la efectividad y rentabilidad de las diferentes medidas de prevención de ciberataques. [31] Aunque estimar el riesgo de un ataque no es sencillo, se pueden considerar el tiempo medio hasta la infracción y el costo esperado para determinar la prioridad para remediar o mitigar una vulnerabilidad identificada y si es rentable hacerlo. [32] Aunque prestar 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 costos o desventajas de usabilidad inaceptables. [33] Por ejemplo, reducir la complejidad y la funcionalidad del sistema es eficaz para reducir la superficie de ataque . [34]
La gestión exitosa de la vulnerabilidad generalmente implica una combinación de remediación (cerrar una vulnerabilidad), mitigación (aumentar la dificultad y reducir las consecuencias de los exploits) y aceptar algún riesgo residual. A menudo se utiliza una estrategia de defensa en profundidad para múltiples barreras de ataque. [35] Algunas organizaciones buscan solo las vulnerabilidades de mayor riesgo, ya que esto permite priorizar 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 corrección corrige vulnerabilidades, por ejemplo, descargando un parche de software . [37] Los escáneres de vulnerabilidades de software generalmente no pueden detectar vulnerabilidades de día cero, pero son más efectivos para encontrar vulnerabilidades conocidas basadas en una base de datos. Estos sistemas pueden encontrar algunas vulnerabilidades conocidas y recomendar soluciones, como un parche. [38] [39] Sin embargo, tienen limitaciones que incluyen falsos positivos . [37]
Las vulnerabilidades sólo pueden explotarse 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 considera un portador. [41] Las vulnerabilidades inactivas pueden ejecutarse, pero no se ejecutan actualmente. El software que contiene vulnerabilidades inactivas y de operador a veces se puede desinstalar o desactivar, eliminando el riesgo. [42] Las vulnerabilidades activas, si se distinguen de los otros tipos, se pueden priorizar para parchearlas. [40]
La mitigación de vulnerabilidades son medidas que no cierran la vulnerabilidad, pero hacen que sea más difícil explotar o reducir las consecuencias de un ataque. [43] Reducir la superficie de ataque , particularmente para partes del sistema con acceso raíz (administrador), y cerrar oportunidades para que los exploits se dediquen a la explotación de privilegios es una estrategia común para reducir el daño que un ciberataque puede causar. [37] Si no hay disponible un parche para software de terceros, es posible desactivar temporalmente el software. [44]
Una prueba de penetración intenta ingresar al sistema mediante 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 los exploits existentes para detectar vulnerabilidades conocidas. [47] Otras pruebas de penetración son realizadas por piratas informáticos capacitados. Muchas empresas prefieren subcontratar este trabajo porque simula un ataque externo. [46]
El ciclo de vida de la vulnerabilidad comienza cuando se introducen vulnerabilidades en el hardware o el software. [48] La detección de vulnerabilidades puede ser realizada por el proveedor de software o por un tercero. En el último caso, se considera más ético revelar inmediatamente la vulnerabilidad al proveedor para que pueda solucionarla. [49] El gobierno o las agencias 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 Rusia, India, Brasil, Malasia, Singapur, Corea del Norte y Irán. [51] Los grupos delictivos organizados también compran vulnerabilidades, aunque normalmente prefieren kits de explotación . [52]
Incluso las vulnerabilidades que se conocen públicamente o que se han parcheado suelen ser explotables durante un período prolongado. [53] [54] Los parches de seguridad pueden tardar meses en desarrollarse, [55] o es posible que nunca se desarrollen. [54] Un parche puede tener efectos negativos en la funcionalidad del software [54] y es posible que los usuarios necesiten probar el parche para confirmar la funcionalidad y la compatibilidad. [56] Es posible que las organizaciones más grandes no logren identificar y parchear todas las dependencias, mientras que las empresas más pequeñas y los usuarios personales pueden no instalar parches. [54] Las investigaciones sugieren que el riesgo de un 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 quedan obsoletas cuando el software o las versiones vulnerables dejan de utilizarse. [49] Esto puede llevar un largo período de tiempo; en particular, es posible que no sea factible reemplazar el software industrial incluso si el fabricante deja de brindarle soporte. [59]
Una escala comúnmente utilizada para evaluar la gravedad de las vulnerabilidades es la especificación de código abierto Common Vulnerability Scoring System (CVSS). CVSS evalúa la posibilidad de explotar la vulnerabilidad y comprometer la confidencialidad, disponibilidad e integridad de los datos. También considera cómo se podría utilizar la vulnerabilidad y qué tan complejo debería ser un exploit. La cantidad de acceso necesario para la explotación y si podría realizarse sin la interacción del usuario también se tienen en cuenta en la puntuación general. [60] [61]
Alguien que descubre una vulnerabilidad puede revelarla 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 sobre vulnerabilidades. [63] [64] No todas las empresas responden positivamente a las divulgaciones, ya que pueden causar responsabilidad legal y gastos operativos. [65] No existe ninguna ley que exija la divulgación de vulnerabilidades. [66] Si un tercero descubre una vulnerabilidad que no la revela al proveedor ni 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 con otras bases de datos, incluida la Base de datos nacional de vulnerabilidad de los Estados Unidos , [68] donde a cada vulnerabilidad se le asigna una puntuación de riesgo mediante el sistema de puntuación de vulnerabilidad común (CVSS), el esquema de enumeración de plataforma común (CPE) y el esquema de enumeración de plataforma común ( CPE). Enumeración de debilidades . [ cita necesaria ] CVE y otras bases de datos normalmente no rastrean las vulnerabilidades en los productos de software como servicio . [38] La presentación de un CVE es voluntaria 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 la vulnerabilidad (informática) en Wikimedia Commons