Security.txt ya es el protocolo formal RFC 9116, ¿Lo usarás en tu web? – Súmate

5 de mayo de 2022

Escrito por Ana Rodilla

Tras 5 años de trabajo, el archivo security.txt es ya un protocolo formal denominado RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, lo que se traduce en: un formato de archivo para ayudar en la divulgación de vulnerabilidades de seguridad. El objetivo de este estándar es dar un impulso a la seguridad de las webs, aportando datos sobre la empresa, las políticas de seguridad o el modo de informar sobre vulnerabilidades. Y tú dirás, ¿qué es este protocolo? ¿tengo que añadir este archivo a mi web? Sigue leyendo porque vamos a profundizar.

¿Qué son los RFC?

Antes de profundizar en qué es el archivo security.txt, vamos a dejar claro un concepto importante: los RFC. Las siglas RFC hacen referencia a la expresión «request for comments», o lo que es lo mismo, peticiones de comentarios. Así se comenzaron a conocer los documentos pensados para estandarizar diferentes aspectos de la red: protocolos, métodos, comunicaciones o conceptos, entre otros. Esta modalidad de trabajo se remonta a 1969, cuando Steve Crocker sentó las bases de lo que conocemos actualmente al crear un sistema de trabajo para hacer llegar propuestas técnicas al resto del grupo. Actualmente, la gestión de estos documentos se realiza a través de IETF (Internet Engineering Task Force), el consorcio de colaboración técnica más importante de la red. 

Estos documentos poseen un número identificativo exclusivo, se redactan en inglés según la estructura fijada y en formato de texto ASCII. No todos los RFC hablan de protocolos de internet, hay algunos creados específicamente para dar a conocer el formalismo previo a la creación, ya que es bastante estricto. Por ejemplo, el RFC 2223 y el RFC 2119 están creados para definir cómo escribir un RFC y qué significado se le asigna a cada término como «must» o «must not», de este modo se evitan malentendidos.

Otra curiosidad es que no todos los documentos llegan a ser RFC, hay numerosos procesos que se quedan por el camino o que tardan años en convertirse en un RFC hasta que se asegura su calidad y coherencia, como el caso de security.txt, que ha tardado 5 años en ser oficial. 

¿Qué es Security. txt?

Ahora que tenemos claro qué es un RFC, vamos a conocer más a fondo el RFC 9116, es decir, el RFC que hacer referencia a security.txt. Como comentamos anteriormente, a finales de abril se dio a conocer que security.txt era oficialmente un protocolo formal tras 5 años de trabajo. 

 

Este archivo servirá como estándar para comunicar a través de la web los datos de la empresa, sus políticas de seguridad, claves públicas o fallos en ciberseguridad. El formato y la implementación es similar al ya conocido robots.txt (RFC 5785), por lo que no supondrá un problema a los desarrolladores. 

Security.txt está listo para usarse en los sitios web

¿Qué campos incluye?

Si navegamos a lo largo del texto que da forma al RFC 9116, podemos ver los diferentes apartados que puede incluir el documento security.txt. A menos que se indique lo contrario, todos los cambios son opcionales: 

  • Acknowledgments: en este apartado de agradecimientos deben aparecer, si los hay, los responsables de seguridad que han colaborado para evitar brechas. Pueden aparecer mencionados o enlazando a una URL donde estén reflejados. 
  • Canonical: indica la URL canonical donde se encuentra el archivo security.txt
  • Contact: el campo contacto debe estar siempre presente en el archivo security.txt, contiene información sobre email, teléfono y URL de contacto. En el caso de poner los tres modos, se deben ordenar de mayor a menor preferencia de modo de contacto y colocados en líneas separadas. El objetivo es ofrecer un modo a través del cual se puedan reportar vulnerabilidades de seguridad. 
  • Encryption: el campo de cifrado indica el acceso a la clave de cifrado de seguridad que los desarrolladores deben utilizar para la comunicación cifrada. Ojo, en este campo NO debe aparecer la clave, se debe enlazar a la URL que contenga la ubicación para obtener la clave.
  • Expires: este campo indica la fecha y hora en la que los datos del archivo security.txt serán considerados obsoletos. Este campo debe aparecer siempre y tan solo una vez, 
  • Hiring: el campo contratación incluye la URL en la que aparecen los puestos de trabajo que ofrece la empresa relacionados con la seguridad.
  • Policy: se informa en este campo de las políticas de seguridad. Es importante que se haga en forma de URL apuntando a la página donde se encuentra la información.
  • Preferred-Languages: este campo indica los idiomas preferidos para la comunicación sobre seguridad. Este campo solo debe aparecer una vez.

ejemplo security txt

Fragmento extraído del RFC 9116

¿Dónde se coloca security.txt?

El archivo se puede colocar en dos ubicaciones: se puede situar directamente en el directorio raíz de la web, donde se sitúa el archivo robots.txt, o en la la ubicación /.well-known/security.txt, siendo esta última la ubicación más recomendada, el mismo Google tiene en esa ruta situado su fichero security.txt.

  • https://example.com/security.txt
  • https://example.com/.well-known/security.txt

¿Cómo crear el archivo security.txt?

La manera más sencilla de crear el archivo security.txt para tu web es a través de la página securitytxt.org. En la propia herramienta aparecen los campos obligatorios, el número de veces que puede aparecer y la nomenclatura específica. Cuando lo tengas completo dale a generar el archivo y cópialo en la ubicación seleccionada. Para mayor tranquilidad, este fichero debe ser revisado por el responsable de seguridad de la compañía.

Inconvenientes del RFC 9116

Algunas de las dudas que los usuarios tienen a la hora de añadir el archivo security.txt están relacionadas con las posibles brechas de seguridad que se pueden generar al mostrar esta información. Y ojo, el público no está desencaminado. En el propio texto del RFC 9116 se indica que hay que tener especial cuidado con los datos en el campo Acknowledgments, se debe limitar la información que se ofrece sobre las vulnerabilidades que ha tenido la web para prevenir futuros ataques.

Otro aspecto a tener en cuenta, que también preocupa a los usuarios, es el spam que se puede recibir al añadir emails en el archivo security.txt. 

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Por Ana Rodilla

Suscríbete a
nuestro Blog

No te pierdas las últimas noticias y consejos sobre Marketing Digital.

Tu privacidad es importante para nosotros. Súmate utiliza la información que proporcionas para ponerse en contacto contigo en relación con contenido, productos y servicios relevantes para ti. Puedes darte de baja para dejar de recibir este tipo de comunicaciones en cualquier momento. Si deseas obtener más información sobre la protección de tus datos en HubSpot, consulta nuestra Política de Privacidad.