Enmilocalfunciona

Con la cuarta entrega de nuestra pequeña serie sobre los conceptos básicos de seguridad digital nos queremos centrar en el contexto de partida para crear software seguro. En las últimas entregas nos metimos en el mundo de la confianza, las medidas de seguridad y los protocolos criptográficos de seguridad.

Teniendo el conocimiento técnico de seguridad y tecnológico se podrían simplemente empezar a desarrollar nuevos sistemas digitales más seguros. Pero considero importante ponernos antes en el contexto actual político y legal de los sistemas basados en software.

Propiedad intelectual

Dentro de nuestro objetivo de construir sistemas de software más seguros, hay que recordar que todo esfuerzo de ingeniería de software estará sujeto a legislación vigente relativa a la Propiedad intelectual.

Más concretamente, antes de empezar a escribir la primera línea de código, hay que establecer las condiciones de uso del mismo software. Es decir, bajo qué condiciones de licencia se va a poder utilizar.
Quien no se haya metido todavía en el mundo de las licencias de software, le recomiendo la lectura de Software License para entrar en la materia.

Además, la propiedad intelectual se suele proteger con mecanismos criptográficos, llamado Digital Rights Management o Gestión de derechos digitales. Antes de integrar tecnologías DRM en nuestro software, recomiendo tomar conciencia de los derechos afectados por su uso. Ver ¿Qué derechos se ven afectados?.

¿Por qué es importante el tema de las licencias?

Para asegurarnos de crear software seguro, es decir, que no sea vulnerable a ningún ataque conocido, es de gran ayuda revisarlo y auditarlo. Con una licencia abierta, dicha revisión la puede hacer todo el mundo sin entrar en problemas legales. Con una licencia propietaria, hay que entrar en contratos de licencias y acuerdos de confidencialidad (NDA), lo que limita el esfuerzo de revisión.

El concepto de Seguridad por oscuridad es muy frágil, ya que el modelo se rompe en cuanto se filtre el código por un canal u otro - incluyendo la posible distribución del binario y una posible ingeniería inversa.

Ahora viene lo ridículo - patentes de software

Sigue siendo un debate vivo que si un programa de software se puede patentar o no (Patente de Software). Las patentes intentan proteger una inversión elevada de desarrollar algoritmos o funciones en software, pero - como los límites son difusos - también pueden llevar a la protección de auténticas ridiculeces. Ver What are the most ridiculous technology patents ever granted?.

Es decir, si escribimos código y no queremos tener futuros problemas legales, hay que mantener un equipo de abogados observando los patentes en todo el mundo para limitar el posible daño que puedan provocar posibles denuncias por infracción del derecho de patente.

Las patentes son especialmente peligrosas para el desarrollo de un ecosistema de software libre como Linux - recordemos que Linux se publica bajo la licencia libre de GNU GPL versión 2. Como los mismos propietarios de patentes utilizan y dependen de un Linux libre, se ha formado una comunidad con un pool de patentes sin agresión llamado Open Invention Network (OIN).

Limitaciones de distribución

Los mecanismos de seguridad para proteger nuestro software, sobre todo la criptografía, se considera un bien de doble uso. Es decir, se puede utilizar para proteger el bien o proteger el mal.
Por un lado tenemos las actividades legales que legítimamente buscan la protección de sus activos con seguridad digital, p.ej. nuestros datos personales o nuestra cuenta bancaria. Por otro lado están las actividades ilegales que utilizan la misma seguridad digital para poder actuar sin ser descubiertos, p.ej. crimen organizado, redes de tráfico de drogas, etc.

Con el fin de regularizar este dilema entre favorecer o prohibir la seguridad digital, la comunidad internacional de muchos estados se ha unido al acuerdo de Wassenar (Wassenar Arrangement). En este acuerdo se definen las tecnologías de doble uso con mucho detalle, entre ellos p.ej. la encriptación simétrica o agujeros de seguridad explotables (exploits). Para ver el detalle de las tecnologías recomiendo leer la lista de Dual use Goods and Tecnologies, sobre todo category 5, part 2, "INFORMATION SECURITY".

Se limita la libre distribución, obligando a la declaración en aduana, prohibiendo la exportación a estados con embargos o incluso prohibir su uso civil completamente.
Este acuerdo es la razón por la cual los productos software (p.ej. JDK, Apache httpd, etc.) que incluyen encriptación fuerte (p.ej. AES256, SSL, etc.) se distribuyen en dos paquetes: uno sin encriptación fuerte y otro paquete con la parte de encriptación fuerte.
En el caso de Apache httpd, se delega en OpenSSL (OpenSSL - Downloads) donde sólo se puede descargar el código fuente y nos encontramos con una nota bien clara:

Legalities

Please remember that export/import and/or use of strong cryptography software, providing cryptography hooks, or even just communicating technical details about cryptography software is illegal in some parts of the world. So when you import this package to your country, re-distribute it from there or even just email technical suggestions or even source patches to the authors or other people you are strongly advised to pay close attention to any laws or regulations which apply to you. The authors of OpenSSL are not liable for any violations you make here. So be careful, it is your responsibility. 

