Sucede todo el tiempo: las empresas son pirateadas porque no hay una forma obvia para que los investigadores de seguridad les informen sobre fallas de seguridad o fugas de datos. O tal vez no esté del todo claro quién debería recibir el informe cuando se vende el acceso remoto a la red interna de una organización clandestina de delitos informáticos.
Para minimizar estos escenarios, cada vez más organizaciones grandes utilizan Security.txt, un nuevo estándar de Internet propuesto que ayuda a las organizaciones a describir sus preferencias y prácticas de divulgación de vulnerabilidades.
Un ejemplo de un archivo security.txt. Imagen: Securitytxt.org.
La idea detrás de Security.txt es simple: la empresa coloca un archivo llamado security.txt en una ubicación predecible, por ejemplo, example.com/security.txt o example.com/.well-known/security.txt. El contenido del archivo security.txt varía un poco, pero la mayoría contiene enlaces a información sobre la política de divulgación de vulnerabilidades y una dirección de correo electrónico de contacto.
El archivo security.txt proporcionado por USAAcontiene, por ejemplo, enlaces a su programa de recompensas por errores; una dirección de correo electrónico para la divulgación de asuntos relacionados con la seguridad; sus directrices sobre vulnerabilidades de seguridad y divulgación de claves de cifrado públicas; e incluso un enlace a una página en la que USAA agradece a los investigadores que han informado de importantes problemas de ciberseguridad.
Otras versiones de security.txt son menos detalladas que en el caso de Atención sanitaria de HCAque contiene una dirección de correo electrónico de contacto y un enlace a la política de «Divulgación responsable» de HCA. Al igual que USAA y muchas otras organizaciones que han publicado archivos security.txt, HCA Healthcare incluye un enlace a información sobre las vacantes de seguridad de TI corporativas.
Un archivo security.txt puede facilitar que las empresas respondan a las amenazas de seguridad activas. Por ejemplo, esta mañana, una fuente confiable me envió las credenciales de VPN de un gran minorista de ropa que habían sido robadas por malware y entregadas a los ciberdelincuentes. Debido a que KrebsonSecurity no pudo encontrar un archivo security.txt en el sitio web del minorista usando gotsecuritytxt.com (que verifica un dominio para este archivo de contacto), KrebsonSecurity envió una advertencia a su dirección de correo electrónico security @ para el dominio del minorista.
Muchas organizaciones han estado utilizando la dirección de correo electrónico security @ de forma no oficial (si no se anuncia) durante mucho tiempo.[companydomain] aceptar informes de incidentes de seguridad o brechas de seguridad. Quizás este minorista también hizo esto una vez, pero mi mensaje fue devuelto con una indicación de que el correo electrónico estaba bloqueado. KrebsOnSecurity también envió un mensaje al director de información (CIO) del minorista, la única persona en el puesto de nivel C de un minorista que estaba en mi red inmediata de LinkedIn. Todavía no tengo ni idea de si alguien lo leyó.
Aunque security.txt aún no es un estándar oficial de Internet compatible con Grupo de trabajo de tecnología de Internet (IETF), sus principios básicos han sido adoptados hasta ahora por al menos el ocho por ciento de las empresas Fortune 100. Estos incluyen Alphabet, Amazon, Facebook, HCA Healthcare, Kroger, Procter & Gamble, USAA y Walmart, según una revisión de los nombres de dominio de las compañías Fortune 100 más nuevas a través de gotsecuritytxt.com.
Puede haber otra buena razón para consolidar los contactos de seguridad y la información de informes de vulnerabilidades en una ubicación predecible. Alex Holden, Fundador de la consultora Hold Security, con sede en Milwaukee, dijo que no era raro que los piratas informáticos malintencionados tuvieran problemas para llamar la atención de las personas adecuadas dentro de la misma organización que acababan de piratear.
«En el caso del rescate, los malos intentan llegar a la empresa con sus demandas», dijo Holden. «No tienes idea de la frecuencia con la que tus mensajes se atascan en filtros, se eliminan, bloquean o ignoran».
Entonces, si security.txt es tan bueno, ¿por qué aún no lo han adoptado más organizaciones? Parece que la configuración de un archivo security.txt tiende a generar un volumen bastante alto de spam. La mayor parte de este correo electrónico no deseado proviene de probadores de penetración autoproclamados que ejecutan herramientas automatizadas de detección de vulnerabilidades, sin preguntar, y luego envían los informes resultantes con la esperanza de obtener una asignación de consultoría o una tarifa de recompensa por error.
Esta dinámica fue un tema importante de discusión en esos hilos de noticias de piratas informáticos en security.txt, donde varios lectores compartieron su experiencia que estaban tan inundados con informes de escaneo de vulnerabilidades de baja calidad que se volvió difícil hacer que los informes reconocieran quiénes realmente valían la pena. perseguir.
Edwin «EdOverflow» Foudil, el coautor del estándar de notificación propuesto, admitió que los informes basura son una gran desventaja para las empresas que ofrecen un archivo security.txt.
«En realidad, esto se indica en la especificación en sí, y es increíblemente importante resaltar que las organizaciones que implementan esto se verán inundadas», dijo Foudil a KrebsOnSecurity. “Una de las razones por las que los programas de recompensas por errores son tan exitosos es que son esencialmente un filtro de spam glorificado. Pero cualquiera que sea el enfoque que adopte, se verá inundado con estos informes de mala calidad y de mala calidad «.
A menudo, estos informes de vulnerabilidad por debajo del promedio provienen de personas que han rastreado todo Internet en busca de una vulnerabilidad o dos y luego han intentado comunicarse semiautomáticamente con todas las organizaciones vulnerables al mismo tiempo. Afortunadamente, según Foudil, muchos de estos informes de acoso se pueden ignorar o agrupar mediante la creación de filtros que busquen mensajes que contengan palabras clave que a menudo se encuentran en escaneos automatizados de vulnerabilidades.
Foudil dijo que a pesar de los desafíos del spam, ha escuchado comentarios tremendos de varias universidades que han implementado security.txt.
“Ha sido un éxito increíble con las universidades, que normalmente tienen muchos sistemas heredados más antiguos”, dijo. «Vimos muchos informes valiosos en ese sentido».
Foudil se complace de que ocho de las empresas Fortune 100 ya hayan implementado security.txt, aunque aún no ha sido aprobado como estándar IETF. Si se aprueba security.txt, espera dedicar más tiempo a promover sus beneficios.
“No estoy tratando de ganar dinero con esto que surgió después de hablar con algunas personas en DEFCON [the annual security conference in Las Vegas] que luchó para informar problemas de seguridad a los proveedores ”, dijo Foudil. «La principal razón por la que no estoy haciendo todo lo que puedo para promoverlo es porque aún no es un estándar oficial».
¿Su organización ha considerado o implementado security.txt? ¿Por qué o por qué no? Tono en los comentarios a continuación.