Security

Get ready for 2007 Daylight Saving Time changes

If you operate a network in the United States, impending changes to Daylight Saving Time (DST), courtesy of the Energy Policy Act of 2005, is going to affect your operations. Mike Mullins details the effects and tells you how to prepare for them.

Time is critical when it comes to security. Logs, access time, and authentication all need to exhibit the precise time if they're going to work correctly. And synchronization of that time across your enterprise is vital.

If you operate a network in the United States, impending changes to Daylight Saving Time (DST), courtesy of the Energy Policy Act of 2005, is going to affect your operations. Let's look at what these changes entail.

What's the problem?

Most of us are familiar with the DST rule of thumb: Spring forward, Fall back. While the concept will remain the same, the details are changing this year.

Previously, DST began on the first Sunday of April and ended on the last Sunday of October. This year, thanks to an energy bill President Bush signed in August 2005, DST begins three weeks earlier on March 11. (DST also ends one week later; this year, it ends November 4.)

Besides having to manually change some clocks, how does this affect your organization? It depends on what type of hardware and software you have in your enterprise.

For example, if you run Microsoft systems on your network, Windows Vista and Windows Server 2003 are good to go. Both OS versions either have the changes built-in or the changes were part of a previous service pack—one more reason to make sure you're up to date on the latest service pack. But you'll need to update other Windows systems. Don't wait until March 9 to make sure—do your homework now.

However, regardless of what software you're running on your network, the possible effects of an unevenly applied time change can have a variety of effects on your security operations.

  • Authentication systems: Systems that rely on accurate local system time (e.g., Kerberos) to grant system access will typically fail, denying authentication credentials to valid users.
  • Time-based access control systems: Erroneously granted access could result in a violation of security policy. Systems could grant access during a time it should be denied, or they could deny valid users access.
  • Logging systems: Incorrect timestamps result in an inaccurate audit trail.

What's the solution?

Whenever feasible, configure systems to record time in Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT)—not local time. Time zones are subject to changes in local laws and regulations, but UTC and GMT time are consistent across the globe. Two synchronized clocks reading UTC or GMT will be identical regardless of their physical locations. If you're not already using GMT on your security devices and logging mechanism, now would be a good time to start.

For systems that need to run on local time, visit your various vendors' Web sites to determine which solutions they suggest. Here's some links from major vendors to get you started:

  • Apple: Mac OS X has an update that will fix this problem.
  • Cisco: Cisco has patches and workaround solutions available for all supported systems.
  • Juniper: Most current JUNOS versions support the changes. However, it also recommends changing devices to use UTC.
  • Microsoft: Redmond has a wide variety of patches and workarounds for systems beyond its support cycle.
  • Sun: Patches are available; Sun recommends applying patches regardless of current time zone setting.

Final thoughts

This change hasn't received nearly as much hype as the millennium bug, but that turned out to be a huge non-event. However, this isn't a problem you can ignore either. Get your systems patched, updated, or mitigated, and move on to the next problem. Remember: Time stands still for no one.

Miss a column?

Check out the Security Solutions Archive, and catch up on the most recent editions of Mike Mullins' column.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.

Editor's Picks