Resumen
00:00:09 – Conoce a Ash Morin de Dmarcian, junto a nuestra Kate Nowrouzi
00:03:20 – ¿Qué es el spoofing o suplantación?
00:09:02 – Cuando DKIM llegó a la fiesta
00:14:27 – DMARC y por qué está aquí
00:00:05
Eric Trinidad: Bienvenidos a Email’s Not Dead. Me llamo Eric y conmigo, como siempre, está Jonathan.
00:00:09
Jonathan Torres: Hola.
00:00:09
Eric Trinidad: Esta semana estamos aquí para hablaros, como hacemos siempre, sobre el email. Este es un podcast creado por un par de frikis que casualmente trabajan en el ámbito del email. Así que bienvenidos de nuevo, amigos. Esta semana después de Halloween. Todavía vamos a entrar en algunas cosas que asustan un poco. Hablamos de phishing y spoofing o suplantación, que son cosas bastante peligrosas ahí fuera. Así que, ya sabes, para ayudarnos en este viaje, tenemos un par de amigos con nosotros. Nos acompaña Ash Morin de Dmarcian. Es director de implementación. Ash, gracias por acompañarnos hoy.
00:00:37
Ash Morin: Gracias por invitarme.
00:00:38
Eric Trinidad: Y también tenemos a Kate Nowrouzi, que es nuestra vicepresidenta de entregabilidad… Kate. Gracias de nuevo por acompañarnos. ¿Cómo estás hoy?
00:00:45
Kate Nowrouzi: Estoy genial. Gracias por invitarme.
00:00:48
Eric Trinidad: Es genial tenerte de vuelta. Hoy hablaremos de spoofing o suplantación y phishing, y de seguridad en general. Ash, tengo entendido que tienes experiencia en seguridad, pero principalmente en el ámbito del email, así que, ¿cómo ha sido esa vida?
00:01:01
Ash Morin: Ha sido divertido, la verdad. Para mucha gente, creo que empecé como generalista y me centré principalmente en los típicos sitios de escritorio, asistencia in situ principalmente, ya sabes, asegurándome de que el hardware y todo eso siguiera funcionando. Pero, con el tiempo, a medida que me metía más en el email y la administración de email, sobre todo a mediados de la década de 2000, cuando empezó a surgir tecnología realmente divertida, fue por necesidad. Seamos sinceros. Me enganché y empecé a centrarme cada vez más en eso. Finalmente, hacia 2011 es cuando conseguí un puesto a tiempo completo en antispam y seguridad. Entonces me di cuenta de que probablemente sería una pasión que tendría durante mucho tiempo. Y de hecho, es interesante porque fue justo un año antes de que la especificación DMARC se hiciera más oficial. Así que mi momento fue muy interesante. ¿Pero sabes qué? Al final salió bien.
00:01:57
Eric Trinidad: Sí, es genial, te enganchó y no te ha soltado desde entonces.
00:02:00
Jonathan Torres: Sí, eso es lo que creo que el email tiende a hacer con todos nosotros. Siento que este grupo en particular, pero me refiero a que hay tanta gente ahí fuera a la que, una vez que el email le clava los dientes, ya está todo listo, estás atrapado. Es así, es un gusanillo y vas a ir a por ello.
00:02:15
Ash Morin: Totalmente.
00:02:16
Eric Trinidad: Así que probablemente has manejado algunas cosas aterradoras que han salido a la luz y han afectado a algunos de tus clientes como Kate. Sé que tú también has experimentado eso. Ya sabes, por tu experiencia.
00:02:26
Kate Nowrouzi: Yo solía luchar contra el spam en la operación antispam de AOL, y era divertido. Es como un rompecabezas. Que, cuanto más vas tras ellos, cambian sus tácticas y entonces es como un juego muy divertido. Desde entonces, siempre he disfrutado luchando contra los malos y asegurándome de que el ecosistema del email se mantenga limpio y seguro.
00:02:45
Jonathan Torres: Sí, la seguridad es sin duda una gran parte de ello. Y creo que hacia ahí nos lleva la conversación. Exacto. Ese es el siguiente paso, porque en general tenemos spam. El spam es algo real. Hemos hablado tanto de ello y creo que la conversación sobre el spam nunca terminará, cómo combatirlo, cómo no hacerlo, ya sabes, asegurarnos de que hacemos lo correcto. Así que eso no entra en juego. Pero creo que, específicamente aquí, en lo que nos centramos es en toda la parte del spoofing o suplantación. Exacto. Ese es otro nivel donde ya no es solo spam. Es algo intencionadamente malo que alguien está intentando hacer. Y creo que se debería hablar de ello. Y tenemos que asegurarnos de dedicar tiempo a hablar sobre eso. Y dentro de este ámbito. Así que el spoofing o suplantación, ¿qué es? ¿Alguien quiere intentarlo? Porque lo voy a dejar abierto.
00:03:20
Ash Morin: Bueno, creo que me sentiría mal si no lo hiciera, para ser sincero. Realmente quiero empezar diciendo que efectivamente, ya sabes, cuando hablabas de spam frente a, ya sabes, spoofing o suplantación, tenemos que entender que el spam es técnicamente un envío masivo de email no solicitado. La intención no es necesariamente maliciosa. Es una mala práctica. Y a veces puede serlo, pero no siempre. Pero cuando hablas de spoofing o suplantación, se trata de un ataque deliberado, generalmente dirigido, donde hay personas que intentan sacarte algo y eso normalmente significa que sufrirás una pérdida. Así que es un ataque. Y ese ataque es bastante aterrador porque los usuarios medios no tendrán ni idea. Y muy a menudo tendrán que confiar en que su equipo de seguridad informática o, ya sabes, la organización con la que trabajan esté debidamente equipada para mantenerlos a salvo. Y eso no siempre ocurre solo en un entorno de trabajo. También estamos hablando, ya sabes, de tu propia dirección de email personal que usas, que es, ya sabes, como una cuenta gratuita de algún tipo. Y es abrumadoramente también un objetivo de esos ataques. Pero, efectivamente, toda la idea del spoofing o suplantación es que, por la forma en que funciona el email, la manera en que tu cliente de email mostrará de dónde proviene un email, esa dirección de remitente si quieres, puede mostrar absolutamente cualquier cosa que el remitente desee. Cualquier cosa, absolutamente cualquier cosa. Y sin tecnologías específicas que se hayan desarrollado a lo largo del tiempo para instalar cierto control sobre eso, alguna verificación, antes no había nada de eso. Y, en última instancia, eso es lo que se necesita. Es que, una vez que recibes un email, intentarán ser alguien que no son, se presentarán en la puerta y mostrarán su identificación diciendo, oye, soy tu proveedor de gas, necesitamos un pago. Y a primera vista, hay muchas posibilidades de que no notes la diferencia. Y eso es, en esencia, lo que es el spoofing o suplantación, ya sabes, matices y tácticas que tomaría un atacante. Pero, en esencia, eso es lo que es. Es alguien que lleva un disfraz muy creíble solo por la forma en que funciona el email y tu cliente de email intenta facilitar y añadir una capa de comodidad a tu vida que efectivamente lo hace peligroso, solo para engañarte y sacarte algo. Y eso es malo para ti y bueno para ellos.
00:05:51
Jonathan Torres: Sí. También hay muchas capas diferentes cuando hablamos de ese tipo de cosas, porque están los pequeños microataques que son muy dirigidos, como, ataques tipo ‘whaling’ que envían información fingiendo ser, sé que he recibido de estos en los que te dicen, oye, soy tu director ejecutivo. En plan, por favor compra una tarjeta de regalo y envíame el código de la tarjeta porque necesito este dinero. Y es como, bueno, eso no tiene sentido. Pero lo siguen intentando. Y obviamente sigue ocurriendo porque la gente lo hace. Está pasando y la gente cae en la trampa. Así que es un lugar muy peligroso en el que estar. Y eso puede causar, ya sabes, sin duda algunos problemas. Pero luego vemos cosas a gran escala. Sé que me encanta comprar por Internet. Creo que la pandemia ha hecho que me encante comprar por Internet todavía más porque me llegan más cosas directamente a la puerta de casa. Así que hay muchísimas cosas que llegan a mi buzón. Y, es decir, es algo difícil de combatir para los proveedores. Y lo hace muy peligroso porque para cualquier gran empresa que haga esto a gran escala, es fácil encontrar su logotipo. Es fácil averiguar cómo formatean sus mensajes. Es fácil imitar esa información y luego enviarla a todo el mundo, enviarla a cualquiera del que puedan conseguir su dirección de email para intentar engañarle; eso te puede pasar a ti. Así que es una de esas cosas que, en fin, me parece una situación muy aterradora en la que estar. O sea, en el email en general. Es algo que, ya sabes, me acelera un poco el corazón. Y creo que eso es, ya sabes, continuar con la temática de Halloween. Sí, lo es. Creo que a veces resulta intimidante. Y simplemente aterrador en general.
00:07:10
Eric Trinidad: Sí. Especialmente ahora durante las vacaciones. Ya sabes, ahora probablemente tendremos muchísimos más mensajes que nunca, al estar en ese ámbito. Sí. ¿Qué decías, Kate?
00:07:20
Kate Nowrouzi: Iba a decir que sí importa si has trabajado en la seguridad del email, si tienes la experiencia, puedes fijarte en los encabezados del email, te conoces esos detalles. Pero incluso yo siempre pensaba, oh, soy de fiar, nadie puede engañarme. Una vez me engañó… Uso Wells Fargo para mi cuenta bancaria… un ataque de phishing de Wells Fargo en el que la W eran dos uves. Así que aunque seas la mejor, te pueden engañar. Así que lo principal a tener en cuenta es que hay que hacer muchísimas cosas para proteger a la gente corriente o incluso a la experimentada de sus ataques de phishing.
00:07:59
Jonathan Torres: Sí, he visto muchas combinaciones diferentes de ese tipo de cosas, en las que usan una R y una N para que parezca una M, o esa misma táctica que viste con dos uves para hacer una W. Hay muchas, muchísimas tácticas diferentes en la forma en que lo hacen. Y así es, te obliga a estar muy atento, ya sabes, como consumidor, pero también como remitente sobre cómo funcionan las cosas. Así que creo que ahí es donde empezamos a desviar un poco la conversación. Hagámoslo un poco menos aterrador y veamos qué podemos hacer para ayudarnos. Sé que cuando empezamos desde arriba del todo, empezamos a fijarnos en lo más básico de esto y hacia dónde ha ido en el pasado. Sabemos que el SPF existe, ¿verdad? El SPF te permite decir básicamente que estos son los lugares que envían mensajes por mí. Exacto. Un registro TXT sencillo, bastante fácil de configurar. Casi todo el mundo debería tenerlo configurado. Si alguien no lo tiene configurado, por favor id a configurarlo. En realidad solo dice que este es mi dominio. De aquí vienen mis emails. Estos son los servidores que quiero decir que, sí, pueden enviar en mi nombre. Así que es muy, muy básico. Luego empezamos a meternos en cosas que se vuelven un poco más complejas. Donde firmas tus mensajes con DKIM. Ash, ¿quieres hablarnos un poco de la parte del DKIM?
00:09:02
Ash Morin: Sí, por supuesto. En esencia, el DKIM entró en juego en su versión actual como una especie de fusión de dos tecnologías en torno a 2004. Y, en la práctica, la idea es usar pares de claves criptográficas a un nivel muy alto. No voy a entrar en demasiados detalles, pero de hecho el remitente va a aplicar una firma al email, especificando en cierto modo, oye, ¿sabes qué?, verifico la autenticidad de este email. Esta es mi firma. Y una vez que lo recibe el destinatario previsto, entonces ese entorno, si está comprobando DKIM, la mayoría, una abrumadora mayoría lo hace ahora. Entonces creará su propia verificación usando una clave pública. Y entonces lo que hará efectivamente es comparar lo que obtienen con lo que firmó originalmente el remitente. Si coincide de forma idéntica, entonces significa que ese email se envió y recibió sin ninguna modificación. ¿A qué? Ese DKIM o esa firma están cubiertos de manera tan efectiva que es una forma de aplicar un certificado o sello de aprobación afirmando que, cuando se envió, estas partes concretas del mensaje tenían este aspecto. De esta manera, usando esa técnica, un receptor puede decir, bueno, se ve igual que cuando lo verificaste. Así que todo bien. Pero si se realiza algún cambio en una parte específica del mensaje, reemplazando algunas cosas, cambiando el contenido del cuerpo o cosas así, cuando el receptor reciba ese email, dirá. No, en realidad estoy viendo algo diferente a lo que tú viste cuando lo enviaste. Así que en ese momento sabremos que ha pasado algo. La parte complicada es: ¿lo que pasó fue de manera legítima, un simple error, o fue algo malintencionado? Eso es otro cantar. Pero, en esencia, eso es lo que hace el DKIM.
00:10:54
Jonathan Torres: Sí. O sea, es una de esas cosas donde está bien tener algo implementado para evitar que pasen. Exacto. Esas, ya sabes, ya sean accidentales o intencionadas, como. Exacto. Para esos cambios que ocurren cuando las cosas ya no se ven igual que cuando se firmaron al enviarlas; aunque con ambas en realidad, porque si envías un mensaje y básicamente no tienes DKIM ni es un mensaje firmado, eso le quita un poco de sentido a la discusión. Siempre que hablamos de spoofing o suplantación. No es que sea completamente inútil, pero sí crea una pequeña brecha de caída. Y sé que ahí es un poco donde, ya sabes, tenemos al SPF entrando todavía un poco en juego y encargándose de parte de eso, básicamente diciendo un par de cosas sobre de dónde debería venir el email. Pero aún así, no es una solución complementaria completamente segura ni integral, ¿sabes? Y creo que es por eso que tantos de nosotros en el ámbito del email somos tan entusiastas con DMARC, porque es como el salvador que lo une todo.
00:11:52
Ash Morin: Totalmente. Y de hecho, también tenemos que ser realistas, por así decirlo, en el sentido de que no hay una única medida que vaya a arreglarlo todo. Simplemente no es lo único en lo que debemos fijarnos. Y eso es lo que era el SPF originalmente. Es como, vale, ahora estoy autorizando a quién puede enviar en nombre de mi dominio, pero solo como parte del return path. Y ahora estamos hablando de la anatomía de un email. Ya sabes, hay dos direcciones de remitente: el encabezado ‘From’ y el ‘Mail From’, o el ‘rfc5321 mail from’, el return path, el sobre (envelope from) o la dirección de rebote. Son distintos nombres para lo mismo, para la misma identidad específica que se configura en un email. Y a menos que estés familiarizado con cómo funciona SMTP, no lo sabes; el usuario medio, evidentemente, no lo sabe. Pero desde el punto de vista de un administrador de sistemas, estás pensando en plan, vale, ya tengo el SPF configurado y todo bien, pero aún me pueden hacer spoofing. Y el principal problema ahí es que DMARC lo une todo por una razón muy concreta: porque es posible que digamos que yo soy John Spammer y he registrado spammer.com. Ya sabes, sí, es un poco obvio, pero está hecho a propósito. Así que he registrado spammer.com. Así que soy dueño de ese dominio. Así que tengo control sobre su DNS y sobre cualquier servidor de email que haya configurado para enviar en nombre de ese dominio. Y por la manera en que funciona el email, puedo enviar un email que esté programado de tal forma que utilice un encabezado ‘From’ diferente al del return path. Así que voy a enviar un return path a mi dominio spammer.com, así que como controlo el dominio, puedo poner el registro SPF como quiera. Así que una autenticación especial va a pasar. Sí, pero voy a empezar a enviar desde PayPal usando un encabezado diferente, y eso es lo que un receptor, un cliente de email, abrumadoramente ha empezado a cambiar. Eso ha empezado a cambiar y es bueno. Pero en general, especialmente en el móvil, sabemos que el móvil es… todo el mundo revisa su email en el móvil ahora, muy raramente en un escritorio, y en el cliente móvil el espacio en pantalla es limitado. ¿Qué van a hacer? Van a mostrar el encabezado ‘From’. No van a empezar a mostrarte en detalle todas las distintas direcciones que hay ahí. Así que vas a ver, oh, he recibido un email de PayPal. Y si, ya sabes, John Spammer es muy bueno creando un cuerpo que parezca un email de PayPal, y seamos sinceros, es muy fácil encontrar un logotipo de PayPal que parezca auténtico en imágenes y demás en Internet.
00:14:25
Eric Trinidad: La gente tiene mucho tiempo libre ahora mismo.
00:14:27
Ash Morin: Sin duda. Y ya sabes, eres un spammer. Así que eres un phisher, ese es efectivamente su trabajo. Así que son buenos en lo que hacen. Así que haces un email que parece de PayPal. Lo envían. Miras tu móvil, parece que es de PayPal.com, pero lo envía spammer.com y ha pasado el SPF. Y lo que da miedo es que el DKIM también pasará, porque si he usado DKIM para enviar desde mi servidor de email spammer.com, entre comillas, entonces tengo el control sobre la firma. Y tengo control sobre dónde está alojada la clave pública, que sería en spammer.com, así que todo eso pasa la autenticación de SPF, la autenticación DKIM, pero parece que es de PayPal. Entonces, ¿qué hago? ¿Qué hace PayPal en ese punto para proteger la reputación de su dominio? Y qué hace un usuario, además de preguntarse si puede confiar siquiera en lo que es esto. Sinceramente, no todo recae simplemente en la heurística del spam. No recae únicamente en que los usuarios estén bien educados, porque no es realista pensar que todo el mundo tenga la educación adecuada o las skills para darse cuenta. ¿Debería preocuparme por esto? ¿Es legítimo? Ahora estamos mejor que nunca porque se ha socializado, pero todavía no hemos llegado. Así que tenemos que pasarle la responsabilidad al propietario del dominio: oye, haz algo. Y para eso servía el SPF. Para eso es el DKIM, pero luego eso no es suficiente. Así que DMARC está ahí para actuar, ya sabes, quiero decir, usando términos para profanos, no basta con que el SPF pase o descomprima lo que se está utilizando para hacer esas comprobaciones en un dominio que tienes que buscar para que un receptor compruebe si el SPF o el DKIM pasan. Tiene que haber una relación entre esas identidades. Y lo que se muestra como de quién pretenden ser el remitente. Ahí es donde realmente… bueno, ya había una necesidad que se identificó antes de DMARC, y hubo algunos esfuerzos aislados y fragmentados para establecer ese tipo de comportamiento mediante otras especificaciones y textos, pero ninguna se adoptó abrumadoramente como un estándar que usaría todo el mundo. DMARC fue realmente el primero que acabó haciéndolo. Así que, en ese punto, una vez que la adopción aumentó, y hablo de verificación y adopción para que el receptor esté adecuadamente equipado para realizar una comprobación de DMARC de los emails que recibe. Así que, en ese momento, lo que DMARC terminó haciendo es decir: vale, volviendo a mi ejemplo, estoy intentando enviar un email porque soy una mala persona. Intento enviar un email desde paypal.com, pero el return path y el DKIM son de spammer.com. Entonces alguien, digamos PayPal, dice, vale, eso no está bien. Así que voy a publicar DMARC, instalaré lo que tenga que instalar y lo haré de manera que ahora cualquiera que no esté autenticado, falle. Lo que acaba pasando es que, por supuesto, un receptor verá eso y verá PayPal. Vaya, PayPal tiene DMARC. Será mejor que compruebe si el return path y el DKIM también son de paypal.com. Vaya, no, es de spammer.com. No es lo mismo. Bueno, eso no es suficiente. Y en ese punto, lo que le pasa a ese email se basa en lo que diga esa política de DMARC. Así que, una vez más, el propietario del dominio tiene el control sobre eso. Entonces el receptor dirá, ah, quieren que lo rechace. No lo acepto. Y es simplemente un uno o un cero, todo o nada, blanco o negro. Exacto. No es una heurística de spam, simplemente está ahí para comprobarlo. ¿Pasa o no pasa? Ya está. Así que esa es la idea detrás de DMARC.
00:18:21
Jonathan Torres: Su diseño es tan bonito, creo, que hace exactamente eso. Exacto. Eso es lo que buscamos, alguna forma de protegerte a ti mismo. Exacto. Como remitente. Si envío cosas, y las envío en mi nombre con mi marca, con mis imágenes, con mi contenido, quiero ser yo el que lo envíe y no cualquier otro. Y, ya sabes, y si es alguien que lo está haciendo, pues sí, voy a protegerme y quiero poder protegerme para decir: no, no dejes entrar estas cosas. Y creo que esa parte es para ti, Kate, en plan, ya sabes, ¿dónde has visto que cosas como esa afecten al aspecto de la entregabilidad? Cuando alguien hace ese uso abusivo, haciendo que parezca que es otro el remitente legítimo, y luego resulta que no lo es.
00:19:00
Kate Nowrouzi: Lo más importante para cualquier marca es su reputación. Así que si sufren phishing o spoofing o suplantación, la marca, los consumidores perderán la confianza en esa marca. Y recuperar la confianza llevará muchísimo tiempo. Si has perdido esa confianza, puede tardar una eternidad. Puede que ni siquiera logres sobrevivir. Por eso animamos encarecidamente a todas las marcas a que autentiquen su tráfico y establezcan registros DMARC sin falta. Pero uno de los retos que veo es que se ha vuelto más fácil animar a las marcas a establecer un registro DMARC. Pero la política que están aplicando; así que todo el mundo publica un registro DMARC, como que eso es más fácil de hacer. Pero luego empiezan con la P, los informes. El informe P igual y así sucesivamente. Son los informes. Esto está pensado en realidad para un periodo de tiempo muy, muy corto mientras haces pruebas y demás. Así que tienes que pasar a cuarentena y rechazar (reject); así que no te detengas, está bien construir y tener una política como p=none al principio. Pero si te quedas ahí, es como si hubieras comprado un regalo para un cumpleaños, lo envolvieras, pero nunca se lo dieras a esa persona. Así que básicamente, pasar por todo eso para luego estar orgulloso diciendo: oh, tengo una política de DMARC.
00:20:29
Eric Trinidad: Construyendo esa relación. Y luego, cuando te ganas esa confianza con tus clientes. O sea, eso es lo que hacemos Jonathan y yo, como TAM todos los días les decimos a nuestros clientes, ya sabes, tienes que construir esa reputación, ganarte esa confianza. Es como cualquier otra relación. No sé si alguna vez has llamado a tu pareja por otro nombre, pero lo fácil que es recuperar esa confianza después de hacer eso… es sumamente difícil. Así que, ya sabes, simplemente hazlo bien y todo irá bien. Configúralo, ponlo en modo de rechazo para que no te rechacen.
00:21:06
Ash Morin: Sí, absolutamente. Y solo para ampliar un poco lo que decía Kate, lo que me parece interesante es ir a implementar un p=none mientras estamos supervisando la aplicación, o como quieras llamarlo. Y lo que me gusta decir también es, vale, ya sabes, crees que la gente está pasando por las puertas, ya sabes, y quieres evitar que eso suceda, y p=none está ahí para encender las luces. Así que instalamos una cámara en la puerta para ver quién está pasando realmente por ella. Pero no estás comprando una puerta ni estás comprando una cerradura. No estás haciendo nada para detenerlo realmente. Ahora sabes quién viene, pero, ¿qué vas a hacer? Y sí, en cuanto a lo que decías, pasan muchas cosas en relación con las razones que podrían explicar por qué se quedan en esa política y no avanzan de verdad. A menudo lo que acaba pasando es que saben que DMARC es beneficioso. Saben que lo necesitan, empiezan con ello. Y luego empiezan a ver esos informes y no tienen forma de procesarlos. Es como, ¿qué hago ahora? En plan, estoy recibiendo miles y miles de informes, y todos son XML y los estoy revisando, y esto es inviable. Así que esa podría ser una razón. Ahora hay muchas soluciones para ello, y evidentemente Dmarcian es una de ellas. Pero cuando te pones a mirar, supongamos que tienes una solución, sin importar cuál sea, puede que te la hayas creado tú mismo. Acudiste a profesionales. No importa. Tienes una forma de ver qué significan. Y entonces te das cuenta de que, uf, aquí hay mucho trabajo que hacer. Eso va a requerir muchas horas de personal. Hay una capacidad que debe asociarse, tal vez necesitemos trabajar en un proyecto aquí para hablar con muchas personas del sector en ese momento, dependiendo del tipo de organización en la que te encuentres, especialmente si es una organización bastante compleja, con muchos usuarios, mucha gente con la que hablar y empezar a tener que juntarlo todo para hacer lo que llamamos ‘descubrimiento de fuentes’, que es entender quién utiliza esa fuente. No puedo hacer un cambio. No hay ningún cambio de DNS que pueda hacer ahora mismo para que esto cumpla. Necesito encontrar quién usa esto. Eso puede ser muy difícil, dependiendo de la estructura de tu organización, de cómo estéis distribuidos y de cómo operéis. Y cuando se dan cuenta de que es mucho trabajo, entonces puede que tengan que preguntarse: ¿tenemos la capacidad para ello ahora mismo? Y si no, entonces necesitan ayuda. Otra razón por la que acudirían a una empresa como Dmarcian, pero eso no viene al caso. El caso es que muchos de ellos, lamentablemente, se quedarán en ‘none’ porque no saben cómo abordarlo. Es mucho trabajo. Y el tiempo es importante para esta gente. Están muy ocupados mitigando amenazas de todas partes. Así que ahora tienen que mirarlo desde la perspectiva de, bueno, ¿cuáles son los riesgos de pasar simplemente a ‘reject’ sin hacer el trabajo previo? Y muy pronto se darán cuenta también de que eso no es posible porque pueden tener algún flujo crítico e importante de email que se verá afectado. Y eso puede que genere ingresos o algo similar, y sencillamente no pueden perjudicarlo. Así que están atrapados. Y eso es una pena.
00:24:07
Jonathan Torres: Ese es exactamente el punto, ¿verdad?, que hay mucho tiempo en el que es simplemente un trabajo abrumador. Y sé que muchas veces es simplemente miedo, miedo a que, si te pones y haces parte de ese trabajo, se te pase algo por alto o pase algo. Y, ya sabes, que no lo implementaste de forma exactamente correcta. O, y que luego rompas de forma crítica algo que funcionaba antes, y entonces todo se te venga abajo. Como la persona que intentaba implementar eso. Así que entiendo perfectamente ese miedo, y a mí nunca me ha pasado, por suerte. Pero no ha sido a ese nivel o no ha sido con DMARC concretamente. Pero entiendo que a veces, ya sabes, bueno, hay cosas que te encomiendan y quieres asegurarte de que haces lo correcto con ellas. Y a eso, creo, es a lo que se reduce todo. Y para los que estéis por ahí y podáis estar en esa situación, que tal vez tengáis ahora mismo una política p=none. Por eso me encantan los Dmarcian del mundo que tienen un sistema y una fuente a la que puedes, digamos, conectarte y obtener esos comentarios. Exacto. Tener la información que necesitas al alcance de tu mano y poder actuar en consecuencia, porque hay muchísimas cosas. Ni siquiera sé cuántas veces he entrado y he mirado el registro SPF de alguien, incluso. Empecemos por algo sencillo, ¿no? Miras un registro SPF. ¿Cuántas personas están enviando mensajes para esta única entidad, ya sabes, una marca reconocible? Están haciendo muchísimas cosas desde muchos sitios diferentes. Miramos el SPF y el registro está al límite en cuanto a la cantidad de fuentes distintas que utilizan para enviar email desde su dominio. Y luego, traduzcamos eso en un intento de implementar DMARC. Con eso, vas a tener que mirar en todos estos lugares y evaluar quién está enviando realmente en tu nombre. ¿Tienen que enviar en tu nombre? Ya sabes, este tipo de auditoría, ¿y qué departamento está haciendo eso? O sea, si eres una empresa grande, probablemente tengas muchos departamentos distintos y cada uno eligió su propio sitio desde el que enviar y tal vez hacen la mitad de la autenticación. Es muy grande y abrumador. Y definitivamente puedo ver, ya sabes, esa parte que da miedo. Exacto, donde intentas hacer lo correcto, pero te quedas paralizado por la cantidad de trabajo que, que conlleva. Así que definitivamente es una de esas cosas que hay que tomarse poco a poco, pero hay que trabajar hacia ese siguiente paso, hacia esa cuarentena y, finalmente, hacia ese rechazo.
00:26:04
Ash Morin: Exacto.
00:26:05
Kate Nowrouzi: Ash, tengo una pregunta para ti. Así que vosotros ayudáis a las marcas a configurar DMARC y tampoco las dejáis ahí, sino que continuáis. Siguen beneficiándose de que vosotros superviséis, les enviéis informes y, si algo sale mal, resolváis el problema. ¿Correcto?
00:26:24
Ash Morin: Bueno, hacemos un poco de todo. En concreto, formo parte de la gestión de los servicios profesionales de EE. UU., de la parte de América, debería decir, en Dmarcian. Así que nuestro objetivo aquí es hacer todo lo anterior. Depende de la ayuda que quieran y de la fase en la que estén. Pero la idea es que intervenimos, si están interesados, y calculamos la cantidad de trabajo que hay que hacer. Y les damos una idea de lo que implicaría para que se vayan preparando. Les preparamos. Les hacemos entender. Oye, esta no es una tecnología de configurar y olvidarse. Te vas a casar con DMARC a partir de ahora. Y hay mucho que tener en cuenta. Así que primero les damos esa perspectiva y luego delineamos el proyecto para que se hagan una idea de: vale, ¿qué haría falta para pasar de ‘none’ a ‘reject’? Y a partir de ahí podemos llegar a un acuerdo. Tal vez quieran ayuda para quedarse con nosotros hasta que lleguemos al modo rechazo (reject). Y en ese momento haremos todo lo que podamos, les ayudaremos no solo a acostumbrarse a… en nuestro caso, vamos a hablar de la plataforma Dmarcian, por supuesto. Así que estoy ahí para asegurarme de que se conviertan en usuarios expertos de nuestro sistema para que lo entiendan a la perfección. También estoy ahí para asegurarme de que entiendan cómo el DNS, SMTP, email, SPT, DKIM, funcionan todos juntos y los matices ahí, mejores prácticas por ejemplo, justo lo que mencionaste antes, empecemos con el SPF, porque es fácil. Por desgracia, no siempre. A veces el SPF puede ser, la gestión del SPF es un problema conocido desde malos consejos que hay en Internet, hasta los límites que existen dentro de un registro SPF, ambos porque el grande que todos temen es el máximo de 10 búsquedas de DNS por las que un receptor debe pasar antes de que emita un error, o simplemente un registro TXT de DNS no puede contener tantos caracteres. Y porque si estamos en un mundo SaaS, tu registro puede crecer inmensamente. Y luego también tenemos que, especialmente si trabajamos tal vez con personas más de la vieja escuela, puede que quieran empezar con el registro SPF como v=spf1 mx -all. Ese es un registro SPF muy común que solía existir. Eso ya no es relevante. Simplemente no lo es. Y ahí tenemos dos mecanismos de consulta de DNS que son inútiles para la mayoría de los dominios. Es solo un ejemplo. Pero luego, si son, ya sabes, enormes y tienen mucho SaaS y quieren centrarse principalmente en su dominio principal de marketing, tal vez no puedan; entonces tendremos que hablar sobre la estrategia de segmentación, que es básicamente aislar los flujos a subdominios por diversas razones, incluida la reputación del dominio. Estoy seguro de que Kate podría comentar sobre ello. Así que ese es solo uno de los aspectos. Así que vamos a hablar sobre cómo configurar MTA específicos hasta hacer cambios de DNS, coordinar y planificar esos cambios, descubrir y también catalogar cada fuente que envía email, a quién pertenecen, quién hace qué, y luego formular un plan y llevarles de la mano. No quiero sonar condescendiente. Por supuesto, se hace con el mejor de los intereses y las mejores intenciones, pero llevarles de la mano para que, si nos necesitan, estemos ahí. Les daremos los mejores consejos que sepamos en base a nuestra experiencia. Y a partir de ahí, aseguramos el éxito. Estamos ahí efectivamente para ofrecerles un resultado exitoso con un riesgo mínimo. Si tuviera que resumirlo lo máximo posible.
00:29:44
Jonathan Torres: Sí, no, quiero decir que eso es exactamente genial. Sí, suena de maravilla. Bueno, creo que eso cubre mucho de lo que queríamos hablar hoy. Exacto. Como qué es y de dónde viene. Las soluciones, las partes que dan miedo. Y luego, con suerte, encontrar un buen punto de encuentro, ya sabes, y gracias por traernos eso, Ash, creo que es algo muy importante. Y Kate, tus conocimientos sobre la parte de la entregabilidad y esa pieza de la reputación. Sé que no solo tienes los conocimientos, sino también la experiencia. Y creo que eso dice mucho y a gritos de, ya sabes, cuál es la importancia de esto y por qué es tan importante que todo el mundo se involucre, lo haga y dé el siguiente paso en ese ámbito de la seguridad, porque es súper, súper, súper importante.
00:30:28
Kate Nowrouzi: Me encantaría continuar esta conversación. Probablemente en el próximo podcast sobre… Ash mencionó un punto muy interesante sobre la segmentación y por qué necesitamos segmentar el tráfico distinto en diferentes subdominios, y cómo implementar una política de DMARC. ¿Esta política de DMARC debe implementarse a nivel organizativo o en cada subdominio? Así que estad atentos. Esperad nuestra próxima sesión. Hablaremos de todos estos detalles. Sí. Muchísimas gracias a Ash, Eric y JT por recibirnos.
00:31:02
Ash Morin: Ha sido un placer.
00:31:04
Eric Trinidad: Muchas gracias a todos. Realmente agradecemos vuestros conocimientos y vuestro tiempo, vuestra sabiduría, todo. Si no hemos cubierto algo hoy y queréis escuchar más al respecto, si queréis que entremos en los detalles para meternos en el meollo de qué es DMARC y cómo configurarlo, ya sabéis, podemos verlo en el próximo episodio, quizás un seminario web, tal vez algo en directo, podríamos hacer algo así. No lo sé. Hacednos saber qué pensáis. Pero si queréis más información sobre DMARC y Dmarcian en concreto, no dudéis en entrar en dmarcian.com y echar un vistazo a sus artículos y blogs allí. Y echad también un vistazo a Mailgun.com/blog para leer nuestros blogs. Gracias de nuevo a todos por vuestro tiempo. Lo agradezco de verdad y espero que volvamos a vernos pronto.
