CERT Y2K FAQ - Includes information to help sites determine whether a failure is Y2K related or an attack.
2380768c6451a4cfb53db684471538c198e1fe40f50bc442053724b576f7e573<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<HEAD>
<TITLE>Frequently Asked Questions About the Year 2000 Computer Problem</TITLE>
</HEAD>
<BODY>
<BODY BGCOLOR="#FFFFFF" VLINK="#C7AA05" LINK="#004A6B" ALINK="#DDB30B">
<DIV ALIGN="left">
<TABLE WIDTH="100%" CELLSPACING="0" BORDER="0" CELLPADDING="0">
<TR>
<TD WIDTH="50%">
<IMG SRC="http://www.cert.org/images/cmu_sei.gif" WIDTH="239" HEIGHT="37" ALT="The CERT/CC is
part of the Software Engineering Institute at Carnegie Mellon University"></TD>
<TD WIDTH="50%" VALIGN="middle" ALIGN="right">
<IMG SRC="http://www.cert.org/images/improvingsecurity.gif" WIDTH="123" ALT="Improving Security" HEIGHT="19" ALIGN="bottom"> </TD>
</TR>
</TABLE>
</DIV>
<DIV ALIGN="left">
<TABLE WIDTH="100%" CELLSPACING="0" BORDER="0" CELLPADDING="0">
<TR>
<TD WIDTH="54">
<IMG SRC="http://www.cert.org/images/invisible.gif" WIDTH="54" ALT="" HEIGHT="1"></TD>
<TD WIDTH="18%">
<IMG SRC="http://www.cert.org/images/certcc_head.gif" WIDTH="189" ALT="CERT® Coordination Center" HEIGHT="18"></TD>
<TD WIDTH="85%" BGCOLOR="#DCDCDC">
<P ALIGN="left"><SMALL><SMALL><FONT FACE="Helvetica, Geneva, Arial">
<A HREF="http://www.cert.org/index.html">Home</A> |
<A HREF="http://www.cert.org/nav/whatsnew.html">What's New</A> |
<A HREF="http://www.cert.org/faq/cert_faq.html">FAQ</A> |
<A HREF="http://www.cert.org/contents/contents.html">Site Contents</A> |
<A HREF="http://www.cert.org/contact_cert/contactinfo.html">Contact Us</A> |
<A HREF="http://search.cert.org:8765/">Search</A>
</FONT></SMALL></SMALL></TD>
</TR>
</TABLE>
</DIV>
<DIV ALIGN="left">
<TABLE WIDTH="100%" CELLSPACING="1" BORDER="0" CELLPADDING="5">
<TR>
<TD WIDTH="47">
<IMG SRC="http://www.cert.org/images/invisible.gif" WIDTH="47" ALT="" HEIGHT="1"></TD>
<TD WIDTH="100%" ALIGN="left"><P ALIGN="left">
<FONT SIZE="1" COLOR="#004A6B" FACE="Helvetica, Geneva, Arial">
<A HREF="http://www.cert.org/nav/aboutcert.html">About Us</A> |
<A HREF="http://www.cert.org/nav/alerts.html">Alerts</A> |
<A HREF="http://www.cert.org/nav/training.html">Education and Training</A> |
<A HREF="http://www.cert.org/nav/events.html">Events</A> |
<A HREF="http://www.cert.org/ftp/">FTP Archives</A> |
<A HREF="http://www.cert.org/nav/securityimprovement.html">Improving Security</A> |
<A HREF="http://www.cert.org/nav/other_sources.html">Other Resources</A> |
<A HREF="http://www.cert.org/nav/reports.html">Reports</A> |
<A HREF="http://www.cert.org/research/">Survivability Research</A></FONT></TD>
</TR>
<TR>
<TD WIDTH="47">
<IMG SRC="http://www.cert.org/images/invisible.gif" WIDTH="47" ALT="" HEIGHT="1"></TD>
<TD WIDTH="100%" HEIGHT="12"></TD>
</TR>
</TABLE>
</DIV>
<!-- This section leaves a table definition open. -->
<!-- Each document must close it somewhere else. -->
<DIV ALIGN="left">
<TABLE WIDTH="100%" BORDER="0">
<TR>
<TD WIDTH="47" VALIGN="top" ROWSPAN="2">
<IMG SRC="http://www.cert.org/images/invisible.gif" WIDTH="47" ALT="" HEIGHT="1"></TD>
<TD WIDTH="100%" VALIGN="top"></TD>
</TR>
<TR>
<TD WIDTH="100%" VALIGN="top">
<TABLE>
<TR>
<DIV ALIGN="left">
<TABLE WIDTH="100" HEIGHT="225" ALIGN="left" CELLSPACING="0" BORDER="0" CELLPADDING="7">
<TR>
<TD BGCOLOR="#DCDCDC" VALIGN="top" HEIGHT="175">
<FONT FACE="Helvetica, Geneva, Arial" COLOR="#004A6B"><SMALL><SMALL>
<P><A HREF="http://www.cert.org/incident_notes/">Incident Notes</A>
<P><A HREF="http://www.cert.org/vul_notes/">Vulnerability Notes</A>
<P><A HREF="http://www.cert.org/security-improvement/">Security Improvement Modules</A>
<P><A HREF="http://www.cert.org/tech_tips/">Tech Tips</A>
<P><A HREF="http://www.cert.org/ftp/tools/">Tools</A>
<P><A HREF="http://www.cert.org/other_sources/tool_sources.html">Other sources of tools</A>
<P><A HREF="http://www.cert.org/nav/training.html">Training</A>
<P><A HREF="http://www.cert.org/nav/alerts.html">Alerts</A>
<P><A HREF="http://www.cert.org/y2k-info">Y2K</A>
</SMALL></SMALL></FONT>
</TD>
<TD WIDTH="3" VALIGN="top" ROWSPAN="2"></TD>
</TR>
<TR>
<TD VALIGN="top" HEIGHT="5"></TD>
</TR>
</TABLE>
</DIV>
<DIV CLASS="intro">
<TABLE>
<TR><TD>
<H1>
Frequently Asked Questions About the Year 2000 Problem</H1>
<P>
<I>This document is the product of the
International Y2K Workshop, held 26-28 October 1999, and the CERT
Coordination Center. Workshop participants represented various parts of the
Internet community, including members of the Forum of Incident Response and
Security Teams (FIRST), several national governments, computer vendors,
industry, educational institutions, and network service providers.<P>
Authors include
<UL>
<LI>Rob D. McMillan - AusCERT (Australian Computer Emergency Response Team)
<LI>Elizabeth A. Siemers, Capt. USAF - DISA/DOD-CERT
<LI>David Parker - UNIRAS
<LI>Quinn Peyton - CERT/CC
<LI>Mark Zajicek - CERT/CC
<LI>Jeffrey Carpenter - CERT/CC
<LI>Katherine Fithen - CERT/CC
</UL>
The International Y2K Workshop was sponsored by the
<A HREF="http://www.y2k.gov/new/icc.html">
Y2K Information Coordination Center (ICC)</A>, and was led by the
<A HREF="http://www.cert.org/">CERT® Coordination Center (CERT/CC)</A>.</I>
<P>
</FONT>
</TD></TR>
</TABLE></DIV>
</TR></TABLE>
<P>This "Frequently Asked Questions" document is intended to be a "living"
document, and new questions and additional information will be added to it
as we receive them. Please check back regularly for updates.
<FONT SIZE="-1">
<P><U>Last updated: December 16, 1999</U> (reorganized document subsections and
added <I>extensive</I> additional information [on Preparation, Triage, and
Response] from <A HREF="http://www.auscert.org.au/"><B>AusCERT</B></A>;
also added link to Y2K virus resources)<BR>
Click <A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#rev">here</A> for full <A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#rev">Revision History</A>.
</FONT>
<BR>
<A NAME="intro"></A>
<OL TYPE="I">
<LI>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#I">General Information</A></LI>
<LI>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#II">Malicious Code</A></LI>
<LI>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#III">Preparation</A></LI><BR>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#III.A">- Technical</A></LI><BR>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#III.B">- Organizational</A></LI>
<LI>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#IV">Detection</A></LI>
<BR><A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#IV.triage">- Triage Guidelines for Distinguishing a Y2K Problem
versus an Attack</A>
<LI>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#V">Response</A></LI>
<BR><A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#V.ir_checklist">- Incident Response Checklist</A>
<LI><A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#VI">What Not To Do</A></LI>
<LI>
<A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html#VII">Other Resources</A></LI>
</OL>
<HR NOSHADE SIZE="2" ALIGN="LEFT"><A NAME="I"></A>
<H3>
I. General Information</H3>
<OL>
<LI><B>What is the Year 2000 (Y2K) computer problem?</B></LI>
<P>A number of computer programs represented the date of a year by using
two digits. In these programs, the year 2000 is represented as 00. This
could cause errors in programs that use the two-digit year format.
<P><LI><B>What are the dates that I should be concerned about?</B></LI>
<P><UL>
<LI><U>September 9, 1999</U></LI>
<BR>There was concern that the date 9/9/99 would be interpreted as an error
code in older programs. The CERT/CC did not receive any reports of problems
caused by the date of September 9, 1999.
<LI><U>Fiscal year roll-overs</U></LI>
<BR>For some businesses, the fiscal year 2000 (FY00) has already started
or will start prior to January 1, 2000.
<LI><U><I>Saturday</I> January 1, 2000</U></LI>
<BR>If software programs use a day of the week in their operations and
interpret 00 to mean the year 1900 they could run in unexpected ways. For
instance, Saturday, January 1, 2000 could be misinterpreted as January
1, 1900, which fell on a Monday.
<LI><U>February 29, 2000</U></LI>
<BR>The general algorithm to determine a leap year is to check if the year
is divisible by 4. The exception to this first rule is that if a year is
divisible by 100 then it is not a leap year. The exception to this second
rule is years divisible by 400 are leap years. Some programs that determine
if a year is a leap year may not consider 2000 to be a leap year.
</UL>
<P><LI><B>Will all Y2K-related activity occur on January 1, 2000?</B></LI>
<P>Y2K failures may occur on days other than January 1, 2000. The
potential for failure depends on how dates are used in an application. If
an application is processing future dates, and it is not Y2K compliant,
there may be failures before January 1, 2000. Failures in non-compliant
applications might also occur after January 1, 2000 if the application's
first process dates beyond 1999 after that day. <P>This means that
differentiating between Y2K problems and possible attacks may be a
problem both before and after January 1, 2000. <P>During preparations
for Y2K, many organizations had a significant number of lines of code
updated or rewritten. It is possible that time bombs or backdoors were
added to applications while they were being updated. If this has
happened, the results of this may not be shown on January 1, 2000. The
activation of a time bomb may occur before or after January 1, 2000 and
the use of a backdoor may also occur before or after January 1, 2000. It
is important that security vigilance not be reduced after January 1,
because the potential for computer security incidents does not decline
after January 1, 2000.
<P>Also keep in mind that not all Y2K failures (if any) will necessarily
occur at midnight, your local time, during the rollover to January 1, 2000.
For organizations that have interdependent systems that span multiple
time zones, some failures may begin to occur hours earlier (or later)
than the time of the rollover in your local time zone.
<P>Also, be aware that different computer systems' internal clocks may
represent their time information in different ways (local time
vs. Greenwich Mean Time [GMT] or Coordinated Universal Time [UTC]).
Therefore, depending on how various software applications might rely upon
and interpret that time information, some failures may begin to occur at
midnight GMT+0, which would be hours before midnight on New Year's Eve
for sites in the western hemisphere (or hours after midnight for sites in
the eastern hemisphere).
<P><LI><B>Will the Internet stop on January 1, 2000?</B></LI>
<P>Internet industry, academia, and government participants have been
working for some time to deal with Internet Y2K problems. A group of them
met in a roundtable of July 30, 1999, which resulted in a compilation of
Y2K information for the Internet industry. The following document is a
result from the Y2K roundtable:
<P><A HREF="http://www.cert.org/y2k/indmessage.html">
http://www.cert.org/y2k/indmessage.html</A>
<BR>
<P><LI><B>Will intruders break into my computer on January 1, 2000?</B></LI>
<P>The need to take security precautions does not necessarily increase or
decrease because of Y2K. Sites should ensure that they are following the
advice that we have provided on securing their systems. However, the
general feeling is that it is possible that intrusion attempts, viruses,
and other attacks will be focused on the time around 01 January 2000
under cover of Y2K incidents. Even if this turns out not to be the case,
it makes sense to prepare as if it were. Sites should therefore ensure
that their systems are appropriately secured.
<P>For further information about the possible threats that intruders may
pose, see the paper <I>Cyber Infrastructure and Malicious Expectations
during the Y2K Transition Period</I>, written by participants of the
International Y2K Workshop, Threat Analysis Working Group; this paper is
available from <P>
<A HREF="http://www.cert.org/y2k-info/y2k-cyberthreats.html">
http://www.cert.org/y2k-info/y2k-cyberthreats.html</A>
<P><LI><B>Are the tools provided on the CERT/CC web site Y2K compliant?</B></LI>
<P>The tools available at the CERT/CC ftp and web site
<A HREF="http://www.cert.org/ftp/tools/">http://www.cert.org/ftp/tools/</A>
were not developed by the CERT/CC. If you have questions, contact the site
that maintains the tool to obtain Y2K compliance information.
</OL>
<A NAME="II"></A>
<H3>
II. Malicious Code</H3>
<OL>
<LI><B>Is Y2K a computer virus?</B></LI>
<P>No. There have been reports of Trojan horse programs and email hoaxes
claiming to fix Y2K problems on your computer. As with past Trojan horse
programs, it is important to take great caution when you receive any email
message telling or tempting you to run an attached file. The following
CERT/CC advisory discusses Trojan horse programs in detail:
<P><A HREF="http://www.cert.org/advisories/CA-99-02-Trojan-Horses.html">
http://www.cert.org/advisories/CA-99-02-Trojan-Horses.html</A>
<P><LI><B>Is it true that there will be a lot of new viruses released around the
year 2000?</B></LI>
<P>New computer viruses are continuously created so it is important
to keep your anti-virus software up to date and to check your system integrity
checking logs frequently. Currently, every day of the year has a virus
set to activate its payload. Further information on computer viruses, hoaxes,
and Trojan horse programs can be found at the following location:
<P><A HREF="http://www.cert.org/other_sources/viruses.html">
http://www.cert.org/other_sources/viruses.html</A>
<P>More information specific to Year 2000 Computer Viruses and Hoaxes can be
found at the following location:
<P><A HREF="http://www.cert.org/y2k-info/y2k-virus.html">
http://www.cert.org/y2k-info/y2k-virus.html</A>
<P>We recommend that system administrators update anti-virus scanning
software after the January 1, 2000 rollover and before the start of
business on Monday January 3, 2000. If there are new viruses discovered
during the Y2K rollover, installing updates during this time will help to
prevent the newly discovered viruses from spreading within your
organization.
</OL>
<A NAME="III"></A></OL>
<H3>
III. Preparation</H3>
<OL><LI><B>What do I need to do to prepare for Y2K?</B></LI>
<P>The preparations required for the Y2K rollover will be a mix of
preventative practices (i.e. steps to prevent any problems) and
precautionary practices (i.e. steps to minimize the impact of any
problems). Many organizations will already be using these practices as
part of their normal day-to-day operations. In this case, the only real
changes that such organizations will need to consider would be extra
awareness and caution when evaluating and responding to abnormal events.
<P>The scope of preparations are both technical (i.e. technical measures
applied to computers and networks) and organizational (i.e. measures to
prepare the organization as a whole, and individual staff in particular).
These are presented in the checklists below. It is possible that not all
steps will be relevant to every case, and so each organization should
evaluate its own needs.
<A NAME="III.A"></A>
<P><B>Technical</B>
<P><LI><B>What do I need to do, from a technical standpoint, to prepare my
systems for Y2K compliance?</B></LI>
<P>Review all of your equipment for Y2K remediation, and confirm that it
is still reliable, both before the rollover and after. This applies not
just to computer systems, but any other embedded systems you may use (for
instance, electronic systems that control physical access to your
building).
<P><LI><B>Can you give me examples of items to test?</B></LI>
<P>Examples of a layered approach to evaluation are:
<P><UL>
<LI>System BIOS</LI>
<LI>Hardware drivers</LI>
<LI>Firmware</LI>
<LI>Operating systems</LI>
<LI>Networking equipment such as routers and switches</LI>
<LI>All software applications</LI>
<LI>Online services you require (e.g., banking, ISP)</LI>
</UL>
<P>Some members of the vendor community have privately noted there have
been cases of system integration problems between two or more supposedly
compliant machines. Each organization should therefore independently
verify the interoperability of systems after remediation.
<P>As part of their verification regime, sites may also wish to consider
creating clones of their operational systems, and verify reliability by
setting the date forward past the rollover.
<P><LI><B>How do I test my system BIOS?</B></LI>
<P>The following site has instructions on testing your BIOS for Y2K
compatibility: <A HREF="http://www.tyler.net/tyr7020/y2kinput.htm">
http://www.tyler.net/tyr7020/y2kinput.htm</A>
<P>If you have an old BIOS that is not Y2K compliant, contact the vendor
for your motherboard or computer. In many cases you can update the system
BIOS using software downloaded from the vendor.
<P><LI><B>I have checked that my systems are Y2K compliant -- what else do
I need to do?</B></LI>
<P>Backups should be taken and verified often. At the very least, a
reliable backup of all systems should be taken several weeks prior to the
date rollover, and another just prior to the rollover. The exact day and
time will depend on organizational business practice. Do not leave backups
until the last minute, as it is important that the backup is completed
before the rollover.
<P>The reliability of these backups should be confirmed by performing a
restore operation from them.
<P>The location, availability and reliability of annual and semi-annual
system archives should also be confirmed.
<P>Additionally, technical staff should be satisfied that each backup is
free from security vulnerabilities. Any backup that is not free from
security vulnerabilities simply re-introduces the problem when used as the
base for a system restoration.
<P>Sites may also wish to consider taking a cryptographically strong
baseline of critical systems that can later be checked for backdoors or
other unfamiliar code.
<P><LI><B>How do I secure my computers?</B></LI>
<P>This should, of course, already be part of your business process.
On networks, for example, only run those network services that are essential,
and ensure those that are essential are securely patched and up to date.
The following CERT/CC documents address this question in detail:
<P>Securing Desktop Workstations
<BR><A HREF="http://www.cert.org/security-improvement/modules/m04.html">
http://www.cert.org/security-improvement/modules/m04.html</A>
<P>Securing Network Servers
<BR><A HREF="http://www.cert.org/security-improvement/modules/m07.html">
http://www.cert.org/security-improvement/modules/m07.html</A>
<P>Also consider other advice in this area from FIRST teams (see
<A HREF="http://www.first.org/">http://www.first.org/</A>).
<P>Ensure your defense mechanisms (such as virus scanners and intrusion
detection systems) are fully up to date. Ensure you have alternative
sources/mirrors for virus scanner vendors, as these may be saturated due to
Y2K demand. Consider the possibility for testing your network and other
defenses. For example, simulate port scanning techniques to see if these
are noticed, or commission a penetration test.
<P><LI><B>To limit the potential for network intrusion, should I shut down or
disconnect my computers from the Internet on December 31, 1999?</B></LI>
<P>Many organizations are considering whether to disconnect systems during
the rollover period. Any decision should be based on confidence in the
security of the systems in question, and how critical it is for these
systems to maintain connectivity. This decision should be taken in
accordance with local policies and procedures. Shutting a system down
should not necessarily be considered to be a requirement. There are
alternatives aside from the extremes of maintenance of normal connectivity
or shutting a system down completely. These include:
<P><UL>
<LI>Total disconnection from external networks</LI>
<LI>Partial decommissioning of some or all services to reduce risk
(e.g. WWW, SMTP, FTP, DNS)</LI>
<LI>Reduce activity by completing existing tasks and postponing acceptance
of new tasks until after the rollover</LI>
</UL>
<P>Bear in mind that 01 January 2000 is a Saturday; this may mean less
disruption than a normal weekday.
<P>In cases where systems are shutdown or disconnected during the rollover
period, it is possible that these systems will still be exposed to some
level of risk during recommissioning. The only advantage is that the
possibility of the failure or attack may be postponed until that time.
<P>There are other problems that may occur by shutting down SMTP, for
example. Most importantly, if a major source of incoming information is
removed, this may prevent the reception of timely and important
information, such as reports on intruder activity and notice of security
patches.
<P>It is also possible that if enough sites choose to do this, common
upstream storage points (such as an ISP providing connectivity) may receive
a sufficient volume of electronic mail to exhaust available storage. In an
extreme case, this may result in a form of denial of service.
<P>Any decision to reduce service to combat one set of risks should take
into consideration other risks that may be introduced as a result.
<P><LI><B>Should I continue to install patches?</B></LI>
<P>We recommend that you continue installing patches and workarounds
for security problems. It may be appropriate to leave other patches until
systems are proven stable in January 2000. As always, we recommend that
you obtain those patches from sources you trust, and verify their integrity.
Be extremely careful with unsolicited patches you receive via email or
with software or patches that claim to solve Y2K problems. Validate these
with your security office/CSIRT/vendor as appropriate. This may also be
a good time to inventory and verify software on your system. Do not forget
to include the software installed to test Y2K compliance and patches in
case last minute problems are discovered.
<P><LI><B>What about anti-virus and intrusion detection updates?</B></LI>
<P>New viruses are being released on an almost daily basis. The rollover
period is not expected to see any decrease in this activity. Therefore it
would be prudent to ensure virus and intrusion detection signature files
are up to date just prior to the rollover, and on regular (possibly
frequent) intervals after the rollover during the period of most heightened
awareness.
<P>Furthermore, it would be prudent to ensure that alternative sources
(mirrors) are available if possible, in case that distribution sites are
saturated during this period.
<P>One of the expected problems that sites may face is a potential increase
in the volume of intruder activity. Such an increase would make the task
of distinguishing the "signal" from the "noise" more difficult simply by
virtue of the increase in traffic volume. Some sites may wish to consider
increasing sensitivity of intrusion detection and auditing systems during
this period, where applicable. However, it is probable that in doing this,
an increase in the number of "false positive alarms" will be experienced.
<P><LI><B>Should we "freeze" our software?</B></LI>
<P>Many organizations are considering software freezes, and some have
already started the freeze period. The motivation for this step is to
ensure a stable platform during the period of heightened awareness. This
is effectively a business decision, and should be taken in conjunction with
maintenance requirements. For instance, some specialist applications may
require data to be refreshed (for example, by closing off 1999 data and
establishing new structures for 2000 data) at the end of a yearly cycle.
As part of the maintenance regime, modifications to configuration files or
software may be required, and allowance for this necessity with appropriate
sign-off should be considered.
<P>Likewise, it is important to ensure that any software freeze does not
affect the ability of staff to rapidly apply security-related updates or
upgrades. We recommend that you continue installing patches and
workarounds for security or Y2K problems. It may be appropriate to leave
other patches until systems are proven stable in January 2000. As always,
we recommend that you obtain those patches from sources you trust, and
verify their integrity. Be extremely careful with unsolicited patches you
receive via email or with software or patches that claim to solve Y2K
problems. Validate these with your vendor, security officer, or CSIRT as
appropriate.
<P>This may also be a good time to inventory and verify software on your
system. Do not forget to include the software installed to test Y2K
compliance and patches in case last minute problems are discovered.
<P>Changes beyond this must strike a fine balance between maintaining a
stable system (and thus minimizing unnecessary change), with the
requirements of ensuring maximum system security for what may be a
critical period.
<A NAME="III.B"></A>
<P>
<B>Organizational</B>
<P><LI><B>What should we prepare to look for?</B></LI>
<P>Sufficient staff will need to be available to carry out monitoring. Two
types of monitoring will be required. Activity on systems and networks
will be important to determine unusual activity - it is likely that the
potential for increased activity means that automated tools to assist in
this task will be required. The other form of monitoring required is
situational - namely to take notice of what is occurring at other
organizations in order to determine what could be expected locally.
Sources of this information include CSIRTs and national Y2K coordination
centers.
<P>Staff will need to be made aware ahead of time the hours in which
availability is required. It is important to ensure that the staff who are
required will have sufficient expertise and experience to address
situations as they may arise.
<P><LI><B>What can we do to educate our staff?</B></LI>
<P>Staff should be educated in advance as to possible events that may
occur during the period of heightened awareness. They should be alerted
to the need to not make false assumptions before an evaluation of any
failure is completed, and to the necessity of a measured response in
order to avoid provoking unnecessary over-reaction.
<P>There is also the possibility of social engineering attempts being
carried out against naive staff, under the guise of addressing some
Y2K-related problem. Staff should be aware of these possibilities and
the correct local procedures that apply.
<P>The possibility of Y2K failure or attack disguised as a Y2K event is
not confined to 1 January, or even to the first week of January. A Y2K
failure or attack could occur at any time throughout the year (or
possibly afterwards) although the incidence of Y2K failure is expected to
decrease over time. However, some level of sensitivity should be
maintained until at least after 1 April.
<P><LI><B>What about contingency plans?</B></LI>
<P>While no organization wishes to see an interruption to critical
services, it is important to have a contingency plan in case these
services are interrupted. The Mitre Corporation has published some
comprehensive material at
<A HREF="http://www.mitre.org/technology/y2k/docs/CONTINGENCY_PLAN.html">
http://www.mitre.org/technology/y2k/docs/CONTINGENCY_PLAN.html</A>
<P>Prepare for the possible failure of critical services such as
electricity, water, or telecommunications. Determine how these types of
failures might affect organizational ability to respond to incidents, and
consider backup plans (such as relocating to another site).
<P><LI><B>What can I do to prepare for Y2K from the perspective of computer
security incident response?</B></LI>
<P>Each site should have a plan for response to a security-related
incident. This is a non-trivial topic that has been covered elsewhere.
Useful references include:
<P><UL>
<LI>RFC2196 - see <A HREF="ftp://ftp.isi.edu/in-notes/rfc2196.txt">
ftp://ftp.isi.edu/in-notes/rfc2196.txt</A></LI>
<LI>Handbook for Computer Security Incident Response Teams - see
<A HREF="http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98hb001.pdf">
http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98hb001.pdf</A></LI>
<LI>Preparing to Detect Signs of Intrusion - see
<A HREF="http://www.cert.org/security-improvement/modules/m05.html">
http://www.cert.org/security-improvement/modules/m05.html</A></LI>
</UL>
<P>Use this review as an opportunity to check your incident response
procedures. Update the list of resources available to your incident
response team. Ensure all internal contacts/procedures are documented
for technical staff, management, and public relations staff. Ensure that
everyone - incident response team, Y2K team, security team, system
administrators, all staff related to this area - has paper-based copies
of procedures and contact details, especially as details for this period
may be different than usual. Ensure that these documents are confirmed
correct.
<P>Ensure sufficient personnel are available to handle potential problems
before, during, and after the change to the Year 2000.
<P>Test your incident response procedures by conducting a drill simulating
the need to activate your incident response team.
<P><LI><B>What else can I do to help ensure communications during the Y2K
period?</B></LI>
<P>In the event of an attack, it is possible that one or more forms of
communication are not possible. A classic example is electronic mail.
Because of this problem and the speed of response necessary in the event
of attack, it is advisable to ensure that reliable contact information
using a variety of methods (email, phone, fax) is available. This
information should be available to any staff who may require it, and be
available in both electronic and printed form.
<P>Examples of contact information that should be included are:
<P><UL>
<LI>Focal technical staff</LI>
<LI>Chain of management</LI>
<LI>Local law enforcement agency</LI>
<LI>Legal counsel</LI>
<LI>Important clients and partners</LI>
<LI>Hardware vendors</LI>
<LI>Operating system vendors</LI>
<LI>Security software vendors (e.g. anti-virus, intrusion detection, authentication)</LI>
<LI>Firewall and router vendors</LI>
<LI>ISP or NSP</LI>
<LI>Local security and/or incident response staff</LI>
<LI>Appropriate CSIRT</LI>
<LI>National Y2K coordination center</LI>
<LI>Media contacts</LI>
</UL>
<P>Ensure that associated tools (such as encryption packages and keys) are
up to date. Staff should understand their procedures and contacts so that
if an incident occurs, everyone knows whom to contact, even outside of
normal business hours.
<P>If there are critical sites that must be in communication with each
other, consider alternative communication mechanisms such as two-way radios
and satellite phones.
<P>Consider setting up in advance a teleconference bridge between sites and
emergency teams to facilitate discussions about the causes of failures
during the Y2K weekend.
<P>Make sure that public relations staff know about any problems that might
lead to media inquiries and what response should be made.
<P><LI><B>How do I prepare to detect intrusions?</B></LI>
<P>The practices contained in the following module identify advance
preparations to take in order for you to obtain evidence of an intrusion
or an intrusion attempt. They are designed to help you prepare by configuring
your data, systems, networks, workstations, tools, and user environments
to capture the necessary information for detecting signs of intrusion.
<P><A HREF="http://www.cert.org/security-improvement/modules/m05.html">
http://www.cert.org/security-improvement/modules/m05.html</A>
<P>It is important to be familiar with what you expect to be normal network
traffic for the period. It may be useful to implement a fallback
logging mechanism.
<P>You may wish to consider using an external logging mechanism to run
detailed logging of Internet connections toward your systems around the
transition to Y2K so that if an incident does take place, the activity
can be recreated at a later stage.
</OL>
<A NAME="IV"></A>
<H3>
IV. Detection</H3>
<OL>
<LI><B>How do I detect an intrusion?</B></LI>
<P>A general security goal is to prevent intrusions. But because no
prevention measures are perfect, you also need a strategy for handling
intrusions that includes preparation, detection, and response. The following
module focuses on detection. The practices recommended in the following
document are designed to help you detect intrusions by looking for the
"fingerprints" of known intrusion methods.
<P><A HREF="http://www.cert.org/security-improvement/modules/m01.html">
http://www.cert.org/security-improvement/modules/m01.html</A>
<P><LI><B>How will I be able to determine if a problem is a Y2K problem or
some type of attack?</B></LI>
<P>There is no easy methodology to help you identify the cause of a
problem. But by increasing the logging activity on your systems and network,
you can make it easier to determine whether the unusual activity was caused
by a Y2K failure or by intruder-related attacks. Follow our advice on
logging:
<P>Hosts:
<UL>
<LI>turn on process accounting</LI>
<LI>ensure that the operating system and applications are logging as much as
possible</LI>
</UL>
Network:
<UL>
<LI>turn on firewall and router logging where possible to log incoming and
outgoing connections and traffic</LI>
<LI>ensure intrusion detection systems and network sensors are logging as much
information as possible</LI>
</UL>
<P>
<HR WIDTH="100%" NOSHADE>
<A NAME="IV.triage"></A>
<P><B>Triage Guidelines/Checklist for Distinguishing a Y2K Problem versus an Attack</B>
<P>The following information outlines common questions relating to the
Y2K event and the problems that may arise as individual sites work through
problems presented by the threats outlined in the paper
<I><A HREF="http://www.cert.org/y2k-info/y2k-cyberthreats.html">Cyber
Infrastructure and Malicious Expectations during the Y2K Transition
Period</A></I> (written by participants of the International Y2K Workshop,
Threat Analysis Working Group).
<P>The purpose for these guidelines is to assist individual sites in
preparing themselves for this threat, and to provide information on
how to distinguish the reasons for different types of failure (that may
have a similar appearance), and in the case of attack, how to respond.
<P><B>Assumptions</B>
<P><UL>
<LI>No deterministic triage regime is available. In determining the likely
cause of failure, victim sites should use the balance of probabilities
based on the following questions.</LI>
<LI>The questions use the generic term "systems." These systems may be hosts,
routers, firewalls, any embedded system, network component, or discrete
hardware or software components.</LI>
</UL>
<P>
<OL TYPE="A">
<LI><B>What happened?</B> (just the facts)</LI>
<P><B>(1) What specifically is the problem; what are the symptoms?</B>
<P>Document a brief high-level description of the problem, including
details of the effects and issues.
<P>Consider the activity that has taken place before, during, and after
the failure. Take care to gather and <B>document</B> your findings,
keeping copies of any artifacts. You will use these to draw conclusions
about the reason for the failure. At this early stage, consider
system-wide facts -- more specific information is covered in later
questions.
<P>Pure Y2K related failures could be expected to occur in discrete
systems or components with a time related aspect. Remember that some
systems or components without a time or date aspect may still fail if
they are dependent upon another system that does have such an aspect.
<P>However, if there is no such aspect or dependency to the failed system
or components, then it is possible that the failure is due to either an
ill-timed "normal" failure, or alternatively due to a targeted attack.
<P><B>(2) What changes took place on the system during or as a result of the
failure (e.g., files been updated)?</B>
<P>Define specifically what system changes have taken place
(e.g. additional services enabled or disabled, application software
changes visible to user or support staff, etc.).
<P>Many attacks require changes in the victim system. This may include:
<UL>
<LI> modifications to configuration files and programs</LI>
<LI> addition of (possibly hidden) files or directories</LI>
<LI> information being inserted into spooled areas (e.g. e-mail, printers)</LI>
<LI> modification to core memory</LI>
<LI> addition, modification, disabling or unexpected activity with
respect to network services such as SNMP, SMTP, name services, file
services, application and database services</LI>
<LI> addition of user information</LI></UL>
<P>Further information is available from the CERT/CC Security Improvement
Module, "Preparing to Detect Signs of Intrusion", available from<BR>
<A HREF="http://www.cert.org/security-improvement/modules/m05.html">
http://www.cert.org/security-improvement/modules/m05.html</A>
<P>In the event of Y2K failure, there should be an explainable reason for
particular unexpected changes.
<P>Changes that occur due to an attack that looks like a Y2K failure may
include changes that do not seem to have an explainable reason. For
instance, if a system administrator notices a new network service
executing, then he or she should question whether this would really be the
result of a Y2K failure.
<P>Likewise, it is important to look for the appearance of unexpected
dynamically loadable modules. This may be very difficult to detect in the
case of total compromise of a system. In such cases, independent network
logging and automated intrusion detection may be the only sources of
reliable information.
<P>On a related thread, try to determine what (if anything) occurred at a
network level prior to or during the failure. If unusual network traffic
(either in terms of content or volume) was sent to the failed system at
this time, then this may indicate either an attack or a non-Y2K failure.
Likewise if a new network service has been unexpectedly established on the
system, an attack is more likely than a Y2K failure.
<P>Further checking should include all of the suggestions in the list above
and the CERT/CC Security Improvement Module. The results of these checks
should provide strong technical information about the reason for the
failure.
<P><B>(3) During the failure, what file system changes occurred?</B>
<P>Define what files were being updated and what those changes were (e.g.,
whether they were application data files with date dependencies, system
fail details). Were those changes correct?
<P>Examine any files that were updated during, just prior to, or just after
the failure. In general, unauthorized modification to files would not be
expected in a Y2K event unless the failure included or interrupted a
process in which a file was being updated.
<P>Many attacks result in the modification of files. Such modifications
may include changes to configuration files for network services and user
information. Be aware of changes to configurations for routers and
firewalls both in configuration sources files and configuration held in
memory on the devices themselves. These changes may provide clues about
the method of the initial compromise, and any further access that the
intruder has allowed.
<P>Many artifacts left on a system after compromise are held in hidden
files or directories. Search for these kinds of files and directories.
Examples include files with the "hidden" attribute in Windows/NT, and files
such as "..." or with embedded non-alphanumeric characters in UNIX. These
files often contain configuration or source for the attack tools.
<P><B>(4) What has happened on the system or network since the failure?</B>
<P>How closely are other failures/events related? Describe any other similar
incidents within your environment. Are there any other seemingly unrelated
failures within your environment?
<P>Activity after the failure may provide clues to what caused it.
<P>In the case of a straightforward software component failure (whether
Y2K or something else), any further unexpected activity should be
explainable as a consequence of the original failure.
<P>This will not be true in the case of an attack. Where multiple
failures across a number of system have occurred, the victim site should
take care to verify whether the later failures were the result of the
earlier failures, or whether these are independent of each.
<P>Furthermore, care should be taken to verify the cause of any other
unexpected activity, regardless of whether that activity is a failure, a
new process, an incrementally increasing volume of disk usage, a change
in network traffic or some other phenomenon.
<P>For example, many emerging attacks are using distributed systems and
information relay back to one or more systems under the control of the
attacker. To the victim, this may be manifested by the unexpected
existence of a dedicated connection or sporadic traffic back to an
external site for some period after the failure.
<P><B>(5) Was there an unexpected date/time change before/during the failure?</B>
<P>Did the date changeover occur within the expected time frame? How many
times did it occur? Were those changes correct both from the point of
view of time and date?
<P>Obviously a Y2K failure will include some kind of time or date aspect.
An important discriminator is whether a date or time change was expected
in terms. If a failure occurs immediately prior to, during, or
immediately following an expected date or time change (or during a date
or time comparison), then this would suggest that a Y2K failure is
possible.
<P>However, if an unexpected time change took place, then this would
suggest some kind of other event such as an attack. For example, if some
kind of system event in November 1999 resulted in the changing of the
system clock to be after 1/1/2000, then a Y2K failure is much less likely
and an attack is more likely.
<P><B>(6) Is the failure or event regularly occurring? For example, does a
regularly executing job continue to fail?</B>
<P>How many times did the failure occur? Does it continue to occur? Have
the failure characteristics changed?
<P>Is this a regular job that is run frequently? Give a brief description
of the job. How often is the job run and at what time or date? Did
it fail before the Y2K date change? If so, how frequently?
<P>If a regularly occurring and expected task that successfully executed
previously is now failing regularly, then this may not indicate system
failure or attack either way. However, it does allow the reason for the
failure to be reproduced, which in turn provides information about the
core problem. This will give further clues about a failure (due to Y2K,
for instance) or an attack. If the job last successfully executed in
1999 and the first failure was in 2000 or during the last scheduled
execution in 1999, then a Y2K failure may be more likely.
<P>
<LI>
<B>Environment</B> (conditions)</LI>
<P><B>Scope</B>
<P><B>(7) Does the range of systems affected indicate a targeting effect?
For example:
<UL>
<LI>How widespread is the problem? Is this a single incident or more?</LI>
<LI>What is the impact?</LI>
<LI>Are multiple administrative domains affected?</LI>
<LI>Are all similar systems affected - that is, are there similar systems which are not affected?</LI>
<LI>Do the victim systems include homogeneous systems and a wider heterogeneous network?</LI>
</B></UL>
<P>If you have similar machines across multiple administrative domains,
then similar symptoms could be expected across the machines if a pure Y2K
problem existed. On the other hand, if only systems in a single
administrative domain are affected (whether similar or dissimilar) and
similar systems in another administrative domain are not, then this may
indicate a targeting effect and hence an attack.
<P>Likewise, if heterogeneous systems in a single administrative domain
are affected in close time proximity, then multiple coordinated failure
across systems with independent code bases may indicate an
attack. Conversely, if homogeneous systems in a single administrative
domain fail with some common element, but not different systems in the
same domain, then the possibility that this is due to natural component
failure (such as Y2K) increases.
<P>Investigate whether there were dependencies (rather than similarities)
between systems that failed. If the failed systems were heavily
codependent, then the multiple failures may be due to natural
consequences of an initial attack or component failure. If failed systems
have absolutely no dependent relationship (e.g., router reconfiguration
combined with an authentication server crash) then this may be an
indication of a coordinated attack.
<P><B>(8) What functions do the affected systems perform?</B>
<P>Natural component failures, such as Y2K, should affect systems
independently of their administrative sensitivity. In other words,
similar systems should be affected similarly regardless of the
sensitivity of their administrative function.
<P>If the only systems affected (or the vast majority of affected
systems) are sensitive (such as firewalls, servers, or socially or
commercially important systems) and many or all non-sensitive systems are
not affected, then this may indicate an attack.
<P><B>(9) How accessible is the system (number of users, network connections)?</B>
<P>A totally closed system with no users and no network services is more
likely to have been affected by component failure rather than attack. As
a system becomes more accessible in terms of users and network services,
the risk of component failure increases, but so does the chance of
attack.
<P>Therefore, failure of a closed system is more likely to have been due
to natural component failure.
<P><B>Compliance</B>
<P><B>(10) What hardware and software (including versions) were involved?</B>
<P>If you are using hardware and software that are late releases or
determined by the vendor to be Y2K compliant, then the possibility of a
Y2K failure is (theoretically!) reduced. If the failure exhibits symptoms
in line with known problems, then Y2K should be suspected, although the
possibility of an attack should nevertheless not be discounted.
<P>If the hardware and software is old and/or not Y2K compliant, then the
possibility of a Y2K failure increases.
<P><B>(11) Did you update, replace, or modify your system for Y2K?</B>
<P>If a system is not updated for the Y2K turnover, then it is far more
difficult to determine the cause of failure -- as both Y2K complications
or attacks are possibilities. If Y2K remediation has taken place then
there is a much lower chance of a Y2K failure, and this should indicate a
greater possibility of attack or a non-Y2K component failure.
<P><B>Timing</B>
<P><B>(12) At what date and time did the event occur?</B>
<P>Almost any time could potentially be associated with a Y2K failure or
an attack. It is important to correlate the time of the failure with
other events that occurred at the same time, such as the ending of
processes (particularly abnormal termination), creation of network links,
user activity and so on.
<P>Do not assume that because the failure occurred at a particular moment
(e.g., 00:01 01 January 2000) that Y2K is responsible. While this is an
important data point, it does not give the explanation as to what
occurred. This data point should be used to find out why the failure
occurred. Unless this latter step is taken, it is impossible to know
whether the failure is due to Y2K or a cleverly timed attack.
<P><B>(13) When was the last time the failed component was used (e.g., it worked
after the rollover)?</B>
<P>An important data point is to determine the last time that the failed
component was used successfully.
<P>If it was last used successfully after the Y2K rollover, then this
suggests an increased likelihood of an attack. If it was last used
successfully before the rollover and the first failure event is since the
rollover, then a natural Y2K event is a stronger possibility although an
attack cannot be discounted.
<P>A determination on what has changed on the system, aside from time and
date, between the last successful execution and the first failure event
should provide high-quality intelligence on the reason for failure. Such
changes may include modifications to environment, software, or
configuration.
<P><B>Activity</B>
<P><B>(14) Do your logs show any indication of privileged user access?</B>
<P>Privileged user access <I>per se</I> will not give an indication of
component failure or attack. However, determining whether
privileged user access was taking place at the time of the failure and
examining the characteristics and related activity will provide clues.
<P>For example, unexpected privileged user access from a system external
to the victim's administrative domain may indicate an attack. Abnormally
terminating processes under the control of a privileged user may indicate
either failure or attack. The reason for the failure should provide some
indication as to whether natural failure or attack is likely.
<P><B>(15) What processes were running?</B>
<P>If system failure was the result of processes running unexpectedly,
then attack is a possibility. Even in cases where a process with an
expected name was executing, it is important to verify, if possible, that
the process was based on known software (i.e., an attack tool
masquerading as an expected process wasn't being used).
<P>The reason for the failure of any process should be investigated if
possible, along with the proximity in time compared with any wider system
failures.
<P>
<LI><B>Repeatability</B></LI>
<P><B>(16) Has this problem occurred before? When? Same impact?</B>
<P>If the problem has previously occurred before the turnover then it may
indicate that it is not a Y2K-related problem (unless it is a process
working that works with future dates that periodically runs). It does not
rule out an attack. If it caused the same impact then further questions
of correlation between the previous problem and the current would be
asked.
<P><B>(17) Can you repeat the same problem on the same machine on a separate
network?</B>
<P>If the problem can be recreated on a separate network then it may be a
software related failure and most likely a local host problem, rather
than a network based attack.
<P>
<LI><B>Trouble-shooting</B></LI>
<P><B>(18) What steps have been taken since the failure? What were the results?</B>
<P>This is to determine the current state and what has already been
determined before the report of the incident. An example would be if the
system has been recycled and the problem still exists or if the system
was taken off line and is still affected. In the case of the latter, the
problem may be software related -- most likely a local host problem and
not a network-based attack.
<P><B>(19) Is the problem repeatable? If so what is the trigger that makes it
a repeatable vs. a failure?</B>
<P>If the problem can be repeated, then it is probably not a network
attack. If it takes a time or process dependent process to repeat the
problem, this would lead you to think that it may be a software problem
based on time or date function, such as would occur with a Y2K problem.
<P><B>(20) After a system backup is employed, do you still have the same problem?</B>
<P>If the system still has problems after the backup is restored, then it
is probably not a hacker attack but a software-related problem.
<P>Take care in making this evaluation that you test using a pre-2000
date if necessary, and that the backup version used for testing is known
to be not compromised.
<P><B>(21) Have you conducted or seen an operational evaluation? Is
this a documented non-problem? Have you consulted available
documentation?</B>
<P>Most organizations have evaluated their hardware/software systems for
Y2K related vulnerabilities and are aware of potential failures and
failure indicators. System administrators should be aware of the
existence of these evaluations and must consult them first before
assuming that a particular failure or system event is Y2K related. If
there was a Y2K Operational Evaluation and it did not find a Y2K related
vulnerability that matches the circumstances in question, then it is
appropriate to assume that the event was caused by malicious conduct.
<P>Additionally, checking first for documented, known and unaddressed
problems from the system vendor beforehand may assist in inappropriately
assuming an attack.
<P><B>(22) Is there a date and time function? Was the event in question
related to a date or time function?</B>
<P>Date/time could be derived from the local clock on the computer or
from a network or server clock that is external to the system in
question. While events that appear to be related to date/time functions
are most likely Y2K related, malicious activity cannot be totally ruled
out. If the failed program is available on a back-up system, or on
back-up tape, and also failed on the backup, then it is most likely a Y2K
related event. Examination of logs might reveal abnormalities that will
help determine if it was related to malicious activity.
<P><B>(23) What is your pre-assessment of the incident? Based on gut feeling,
other evidence, etc., what does the system administrator feel?</B>
<P>The system administrator has the best understanding of the system and
should know what "normal" conditions are. As such, the administrator
should be aware of abnormalities in their system, and should be
knowledgeable about any evaluations conducted, tests, or changes made to
the system prior to the turnover date. Draw from the system
administrators' experience with the system to isolate the specifics of
the failure and determine from their knowledge of the system if this
appears to be malicious conduct or a failure of a software or hardware
component that mimics other events seen in the past.
<P><B>(24) Is there additional information available from other resources? What
other evidence do you have to support your claim?</B>
<P>Evaluations and technical information from the product vendor, online
resources, and newsgroups may provide additional information to assist in
determining the cause of the problem. The system administrator may also
be aware of other systems in his organization that are experiencing
similar problems or of other circumstances that might support a
particular theory.
<P><B>(25) Have your technical support or software vendors offered any
indication that symptoms show a non-Y2K problem?</B>
<P>Y2K-related hardware and software problems normally affect all
computers or systems made by a particular vendor that have not been
patched for the problem unless that system is uniquely configured for the
organization. Most vendors have published known Y2K problems and these
references must be consulted prior to drawing conclusions about the
nature of the problem. Malicious activity, on the other hand, will
likely target a specific computer or system and will result in other
similar systems being unaffected by the event.
</OL>
<P>
<HR WIDTH="100%" NOSHADE>
</OL>
<A NAME="V"></A>
<H3>
V. Response</H3>
<OL TYPE="1">
<LI><B>How do I respond to an intrusion?</B></LI>
<P>You need a strategy for handling intrusions effectively that includes
preparation, detection, and response. The practices in the following document
identify steps you must take to respond to and recover from a detected
intrusion.
<P><A HREF="http://www.cert.org/security-improvement/modules/m06.html">
http://www.cert.org/security-improvement/modules/m06.html</A>
<P><LI><B>What should I do if I detect some kind of anomalous activity (or
an incident has occurred)?</B></LI>
<P>In determining your response, take time to determine the type of
behavior observed, and its severity. In general, the activity is likely
to fall into one of five categories:
<P><UL>
<LI>Anomalous behavior due to Y2K failure</LI>
<LI>An attack that looks like Y2K failure</LI>
<LI>An attack exhibiting no signs of a Y2K relationship</LI>
<LI>Anomalous behavior due to an event not locally related to Y2K</LI>
<LI>A false positive</LI>
</UL>
<P>The most important determination to make is whether the behavior has
a security implication or not. In the case of a failure that does appear
to have a Y2K relationship, it may be very difficult to determine whether
this is due to the Y2K bug (the first category above) or an attack
designed to look like the Y2K bug (the second category above). The
Triage guidelines earlier in this document should assist in this
determination. Another document that may also be useful is "Detecting
Signs of Intrusion," available from<BR>
<A HREF="http://www.cert.org/security-improvement/modules/m01.html">
http://www.cert.org/security-improvement/modules/m01.html</A>
<P><LI><B>What do I do if the anomalous behavior DOES NOT have a security
implication?</B></LI>
<P>Where the anomalous behavior is assessed as having no security
implication, it should be possible to fairly easily address the situation
using procedures in place.
<P>False positive events can simply be ignored, once they are verified as
false. In doing this do not dismiss each occurrence out of hand - each
event should be deliberately assessed if possible.
<P>In cases of anomalous behavior due to an event not locally related to
Y2K, the Business Continuity Plan should be used. These kinds of events
(e.g. a power outage) could occur at any time, regardless of Y2K. This
means that the cause of original problem, whether Y2K or something else
(e.g. flood) is irrelevant, since it is beyond the sphere of
organizational control. It is up to the organization to respond as it
would for any other external event that indirectly affects the health of
the organization.
<P>In the case of anomalous behavior that is due to Y2K and for which
there is no security implication, the response should be in accordance
with any earlier Y2K planning. This may include the implementation of
the paper-based procedures in place for Y2K incidents - including all
relevant contacts with management, public relations and the use of
communications mechanisms. Workarounds for technical problems should be
introduced where possible, and the vendor of the failed system should be
contacted for remediation.
<P><LI><B>What do I do if the anomalous behavior DOES have a security
implication?</B></LI>
<P>If a security implication is <B>determined or suspected</B>, then a
different response is required. Any response to a security breach should
be measured.
<P>Good descriptions of the phases and practices involved in responding
to security incidents can be found in the following documents:
<UL><LI>RFC2196 - see <A HREF="ftp://ftp.isi.edu/in-notes/rfc2196.txt">ftp://ftp.isi.edu/in-notes/rfc2196.txt</A></LI>
<LI>Responding to Intrusions - see <A HREF="http://www.cert.org/security-improvement/modules/m06.html">http://www.cert.org/security-improvement/modules/m06.html</A></LI>
</UL>
<P>Decide whether there is a need to preserve evidence for later
civil or criminal litigation. If so, preserve a forensic-quality record
of the system in accordance with your local legal system.
<P>Discuss this with your incident response team to ensure analysis of
your system as appropriate (e.g., for backdoors or other unfamiliar code,
use the provably strong baseline you took before the Y2K event).
<P>Analyze your intrusion detection and other logging mechanisms for
clues to the incident. If appropriate, recreate the incident from network
traffic records.
<P>When all incident analysis is complete (or a forensic-quality copy has
been taken for analysis), restore from the backup you took of your system
before Y2K (or if needed the emergency copy several weeks before).
<P><LI><B>What if Y2K has passed without incident (or all incidents have been
handled)?</B></LI>
<P>Reinstate any systems/services that have been disabled for the Y2K
period. Apply any relevant patches that were not applied in the Y2K
period.
<P><LI><B>Will CERT/CC staff be available during the transition to the Year 2000?</B></LI>
<P>The CERT Coordination Center hotline will have staff available to
help with <U>emergency computer security</U> incidents. The following
incident reporting form can be sent to CERT/CC via email or fax:
<BR><A HREF="http://www.cert.org/ftp/incident_reporting_form">
http://www.cert.org/ftp/incident_reporting_form</A>
<P>
<DD>
<B>Email:</B> cert@cert.org</DD>
<DD>
<B>Fax:</B> +1 412 268 6989</DD>
<P>If you are unable to use email or fax, you can call the hotline at
<DD>
<B>Phone: </B>+1 412 268 7090</DD>
<P>
<HR WIDTH="100%" NOSHADE>
<A NAME="V.ir_checklist"></A>
<P><B>Incident Response Checklist</B>
<P><UL>
<LI>Take a baseline of your systems in order to identify back doors or
other familiar code.</LI>
<LI>Prepare for an increased volume of scans, probes, hacker attacks, and
viruses.</LI>
<LI>In the event a pattern of Y2K or security events occurs, contact your
internal security team and consider notifying the CERT® Coordination
Center (CERT/CC) for updated information and coordination.</LI>
<LI>In order to protect critical system infrastructure from serious
attacks, use moderated response procedures based on the occurrence and
severity of compromised computer resources.</LI>
<LI>Should a significant attack be identified at your site, remove the
risks of standard UDP and TCP attacks by reducing access from the Internet
other than via HTTP (and related protocols, HTTPS, IDENT), and email
(SMTP).</LI>
<LI>Understand how information you receive is validated.</LI>
<LI>Ensure that information is validated before taking action. Do not share
questionable data with others without clearly indicating that it has not
been validated. Should questions of validity arise, contact an appropriate
security incident response team for clarification.</LI>
<LI>Notify your security officer or appropriate law enforcement officers
immediately when you suspect illegal or criminal activity.</LI>
<LI>Don't assume you should turn the machine off when you identify or suspect
a compromise.</LI>
<LI>Consider isolating a compromised machine by disconnecting it from the
network.</LI>
<LI>Assess whether to implement your contingency plan.</LI>
<LI>Assure that all patches for known system/network security vulnerabilities
are installed.</LI>
<LI>Be prepared to quickly install new patches as soon as possible after
issuance during Y2K time period.</LI>
<LI>Update anti-virus software code, including desktops is updated as near
30 December as practical; be prepared to download from vendors and update
OPDIV anti-virus software (perhaps frequently) during Y2K time period.</LI>
<LI>Implement and use Y2K-aware intrusion detection and auditing systems.</LI>
<LI>Increase firewall/intrusion detection monitoring from 29 December through
04 January.</LI>
<LI>Check to see whether other systems have been compromised.</LI>
<LI>Check to see whether network cards are in promiscuous mode (reference web
documents on what to do when responding to an incident).</LI>
<LI>Continually monitor networks for intruders using Y2K fix as a
diversion.</LI>
<LI>Back up data.</LI>
</UL>
<BR>
<P><HR WIDTH="100%" NOSHADE>
</OL>
<A NAME="VI"></A>
<H3>
VI. What Not To Do</H3>
<UL>
<P><B>Don't necessarily deviate from your normal security practices.</B>
<P>This is a good time to review existing practices and familiarize
yourself and your users with these practices. In some sense, Y2K is just
like any other computer security event except that it has an absolute
worldwide deadline with unprecedented reach. Last-minute changes to
procedures may introduce uncertainty and error. "Maintaining the
status quo" helps to ensure that existing practices will continue to
produce expected results within predictable timeframes. Although the
pressure may be enormous to upgrade software and hardware or introduce
new steps into existing procedures, changes should only be allowed under
strict requirements with appropriate notification to anyone affected by
the modifications.
<P><B>Don't act on, send out, or publish unsubstantiated information.</B>
<P>Hoax email messages will continue through the Y2K event period, so
follow existing guidance. See
<A HREF="http://www.cert.org/y2k-info/y2k-virus.html">
http://www.cert.org/y2k-info/y2k-virus.html</A>
for more information. Know how to contact your computer security office,
your computer security incident response team (CSIRT), or your Y2K team
and ask them to validate and verify the information. If they determine
the information is accurate and worthy of distribution, they should be
the only forwarding agent. Any email message, netnews posting, or web
page that directs you to install software, provide the sender with
information, or forward the message on to others should be validated and
verified by a trusted agent before taking any action. Check with your
computer security office, your CSIRT, or your Y2K team for more
information.
<P><B>Don't be fooled by social engineering whether by email, telephone,
or in person.</B>
<P>Social engineering is the method used by an untrusted person to
persuade you to do something that may compromise your security. Classic
examples include an unknown caller claiming to be a customer support
engineer that asks for a password in order to fix a problem. For another
example, the message that was attached to the Melissa virus was designed
to convince the reader that he or she had requested the enclosed
attachment from a friend. Users that blindly trusted the message and were
not protected from macro viruses were infected, and propagated the
malicious message to other users. Social engineering also may occur in
person. Confirm any request for information, access, or changes with the
appropriate authority at your site. Ask for identification or additional
information you can use to confirm the request. Report any fraudulent
attempts at social engineering to your computer security office or
CSIRT. If the attempt is related to the Y2K event, also report it to your
Y2K team.
<P><B>Don't assume you should turn off your computer or network equipment
especially for this single event.</B>
<P>Follow your normal operating procedures during this time unless
changes have been specified by your network or security
organization. Some systems have to be on and operating in order to be
repaired by remote administrators. Turning off your computer as a
precaution (without the prior recommendation of your systems
administrator) may thwart an emergency effort to fix a problem. Likewise,
don't leave the system on if it is not your normal practice (unless
directed otherwise by your system maintainers).
<P>For some sites, disconnecting or turning systems off may be a
legitimate approach. However, in the case of any Y2K failures or
potential attacks, this tactic will only delay the threat rather than
overcome it. The benefit to the site is that systems can at least be
monitored more closely when they are brought back on-line. For example,
if a system is vulnerable to some problem during the rollover and it is
switched off on 31-Dec-1999, then it is still likely to be in need of
remediation to avoid the failure when it is switched on regardless of
whether it is restored on 1-Jan-2000, 4-Jan-2000 or any other date in
2000.
<P>Likewise, bear in mind that there may be upstream consequences of
taking a system off-line. For example, if the system that is taken down
is a mail spool, then any system upstream that would normally deliver
mail during that period will have to store that mail. This may
potentially cause a cascading denial of service on upstream mail delivery
systems.
<P><B>Don't make unnecessary changes to your hardware or software.</B>
<P>Only make changes that are required for processing to continue in the
face of the Y2K event; such changes should include installing Y2K or
security patches or workarounds. Enhancements may place your system in an
unknown state and result in unexpected consequences. If possible, make
these changes after 29 February 2000 to avoid any unforeseen leap year
miscalculations.
<P><B>Don't make noticeable changes without warning your users.</B>
<P>Unexpected changes to what users see in web pages or applications may
cause false reports of Y2K problems, thus occupying team resources and
limiting response to legitimate Y2K incidents.
<P><B>Don't install hardware or software from untrusted sources.</B>
<P>Download software patches and other security tools only from trusted
Internet sites such as those maintained by various vendors and CSIRTs.
Many sites provide cryptographically proven hashes or digital signatures
that provide some form of authenticity for patches, documents, and
software images.
<P><B>Don't release unnecessary or excessive information to unauthorized
persons or groups.</B>
<P>Organizations should have a policy on who can provide what information
to whom, and it should include rules for the dissemination of plans,
policies, configurations, incidents (past or present), contingency
planning, the identities and contact information for employees, and so
forth. Such requests should be deferred to the appropriate office.
<P><B>Don't respond to an intrusion by attacking.</B>
<P>Such activity merely creates bigger problems and takes the focus off
of remediation and returning to normal operation.
<P><B>Don't make decisions in a vacuum.</B>
<P>Consider the consequences of an action and, if in doubt, get a second
(or third) opinion. Incomplete or incorrect information almost certainly
results in bad decisions.
<P><B>Don't be overconfident.</B>
<P>Don't assume you and your organization have anticipated all possible
outcomes to the Y2K event. Make contingency plans and be certain that key
personnel are aware of alternative plans and the conditions under which
they will be implemented. Expect excitement and use it to your advantage.
A measured response to this event is the best response.
<P>It is suggested that systems normally accessible by the public and/or
providing services to the public remain available (e.g., email). Sites
should consider developing "Security Contingency Plans". These are plans
that outline two or three more restrictive/reduced levels of Internet
service when unusual or massive cyber attacks are identified.
<P>
</UL>
<P><A NAME="VII"></A>
<H3>
VII. Other Resources</H3>
<OL TYPE="1">
<LI>
<B>What are some other resources that offer Y2K information?</B></LI>
<P>President's Council on Year 2000 Conversion
<BR><A HREF="http://www.y2k.gov/">http://www.y2k.gov/</A>
<P>Y2K Information Coordination Center (ICC)
<BR><A HREF="http://www.y2k.gov/new/icc.html">http://www.y2k.gov/new/icc.html</A>
<P>The following site has many Y2K-related links, news articles, and
pointers to vendors:
<BR><A HREF="http://www.year2000.com/">http://www.year2000.com/</A>
<P>The following site is a source of Y2K information relating to ISPs and
the Internet:
<BR><A HREF="http://www.nety2k.org/">http://www.nety2k.org/</A>
<P>MITRE/ESC Year 2000 Website and FAQ
<BR><A HREF="http://www.mitre.org/centers/cafc3/y2k/index.html">http://www.mitre.org/centers/cafc3/y2k/index.html</A>
<BR><A HREF="http://www.mitre.org/centers/cafc3/y2k/faq/">http://www.mitre.org/centers/cafc3/y2k/faq/</A>
<P>The GSA Y2K Telecommunications Web Site
<BR><A HREF="http://y2k.fts.gsa.gov/">http://y2k.fts.gsa.gov/</A>
<P>Compuware <U>InTelligence</U> (Vol. 3 No. 1, 1999) Y2K Readiness Checklist
<BR><A HREF="http://www.itmagonline.com/issue6/resources.htm">http://www.itmagonline.com/issue6/resources.htm</A>
<P>The following site hosts a Y2K compliancy database:
<BR><A HREF="http://www.y2kbase.com/">http://www.y2kbase.com/</A>
<P>Microsoft's Y2K FAQ
<BR><A HREF="http://www.computingcentral.msn.com/guide/year2000/msy2k/learningmore/faq.asp">http://www.computingcentral.msn.com/guide/year2000/msy2k/learningmore/faq.asp</A>
<P>Sun Microsystems' Y2K FAQ
<BR><A HREF="http://www.sun.com/y2000/faq.html">http://www.sun.com/y2000/faq.html</A>
<P>International Year 2000 Cooperation Center (IY2KCC)
<BR><A HREF="http://www.iy2kcc.org/">http://www.iy2kcc.org/</A>
<P>Australian Government - Year 2000 National Coordination Centre (Y2K NCC)
<BR><A HREF="http://www.y2kaustralia.gov.au/">http://www.y2kaustralia.gov.au/</A>
<P>
</OL>
<HR WIDTH="100%" NOSHADE>
<A NAME="rev">
<FONT SIZE="-1">
<B>Revision History</B></A>
<BR>Initial Release: October 15, 1999
<BR>Updated: October 18, 1999 (minor corrections)
<BR>Updated: October 21, 1999 (minor corrections; added GSA and Compuware
links)
<BR>Updated: November 24, 1999 (added info from the International Y2K
Workshop, Y2K Failure vs. Attack FAQ Working Group)
<BR>Updated: December 16, 1999 (reorganized document subsections and added
extensive additional information [on Preparation, Triage, and Response]
from <A HREF="http://www.auscert.org.au/">AusCERT</A>; also added link to
Y2K virus resources)
</FONT>
<HR WIDTH="100%" NOSHADE>
<DT>This document is available from
<DD><A HREF="http://www.cert.org/y2k-info/Y2K_FAQ.html">
http://www.cert.org/y2k-info/Y2K_FAQ.html</A></DD> and
<DD><A HREF="http://www.auscert.org.au/Information/Y2K/Y2K_FAQ.html">http://www.auscert.org.au/Information/Y2K/Y2K_FAQ.html</A></DD>
</DT>
<HR WIDTH="100%" NOSHADE>
<H2>
CERT/CC Contact Information</H2>
<DL><B>Email:</B> <A HREF="mailto:cert@cert.org">cert@cert.org</A>
<BR><B>Phone:</B> +1 412-268-7090 (24-hour hotline)
<BR><B>Fax:</B> +1 412-268-6989
<BR><B>Postal address:</B>
<DD>
CERT<SUP>®</SUP> Coordination Center<BR>
Software Engineering Institute<BR>
Carnegie Mellon University<BR>
Pittsburgh PA 15213-3890<BR>
U.S.A.</DD>
</DL>
CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) Monday
through Friday; they are on call for emergencies during other hours, on
U.S. holidays, and on weekends.
<H4>
Using encryption</H4>
We strongly urge you to encrypt sensitive information sent by email. Our
public PGP key is available from
<UL><A HREF="http://www.cert.org/CERT_PGP.key">http://www.cert.org/CERT_PGP.key</A></UL>
If you prefer to use DES, please call the CERT hotline for more information.
<BR>
<H4>
Getting security information</H4>
CERT publications and other security information are available from our
web site
<UL><A HREF="http://www.cert.org/">http://www.cert.org/</A></UL>
To be added to our mailing list for advisories and bulletins, send email
to
<A HREF="mailto:cert-advisory-request@cert.org">cert-advisory-request@cert.org</A>
and include <TT>SUBSCRIBE your-email-address</TT> in the subject of your
message.
<BR>Conditions for use, disclaimers, and sponsorship information can be
found in
<UL><A HREF="http://www.cert.org/legal_stuff.html">http://www.cert.org/legal_stuff.html</A></UL>
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent
and Trademark Office.
<HR WIDTH="100%" NOSHADE><B><U>NO WARRANTY</U></B>
<BR><B>Any material furnished by Carnegie Mellon University and the Software
Engineering Institute is furnished on an "as is" basis. Carnegie Mellon
University makes no warranties of any kind, either expressed or implied
as to any matter including, but not limited to, warranty of fitness for
a particular purpose or merchantability, exclusivity or results obtained
from use of the material. Carnegie Mellon University does not make any
warranty of any kind with respect to freedom from patent, trademark, or
copyright infringement.</B>
<!-- This completes the table started in *_titlebar.html --></TD>
</TR>
</TABLE>
</BODY>
</HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed