En toda Europa, se está tomando una decisión ya conocida en una capital tras otra. Los gobiernos tienen razón al concluir que los asuntos sensibles no deben depender de aplicaciones de mensajería para consumidores y que las comunicaciones oficiales deben permanecer bajo control nacional. Francia gestiona Tchap. Alemania opera BundesMessenger. Bélgica, Polonia, Luxemburgo y otros países han puesto en marcha equivalentes nacionales, y la OTAN ha creado uno para su propio personal. La tendencia es inequívoca. La cuestión más candente es si la soberanía se garantiza mejor siendo propietarios del código o bien controlando los aspectos que determinan dónde se ejecuta el sistema, quién posee las claves, qué legislación lo rige y quién es responsable de garantizar su seguridad.

BlackBerry Secure Communications aborda esta cuestión desde su amplia experiencia en el ámbito de las comunicaciones seguras de nivel gubernamental, incluidas aquellas implementaciones en las que el control nacional, la gestión interna y la garantía certificada son requisitos innegociables. La soberanía debe ser la norma. La cuestión es si una plataforma desarrollada internamente o una tecnología certificada implementada según los términos nacionales ofrece un mayor control a largo plazo, y qué debe mantener un país para garantizar la seguridad de ese control.

Desarrollar o implementar según las condiciones nacionales

Los gobiernos suelen disponer de dos vías para ejercer el control soberano sobre las comunicaciones oficiales:

1. Pueden crear o bifurcar su propia plataforma y gestionarla por sí mismos;

2. Pueden implementar software comercial certificado siguiendo exclusivamente sus propias condiciones: en una infraestructura nacional, con las claves de cifrado en poder del Estado y de nadie más, aprobado por su propia autoridad nacional y gestionado dentro de sus propias fronteras.

Ambas vías pueden otorgar el control al gobierno. La diferencia no radica en el objetivo, sino en el modelo operativo que un país acepta para alcanzarlo. Una plataforma desarrollada internamente concentra la responsabilidad de las actualizaciones, la certificación, la dotación de personal, la resiliencia y la financiación a largo plazo en un único programa nacional. Un modelo comercial certificado puede preservar el control nacional al tiempo que aprovecha los conocimientos técnicos, la capacidad de respuesta ante vulnerabilidades y la experiencia operativa ya consolidados en una base de clientes más amplia.

La vía de desarrollo resulta atractiva por razones comprensibles: parece la máxima expresión de independencia; las herramientas modernas permiten crear un prototipo funcional más rápido que nunca; y una plataforma nacional puede presentarse como una inversión en la capacidad propia del país. Ninguna de esas motivaciones es errónea. Pero describen el momento del lanzamiento. La prueba más difícil es lo que el país debe financiar, dotar de personal, certificar y defender una vez que la plataforma esté en funcionamiento.

A qué se compromete un país con un proyecto de este tipo

Casi ninguno de los sistemas de mensajería nacionales actualmente en servicio se ha desarrollado partiendo de cero. La mayoría son bifurcaciones de la misma base de código abierto, adaptadas y mantenidas por el Estado desde ese momento en adelante. Se trata de una decisión de ingeniería razonable. También significa que el Gobierno hereda todo lo que se ha desarrollado a partir de esa base —y lo hereda de forma permanente—.

Poner en marcha una plataforma es un proyecto, con un principio y un final. Gestionarla de forma segura es una función permanente del Gobierno. Implica la aplicación continua de parches, operaciones las 24 horas del día, certificaciones periódicas, conocimientos especializados internos en criptografía y seguridad, y rendición de cuentas ante la ciudadanía cuando algo sale mal.

El coste de desarrollo suele citarse como una cifra puntual. La cifra real es el coste de propiedad a lo largo de diez años, cuya mayor parte se genera tras el lanzamiento. Las actualizaciones continuas, un centro de operaciones de seguridad, las certificaciones periódicas y los especialistas que las gestionan cuestan aproximadamente lo mismo, tanto si prestan servicio a un gobierno como a cincuenta. Un proveedor mantiene esa capacidad una sola vez y la distribuye entre todos sus clientes. Un gobierno que desarrolla su propio sistema asume la totalidad de ese coste con cargo a un único presupuesto nacional. 

La carga operativa es la misma en ambas vías. La diferencia radica en si un solo presupuesto nacional se hace cargo de ella por sí solo.

La amenaza ha cambiado el panorama

