Keeping Time Without a Source

A while back I wrote about the importance of using a standardized time source.  Keeping accurate time across devices is essential so that you can easily correlate events within logs across the network.  This is normally a pretty easy problem to solve.  In the JNN there is a GPS that is able to pull time from the satellite.  In other cases there are numerous time sources across the NIPRnet and SIPRnet that can be pointed to.  Once you have a local server that is pulling time, it’s just a matter of pointing the rest of devices to it.

But let me ask you a question.  What do you do when you’re operating on a closed network and there is no time source that you can pull from?  As a rule, it is my goal to keep our hunt network as isolated from the customer network as possible.  I do this to ensure the security of the hunt network and everything it touches on the back side.  We pull data in through passive taps, and on the occasion that I need to actually connect a system to the customer network, we take great care to ensure that our network stays safe.

At the same time though, time is critical on my mission network.  When we have multiple sensors across the network, there is the real possibility that they will see the same traffic across multiple sensors.  This is an easy fix when the times match up but if they are even just a few minutes apart, it makes life a lot harder.  But how do you keep time without an authoritative time source?

This was a problem that one of the CPTs on my team John Rollinson recently decided to tackle.  His idea was to sniff the NTP packets that were already going across the wire on the customer network, grab them with the sensor (which is already happening), and then run a program that actually processes the NTP packet and uses it to set the clock on the sensor which I can then use as a time source for the rest of the network.  With that idea in mind, John created TARDIS.

The basic principle of TARDIS is fairly simple, pretend to be the originator of an NTP query and substitute the relevant time fields when doing the time difference calculations. The basic idea behind NTP is to send local time to a remote time server and then calculate clock difference by attempting to account for network latency. Specifically, the requester sends t0 (time request sent) and the time server responds with t0, t1 (time request received), and t2 (time response sent). Upon receiving the response, the requester records t3 (time response received) and calculates ((t1-t0) + (t2-t3))/2. By tracking requests and the associated responses, TARDIS substitutes its local receipt times of the request and response for t0 and t3, respectively. While not a perfect solution, this provides a good reference for synchronizing an isolated monitoring network to the target network, regardless of the actual upstream source of time.

TARDIS provides the ability of anyone operating a closed network the ability to passively grab NTP traffic that is already going across the customer network and put it to work on the closed network and set a time source.  TARDIS is still very much a work in progress.  Currently because of a few technical problems the clock on the sensor is +/- about two seconds of the “true” time according to the actual NTP packets but that is a problem he is working to solve.