This document is the product of the Y2K Failure vs. Attack FAQ
Working Group at the International Y2K Workshop, held at the Renaissance
London Gatwick Hotel in Gatwick, England, 26-28 October 1999.
The International Y2K Workshop was sponsored by the
Y2k Information Coordination Center (ICC), and was led by the
CERT® Coordination Center (CERT/CC).
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.
Updated: November 24, 1999 (added info from the International Y2K
Workshop, Y2K Failure vs. Attack FAQ Working Group)
Updated: October 21, 1999 (minor corrections; added GSA and Compuware
links)
Updated: October 18, 1999 (minor corrections)
Initial Release: October 15, 1999
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.
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.
This means that differentiating between Y2K problems and possible attacks may be a problem both before and after January 1, 2000.
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.
The tools available at the CERT/CC ftp and web site http://www.cert.org/ftp/tools/
were not developed by the CERT/CC. If you have questions, contact the site
that maintains the tool to obtain Y2K compliance information.
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.
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.
http://www.cert.org/advisories/CA-99-02-Trojan-Horses.html
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.
http://www.cert.org/other_sources/viruses.html
Many anti-virus vendors have further information about viruses and Y2K. Some of the current viruses and Trojan horse programs using Y2K:
You should make a decision that is based on how confident you are
in the security of your systems, and how critical it is for your systems
to be connected to the Internet. Your decision should also follow your
policies and procedures. Keep in mind that if you do disconnect your systems
from the Internet you will probably need to reconnect them eventually.
You may wish to consider a selective disconnect (either in terms of servers
or services) to reduce the potential areas at risk. For example, temporarily
reduce the availability from WWW, ftp, email, and DNS to just email and
DNS. Bear in mind that 01 January 2000 is a Saturday; this may mean less
disruption than a normal weekday.
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.
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.
Securing Desktop Workstations
http://www.cert.org/security-improvement/modules/m04.html
Securing Network Servers
http://www.cert.org/security-improvement/modules/m07.html
Also consider other advice in this area from FIRST teams (see http://www.first.org).
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.
The following site has instructions on testing your BIOS for Y2K
compatibility. http://www.tyler.net/tyr7020/y2kinput.htm
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.
Contact the vendor for your motherboard or computer. In many cases
you can update the system BIOS using software downloaded from the vendor.
Consider taking a cryptographically strong baseline of critical
systems that can later be checked for backdoors or other unfamiliar code.
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.
For further information about the possible threats that intruders may pose, see the paper "Cyber Infrastructure and Malicious Expectations during the Y2K Transition Period", written by participants of the International Y2K Workshop, Threat Analysis Working Group; this paper is available from
http://www.cert.org/y2k-info/y2k-cyberthreats.html
Use this review as an opportunity to check your incident response procedures. Ensure that the procedures are still correct. 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.
Update the list of resources available to your incident response team:
Staff should understand their procedures and contacts so that if an incident occurs, everyone knows whom to contact, even during abnormal hours. Ensure sufficient personnel are available to handle potential problems before, during, and after the change to the Year 2000.
If you have critical sites that must be in communication with each other, consider alternative communication mechanisms such as two-way radios and satellite phones.
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.
Prepare for the possible failure of critical services such as electricity, water, or telecommunications. Determine how these types of failures might affect your ability to respond to incidents, and consider backup plans (such as relocating to another site).
Test your incident response procedures by conducting a drill simulating the need to activate your incident response team.
Make sure that your public relations staff knows about any problems
that might lead to media inquiries and how you want to respond to them.
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.
http://www.cert.org/security-improvement/modules/m05.html
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.
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.
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.
http://www.cert.org/security-improvement/modules/m01.html
There is no easy methodology to help you identify the cause of a
problem. 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: Hosts:
Guidelines for Distinguishing a Y2K Problem versus an Attack
What specifically is the problem; what are the symptoms?
Give a brief high-level description of the problem including details
of the effects and issues.
What changes took place on the system during or as a result of the
failure (e.g. files been updated)?
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.).
During the failure what file system changes occurred?
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?
What has happened on the system or network since the failure?
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?
Was there an unexpected date/time change before/during the failure?
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?
Is it a regularly occurring characteristic?
How many times did the failure occur? Does it continue to occur? Have
the failure characteristics changed?
Does the regularly running job continue to fail?
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?
A. Scope
How widespread is the problem? Is this a single incident or more?
What is the impact? Are multiple administrative domains affected? Are all
similar systems affected – that is, are there similar systems which are
not affected? Do the victim systems include homogeneous systems and a wider
heterogeneous network?
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.
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.
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.
What functions do the affected systems perform?
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.
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.
How accessible is the system (number of users, network connections)?
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.
Therefore failure of a closed system is more likely to have been due
to natural component failure.
B. Compliance
What hardware and software (including versions) were involved?
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.
If the hardware and software is old and/or not Y2K compliant, then the
possibility of a Y2K failure increases.
Did you update, replace, or modify your system for Y2K?
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.
C. Timing
At what date and time did the event occur?
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 or processes
(particularly abnormal termination), creation of network links, user activity
and so on.
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.
When was the last time the failed component was used (e.g., it worked
after the rollover)?
An important data point is to determine the last time that the failed
component was used successfully.
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.
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.
D. Activity
Do your logs show any indication of privileged user access?
Privileged user access per se 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.
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.
What processes were running?
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).
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.
E. Repeatability
Has this problem occurred before? When? Same impact?
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.
Can you repeat the same problem on the same machine on a separate
network?
If the problem can be recreated on a separate network then it may be
a software related and most likely a local host problem and not be a network
based attack.
F. Trouble-shooting
What steps have been taken since the failure? What were the results?
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 offline
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.
Is the problem repeatable? If so what is the trigger that makes it
a repeatable vs. a failure?
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
After a system backup is employed, do you still have the same problem?
If the system still has problems after the backup is restored, then
it is probably not a hacker attack but a software-related problem.
G. Miscellaneous indicators
Have you conducted or seen an operational evaluation? Is this a documented
non-problem? Have you consulted available documentation?
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 OPEVAL 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.
Is there a date and time function? Was the event in question
related to a date or time function?
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.
What is your pre-assessment of the incident? Based on gut feeling,
other evidence, etc., what does the system administrator feel?
The system administrator has the best understanding of the system and
should know what "normal" conditions are. As such, he should be aware of
abnormalities in his 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 his or her 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.
Is there additional information available from other resources? What
other evidence do you have to support your claim?
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.
Have your technical support or software vendors offered any indication
that symptoms show a non-Y2K problem?
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.
Network:
Assumptions
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.
http://www.cert.org/security-improvement/modules/m06.html
The CERT Coordination Center hotline will have staff available to help with emergency computer security incidents. The following incident reporting form can be sent to CERT/CC via email or fax.
http://www.cert.org/ftp/incident_reporting_form
If you are unable to use email or fax, you can call the hotline at:
Implement the paper-based procedures in place for Y2K incidents
– including all relevant contacts with management, public relations and
use the communications mechanisms that you have prepared.
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.
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).
Analyze your intrusion detection, logging mechanisms, etc. – including any fallback logging, for clues to the incident. If appropriate, recreate the incident from network traffic records.
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).
Reinstate any systems/services that have been disabled for the Y2K
period. Apply any relevant patches that were not applied in the Y2K
period.
Incident Response Checklist
Things Not To Do
Don't necessarily deviate from your normal security practices.
This is a good time to review existing practices and familiarize your self 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.
Don't act on, send out, or publish unsubstantiated information.
Hoax email messages will continue through the Y2K event period, so follow existing guidance. See http://ciac.llnl.gov/hoaxes.htm/ 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.
Don't be fooled by social engineering whether by email, telephone, or in person.
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.
Don't assume you should turn off your computer or network equipment especially for this single event.
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).
Don't make unnecessary changes to your hardware or software.
Only make changes that are required for processing to continue in the face of the Y2K event; such changes can 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.
Don't make noticeable changes without warning your users.
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.
Don't install hardware or software from untrusted sources.
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.
Don't release unnecessary or excessive information to unauthorized persons or groups.
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.
Don't respond to an intrusion by attacking.
Such activity merely creates bigger problems and takes the focus off of remediation and returning to normal operation.
Don't make decisions in a vacuum.
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.
Don't be overconfident.
Don't assume you and your organization has 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.
NOTE:
The authors recommend that systems accessible by the public and/or
providing services to the public remain available (e.g., email). The authors
recommend that you consider developing multi-phase down type "Security
Contingency Plans" (e.g. plans that outline two or three more restrictive/reduced
levels of Internet service when unusual or massive cyber attacks are identified).
President's Council on Year 2000 Conversion
http://www.y2k.gov/
Y2K Information Coordination Center (ICC)
http://www.y2k.gov/new/icc.html
The following site has many Y2K-related links, news articles, and
pointers to vendors.
http://www.year2000.com/
The following site is a source of Y2K information relating to ISPs and
the Internet.
http://www.nety2k.org/
MITRE/ESC Year 2000 Website and FAQ.
http://www.mitre.org/centers/cafc3/y2k/index.html
http://www.mitre.org/centers/cafc3/y2k/faq/
The GSA Y2K Telecommunications Web Site
http://y2k.fts.gsa.gov/
Compuware InTelligence (Vol. 3 No. 1, 1999) Y2K Readiness Checklist
http://www.compuware.com/intelligence/resources.htm
The following site hosts a Y2K compliancy database.
http://www.y2kbase.com/
Microsoft's Y2K FAQ
http://www.computingcentral.msn.com/guide/year2000/msy2k/learningmore/faq.asp
Sun Microsystems' Y2K FAQ
http://www.sun.com/y2000/faq.html