"...Every year is getting shorter.
Never seem to find the time..."
2010 has already given us the facetiously-named Y2.01K Bug, following the appearance of date-related calculation flaws in the very sorts of application you might reasonably expect not to display such faults.
Merchants and their customers in Australia and in Germany have been bitten by point-of-sale (POS) machines which wouldn't accept payment cards after the clocks ticked over to 01 January 2010. Quite what went wrong in the banking community is not clear.
Media reports in Australia seem to blame the POS firmware for thinking that 2016 followed 2009, bumping the clock forward seven years instead of one and leaving current payment cards apparently long expired. European reports seem to blame the payment cards for failing to accept 2010 and thus ruling themselves invalid.
Spamassassin users found a legacy anti-spam rule which treated their New Year emails as suspicious due to a datestamp of 2010 – a year well into the future back in 2006 when the rule was introduced. Well done to the Spamassassin guys for providing a fix on New Years' Day, but next time, chaps, evaluate "mail in the future" using a relative test, not an absolute one.
Symantec users found their systems rejecting updates after 31 December 2009. Symantec's fix has been to label all 2010 updates as dating from 2009. Smart thinking, indeed, but an unhappy solution because it creates an audit trail which isn't correct. In a well-managed network, cheating your timestamps in one part of the system really ought to produce alerts or alarms in other parts of it.
Other consumer products are also reported to have suffered Y2.01K-itis, leading to speculation about whether some commonly-used code libraries, or some commonly-followed coding practices, are to blame.
The bottom line here is that dates and times, whilst simple in theory, are in practice very hard to work with correctly. Small errors can accumulate until drastic corrections are needed, as a glance at the British and American calendar for 1752 will show. (On Linux/UNIX systems, running the command 'cal 1752' counts as a geeky party trick.)
Even more importantly, the Y2.01K bug ought to be a reminder to those of us who are concerned with network security as a whole – not just with virus prevention, or application control, or endpoint encryption, but with the overall health of the network and all who use it – that it is vital to manage and record dates and times correctly.
In particular, don't let year-ends, timezones, daylight saving changes or varying local conventions confuse your logs. If you suffer a breach, you will almost certainly want to put together an irrefutable historical sequence of events, based on your system logs, possibly from many systems and many locations.
Without reliable logs, you are unlikely to understand the breach, which makes it harder to prevent it happening again. Without reliable logs, you are unlikely to be able to prove your case against the perpetrator, if you are even able to get anyone in your sights. And without reliable and consistent logs, you might not even spot breaches in the first place.
Your homework, then, is to review the following web pages:
* RFC3339: Date and Time on the Internet: Timestamps
* NTP: The Network Time Protocol
(When you have finished your homework, please let me know. We can then work together to explain to my colleagues in the UK how, and why, UTC and GMT differ, and that they oughtn't to be used as synonyms.)