Supongamos un conjunto de elementos cuyos valores pueden ser positivos o negativos. Este conjunto podríamos subdividirlo en dos subconjuntos según sus valores pertenezcan a uno u otro ámbito.
El conjunto raíz crece a una velocidad variable, engordando arbitrariamente un u otro subconjunto.
De esta manera, donde antes había 100 elementos, 50 positivos y 50 negativos, en otro momento puede haber 300 elementos, 150 positivos y 50 negativos, y al siguiente 1000 elementos, 750 positivos y 250 negativos.
Si nos interesa recuperar únicamente los elementos positivos, debemos encontrar la manera de discernir lógicamente cuáles son positivos y cuáles son negativos, de forma que podamos señalarnos y recuperarlos del conjunto.
Esta es una de las posibles formas de solucionar un problema semejante. Encontrar los elementos que nos interesan y agruparlos. Ahora bien, si esos elementos positivos son números, bastaría con hacer uso de la lógica matemática. Pero cuando esos elementos son bienes digitales, no hay una “ecuación” sencilla de aplicar. Y aquí entran en juego las listas blancas.
Una lista blanca es un subconjunto de todos esos elementos presentes en el ecosistema estudiado que presentan al menos una particularidad afín a nuestros intereses. En el mundo digital, podría traducirse en correos deseados, en aplicaciones legítimas o en comentarios hechos por nuestros lectores.
Tiene la ventaja que los miembros de una lista blanca son confiables, es decir, podemos saber a ciencia cierta que todo elemento en una lista blanca cumple nuestras expectativas. Y como desventaja, que por defecto todo nuevo elemento en el ecosistema estudiado será excluido de antemano, requiriendo un sistema de supervisión (un sistema de control) exhaustivo.
Por contra, una metodología de control de confianza basada en la lista negra se encarga de aglutinar de todo el ecosistema estudiado (recordemos, emails, aplicaciones o comentarios, en nuestro ejemplo) aquellos que no cumplan nuestras expectativas (correos no deseados, aplicaciones fraudulentas o spam), de manera que por un lado sabemos a ciencia cierta que todo elemento en una lista negra no es de nuestro agrado, y por otro, no podemos asegurar que todos los que no estén en la lista negra lo sean.
Bajo este paraguas se yergue prácticamente todas las plataformas digitales. Aceptamos por defecto que las intenciones de un elemento del sistema es bueno, y en caso de que al final resulte nocivo, se le incluye en la lista negra, no volviendo (presumiblemente) a afectar al resto de participantes. Pero quien o quienes hayan sido afectados ya poco pueden hacer.
Por ello, me parece interesante debatir sobre las implicaciones de una lista blanca en algunas materias informáticas que quizás se presten a ello.
El ejemplo más claro serían sistemas con fuerte marcado control, como puede ser un SCADA o la red de terminales empresariales MDM. Sería absurdo que un operario cualquiera que controla el funcionamiento de una plataforma petroquímica tuviera la capacidad de instalar cualquier programa en el sistema, y pasaría lo mismo con los trabajadores de una empresa y su servidor compartido.
En estos casos, se trabaja partiendo de la hipótesis de que todo nuevo elemento es por naturaleza nocivo, y de esta manera, se minimiza enormemente el riesgo asociado a su mantenimiento y evolución. Solo las fuentes permitidas pueden realizar los cambios, y cualquier nuevo sistema tendrá que auditarse con anterioridad antes de incluirlo en el sistema.
Ahora demos un paso más allá, y echemos un ojo a plataformas masivas. Está bien que un sistema SCADA funcione de esta manera, ya que pueden pasar años sin que necesite tan siquiera un cambio de metodología, ¿pero qué hay de la política de actualización de aplicaciones en dispositivos móviles? ¿Qué hay de la política de gestión de certificados de autoridad TLS en páginas web con protocolo de comunicación seguro?
Aquí la cosa se complica. Creo que queda patente que una lista blanca es “más segura” (entraña menor riesgo) que su antónima, pero mantenerla lo suficientemente actualizada puede ser un problema en un número para nada despreciable de situaciones.
Si miramos al mundo móvil, los markets figurarían como un primer paso hacia esa posible lista blanca. Y digo básico porque las expectativas de la mayoría de markets son demasiado bajas como para servir de variable a la hora de instalar o no una aplicación.
Con los CAs pasa casi lo mismo. A excepción que el propio medio (y según el navegador) los gestiona como le parece, por lo que es relativamente fácil saltárselos si se tiene acceso al dispositivo.
¿De qué va este artículo entonces? De exponer una realidad compleja de analizar. Las listas blancas minimizan el riesgo a cambio de perder control del sistema por parte del usuario. Requieren de un organismo y una plataforma lo suficientemente actualizable y versátil para que funcione, con los gastos que ello conlleva. Y aquí es donde entra la figura del crowdsourcing.
¿Sería viable una lista blanca de servicios de internet que tirara de una plataforma colaborativa? Es posible, aunque tendría que ser externa, abierta y neutral (quedan descartadas por tanto empresas de antivirus y sistemas operativos), y a la vez debe ser masiva (de fácil instalación y transparente al usuario) y moduralizable (capaz de administrar ya no únicamente los nuevos elementos del conjunto, sino la actualización de los que ya existían). Una cadena de confianza encargada de gestionar los servicios a los que accedemos, y compartir un registro anónimo con el resto de participantes, de tal manera que si cualquiera descubre un falso positivo, se aísla y la información se propaga en el resto de participantes.
Todo ello muy bonito sobre el papel. Ahora a ver quién es el guapo que consigue mantenerlo sin que los de siempre quieran meter mano a esa información (corromper su gestión con intereses alejados del bien común), que será anónima, pero en todo caso de un potencial informativo más que interesante.
