The daylight saving time (DST) shift that will kick in this weekend is a “sleeper event” whose impact hasn’t yet been fully grasped, says a Canadian executive.
The event has been flying under the radar – but its potential fallout should not be minimized, according to Roger Hamshaw, director of channel marketing at Fusepoint Managed Services Inc., a Mississauga-based provider of managed IT services.
Hamshaw says many organizations don’t completely understand the impact of the DST shift, nor have software providers delivered patches with a lot of advanced notice.
“There really needs to be a wakeup call.”
Starting this year, DST will be extended by three weeks on the front end, and one week on the back end. The idea behind the change is to cut energy consumption.
The impact of not applying, or incorrectly applying, DST patches can be as great as a security-related vulnerability, says Hamshaw. “It won’t bring the organization down, but will have a huge impact on [the company’s] brand and its ability to process transactions online.”
Part of the challenge, says Hamshaw, is many companies’ IT departments have had only a month or so to actually apply patches.
The delay is because vendors have only recently issued DST patches despite the legislation passing in August 2005, says George Kerns, president and CEO of Fusepoint.
“I’m sure vendors didn’t neglect this intentionally, but my guess is people didn’t think enough about what would happen. They probably viewed it as more of a cosmetic thing.”
Fusepoint attempted to patch its own servers for the DST shift. Kerns says a particular software vendor, issued 17 patch updates within 30 days. It’s obvious “there wasn’t very good planning done,” he says.
Updating server settings to reflect the new algorithm is not as straightforward as merely applying a patch by the deadline date, the Fusepoint CEO says. “Typically, you have a test environment where you apply the patch, and run tests to make sure it doesn’t break anything else.”
Furthermore, the fall out of poor patching will depend on company size and the types of applications that run on the server infrastructure, he says.
An organization that performs time-sensitive commercial transactions, for instance, may process a transaction with the wrong date. Or the transaction might fail entirely because some patches have been applied along the process, while others have not, says Kern.
A smaller organization on the other hand, he says, may suffer a correspondingly smaller headache with e-mail messages stamped with the wrong time, or calendars off by an hour.
Everyone will probably apply the DST patch, however, the only possible area of omission would be an error in applying a patch, or missing a patch altogether, says Brian O’Higgins, chief technology officer at Ottawa-based Third Brigade Inc. that specializes in intrusion prevention systems.
While improper DST patching won’t result in actual corporate security threats, there may be an increase in incidents of false positives as time changes trigger server alarms, says O’Higgins.
However, he adds, server alarms may not be so bad.
A client, with an IT group of around 50, recently used a Third Brigade security product to assist with the DST change, says O’Higgins.
Essentially, the organization used an alarm as notification that a particular server had been DST patched, therefore providing a checklist of which servers had been patched and which had not.
“You always need visibility. That’s the trouble with any kind of patch, you just don’t know what’s going on,” he says.
Additional reading
