Política de no revelación de vulnerabilidades

Históricamente esta fue la primera política de revelación utilizada en el mundo de la informática. Las vulnerabilidades se comunicaban directamente a las empresas proveedoras para que éstas las arreglaran. Con el tiempo fueron apareciendo organizaciones como el CERT Coordination Center que se actuaban de intermediarios entre los investigadores y las empresas proveedoras. Los investigadores informaban a estas organizaciones sobre la vulnerabilidad, ellos la verificaban y si la confirmaban entonces informaban de forma secreta al proveedor y una vez que el arreglo estaba disponible entonces publicaba los detalles de la vulnerabilidad.

También aparecieron pequeños círculos cerrados donde hackers, ingenieros del software y profesionales de la seguridad intercambiaban información sobre vulnerabilidades. Como ejemplo de este tipo de organizaciones podríamos destacar la Zardoz 'Security-Digest'. El que la información fuera compartida por, en principio, personas que no iban a usar esta información de forma ilícita, no garantizaba en absoluto que no fuera usada de forma ilícita ya que tener acceso a esta información se convertía en objetivo básico de hackers con fines ilícitos.[1] En definitiva, estos 'secretos' eran usados tanto de forma bienintencionada como maliciosa y esa información raramente llegaba a los ojos del público en general.

Motivaciones para que un investigador que descubre una vulnerabilidad adopte este tipo de política:

• Mantener en secreto para poder utilizar indefinidamente esa vulnerabilidad para atacar sistemas. Es la actitud típica de atacantes de sistemas que buscan beneficio propio.
• Poder venderla (mercado de vulnerabilidades)
• Por pereza. Puede resultar laborioso y tedioso estudiar y/o publicar una vulnerabilidad recién descubierta.

Inconvenientes de esta política de revelación de vulnerabilidades:

• El sistema permanece vulnerable (puede ser objeto de ataque) sin que el usuario sepa el riesgo que corre y pueda tomar medidas. Se asume que los atacantes maliciosos no pueden descubrir por sí mismo vulnerabilidades. Sólo se revelan los detalles si se dispone el arreglo para la misma.
• La falta de publicidad no motiva al productor del software a reparar una vulnerabilidad en un tiempo adecuado. Se ha comprobado que sin esta motivación los proveedores no invierten recursos (dinero y tiempo) en hacer los sistemas más seguros y solucionar rápidamente las vulnerabilidades existentes. Tardan mucho tiempo en solucionar los problemas o simplemente los ignoran confiando en que la información no se difundirá porque se mantendrá en secreto. Esto es debido que los proveedores ofrecen sistemas a otras empresas. Las vulnerabilidades no afectan directamente a las empresas proveedoras, afectan directamente a sus clientes. Por esta razón las empresas proveedoras tienden a tratar la información sobre vulnerabilidades como informes sobre problemas de sus productos, no como problemas que afectan a la empresa en sí. Hay que motivar más profundamente a los proveedores a resolver estos problemas.
• Es imposible evaluar el grado de seguridad ya que no hay un conjunto de personas de confianza que tengan acceso a toda la información sobre vulnerabilidades.
• Dificulta la educación sobre seguridad y por tanto dificulta que se pueda ir mejorando la calidad de los productos.

• Andrew Cencini et ali., "Software Vulnerabilities: Full-, Responsible-, and Non-Disclosure". Diciembre 2005
• Stephen A. Sheperd,"Vulnerability Disclosure. How do we define Responsible Disclosure?. SANS Institute. Abril 2003