Confianza, Transparencia y Seguridad

Hay ciertos aspectos que no se tocan demasiado cuando se habla de seguridad. Y es probablemente porque son tan evidentes que a nadie se le ocurriría que es necesario ahondar en ellos. Pero precisamente esos temas son los que pueden hacer la diferencia entre un sistema con buena seguridad y otro con algunas debilidades. Estas debilidades pueden crear vulnerabilidades objetivas, pero en la mayoría de los casos presentan desventajas más bien subjetivas que inciden en el nivel de confianza que se puede tener en el sistema.


Muchas veces se restringen los conceptos de seguridad a elementos donde ésta se presenta en forma protagónica, como es el caso de evitar ataques físicos o virtuales, proteger información confidencial y resguardar transacciones por medio de criptografía y firmas digitales. Sin embargo la seguridad en sí abarca aspectos mucho más amplios. Se puede argumentar que la seguridad computacional tiene relación con, justamente, asegurar el funcionamiento de un sistema en la forma que éste ha sido definido. A partir de esta definición podemos considerar diversos aspectos que afectan el correcto funcionamiento de un sistema y por lo tanto constituyen un riesgo de seguridad. Esto toma mayor importancia cuando consideramos que la seguridad de un sistema depende de su eslabón más débil.

La criptografía ha abierto la posibilidad de enfrentar estos desafíos de forma concreta y bastante exitosa, superando por lo general los esquemas tradicionales que hasta ese momento se han debido considerar suficientemente buenos para su uso masivo, más que nada por falta de alternativas. Sin embargo, nos falta por aprender sobre la puesta en práctica de muchos de los esquemas que en la teoría funcionan impecablemente.

Por ejemplo, existe una gran inversión en infraestructura y sobre todo procedimientos para garantizar que los certificados emitidos por las empresas certificadoras correspondan a la identidad de quienes efectivamente los reciben. Pero por otro lado, muchos de los sitios web que permiten transacciones comerciales en Chile exigen los datos sensibles del cliente antes de que éste pueda posiblemente confirmar la identidad del sitio web al que se conectó. Eso reduce en forma importante el nivel de seguridad que pueda existir, y sobre todo malacostumbra a los usuarios, quienes debieran aprender a ingresar datos confidenciales solamente una vez establecida la conexión segura. Un usuario que aprendió correctamente el uso del navegador, resistiéndose a ingresar datos cuando no puede validar la identidad del sitio web al cual se enviarían, simplemente deberá dirigirse a una de las pocas instituciones que usan correctamente las herramientas criptográficas en sus sitios web, o bien abstenerse de gozar de los beneficios de las transacciones online.

Una vez que los usuarios han adquirido la costumbre de ignorar que esté iniciada la sesión segura, generalmente identificada a través de un ícono que representa un candado, éstos se hacen más vulnerables a futuros abusos. Si esos abusos se hacen masivos antes que seamos capaces de revertir la situación y enseñar el correcto uso de sitios web a los usuarios, la confianza en las transacciones online van a ser las que sufren. Y la pérdida de confianza sería lo más grave que podría sucederle a nuestra tan anciada economía en línea.

Efectivamente, la confianza es el elemento clave en cualquier transacción, y es justamente el vínculo que existe entre el mundo virtual y el real, entre bits y átomos. Pero existe otra forma de generar confianza, y esa es la transparencia. El concepto de transparencia es considerado una condición obligatoria dentro de muchas áreas de la seguridad. Los procedimientos deben ser conocidos y claros, un algoritmo criptográfico que depende de un elemento que no está claro inmediatamente despierta sospechas y posiblemente sea catalogado de "snake oil" o bien escondido detrás de un cartel que dice "security through obscurity". El caso excepcional lo constituye DES con sus S-Boxes, cuya importancia era conocida por unos pocos y solamente fue evidente veinte años después de ser definidas y aceptadas como standard.

Si nosotros o terceros adquirimos una máquina, un software o algún otro servicio, podemos aumentar la confianza que tenemos en dicha adquisición si es posible verificar la forma en que funciona. Esta transparencia no está garantizada en ningún lado, y de hecho, sobre todo en lo que respecta a programas de computadores (software), no solo es difícil poder determinar a partir de código ejecutable qué hace exactamente un programa, sino que en muchas partes es ilegal. En Chile por ejemplo, una consecuencia del Tratado de Libre Comercio con Estados Unidos de America es que en poco tiempo más será ilegal usar ingeniería reversa para revisar si un programa cumple con lo que supuestamente hace sin el consentimiento del proveedor. Eso afecta negativamente cualquier intención de garantizar la seguridad, es decir, la falta de transparencia limita la confianza que le podemos tener a un sistema y por ende ese sistema nos ofrece una menor seguridad. Es necesario por lo tanto identificar el nivel de transparencia que se puede recibir del proveedor directamente.

