Voy a darle al abogado del empresario algo que normalmente se reserva para la audiencia.
Voy a darle las preguntas. Las preguntas que destruyen un peritaje mediocre. Las preguntas que hacen que el perito del banco se quede en silencio frente al juez. Las preguntas que convierten un dictamen de 40 páginas en un ejercicio de confirmación de la narrativa del banco que no resiste el escrutinio técnico.
No todas las preguntas. No voy a entregar la metodología completa de Duriva en un artículo público. Eso sería irresponsable con los clientes que confían en nosotros. Pero voy a darle las 7 preguntas que todo abogado debería hacer en una audiencia contra el perito del banco en un caso de transferencia no reconocida. Las 7 preguntas que establecen el estándar mínimo de lo que un peritaje informático debería incluir. Las 7 preguntas que, si el perito del banco no puede responder, demuestran que su dictamen está incompleto.
Llevo 17 años en informática forense. He formado a más de 1,300 peritos en 10 países. He enfrentado a los peritos de los cinco bancos más grandes de México en audiencia. Récord invicto en casos de transferencias no reconocidas. Cero derrotas.
Ese récord no se construyó solo con análisis técnico. Se construyó también con la capacidad de hacer las preguntas correctas en el momento correcto. Porque en una audiencia, la pregunta correcta vale más que cien páginas de argumento.
Abogado del empresario, ya sea junior armando su primer caso contra un banco o sénior con años de litigio mercantil: estas 7 preguntas son su arsenal para la contrapericial. No son preguntas retóricas. Son preguntas técnicas con respuestas verificables. Si el perito del banco puede responderlas satisfactoriamente, su peritaje es sólido y usted necesita replantear su estrategia. Si no puede — y en mi experiencia, no puede, porque no hizo el análisis que esas preguntas requieren –, cada «no» que responda es un ladrillo que usted le quita al edificio del banco.
Perito del banco que va a leer esto para prepararse: con todo respeto profesional, y se lo digo porque nos vamos a ver en audiencia: si las respuestas a las 7 preguntas que siguen no están en su dictamen, tiene tiempo de ampliar su análisis. Le conviene. Porque si llega a la audiencia sin esas respuestas, la contrapericial va a evidenciar cada vacío. Y los vacíos en un dictamen pericial no son omisiones menores — son fundamentos para impugnarlo.
Empresario al que le vaciaron la cuenta: lo que sigue es técnico. Pero necesita leerlo. Necesita entenderlo al menos en términos generales. Porque cuando su abogado le presente la estrategia para la audiencia, usted va a saber qué preguntas se van a hacer, por qué se hacen y qué se espera que el perito del banco no pueda responder. Eso le da claridad. Y la claridad, a las 3 AM, vale su peso en oro.
Juez que eventualmente escuchará estas preguntas en una audiencia: con todo respeto al tribunal, las preguntas que presento aquí representan el estándar mínimo que la comunidad internacional de informática forense considera necesario para un peritaje completo en un caso de fraude electrónico. Un dictamen que no aborde estos puntos es un dictamen que analizó solo una parte de la ecuación. Y una parte de la ecuación no es la ecuación.
Antes de las preguntas: por qué el dictamen del banco es predecible
El dictamen pericial que presentan los bancos en casos de transferencias no reconocidas sigue un patrón que he visto repetirse sin variación significativa durante 17 años. El perito del banco — ya sea interno o contratado — hace lo siguiente:
- Obtiene los logs del portal de banca en línea.
- Verifica que las credenciales utilizadas corresponden al titular.
- Verifica que la IP de origen coincide con la registrada.
- Verifica que el token de autenticación fue validado.
- Concluye que la operación fue ejecutada «con las credenciales correctas del usuario, desde la IP registrada, sin anomalías en los sistemas del banco.»
Ese dictamen no es falso. Todo lo que dice es cierto. Las credenciales eran correctas. La IP coincidía. El sistema del banco funcionó correctamente.
Pero ese dictamen es estructuralmente incompleto. Porque analiza exclusivamente el extremo del banco. No analiza el extremo del usuario. No investiga cómo se obtuvieron las credenciales. No examina si el dispositivo del usuario estaba comprometido. No verifica si la red del usuario fue atacada. No determina si el segundo factor de autenticación fue interceptado.
Es como un informe de un accidente de tránsito que solo analiza el semáforo: «El semáforo funcionaba correctamente. La luz estaba en verde para el vehículo que cruzó. Conclusión: no hubo anomalías en el sistema de semaforización.» Correcto. Pero no dice nada sobre el otro vehículo, el conductor, la velocidad, el estado de los frenos, la visibilidad. Analizó el semáforo. No analizó el accidente.
Las 7 preguntas que siguen son las que obligan al perito del banco a confrontar lo que no analizó. Y cada pregunta que no pueda responder es un agujero en su dictamen que la contrapericial va a explotar.
Pregunta 1: «¿Realizó usted un análisis de la memoria RAM del dispositivo desde el que se ejecutó la operación? Si no, ¿por qué no?»
Esta es la primera pregunta porque ataca el punto más crítico: la volatilidad de la evidencia.
La memoria RAM de una computadora contiene información que no existe en ningún otro lugar. Procesos activos en el momento de la operación. Conexiones de red en tiempo real. Malware ejecutándose en memoria que no deja rastro en el disco duro. Sesiones de navegación con credenciales en caché. Inyecciones de código en el navegador (man-in-the-browser). Comunicaciones activas con servidores de comando y control del atacante.
Un peritaje forense serio en un caso de fraude electrónico incluye, como paso prioritario, la captura y análisis de la memoria RAM del dispositivo involucrado. Es el estándar en informática forense. No es un lujo. No es un «plus.» Es el mínimo.
Si el perito del banco no analizó la RAM, no puede descartar la presencia de malware en ejecución al momento de la operación. No puede descartar man-in-the-browser. No puede descartar inyección de código en el navegador. No puede descartar nada de lo que se ejecuta en memoria sin dejar rastro persistente en disco.
Y si no puede descartarlo, su conclusión de que «la operación fue ejecutada por el titular» está construida sobre una premisa que no verificó. No sabe si el titular fue quien dio la instrucción o si un troyano en memoria modificó la instrucción sin que el titular lo supiera. Y si no sabe, no puede concluir.
La respuesta del perito del banco a esta pregunta, en mi experiencia, es siempre la misma: «El análisis de la memoria RAM del dispositivo del usuario no formaba parte del alcance de mi peritaje.» O alguna variación de «no tuve acceso al dispositivo del usuario.»
Cualquiera de las dos respuestas demuestra que el peritaje está incompleto. Si no analizó la RAM porque no estaba en su alcance, su alcance era insuficiente para la conclusión que presentó. Si no tuvo acceso al dispositivo, su conclusión sobre quién ejecutó la operación se basa en datos que no incluyen el dispositivo desde donde se ejecutó. En ambos casos, la conclusión no está sustentada.
Pregunta 2: «¿Correlacionó usted los logs transaccionales del banco con los logs de endpoint del dispositivo del usuario? ¿Tiene evidencia de esa correlación?»
Esta pregunta es devastadora porque expone la falta de análisis cruzado.
Los logs del banco registran la operación desde la perspectiva del servidor del banco: hora de conexión, IP de origen, credenciales utilizadas, instrucción recibida, resultado de la operación. Esos son los logs transaccionales.
Los logs de endpoint son los registros del dispositivo del usuario: historial de navegación, procesos activos, conexiones de red, actividad del sistema operativo, eventos de seguridad. Esos logs registran lo que pasó en la computadora del usuario en el mismo periodo de tiempo.
La correlación entre ambos es lo que reconstruye la historia completa. Porque los logs del banco pueden decir «a las 14:32:17 se recibió una instrucción de transferencia desde la IP 187.xxx.xxx.xxx con las credenciales correctas.» Y los logs de endpoint pueden decir «a las 14:32:15, dos segundos antes, el proceso malware.exe inyectó código en el proceso del navegador chrome.exe y modificó el contenido del formulario de transferencia.»
Sin la correlación, solo tienes la mitad de la película. Y la mitad de la película que tiene el banco siempre cuenta la misma historia: «la operación fue normal.» La otra mitad — la que está en el dispositivo del usuario — puede contar una historia completamente diferente.
Si el perito del banco no hizo esta correlación, su análisis es unilateral. Analizó los logs de su cliente. No analizó los logs del dispositivo involucrado en la operación. Y una conclusión basada en un análisis unilateral no es imparcial ni completa.
Pregunta 3: «¿Los valores hash de la evidencia digital que presenta en su dictamen fueron calculados con SHA-256 o con MD5? ¿Puede justificar técnicamente su elección?»
Esta pregunta parece técnica y menor. No lo es. Es fundamental.
El hash es la huella digital de un archivo o de una pieza de evidencia digital. Es un cálculo matemático que produce un valor único para cada conjunto de datos. Si un solo bit cambia, el hash cambia. Por eso se usa en informática forense: para demostrar que la evidencia no fue modificada entre el momento de la adquisición y el momento del análisis.
MD5 es un algoritmo de hash que fue el estándar durante años. Ya no lo es. MD5 tiene vulnerabilidades conocidas de colisión — es decir, se pueden generar dos archivos diferentes que produzcan el mismo hash MD5. Esto significa que, en teoría, alguien podría modificar una pieza de evidencia y hacer que el hash MD5 siga siendo el mismo. La comunidad de informática forense migró a SHA-256 hace años. SHA-256 no tiene vulnerabilidades conocidas de colisión. Es el estándar actual.
Si el perito del banco presenta evidencia con hashes MD5, esa evidencia tiene un problema de integridad. No porque haya sido modificada, sino porque el método de verificación que utilizó tiene vulnerabilidades documentadas. Y un abogado con conocimiento técnico puede cuestionar la integridad de cualquier pieza de evidencia cuyo hash fue calculado con un algoritmo obsoleto.
Si el perito del banco responde «usamos MD5,» la siguiente pregunta es: «¿Sabe usted que MD5 tiene vulnerabilidades de colisión documentadas desde 2004 y que la comunidad de informática forense recomienda SHA-256 como estándar mínimo?» La respuesta a esa pregunta le dice al juez si el perito está actualizado en las mejores prácticas de su profesión o si está usando herramientas y métodos obsoletos.
Y si el perito responde «no calculamos hash» — que he visto suceder –, su evidencia no tiene verificación de integridad. Lo cual es una falla básica de cadena de custodia digital que cualquier juez instruido en materia de evidencia electrónica debería considerar.
Pregunta 4: «¿Utilizó usted un bloqueador de escritura al examinar los dispositivos de almacenamiento relacionados con la operación? ¿Qué marca y modelo de bloqueador utilizó?»
El bloqueador de escritura es un dispositivo de hardware que se conecta entre el disco duro que se va a analizar y la computadora del perito. Su función es permitir la lectura del disco pero impedir cualquier escritura. Es decir, garantiza que el análisis del perito no modifica absolutamente nada en la evidencia original.
Sin bloqueador de escritura, cada vez que un perito conecta un disco duro a su computadora para analizarlo, el sistema operativo escribe datos en el disco: archivos temporales, registros de acceso, metadatos. Esas escrituras modifican la evidencia. Y evidencia modificada puede ser impugnada.
El uso de bloqueador de escritura es el estándar básico — el más básico — de la informática forense. No es negociable. No es opcional. No es «avanzado.» Es lo mínimo. Cualquier perito que examine un disco duro sin bloqueador de escritura está potencialmente contaminando la evidencia.
Si el perito del banco no usó bloqueador de escritura — o no sabe qué marca y modelo usó, lo cual sugiere que no lo documentó –, la integridad de su evidencia está comprometida. Cada dato que extrajo del disco pudo haber sido modificado por el propio acto de análisis. Y si la evidencia está contaminada, las conclusiones basadas en esa evidencia no son confiables.
En audiencia, esta pregunta tiene un efecto demoledor. Porque si el perito responde «no, no usé bloqueador de escritura,» acaba de admitir que su metodología no cumple con el estándar básico de la profesión. Y si el perito responde «no examiné ningún dispositivo físico, solo revisé los logs del servidor del banco,» acaba de admitir que no hizo análisis forense — hizo lectura de registros. Que es una cosa completamente diferente.
Pregunta 5: «¿Puede usted describir la cadena de custodia del servidor del banco desde el que se extrajeron los logs que presenta como evidencia? ¿Quién tuvo acceso a esos logs entre el momento de la operación y el momento de su análisis?»
Esta pregunta invierte la presión. En lugar de cuestionar la cadena de custodia del lado del usuario, cuestiona la cadena de custodia del lado del banco.
Los logs del banco son la pieza central del argumento del banco. «Los logs demuestran que las credenciales eran correctas.» Pero esos logs no son objetos inmodificables. Son archivos digitales almacenados en servidores. Archivos que pueden ser modificados, filtrados, editados. No estoy sugiriendo que los bancos manipulen logs — estoy preguntando si pueden demostrar que no lo hicieron.
La cadena de custodia digital requiere documentar quién tuvo acceso a la evidencia, cuándo, desde dónde, y qué acciones realizó. Si los logs fueron extraídos del servidor del banco por un administrador de sistemas del banco, y luego entregados al departamento jurídico del banco, y luego entregados al perito del banco, cada uno de esos eslabones tuvo acceso a los logs y tuvo la capacidad técnica de modificarlos.
Eso no significa que los hayan modificado. Pero sin cadena de custodia documentada, no pueden demostrar que no los modificaron. Y un log sin cadena de custodia tiene el mismo problema probatorio que cualquier otra pieza de evidencia sin cadena de custodia: no se puede garantizar su integridad.
En mis contraperitajes, he encontrado que los bancos raramente documentan la cadena de custodia de sus propios logs con el rigor que exigen del usuario. Los logs se extraen, se copian a un USB, se envían por correo al departamento jurídico, se imprimen. En ningún punto de ese proceso hay hash de integridad. En ningún punto hay bloqueador de escritura. En ningún punto hay documentación verificable de quién tuvo acceso.
Si el perito del banco no puede describir la cadena de custodia de su propia evidencia, su evidencia tiene el mismo vicio que el banco le atribuye a la evidencia del usuario: falta de integridad verificable.
Pregunta 6: «¿Analizó usted las reglas de reenvío de correo electrónico configuradas en las cuentas de correo corporativo del usuario en la fecha de la operación?»
Esta pregunta apunta a un vector de ataque específico que los peritos del banco consistentemente ignoran: el compromiso del correo corporativo.
En fraudes bancarios sofisticados, los atacantes no solo comprometen las credenciales bancarias. Comprometen el correo electrónico del usuario. Y una vez dentro del correo, configuran reglas de reenvío automáticas que redirigen copias de todos los correos que contienen palabras como «transferencia,» «CLABE,» «pago,» «factura» a una dirección controlada por los atacantes.
Esas reglas de reenvío son invisibles para el usuario. Están configuradas en la sección de reglas del correo — un menú que el 99% de los usuarios jamás revisa. Y siguen funcionando incluso si el usuario cambia su contraseña, porque las reglas están configuradas a nivel de cuenta, no de sesión.
La presencia de reglas de reenvío maliciosas en el correo del usuario es evidencia directa de compromiso. Demuestra que un atacante tuvo acceso al correo, que configuró infraestructura de espionaje dentro del propio sistema del usuario, y que estaba interceptando comunicaciones financieras.
Si el perito del banco no verificó las reglas de reenvío del correo, no puede descartar que las credenciales bancarias fueron obtenidas a través del compromiso del correo. Y si no puede descartarlo, no puede concluir que el usuario fue quien ejecutó la operación.
En mi experiencia, cuando hago esta pregunta en audiencia, la respuesta es siempre «no.» Porque el perito del banco no tiene acceso al correo del usuario. Y porque no lo consideró parte de su análisis. Lo cual, de nuevo, demuestra que su análisis está incompleto.
Pregunta 7: «¿Verificó usted la integridad de los logs del banco para descartar que hayan sido modificados, truncados o filtrados entre la fecha de la operación y la fecha de su análisis? ¿Qué método de verificación utilizó?»
Esta es la pregunta final y es la que cierra el círculo.
Los logs del banco son la base de todo el argumento del banco. Son los logs los que dicen que las credenciales eran correctas. Son los logs los que dicen que la IP coincidía. Son los logs los que dicen que «no hubo anomalías.»
Pero los logs son archivos digitales. Y los archivos digitales pueden ser modificados. Pueden ser editados para eliminar entradas que muestren anomalías. Pueden ser truncados para mostrar solo el periodo que le conviene al banco. Pueden ser filtrados para excluir registros que evidencien problemas en los sistemas del banco.
La pregunta no es si el banco modificó los logs. La pregunta es si el perito verificó que no los modificó.
La verificación de integridad de logs se hace comparando los logs presentados con una fuente independiente: un sistema de logging centralizado con acceso restringido, un SIEM (Security Information and Event Management) que almacena logs en formato inmutable, un respaldo automático con hash de integridad calculado al momento del respaldo.
Si el perito tomó los logs que le dio el departamento de TI del banco y los presentó como evidencia sin verificar su integridad contra una fuente independiente, esos logs son tan confiables como la buena voluntad del banco. Y en un juicio donde el banco es parte interesada, la buena voluntad no es un sustituto de la verificación técnica.
En mis contraperitajes, pregunto específicamente: «Los logs que usted presenta, ¿fueron extraídos directamente del SIEM del banco o fueron proporcionados por el área de TI? Si fueron proporcionados por TI, ¿verificó usted que esos logs coinciden bit a bit con los almacenados en el SIEM?»
La respuesta, consistentemente, revela que el perito no hizo esa verificación. Porque los bancos no le dan al perito acceso directo al SIEM. Le dan una extracción de logs. Y una extracción de logs proporcionada por una parte interesada, sin verificación independiente de integridad, es evidencia que descansa en la confianza, no en la técnica.
Lo que estas preguntas demuestran en conjunto
Cada pregunta, individualmente, expone un vacío en el peritaje del banco. Pero el poder real de las 7 preguntas está en el patrón que revelan cuando se hacen en secuencia.
Pregunta 1: no analizó la RAM. Pregunta 2: no correlacionó logs del banco con logs del dispositivo. Pregunta 3: usó hash obsoleto o no usó hash. Pregunta 4: no usó bloqueador de escritura o no examinó dispositivos físicos. Pregunta 5: no documentó la cadena de custodia de su propia evidencia. Pregunta 6: no verificó reglas de reenvío del correo. Pregunta 7: no verificó la integridad de los logs del banco.
Siete «no.» Siete vacíos. Siete puntos donde el peritaje del banco no hizo lo que un peritaje completo debería haber hecho.
Y cuando el juez escucha siete «no» consecutivos, entiende algo que cambia la dinámica del caso: el peritaje del banco no es un análisis forense. Es una lectura de los logs del banco con conclusión predeterminada. Es una certificación de la versión del banco, no una investigación imparcial de lo que ocurrió.
Frente a esos siete «no,» un peritaje que sí analizó la RAM, que sí correlacionó logs, que sí usó SHA-256, que sí usó bloqueador de escritura, que sí documentó cadena de custodia, que sí verificó reglas de reenvío, que sí verificó integridad de logs, tiene un peso probatorio incomparablemente mayor.
La diferencia entre los dos peritajes no es de opinión. Es de rigor. Y en un juicio, el rigor gana.
Lo que NO estoy revelando (y por qué)
Voy a ser transparente: estas 7 preguntas son el estándar mínimo. Son las preguntas básicas que cualquier perito competente debería poder responder. Son las preguntas que elevan el piso de lo que se debe exigir en un peritaje bancario.
Lo que no estoy revelando es la metodología completa que Duriva emplea en los contraperitajes. No estoy revelando las herramientas específicas de análisis de RAM. No estoy revelando las técnicas de correlación que usamos para vincular la actividad del troyano con la transacción del banco al milisegundo. No estoy revelando la metodología de reconstrucción cronológica del ataque. No estoy revelando el proceso de análisis de reglas de reenvío ocultas en Exchange y Office 365. No estoy revelando las técnicas de validación de integridad de logs bancarios contra fuentes SIEM independientes.
Eso se queda en el laboratorio. Eso se presenta en audiencia. Eso es lo que diferencia un peritaje genérico de uno que tiene récord invicto contra bancos.
Lo que sí estoy haciendo con estas 7 preguntas es subir el estándar. Subir el piso de lo que un abogado debe exigirle a un peritaje bancario. Subir la vara de lo que un juez debe considerar como peritaje completo versus peritaje parcial. Y, con todo respeto al gremio, subir la exigencia de lo que un perito del banco debería hacer antes de presentar un dictamen que dice «todo fue normal.»
Porque si «todo fue normal» pero no analizaste la RAM, no correlacionaste los logs, no verificaste la integridad de tu propia evidencia, no usaste hash moderno, no usaste bloqueador de escritura, no revisaste el correo y no documentaste la cadena de custodia de los logs del banco, tu «todo fue normal» es una conclusión sin fundamento. Y una conclusión sin fundamento, en informática forense, no es una conclusión. Es una afirmación.
Y las afirmaciones, sin evidencia que las sustente, se caen.
Lo que necesita hacer cada persona que lee esto
Abogado junior armando su primer caso contra un banco:
Memorice estas 7 preguntas. Practíquelas. Entienda por qué cada una es devastadora. Y cuando llegue a la audiencia, hágalas en orden. Cada «no» que obtenga del perito del banco es una grieta en el edificio del argumento del banco. Siete «no» y el edificio se derrumba.
Pero no se quede solo con las preguntas. Necesita el peritaje que sí hizo lo que el perito del banco no hizo. Las preguntas abren los huecos. El peritaje de su lado los llena con evidencia. Las dos cosas juntas — las preguntas y el peritaje — son lo que gana el caso.
Abogado sénior con experiencia en litigio:
Usted ya sabe que la batalla contra el banco es asimétrica. Lo que estas preguntas le dan es la herramienta técnica para nivelar esa asimetría en la contrapericial. Úselas. Y úselas para evaluar al perito que contrate para su lado: si su propio perito no puede responder estas 7 preguntas sobre su propia metodología, busque otro perito.
Perito del banco:
Con todo respeto profesional: si las respuestas a estas 7 preguntas no están en su dictamen, su dictamen no está completo. Y si no está completo, la contrapericial va a exponerlo. Tiene la oportunidad de ampliar su análisis antes de la audiencia. Le sugiero que la tome. Porque llegar a la audiencia con un dictamen que solo lee logs y pretende que eso es un peritaje forense es exponerse a una serie de preguntas para las que no va a tener respuestas satisfactorias.
Y un perito que no tiene respuestas en una audiencia pierde credibilidad. No solo en ese caso. En todos los casos futuros donde ese juez lo vuelva a ver.
Empresario al que le vaciaron la cuenta:
Estas 7 preguntas son la razón por la que el peritaje del banco no es la última palabra. El banco va a presentar su dictamen. Su dictamen va a decir que todo fue normal. Y su abogado, armado con estas preguntas y con un peritaje forense que sí analizó lo que el banco no analizó, va a demostrar que «todo fue normal» es una conclusión basada en un análisis incompleto.
La batalla se gana en la audiencia. Y en la audiencia, las preguntas correctas valen más que las respuestas del banco.
Juez:
Con todo respeto al tribunal: un dictamen pericial que no incluye análisis de RAM, que no correlaciona logs de ambos extremos, que usa hashes obsoletos, que no documenta cadena de custodia, que no verifica integridad de sus propios logs, no es un análisis forense completo. Es una lectura parcial de datos de una de las partes. Y una lectura parcial de datos de una de las partes es exactamente eso: la versión de una parte. No la verdad del caso.
La verdad del caso está en la investigación completa: el lado del banco y el lado del usuario. El dictamen que analice ambos lados es el que refleja la realidad. El dictamen que analice solo uno es el que refleja un interés.
El peritaje del banco dice que «todo fue normal.» Siempre dice que todo fue normal. Es lo único que puede decir cuando solo mira sus propios logs. Porque sus logs siempre muestran lo mismo: credenciales correctas, IP registrada, sin anomalías.
Pero «todo fue normal» no responde 7 preguntas. No responde si había malware en la RAM. No responde si los logs del endpoint cuentan otra historia. No responde si el hash que usó sigue siendo confiable. No responde si usó bloqueador de escritura. No responde si la cadena de custodia de sus propios logs es verificable. No responde si el correo estaba comprometido. No responde si sus logs están intactos.
Siete preguntas. Siete vacíos. Siete razones por las que «todo fue normal» no es una conclusión forense, sino una afirmación sin sustento.
En Duriva, no hacemos afirmaciones. Hacemos análisis. Y nuestros análisis responden las 7 preguntas — y muchas más que no están en este artículo. Por eso el récord es invicto. No por las preguntas que hacemos en audiencia. Por las respuestas que nuestro peritaje ya tiene cuando las preguntas se hacen.
El peritaje del banco dice «todo fue normal.» El peritaje forense dice «esto es lo que realmente pasó.»
Y cuando un juez tiene los dos frente a él, la diferencia es evidente. No por retórica. Por rigor. Por evidencia. Por ciencia.
Siempre por ciencia.