La ciberseguridad de un sistema de información se basa en numerosos mecanismos diferentes. Pero casi todos tienen algo en común: necesitan disponer de una referencia horaria correcta y precisa. Los registros llevan sellados de tiempo, los certificados tienen fechas de validez, los tickets de autenticación caducan y los códigos de un solo uso tienen un periodo de validez limitado. Mientras los relojes de los servidores y ordenadores estén sincronizados entre sí, todo funciona correctamente. Pero, en cuanto aparecen desfases, los mecanismos empiezan a fallar uno tras otro: registros que no pueden correlacionarse, autenticaciones rechazadas y certificados que se consideran erróneamente caducados. La seguridad se ve entonces comprometida.
Peor aún, si se produce un ataque con éxito, la falta de sincronización horaria suele impedir conservar la trazabilidad necesaria para determinar qué ha ocurrido.
Por tanto, esta sincronización es indispensable no solo para la seguridad, sino también para cumplir los marcos normativos de referencia.
Un servicio diseñado originalmente sin medidas de seguridad
La sincronización horaria es uno de los servicios más antiguos de Internet. El protocolo NTP (Network Time Protocol), que distribuye la hora entre los equipos, se remonta a los años 80. Se diseñó en una época en la que la red conectaba laboratorios que confiaban unos en otros: sus intercambios no están autenticados ni cifrados, y cualquier equipo puede consultar a cualquier servidor. Este diseño sigue siendo sólido en términos de precisión, pero no tanto en materia de seguridad. Durante décadas, nadie se ha preocupado por ello: la hora era un servicio en segundo plano que no despertaba el interés de los atacantes. A medida que los mecanismos de seguridad empezaron a depender de la sincronización horaria, la hora pasó a ser un objetivo.
Mantenga el control sobre su red horaria
Supervise y controle su sincronización desde una interfaz centralizada e intuitiva.
La importancia del sellado de tiempo en los registros
El efecto más evidente y crucial de la sincronización horaria se observa en los registros. Cada equipo de un sistema de información registra sus eventos internos: conexiones, errores, alertas, etc. Considerados de forma aislada, estos registros narran la «vida» de cada equipo.
Pero, si se cruzan los registros de todos los equipos de un mismo sistema, se puede saber lo que ocurre en el conjunto del sistema. El cruce de registros permite, entre otras cosas, detectar ataques. Existe un tipo de herramienta específica, denominada SIEM (Security Information and Event Management), que recopila los registros de cientos de equipos para identificar secuencias sospechosas.
Sin embargo, para cruzar eventos de distintos equipos, es necesario poder establecer su orden cronológico, y esto solo es posible si todos los equipos asignan a sus registros un sellado de tiempo con la misma hora. Un desfase de apenas unos segundos entre dos servidores basta para invertir el orden aparente de dos eventos y llevar, por ejemplo, a una conclusión errónea sobre cómo se desarrollaron.
El problema resulta aún más evidente después de un incidente. El análisis forense (el que se realiza tras un ataque) consiste en reconstruir cómo sucedieron los hechos a partir de los registros de decenas de equipos: por dónde entró el atacante, cuándo lo hizo y a qué elementos del sistema afectó. Si los relojes no coinciden, esta cronología resulta inutilizable. Y lo que está en juego va más allá de lo técnico: la cronología de un incidente puede presentarse ante una aseguradora o un juez, y su valor depende de la fiabilidad de la fuente horaria en la que se basa.
Por este motivo, la ANSSI recuerda, en sus recomendaciones sobre el registro de eventos, que un evento solo puede analizarse si puede situarse en el tiempo.
La hora y los mecanismos de autenticación
Hay otro aspecto menos evidente de la importancia de la sincronización horaria. Hay que tener en cuenta que algunos mecanismos de seguridad utilizan la hora como uno de sus componentes. Es el caso, por ejemplo, de Kerberos, el protocolo de autenticación que constituye un elemento central de los directorios corporativos como Active Directory y que asigna sellados de tiempo a sus intercambios para impedir que un atacante los capture y los reenvíe posteriormente.
Otro ejemplo son los certificados que protegen las conexiones cifradas, que incluyen una fecha de inicio y otra de fin de validez: un equipo cuyo reloj está muy adelantado rechaza un certificado que en realidad sigue siendo válido, mientras que un equipo cuyo reloj está muy atrasado acepta un certificado caducado.
Por último, los códigos de un solo uso de las aplicaciones de autenticación, basados en el algoritmo TOTP (Time-based One-Time Password), se calculan a partir de la hora actual, en intervalos de treinta segundos: si el reloj del servidor presenta una deriva, los códigos válidos son rechazados.
En todos estos casos, la lógica es la misma. La hora sirve para demostrar que la información es reciente, y una hora incorrecta puede convertir un mecanismo de protección en un fallo de seguridad o en una puerta de entrada para un ataque.
El tiempo como objetivo y arma
Dado que tantas cosas dependen de la hora, falsearla constituye un ataque en sí mismo. Un atacante capaz de alterar la hora de un equipo puede distorsionar la cronología de sus registros, hacer que sus certificados parezcan caducados o prolongar la validez aparente de secretos ya caducados, sin modificar el resto del sistema.
El protocolo NTP es vulnerable a este tipo de ataques: como sus intercambios no están autenticados, un atacante situado en el trayecto de las comunicaciones puede alterar la hora distribuida. Es lo que se conoce como un ataque de intermediario (man-in-the-middle). Existe una medida de protección: el protocolo NTS (Network Time Security), definido en la RFC 8915, autentica el servidor de tiempo y protege los intercambios contra la falsificación.
El tiempo también puede utilizarse como arma contra terceros. En 2013, una función de administración de NTP, el comando monlist, se utilizó masivamente con fines maliciosos: una pequeña solicitud enviada con una dirección de origen falsificada provocaba una respuesta aproximadamente doscientas veces mayor, dirigida a la víctima. De este modo, miles de servidores de tiempo mal configurados sirvieron para amplificar ataques de denegación de servicio. Esta vulnerabilidad, identificada como CVE-2013-5211, deja una lección clara: un servidor de tiempo mal configurado no solo supone un riesgo para su propietario, sino que también puede convertirse en un instrumento para atacar a terceros.
Cumplimiento normativo
Con el tiempo, y debido a los tres aspectos expuestos anteriormente, la sincronización horaria se ha convertido en un requisito de cumplimiento normativo. El estándar PCI-DSS, que regula la protección de los datos de las tarjetas de pago, exige en su requisito 10.4 el uso de servidores de tiempo internos. En Francia, las recomendaciones de la ANSSI sobre el registro de eventos lo consideran un requisito previo para poder utilizar los registros de forma eficaz. La Directiva europea NIS2 (Network and Information Security) exige notificar los incidentes en plazos breves, lo que, en la práctica, requiere poder establecer rápidamente una cronología fiable. Para un responsable de seguridad, la consecuencia es clara: debe comprobar que la arquitectura de sincronización horaria de su sistema cumple los requisitos que ya establecen sus normas de referencia.
Por dónde empezar
Las medidas que deben adoptarse son pocas, pero todas son importantes. En primer lugar, es necesario disponer de una fuente horaria interna y controlada, es decir, de un servidor de tiempo dedicado.
A continuación, hay que utilizar esta fuente como punto de sincronización de todos los equipos, de modo que la coherencia del sellado de tiempo quede garantizada por diseño.
Por último, dependiendo del uso, puede ser recomendable incorporar la autenticación que proporciona el protocolo NTS para mejorar la seguridad del sistema.
No olvide que el propio servidor de tiempo debe considerarse un equipo de seguridad. De hecho, algunos de estos servidores cumplen la norma IEC 62-443.
