Starting this year, DST will be extended by four weeks in the U.S., Canada, Bermuda and the Bahamas because of...
the Energy Policy Act of 2005. For the first time in 20 years, DST will not start on the first Sunday in April. It will begin three weeks earlier, at 2 a.m. on the second Sunday in March. IT shops must now apply a series of patches from their various IT vendors to ensure electronic appointment calendars and other software tools aren't knocked off kilter when the clocks spring an hour ahead.
While basic security tools won't be affected by the switchover, some IT administrators fret about possible timing glitches in their forensic and auditing tools, while others worry about security network access controls being knocked out of balance.
Adding to the complexity of the situation is that Microsoft's next security update comes two days after DST begins, increasing concerns that DST troubleshooting will trump the usual security patching.
Some security bloggers are lamenting the difficulties of making network adjustments and sharing their fears over what could go wrong. Others are downplaying the potential problems and calling for calm.
"Do you know if your computing systems -- PCs, laptops, servers, networking gear, phone systems, security systems -- have been updated to address this change?" IT security professional Jeff Hayes asked in his security blog. "Friday, 9 March is not the day to check and see."
He cited a position paper from Stamford, Conn.-based Gartner Inc. warning that disruptions at an IT infrastructure and application level are likely and will have significant implications for organizations around the world. Gartner warned that interruptions could affect calendaring applications, billing software and security programs as well as travel and trading schedules.
"For security systems, time is a critical component," Hayes wrote. "Incorrect time -- off by an hour in this case -- can cause issues from simple inconveniences to catastrophes."
He said that timing glitches could affect physical access to gates and doors, user authentication systems to user applications, time-based policy rules that regulate privileges, time stamps for logs and records and router-and switch-based controls.
"It is essential that IT managers and security personnel check with their equipment and system suppliers and validate that the versions of software they are running will address this year's DST change," he said.
Some IT professionals noted that the installation of DST patches has been anything but smooth sailing. Tom Olzak, for example, blogged about the headaches he experienced while installing the DST patch for Microsoft Exchange.
"Adjusting calendars in systems like Exchange can be difficult if done manually," he wrote. "Microsoft provided what we believed to be a useful tool to automate this process. If only they had given our patch management team ALL the information required to be successful."
He said the Exchange patching seemed to be going fine until his IT department tried to execute the calendar fix program, which was supposed to move all calendar entries during the weeks between March 11 and April 2 forward by an hour.
"Looking at the instructions for this process, our engineers found no mention of a very important required configuration change -- the calendar must be configured to allow conflicting calendar entries for conference room resources," he wrote. "This important piece of information was also omitted during two telephone conversations with Microsoft support."
Because the fix application was run without making this change, he said, "no appointments for which conference rooms were reserved were adjusted."
While similar tales abound in entries throughout the blogosphere, others wrote that the switchover won't be so bad if cool heads prevail.
Ulrich Drepper wrote in his blog that IT administrators in the U.S. wouldn't be so panicked over DST if they updated their operating systems more often.
"Time zone changes are nothing special. I guess on average we see about 20 each year, maybe more. Do you see people packing 20 times a year?" he asked. "No, only if the U.S. is involved … the root of the problem is the same that keeps the U.S. from making progress on other fronts: fear of change and trying to prevent change through denial."
Pete Lindstrom, senior analyst at Midvale, Utah-based Burton Group, wrote in his Spire Security Viewpoint blog that the DST switch isn't worth all the fuss. At the very least, he said, it's not worth all the comparisons to Y2K.
"For the life of me, I can't figure out what the big deal is, and how it could ever compare to Y2K," he said. "There is a big difference between being off by 100 years and off by an hour."
He said that if an hour really matters to the performance of business applications, IT shops should have a strong handle on it by now.
"The most interesting thing about the DST issue is that it brings time into the limelight," he said. "We really don't work too hard to ensure the validity of our entire time infrastructure on the Internet, anyway. In the same way that we can spoof email addresses and electronic signatures, we can also spoof time."
His advice to IT security professionals: Don't worry about an hour here or there. Instead, worry about the integrity of your entire time infrastructure.