En el caso del JDK de Oracle lo conocemos bajo el nombre de JCE (Java Criptography Extension) que se descarga aparte y que quita las limitaciones a las implementaciones criptográficas del JDK/JRE, siempre avisando al receptor (ver jce_policy-8.zip#README.txt):

----------------------------------------------------------------------
Understanding The Export/Import Issues
----------------------------------------------------------------------
[..]
You are advised to consult your export/import control counsel or attorney to determine the exact requirements.

Vulnerabilidades de software

Desde el punto de vista de la ingeniería de software sabemos que no puede existir ningún software sin fallos. En el caso de fallos de seguridad hablamos de vulnerabilidades. Dichas vulnerabilidades, en cuanto se conocen, se registran en bases de datos de llamados Common Vulnerabilities and Exposures, es decir CVE.

Existen varios protocolos de comunicación responsables de las vulnerabilidades para facilitar su corrección por parte del proveedor del software, evitando que posibles adversarios se aprovechen del conocimiento.

Los que creamos o mantenemos software queremos mantenerlo seguro, es decir no vulnerable a los ataques conocidos. Por lo tanto es importante que las CVE se conozcan y que se distribuyan los arreglos o fixes correspondientes. Según el nivel de regularización del sector, incluso nos pueden obligar a la verificación de que nuestro software no es vulnerable por los CVE conocidos, p.ej. PCI-DSS, ISO 27000, etc.

Existen varias listas de CVE, incluyendo todos los productores de software grandes (p.ej. Microsoft, Oracle, Red Hat, etc.) y todas las organizaciones que mantienen un Computer emergency response team (CERT).
En España el Instituto Nacional de Ciberseguridad (INCIBE) mantiene su CERT que ofrece una lista agregada de CVE. Ver Vulnerabilidades.

En el momento de desarrollar software, debemos cumplir con la debida diligencia y evitar el uso de componentes de terceros (frameworks, utilidades, etc.) que tengan vulnerabilidades conocidas. Con este fin debemos integrar en nuestro ciclo de vida algo como el OWASP Dependency Checker o productos comerciales como Black Duck de Synopsys, entre otros.

Actores estatales vs. crimen organizado

Es obvio que el conocimiento de vulnerabilidades todavía existentes tiene un valor. Por lo tanto existe un mercado de vulnerabilidades que se puedan aprovechar para ataques (Exploit). En concreto los exploits que todavía no tienen arreglos (Zero-day) se valoran especialmente.

Existe un mercado negro donde se encuentran expertos de seguridad sin escrúpulos con el crimen organizado. Este mercado se vuelve gris cuando actores legales participan en el mercado (p.ej. actores estatales).
Por el otro lado existe un mercado blanco donde las organizaciones grandes de productos software, p.ej. Google, Apple, Microsoft, etc., dan premios económicos a aquellos expertos que encuentran vulnerabilidades. Estas acciones se llaman Bug bounty programs.

Los expertos de seguridad que saben buscar y encontrar las vulnerabilidades y participan de forma legal en el mercado blanco, se suelen llamar white hats. Aquellos expertos de seguridad sin escrúpulos que participan en el mercado negro se suelen llamar black hats.

Este mercado de vulnerabilidades no está regularizado ya que participan tanto actores del crimen organizado como actores estatales. Por lo tanto existen empresas que se dedican a este negocio llamado Exploit brokers, por ejemplo zerodium con el lema "The leading exploit acquisition platform for premium zero-days".

El problema es que dichas armas digitales (exploits) se pueden utilizar también en contra de los que lo utilizan con fines benéficos. Es decir, también los estados democráticos utilizan mucho dinero público para comprar exploits - luchando contra el crimen organizado y el terrorismo, se supone - manteniéndonos a todos vulnerables ya que dichas vulnerabilidades se mantienen en secreto. Porque si no, se arreglarían.

Que esta circunstancia de mantener exploits secretos por parte de actores estatales (pagado con dinero público) nos puede afectar a todos, se ha visto con el caso más famoso llamado WannaCry. Este ataque tenía consecuencias a muchos niveles críticos como hospitales, líneas de producción y sistemas de transporte.

Con otras palabras, ya estamos metidos en una auténtica guerra digital (Cyberwarfare o Guerra digital). Existe un video muy explicativo y recomendable de la situación llamado Make Cyberpeace not Cyberwar!.

Para tener una impresión de la actividad continua de ataques, recomiendo el mapa de ataques a los honeypots de Norse.

Conclusiones

Como conclusión del estado del mundo del software podemos sacar que antes de empezar a desarrollar software hay que conocer las obligaciones y limitaciones legales respecto a los mecanismos de seguridad que implementemos.

En el contexto de la Tranformación digital nos encontramos de nuevo con que la seguridad del software es también un tema político y de toda la sociedad.

Para no quedarnos con una impresión demasiado distópica, os invito a esperar a la siguiente entrega de esta serie donde hablaremos de buenas prácticas de organización, arquitectura y codificación junto con los estándares de seguridad digital.

¡Síguenos en Twitter para estar al día de nuevos artículos de esta serie!