Descargo de responsabilidad: El original de esta página está escrito en neerlandés. Esta página se ha traducido automáticamente a otros idiomas utilizando DeepL. Esto puede dar lugar a diferencias de matiz, tono y significado. En caso de duda, consulta siempre primero la versión neerlandesa. Debido al elevado coste de las traducciones, esta página puede ir por detrás de la versión neerlandesa en cuanto a contenido. Consideramos que la versión neerlandesa de esta página es la principal.
La Fundación para la Limpieza de Internet tiene un código de conducta que establece los principios básicos sobre qué medidas se publican y cuáles no.
Esta página profundiza en ello con ejemplos prácticos.
Medidas públicas con finalidad pública
En principio, la Seguridad Básica mide la seguridad en el nivel básico. Esto puede publicarse libremente sin aumentar el riesgo de abuso más allá de lo que ya está. Considera la posibilidad de medir dónde faltan medidas de seguridad comunes.
La base de datos de Basisbeveiliging.nl contiene más de 10 millones de mediciones únicas. Todas las mediciones de la base de datos pueden publicarse íntegramente en cualquier momento, o filtrarse, sin crear nuevos riesgos que pueda aprovechar un atacante.
Una organización con una política de seguridad adecuada siempre estará en verde en seguridad básica: las medidas en sí mismas no son noticia ni chocan, pero la falta de aplicación a veces puede serlo.
Las mediciones de la seguridad básica se sitúan en el ámbito del hacking ético y las pruebas de seguridad. Existen grandes similitudes con los primeros pasos de las pruebas de seguridad profesionales, como el mapeo de la superficie de ataque. Esto abarca dominios, puertos y software. Se trata de información pública fácil de recopilar a gran escala. Hay muchas empresas que lo hacen y lo ofrecen a muy bajo coste o incluso de forma pública y gratuita.
Basic Security nunca publica vulnerabilidades graves o críticas. Deja esto en manos de otras organizaciones, como empresas profesionales de pruebas de seguridad como Secura, Zerocopter u organizaciones voluntarias como la DIVD.
Conclusiones publicables
La Internet Cleanup Foundation publica información sobre vulnerabilidades y medidas de seguridad que faltan. Lo hace con el objetivo de que se solucionen estas vulnerabilidades. Basándose en el código de conducta, se determina si una vulnerabilidad puede publicarse. Aquí se tienen en cuenta el interés público, la proporcionalidad y la subsidiariedad.
Las vulnerabilidades publicables están disponibles públicamente para todo el mundo en el sitio web de seguridad básica. También se puede acceder automáticamente.
Las vulnerabilidades publicables se clasifican por riesgo. Se trata de una clasificación de riesgo diferente, habitual en el mundo de la seguridad, porque el espectro de medidas es diferente. El espectro sobre seguridad básica tiene cuatro grados que se escalan en función de lo que potencialmente podría ir mal. Esto contrasta con las pruebas de seguridad habituales, que enfrentan los mismos resultados con cosas que realmente van mal en este momento. Donde la Seguridad Básica valora algo como «alto», en una prueba de seguridad profesional se pondrá como «info», «bajo» o, en un caso especial, como «medio», dependiendo del propósito de la prueba.
Las gradaciones de la seguridad básica cambian con el tiempo, para elevar lentamente el listón de la seguridad básica. Cuando una medida es naranja este año, puede ser roja el año que viene para llamar más la atención sobre ella. Por ejemplo, la aplicación de security.txt no es obligatoria hasta mediados de 2023, por lo que en esa fecha no todas las organizaciones aplicarán esta norma. Sin embargo, a mediados de 2024, esto sería inaceptable, ya que habrán tenido un año para aplicarla. Hay más información al respecto en la política de medición.
Éstas son las cuatro gradaciones que aplicamos:
Rojo: representa una vulnerabilidad de alto riesgo. Aquí se trata de una imperfección que hay que arreglar. Considera, por ejemplo, un cifrado débil. La filtración de información sobre la versión (léase: decirle a un atacante qué debe ejecutar) y cosas por el estilo.
Naranja: suele referirse a instituciones y deficiencias administrativas. También, nuevas mediciones que eventualmente deberían ser rojas, pero que se escalan como naranja para su introducción: para que la medición sea visible y accionable en las organizaciones responsables.
Verde (bajo): Medida que implica una desviación sobre la seguridad que tiene muy poco impacto (todavía) porque son pocas las personas que pueden experimentar este problema, y en ese caso suelen estar ya expuestas a una amplia gama de problemas más graves. Este nivel también se utiliza para mediciones que pueden implicar obligaciones legales en el futuro, pero que no son muy comunes hoy en día.
Verde (ok): Una medición correcta: la seguridad está garantizada en este punto.
Los resultados se facilitan siempre con documentación, referencias y, cuando es posible, un enlace de segunda opinión sobre el que se puede realizar una nueva prueba. Éstos también figuran en la política de medición. Esto permite conocer la relevancia de un nuevo hallazgo y verificar inmediatamente que la vulnerabilidad se ha solucionado.
Algunos ejemplos de vulnerabilidades publicables son: falta de cifrado, falta de DNSSEC, falta de security.txt, ubicación física del servicio, aplicación de RPKI, información pública de la versión.
Toda la información de los sitios web, incluidas todas las medidas, está sujeta a nuestra cláusula de exención de responsabilidad. Por lo tanto, actuar de acuerdo con ellas corre siempre por tu cuenta y riesgo. Hacemos todo lo posible por publicar siempre medidas correctas y actualizadas, lee más sobre esto en la política de medidas.
Cómo se publican las nuevas medidas
Antes de que se publique una nueva medición, primero se anuncia a las organizaciones paraguas para que éstas puedan tomar medidas al respecto. Para entonces, los propios resultados de la medición a menudo todavía no son reveladores. Al menos un mes después, la medición se hace visible y pública.
A continuación habrá un periodo de prueba durante el cual la medida se calificará como máximo de naranja. Durante este periodo de prueba, todo el mundo puede reaccionar ante la medida y ésta puede endurecerse. Este periodo suele durar uno o dos meses. Después de este periodo, la medida se vuelve a ajustar y posiblemente se establece en rojo.
Ejemplo de escenario de vulnerabilidad publicable
Una organización necesita un sitio web. Este sitio web lo realiza una agencia de desarrollo. Esta agencia de desarrollo utiliza software estándar y se centra principalmente en la funcionalidad y la información.
El sitio web se está poniendo en marcha, pero aún no se ha abordado el tema de la seguridad. Por ejemplo, todavía no se puede acceder al sitio a través de una conexión cifrada (1: https), no hay garantías de que el nombre de dominio pertenezca a la dirección ip del sitio (2: DNSSEC) y hay un panel de gestión público (3: panel de acceso) que muestra que se trata de la versión de software 7.0.2 (4: información sobre la versión).
Este caso proporciona a un atacante todo tipo de asideros que pueden evitarse fácilmente. Un atacante necesita poco o ningún esfuerzo para encontrarlas, y ha automatizado durante mucho tiempo y ampliamente este conocimiento para hacer el mayor daño posible de esta forma.
En este caso práctico, un atacante puede explotar las vulnerabilidades de las siguientes formas: puede leer junto con el tráfico de Internet en la misma red, como un punto de acceso Wi-Fi, porque falta https (1: https), en la misma red el atacante puede redirigir el tráfico a una página falsa (2: dnssec), se pueden realizar intentos de inicio de sesión en la página de gestión en cualquier parte del mundo (3: panel de inicio de sesión) y buscar y aplicar vulnerabilidades conocidas públicamente en cualquier parte del mundo (4: información de la versión).
Los atacantes ya disponen de esta información, por lo que es importante que las personas que tienen que defender también la tengan. En todos estos ataques, hay una base de apertura y buena profesionalidad.
Cuando se siguen de forma competente los marcos y normas de seguridad conocidos, todas estas vulnerabilidades no están presentes. Piensa en ISO27002, NEN7510, Baseline Information Security Government y similares. Ten en cuenta que estos marcos no son prácticos y dejan que cada uno mida y mida las soluciones por sí mismo. Como resultado, en la misma situación, un novato redactará un plan diferente en cuanto a contenido que un profesional. En seguridad básica, fijamos un cierto listón que es relevante en todos los casos. A algunos este listón les parece demasiado alto, a otros demasiado bajo. En cualquier caso, es la base.
Vulnerabilidades no publicables
La seguridad básica se centra en los requisitos básicos de seguridad.
Los voluntarios de la Fundación también encuentran a veces vulnerabilidades graves. Esto es un subproducto y no el objetivo de la Fundación. Así es como lo abordamos. Las búsquedas activas de vulnerabilidades graves las realiza la organización amiga DIVD. Así que la seguridad de la base nunca busca activamente vulnerabilidades graves.
En caso de que accidentalmente encontremos una vulnerabilidad grave, a continuación te explicamos cómo tratarla.
Cuando se sospecha que existe una vulnerabilidad grave, se considera aquí, caso por caso, el planteamiento que proporcione la mayor seguridad en el plazo más breve. Se consideran varias opciones:
- Si se trata de una vulnerabilidad nueva que aún no se conoce (no es un CVE), hay varias opciones. Depende de dónde se haya identificado la vulnerabilidad y de cuál sea su gravedad. Se consideran las siguientes vías:
- Pásalo al Instituto Holandés para la Divulgación de Vulnerabilidades. Ellos tienen la infraestructura para identificar a las víctimas de esta vulnerabilidad y advertir sobre la filtración. Esta acción es nuestra opción preferida.
- Cuando el creador del software dispone de un proceso adecuado de Divulgación Coordinada de Vulnerabilidades, esta vulnerabilidad también se transmite directamente al creador. Esto sólo ocurre cuando puede hacerse de forma confidencial.
- Se aplican las normas básicas en torno a la Divulgación Coordinada de Vulnerabilidades para notificar a la parte vulnerable.
- Cuando se trata de una vulnerabilidad conocida, se siguen las reglas básicas en torno a la Divulgación Coordinada de Vulnerabilidades. Se examina si la organización dispone de un proceso de este tipo.
- Si no existe un proceso de CVD, se contacta con la organización paraguas de seguridad a la que pertenece. Se trata, por ejemplo, del Servicio de Seguridad de la Información para Municipios o del Centro Nacional de Ciberseguridad para el gobierno nacional.
- Se está estudiando la posibilidad de remitir el informe a través de la Línea Directa de Seguridad.
- La comunicación en torno a la vulnerabilidad grave se considerará de acuerdo con las normas básicas del CVD. Dado que encontrar y publicar nuevas vulnerabilidades no es nuestro objetivo, es probable que la comunicación sobre nuevas vulnerabilidades, si es que llega a producirse, se realice a través de la parte a la que se informó, la Línea Directa de Seguridad, la DIVD o una organización similar.
Algunos ejemplos de vulnerabilidades no publicables son: Inyección SQL, secuencias de comandos en sitios cruzados, uso de contraseñas débiles, contraseñas filtradas, ejecución remota de código, desbordamientos de búfer y CVE.
Ejemplo de escenario de vulnerabilidad grave
Este ejemplo se basa en un escenario real y en una vulnerabilidad conocida: desactivar un módulo que hacía directamente legibles los archivos que contenían contraseñas en la portada de un sitio (desactivando PHP). Se trata de un error de configuración.
Un voluntario está navegando por información en basicsecurity.es. El voluntario ve un sitio «oud.belangrijkeoganisation.nl», que por tanto puede tener una seguridad débil. El voluntario se interesa y visita el sitio.
Al visitar el sitio, parece que algo va mal en la configuración: se ve el código fuente del sitio, en lugar de un sitio web bonito. Este código fuente contiene una contraseña de base de datos y enlaces a archivos sensibles.
El voluntario sabe que esa no es la intención y consulta con otros voluntarios sobre lo que es prudente hacer. Se trata de una vulnerabilidad individual y conocida, por lo que se siguen las normas del CVD.
El voluntario se pone en contacto con la organización de seguridad perteneciente al sitio web. Se intercambia información sobre la vulnerabilidad y la organización sigue los procesos internos asociados a la CVD y a la resolución de vulnerabilidades.
La organización resolvió la vulnerabilidad en un plazo previsible. A veces, la organización opta por recompensar al informador con un obsequio o una entrada en el salón de la fama.