Autenticación de mensajes basada en dominio
A principios de este año, como parte de nuestra iniciativa a nivel de toda la empresa para cumplir con los 20 controles de seguridad críticos del Centro para la Seguridad en Internet (CIS) (se abre en una nueva pestaña), Tanium implementó una configuración más restrictiva mediante el protocolo DMARC (Domain Based Message Authentication, Reporting, and Conformance) para los correos electrónicos de la empresa. Tal y como se esperaba, se redujo considerablemente el número de correos electrónicos no deseados y de phishing de . Sin embargo, también nos encontramos con varios retos imprevistos durante la implementación. Dado el número de empresas que optan por no configurar DMARC, hemos pensado que podría resultar útil compartir nuestra experiencia ofreciendo una visión general de DMARC, los retos habituales asociados a su implementación y algunas sugerencias útiles que hemos aprendido a lo largo del proceso.
DMARC utiliza dos tecnologías, Sender Policy Framework (SPF) y DomainKeys Identified Mail (DKIM), para determinar si un correo electrónico ha sido suplantado (es decir, falsificado para que parezca que procede de su organización) o si ha sido enviado legítimamente desde su empresa. Tanto el SPF como el DKIM se publican como registros DNS públicos a los que se puede acceder desde cualquier lugar. Estos controles permiten a los servidores SMTP receptores examinar las cabeceras entrantes, comparar sus claves de origen e integridad con las publicadas por su organización y, a continuación, decidir si entregan el mensaje o si toman alguna medida, como ponerlo en cuarentena. A continuación, esta información se envía a una dirección de correo electrónico específica, donde puede analizarse y clasificarse para detectar anomalías o problemas.
La lista SPF es, sencillamente, una lista de nombres de dominio completos (FQDN) o direcciones IP que una empresa ha designado como remitentes SMTP autorizados. Los servidores SMTP receptores pueden analizar las cabeceras de un mensaje entrante para determinar cuál es el servidor SMTP de origen. DKIM es un mecanismo de control mucho más preciso que se basa en el cifrado asimétrico. Tanium publica una clave pública a través del DNS y conserva de forma segura la clave privada correspondiente, que no se hace pública. Cualquier tercero que desee enviar correos electrónicos en nombre de la empresa deberá generar también un par de claves pública y privada, e incluir su clave pública en el DNS.
Cuando llega un correo electrónico, el servidor receptor extrae la clave DKIM adjunta de los encabezados del mensaje y consulta al servidor de origen para verificar su legitimidad. Si la clave DKIM facilitada no coincide con la clave privada del servidor de origen, el mensaje es falso. Si hay una coincidencia, el servidor remoto sabe que el correo electrónico procede del remitente y puede entregarse de forma segura.
Retos de implementación
Aunque tanto el SPF como el DKIM son bastante sencillos de implementar, sí que requieren que otras organizaciones participen y configuren correctamente sus registros DNS. A la hora de evaluar un software de terceros que vaya a enviar correos electrónicos en su nombre, debe comprobar si el proveedor es totalmente compatible con SPF y DKIM. Si el proveedor no implementa correctamente los protocolos SPF y DKIM, podría resultar difícil o imposible garantizar su pleno cumplimiento.
Dicho esto, aunque otras organizaciones configuren correctamente el SPF y el DKIM, debe tener en cuenta otros retos:
Escalabilidad de SPF
SPF solo puede realizar diez consultas DNS, limitadas a varios tipos de registros diferentes (entre los que se incluyen los registros A, MX, PTR, EXISTS, INCLUDE y REDIRECT). Este límite existe para evitar búsquedas infinitas de registros, pero también limita la escalabilidad del SPF. Las redirecciones y otros mecanismos de DNS que requieren varias consultas pueden agotar el límite rápidamente y generar confusión a la hora de resolver problemas. Por este motivo, es sumamente importante analizar detenidamente cómo se utilizan los registros DNS para implementar el SPF. Las direcciones IP y los rangos de direcciones IP no se incluyen en esta limitación; sin embargo, mantenerse al día con los cambios en las direcciones IP puede suponer un gran consumo de recursos en comparación con el uso de un nombre de dominio completo (FQDN).
Subdominios no incluidos
SPF solo evalúa el nombre de dominio exacto que se especifica en el registro; se incluyen los subdominios y , pero noni . Por ejemplo, si especifica una dirección IP en el registro SPF para @company.com y esa IP envía mensajes desde @_subdomain.company.com, la comprobación SPF dará error. Cada subdominio debe tener su propio registro SPF.
Uso de claves DKIM de otros dominios
Las claves DKIM permiten que otras organizaciones se autentiquen plenamente con respecto a su dominio (y, por lo tanto, puedan enviar correos electrónicos verificados en su nombre). Los terceros debidamente configurados pueden proporcionarle una clave de selección (esta clave consiste, en esencia, en que le ceda su clave pública, mientras que ellos mantienen el control de la clave privada). Aunque no disponga de la clave privada, si configura correctamente la clave de selección en el DNS, podrá reenviar las solicitudes de descifrado al tercero y completar la validación.
Las organizaciones pueden especificar el nivel de control que desean aplicar a los errores de SPF o DKIM mediante las siguientes opciones:
-Ninguna: : los mensajes se procesan y se registran para su revisión, al tiempo que se permite que el mensaje problemático se entregue
-Cuarentena: cada proveedor de correo electrónico determina cuál será esta acción, pero en la mayoría de los casos significa enviar los mensajes directamente a la carpeta de spam del usuario
-Rechazo: los mensajes se rechazan directamente cuando no cumplen con los requisitos de SPF o DKIM
Tenga en cuenta que: los resultados de DMARC no son fáciles de interpretar. Los resultados se recogen en un archivo XML y se envían a la dirección de correo electrónico especificada en la política DMARC desde cada servidor SMTP que reciba mensajes. En función del volumen de tráfico de correo electrónico, podrían enviarse miles de mensajes al día, lo que dificultaría la identificación y la resolución de posibles problemas.
Para comprender adecuadamente su entorno, existen varias herramientas que permiten, por un lado, identificar problemas en los propios registros DMARC/SPF/DKIM y, por otro, ayudar a detectar problemas ocultos en los informes XML de DMARC que se envían cuando un servidor SMTP ha determinado que un mensaje incumple la política. Tanium utiliza un servicio denominado Dmarcian (se abre en una nueva pestaña) para ayudar a analizar nuestra configuración y agregar los resultados.
Aunque no es perfecta, la implementación de DMARC contribuye en gran medida a que las organizaciones dispongan tanto de visibilidad como de control sobre quién envía correos electrónicos utilizando su nombre de dominio. Mediante un uso eficaz de estas herramientas, las organizaciones pueden reducir considerablemente la cantidad de correos electrónicos maliciosos que llegan a su organización y evitar que usuarios malintencionados suplanten su dominio. DMARC permite a las organizaciones controlar la forma en que los servidores SMTP receptores pueden verificar y tomar medidas respecto a los correos electrónicos legítimos e ilegítimos que afirman proceder del origen «@sudominio.com».
Gracias a la configuración de una implementación adecuada de DMARC, Tanium pudo ampliar la cobertura de los controles de seguridad en 3 áreas diferentes del CIS:
- CSC 7: Medidas de protección para el correo electrónico y el navegador web
- CSC 8: Medidas de defensa contra el malware
- CSC 9: Limitación y control de puertos de red, protocolos y servicios
Conclusión
Si gestiona dominios que prestan servicios de correo electrónico, le recomendamos encarecidamente que considere la posibilidad de implementar DMARC. No solo redunda en beneficio de cada empresa en particular, sino que también beneficiará al ecosistema del correo electrónico en su conjunto, ya que el número de dominios que pueden ser objeto de suplantación de identidad se reducirá cada vez más. Reducir el riesgo de suplantación de su dominio implica que sus usuarios corran menos riesgo de ser víctimas de abusos, así como que haya menos probabilidades de tener que incurrir en gastos para responder a incidentes o hacer frente a otros problemas de responsabilidad civil. Se trata de una parte pequeña, pero importante, de la aplicación íntegra de medidas de seguridad proactivas, como los controles «Top 20 » del CIS, y contribuye a cumplir los requisitos necesarios para obtener la certificación en marcos de cumplimiento normativo como la norma ISO 27002. Es lo más lógico para la salud y el bienestar de las empresas de cualquier tamaño.
Acerca del autor: Eric Fisher es analista de seguridad de la información y experto en diseño de operaciones empresariales en Tanium, en Raleigh (Carolina del Norte). Eric cuenta con un máster en Seguridad de la Información y Análisis Forense, y anteriormente ha trabajado como consultor de seguridad, encargándose de la puesta en marcha de centros de operaciones de seguridad (SOC) y programas de respuesta a incidentes para varios bancos, minoristas y empresas tecnológicas que figuran en la lista «Fortune 500 ». Asimismo, ha diseñado y puesto en marcha arquitecturas informáticas y redes a gran escala para diversos organismos gubernamentales y para las Fuerzas Armadas, en su calidad de empleado del Laboratorio de Investigación Aplicada de la Universidad Estatal de Pensilvania y de Raytheon.