Hay un nuevo aspecto que cualquiera que esté valorando hoy en día la estrategia de desarrollo debería tener en cuenta. A medida que las herramientas automatizadas reducen el tiempo que transcurre entre que una vulnerabilidad se hace pública y que se aprovecha, la limitación que realmente importa ya no es si un gobierno puede permitirse aplicar el parche, sino si es capaz de hacerlo dentro del plazo necesario antes de que la vulnerabilidad se utilice en su contra.

A principios de este año, una de estas plataformas nacionales sufrió una brecha de seguridad. No se descifró ningún cifrado ni se aprovechó ninguna vulnerabilidad del propio software. Una sola cuenta de usuario se vio comprometida mediante ingeniería social, y eso bastó para acceder a las salas públicas sin cifrar, a las que la arquitectura permite el acceso a cualquier usuario autenticado. El cifrado cumplió su función. La vulnerabilidad parece haber provenido de la arquitectura que lo rodea: un modelo heredado de una fundación de código abierto y mantenido dentro de un único programa nacional.

La profundidad es importante porque la respuesta ante vulnerabilidades depende de la telemetría, la inteligencia sobre amenazas, la capacidad de ingeniería, la visibilidad de los clientes y la rapidez en las pruebas y la implementación. Un pequeño equipo nacional que depende de una solución de un proveedor superior sobre la que no tiene control se encuentra en una situación de desventaja estructural en una carrera que ahora se mide en horas. Una organización que gestiona la respuesta ante vulnerabilidades para una amplia base de clientes está en condiciones de actuar con mayor rapidez a medida que la amenaza se intensifica.

La resiliencia sigue la misma lógica. La capacidad de resistir picos de carga, redes con rendimiento reducido y una infraestructura que puede estar siendo objeto de un ataque se ha demostrado en la práctica en numerosas implementaciones, y no se pone de manifiesto por primera vez durante el primer incidente nacional de la propia plataforma.

Cuando la explotación se produce pocas horas después de la divulgación, la responsabilidad por la corrección es más importante que la autoría del código.

Más que una aplicación de mensajería

Hay otro aspecto que una bifurcación de mensajería no aborda. Garantizar la seguridad de las llamadas y los mensajes supone un trabajo considerable, y una bifurcación que lo consiga habrá logrado algo sustancial. Pero las comunicaciones seguras van más allá de la mera mensajería. El dispositivo en el que se desarrolla la conversación también debe estar protegido; de lo contrario, la seguridad del intercambio dependerá únicamente de la del terminal en el que se ejecute. Cuando un incidente afecta a organismos que no comparten una misma cadena de mando, la respuesta también debe coordinarse entre ellos. Cada capa constituye una estructura independiente, con su propia certificación y sus propias cargas operativas. Una bifurcación proporciona la primera capa. Un gobierno que desee disponer de todas las capacidades se está comprometiendo, en la práctica, a desarrollar y mantener más de una plataforma.

La soberanía es control, no autoría

Detrás de todo esto se esconde una confusión que merece la pena señalar. A veces se trata la soberanía como una cuestión de quién escribió el código, cuando en realidad se trata de una cuestión de control: quién tiene las claves, dónde se ejecuta el sistema, qué legislación lo rige y quién responde de él. Un gobierno puede escribir cada línea de código y, aun así, depender de un proveedor externo para las correcciones de seguridad. También puede implementar software comercial y, al mismo tiempo, mantener todos los puntos de control que importan, siempre que la arquitectura esté diseñada para ello.

Esa es la distinción que cualquier gobierno que se plantee esta opción debería tener muy presente. El objetivo no es la autoría por sí misma. El objetivo es el control sobre dónde se ejecuta el software, quién posee las claves, quién lo certifica y lo gestiona, y quién responde cuando hay que defenderlo. La autoría puede ser una vía para alcanzar ese control, pero solo es una vía. La profundidad técnica, la atención operativa y el presupuesto que exige cada año una plataforma de desarrollo propio son limitados. Lo que se gasta en esto no se puede destinar al resto de una misión de seguridad nacional. Entre naciones con ideas afines, la resiliencia se refuerza al apoyarse mutuamente cuando tiene sentido, en lugar de que cada una reconstruya por su cuenta los mismos cimientos.

Secusmart ofrece un ejemplo de este modelo en la práctica. Se trata de una empresa alemana, diseñada y gestionada dentro de las propias estructuras de Alemania y certificada por su autoridad federal. Su labor en el ámbito de las comunicaciones gubernamentales seguras forma parte del panorama nacional desde hace años. Esto demuestra que la soberanía no tiene por qué implicar reconstruir cada capa por cuenta propia. Los gobiernos deberían exigir soberanía sin concesiones y, a continuación, calcular el coste total a diez años vista antes de decidir qué modelo adoptar.