La transparencia no siempre es absoluta, existen pasos intermedios entre un programa completamente opaco y uno transparente. Podemos ver dos extremos: por un lado software propietario en el cual se prohibe cualquier tipo de uso que no sea el indicado en el manual de uso, y por otro lado el software libre en el cual se incluye el código fuente y diversos permisos. Estos permisos incluyen usar el software en cualquier circunstancia y por cualquiera, ver el código fuente para aprender de él, modificarlo y experimentar con él, así como redistribuir el código, tanto original como el modificado, a terceros que gozarán de los mismos permisos.

Los beneficios de tener disponibilidad de código sin restricciones y abierto a cualquiera que quiera verlo es una ventaja, puesto que este nivel de transparencia tiene un resultado directo en la confianza que se pueda tener en el producto. Esto, porque se asume que una gran cantidad de gente puede verificar diversas partes del código, hay un cierto nivel de garantía que no existen puertas traseras que permitan a alguien externo acceso no deseado y en general el código puede ser auditado sin problemas por quien lo desee. Aún así, eso no basta para asegurar la calidad y seguridad del código, pero al menos es un requisito que lo permite.

Hay empresas que se han dedicado tradicionalmente al software propietario, y que han caído en cuenta que la transparencia realmente genera un nivel elevado de confianza. Es por eso que hemos visto cada vez más que se ofrece a clientes distinguidos, por lo general gobiernos, la oportunidad de ver el código fuente de algún producto. Sin embargo, las condiciones bajo las cuales se muestra ese código fuente no son las mismas que las existentes dentro de un proyecto de software libre. Por ejemplo, no es posible compilar la totalidad de la aplicación para asegurar que efectivamente el código fuente al que se tiene acceso corresponda a la aplicación que se ejecuta. Tampoco es posible, en muchos casos, modificar el código y experimentar con esas modificaciones para aprender de mejor manera el funcionamiento del mismo. Además de esto, las personas que tendrán acceso real al código fuente deberán firmar acuerdos de no divulgación, lo que alejará a muchos especialistas de aceptar la oferta. Y es que los acuerdos de no divulgación les limitarían su trabajo, ya que tendrían que separar impecablemente lo visto en ese código de lo que ellos son capaces de producir solos. El efecto de esto es que la gente involucrada en estos esquemas de código compartido no es la que idealmente quisiéramos que revise el código. También se puede dar el caso de que los errores detectados en la revisión no se informen al distribuidor y en cambio se usen para beneficios propios, como acceso a datos de otros gobiernos o instituciones.

Según esto, es posible tener distintos niveles de transparencia en las soluciones de software que usemos. Es importante notar que esta transparencia tiene incidencia directa con la seguridad que podamos asignarle a un sistema, la cual está dada por el nivel de confianza que le podemos tener. El software libre en ese sentido proporciona la mejor solución, porque permite no sólo mejorar la seguridad, sino además romper la dependencia total que se tiene con un proveedor de software propietario. Esta dependencia impide por ejemplo realizar cambios necesarios a un sistema de forma local, o incluso obliga a dejar de usar un sistema porque ya no existe ni existirá más soporte para ello, y las fallas de seguridad conocidas hacen imposible seguir usándolo.

Por otro lado, es posible que código malicioso sea insertado en cualquier programa, y siempre es posible camuflar ese código malicioso para que aparente ser (o incluso sea) algo útil dentro del sistema. En el software propietario, existen procedimientos formales para evitar que ello ocurra (desde la contratación del personal que trabaja en la empresa hasta la definición de niveles de seguridad y revisiones internas antes de permitir modificación del código). Sobre todo, existe un incentivo importante para la empresa de mantener control sobre el desarrollo en todos los aspectos. En cambio, en el caso del software libre el esquema es mucho menos formal. Esto no significa que sea menos seguro, pero sí es importante tener en consideración el proceso de desarrollo con el mismo rigor con que se controla el código fuente, tomando en cuenta aspectos como qué criterios se aplican para aceptar contribuciones de terceros, la cantidad de gente involucrada en esas decisiones, etc. Los grandes proyectos de Software Libre han demostrado ser suficientemente sólidos respecto de resultados de seguridad, por lo que son un referente de metodología a tener en cuenta.

Jens Hardings
29 de diciembre de 2003

Valid HTML 4.01!