September 13, 1999
Are you beefing up your incident-response teams for year 2000?
The year-2000 problem has held back many IT projects, including many much-needed security efforts. However, until the year-2000 problem is resolved and buried, the pressing concerns for IT departments will not be security, but rather the impending transition from the two-digit address space of the 20th century. But once the dust has settled and the year-2000 hurdle is cleared, the primary focus will turn to security (we hope). But don't wait until after the year 2000 to worry about attacks, because now is when you need to worry most about security breaches.
The scuttlebutt in the field is that malicious hackers, particularly internal attackers, will take advantage of year-2000 paranoia to launch attacks. After all, why not launch an attack during the confusion? Most of the problems discovered following Jan. 1 will probably be blamed on year-2000 programmers, not security compromises.
Worse yet, what havoc could insiders wreak by purposely creating chaos? The year-2000 problem has not received top billing as a security vulnerability because it is potentially present in any software or firmware. With careful planning and judicious placement of code, extortionist Cobol programmers could trigger disaster at the touch of a button.
The psychology of IT is that the first, most reasonable explanation of a problem is most likely the right one. Who among us IT mavens haven't made two or three corrections at once to solve a problem? Throwing the kitchen sink at a problem and hoping any one or a combination of steps will take care of it is often the quickest way to resolution.
But who can blame these overworked, underpaid support engineers? After all, they're not paid to definitively determine the cause of the problem at hand; they're just paid to fix it. This is precisely why year 2000 is ripe to be taken advantage of. As IT departments struggle to resolve year-2000 problems, their first instinct will be to blame the year-2000 bug, not an attacker. Furthermore, when will this attitude end? One day after Jan. 1, 2000? Ten days afterward? There could be a rather large window of opportunity that intruders could exploit.
Incident response (IR) determines definitively when an attack has occurred, and defines the steps necessary to recover from a breach in security. Much like year-2000 preparation, IR preparation involves the classification and resolution of a problem to minimize a system's downtime and exposure. That's why coordinating your IR efforts with your year-2000 staff makes sense.
Schedule a meeting with the year-2000 staff and educate them about your IR methodology, how to detect a break-in attempt, and how to spot a successful break-in. Familiarize them with your incident-reporting structure and gain their confidence so that your participation early in the process can lead to a successful identification of the problem. Devise contingency plans for the unexpected issues, such as IR personnel who may not be able or willing to get to incident sites.
Use the next four months to talk to your year-2000 staff and cross-pollinate your response efforts. Discuss their response methodology and inform them of your own. Cultivate changes that can help you find common ground and a better understanding of the security implications of year-2000 . Now is the time to coordinate your IR along with your year-2000 efforts. Will you be ready? Let us know at security_watch@infoworld.com.
Stuart McClure is a senior manager and Joel Scambray is a manager at Ernst & Young's eSecurity Solutions group. They have managed information security in academic, corporate, and government environments for the past 10 years.
Missed a column? Go back for more.
Copyright © 1999 InfoWorld Media Group Inc.
