 |
 |
|
|
|
 |
 |
Home | What's New | FAQ | Site Contents | Contact Us | Search |
|
|
About Us | Alerts | Education and Training | Events | FTP Archives | Improving Security | Other Resources | Reports | Survivability Research |
|
|
|
|
||||
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.
Last updated: December 16, 1999 (reorganized document subsections and
added extensive additional information [on Preparation, Triage, and
Response] from AusCERT;
also added link to Y2K virus resources)
- Technical - Organizational - Triage Guidelines for Distinguishing a Y2K Problem versus an Attack - Incident Response Checklist I. General Information
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. 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. For some businesses, the fiscal year 2000 (FY00) has already started or will start prior to January 1, 2000. 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. 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. 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. 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. 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). 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:
http://www.cert.org/y2k/indmessage.html
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 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. II. Malicious Code
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 More information specific to Year 2000 Computer Viruses and Hoaxes can be found at the following location: http://www.cert.org/y2k-info/y2k-virus.html 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. III. Preparation
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. 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. Technical 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). Examples of a layered approach to evaluation are: 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. 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. The following site has instructions on testing your BIOS for Y2K compatibility: http://www.tyler.net/tyr7020/y2kinput.htm 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. 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. The reliability of these backups should be confirmed by performing a restore operation from them. The location, availability and reliability of annual and semi-annual system archives should also be confirmed. 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. 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. 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
Securing Network Servers
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. 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: Bear in mind that 01 January 2000 is a Saturday; this may mean less disruption than a normal weekday. 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. 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. 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. Any decision to reduce service to combat one set of risks should take into consideration other risks that may be introduced as a result. 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. 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. 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. 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. 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. 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. 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. 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. Organizational 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. 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. 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. 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. 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. 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 http://www.mitre.org/technology/y2k/docs/CONTINGENCY_PLAN.html 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). 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: 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. Ensure sufficient personnel are available to handle potential problems before, during, and after the change to the Year 2000. Test your incident response procedures by conducting a drill simulating the need to activate your incident response team. 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. Examples of contact information that should be included are: 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. 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. 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. Make sure that public relations staff know about any problems that might lead to media inquiries and what response should be made. 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. IV. Detection
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. 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: Hosts:
Triage Guidelines/Checklist for Distinguishing a Y2K Problem versus an Attack 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 Cyber Infrastructure and Malicious Expectations during the Y2K Transition Period (written by participants of the International Y2K Workshop, Threat Analysis Working Group). 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. Assumptions
(1) What specifically is the problem; what are the symptoms? Document a brief high-level description of the problem, including details of the effects and issues. Consider the activity that has taken place before, during, and after the failure. Take care to gather and document 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. 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. 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. (2) 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.). Many attacks require changes in the victim system. This may include: Further information is available from the CERT/CC Security Improvement
Module, "Preparing to Detect Signs of Intrusion", available from In the event of Y2K failure, there should be an explainable reason for particular unexpected changes. 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. 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. 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. 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. (3) 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? 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. 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. 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. (4) 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? Activity after the failure may provide clues to what caused it. 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. 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. 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. 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. (5) 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? 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. 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. (6) Is the failure or event regularly occurring? For example, does a regularly executing job continue to fail? How many times did the failure occur? Does it continue to occur? Have the failure characteristics changed? 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? 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.
Scope (7) Does the range of systems affected indicate a targeting effect?
For example:
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. (8) 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. (9) 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. Compliance (10) 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. (11) 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. Timing (12) 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 of 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. (13) 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. Activity (14) 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. (15) 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.
(16) 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. (17) 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 failure and most likely a local host problem, rather than a network based attack.
(18) 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 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. (19) 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, such as would occur with a Y2K problem. (20) 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. 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. (21) 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 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. Additionally, checking first for documented, known and unaddressed problems from the system vendor beforehand may assist in inappropriately assuming an attack. (22) 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. (23) 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, 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. (24) 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. (25) 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.
V. Response
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 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: 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 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. 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. 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. 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. If a security implication is determined or suspected, then a different response is required. Any response to a security breach should be measured. Good descriptions of the phases and practices involved in responding to security incidents can be found in the following documents: 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 and other logging mechanisms 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. 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:
If you are unable to use email or fax, you can call the hotline at
Incident Response Checklist VI. What Not To DoDon't necessarily deviate from your normal security practices. 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. 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://www.cert.org/y2k-info/y2k-virus.html 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). 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. 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. 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 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. 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 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. 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.
VII. Other Resources
President's Council on Year 2000 Conversion
Y2K Information Coordination Center (ICC)
The following site has many Y2K-related links, news articles, and
pointers to vendors:
The following site is a source of Y2K information relating to ISPs and
the Internet:
MITRE/ESC Year 2000 Website and FAQ
The GSA Y2K Telecommunications Web Site
Compuware InTelligence (Vol. 3 No. 1, 1999) Y2K Readiness Checklist
The following site hosts a Y2K compliancy database:
Microsoft's Y2K FAQ
Sun Microsystems' Y2K FAQ
International Year 2000 Cooperation Center (IY2KCC)
Australian Government - Year 2000 National Coordination Centre (Y2K NCC)
Revision History Initial Release: October 15, 1999 Updated: October 18, 1999 (minor corrections) Updated: October 21, 1999 (minor corrections; added GSA and Compuware links) Updated: November 24, 1999 (added info from the International Y2K Workshop, Y2K Failure vs. Attack FAQ Working Group) Updated: December 16, 1999 (reorganized document subsections and added extensive additional information [on Preparation, Triage, and Response] from AusCERT; also added link to Y2K virus resources) CERT/CC Contact Information
Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: Using encryptionWe strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from If you prefer to use DES, please call the CERT hotline for more information.Getting security informationCERT publications and other security information are available from our web site To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org and include SUBSCRIBE your-email-address in the subject of your message.Conditions for use, disclaimers, and sponsorship information can be found in * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. NO WARRANTY 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. |