فا

‫ Computer Security Incident Handling in Six Phases- Identification

IRCAR201105097
Identification involves determining whether or not an incident has occurred, and, if one has occurred, determining the nature of the incident. Identification normally begins after someone has noticed an anomaly in a system or network. This phase also includes informing and soliciting help from the people who can help you understand and solve the problem. It is important to recognize at this point that not every network or system anomaly will be a security incident. Too often, people leap to the conclusion that there's a hostile intent behind every problem.
 
STEP 1: ASSIGN A PERSON TO BE RESPONSIBLE FOR THE INCIDENT
Without a central point of control, too many people may be working at cross-purposes. Undirected activities could cause the misdiagnosis of the nature of the incident, loss of forensic evidence, and possibly creation of a worse situation than the incident by itself would have caused.
 
Action 1.1: Select a person to handle or coordinate identification and assessment
If at all possible, the method for selecting a person as an incident handler should be predefined. This person should have broad general knowledge of the enterprise, and have some experience in handling incidents and problem determination. If the Command Decision Team and On Site Team are in different locations, it is imperative the two teams remain in communication using secure means throughout the incident. Because incidents often take place during off-hours, weekends or holidays, a pool of several potential handlers should be identified and be familiar with the security policies and procedures. And they should know where to find the contact and escalation lists developed during the preparation phase, both internal and external.
 
Action 1.2: Begin a log of the incident
From the very beginning of a suspected incident, the person handling the incident should start taking notes on each step, identifying who did what, when and how and why they did it. The notes should be chronological, with the time of each entry indicated. Keep the log as factual as possible; care should be taken to avoid speculation. Avoid statements like "The hacker has clearly erased the system logs"; instead use a statement like "The system logs do not show any entries for a period of six hours." Log entries must be statements of fact; careless speculation can confuse the evaluation of the incident, and when repeated in court, could damage a legal case.
 
STEP 2: DETERMINE WHETHER OR NOT AN EVENT IS ACTUALLY AN INCIDENT
Evidence indicating a potential security incident often turns out to indicate something else too. If a situation is misdiagnosed, it is often easy to make the data "fit" the misdiagnosis.
 
Action 2.1: Check for simple mistakes
Examples of simple mistakes include errors in system configuration or an application program, hardware failures, and, most commonly, user or system administrator errors. A seasoned incident handling professional, who has seen many cases, can often make the determination with just a few questions of the local system administration staff. Taking the time to evaluate the configurations for simple mistakes has a dual purpose: it is also possible to expose other related problems or vulnerabilities through this initial examination process. Once the simple mistakes have been quantified or ruled out, it is much easier to determine the total scope of the incident.
 
Action 2.2: Assess the evidence in detail
Use the list of indicators you developed during the preparation phase to quickly assess the possible type of incident.
 
STEP 3: BE CAREFUL TO MAINTAIN A PROVABLE CHAIN OF CUSTODY
The events that you see and the evidence you collect may be excellent, but they won't be worth much in a courtroom unless you can prove six months later that these are the exact events that happened, and are the same evidence you collected during the incident. Maintaining a clear chain of evidence may become critical in the event that the incident ends up in a legal case. The opposition will challenge each item. If they can show that someone has had the opportunity to modify the evidence during or after the time it was collected, they can radically reduce the legal impact of the evidence.
 
Action 3.1: Identify every piece of evidence
Unless you are facing a dire emergency where you must immediately unplug the system to stop damage, before you touch the computer, begin to identify the evidence. Your logs should state the day and time, and describe your location and any serial numbers or other identifying information. Law enforcement agencies may request that suspect disk drives be removed and sealed as evidence. If they have identifying information—make, model or serial number—be certain to record that. In addition, plans should be in place to recover both hardware and backup data. Even older backup tapes that predate the incident may provide valuable evidence. Whenever copies of electronic data are made, the original data, not the copy, should then be sealed for evidence.
Number, date, and sign notes and printouts. Seal disks with original, unaltered, complete logs in an envelope or other container; then number, date, and sign the container. When you turn evidence over to the appropriate person in your organization, have the recipient sign for each item. If evidence is turned over to law enforcement, ensure every item turned over is detailed and signed for as part of your chain of custody process. Original handwritten notes should be copied, and the original notes sealed as part of the chain of custody. Electronic data should be captured as soon as possible, and the process of making copies of the evidence should be witnessed.
 
Action 3.2: Control access to evidence
Identify an evidence custodian to ensure that you can prove who has access to the secure container used to store the evidence – and this is a very small group of people. If there is a key lock, each key should be stamped do not duplicate. Make sure, by policy and practice, that each person with access understands they are required to control access to these items. Any and every person with access to the evidence may have to testify if the incident results in a court trial.
 
STEP 4: COORDINATE WITH THE PEOPLE WHO PROVIDE YOUR NETWORK SERVICES
Problem: Many of the corrective actions may require the assistance of your ISP. Filters may need to be applied, or routing tables modified before the network traffic reaches your site. In addition there may be forensic evidence in the ISP's logs that should be protected.
 
Action 4.1: Coordinate closely with your Internet Service Provider
Inform your ISP of your initial evidence or opinion, and ask the ISP to assist in the investigation. If possible, it is helpful to have contact names and numbers of the senior personnel at the ISP prior to the incident. Many hours can be lost navigating through the average help desk escalation procedures. You need to reach those people who have the capacity and experience to evaluate the logs and to make changes to the network equipment.
To protect themselves against user complaints, most ISPs will ask for a properly executed court order before sharing any information they gather with you. Unfortunately normal log rotation schedules may destroy evidence before a court order can be obtained. To protect the data, ask your ISP to set aside copies of their logs as a courtesy until a final determination is made about whether a court order is merited.
 
STEP 5: NOTIFY APPROPRIATE OFFICIALS
Problem: Computer incidents, fires, and medical emergencies are usually a lot easier to handle when reported promptly. If you saw a co-worker in the cafeteria collapse, hopefully you wouldn't wait until the next day to alert the emergency medical system.
 
Action 5.1: Notify your local or organizational incident handling team
Notify your manager and security officer as soon as the incident is suspected. It is far too easy to begin working through an incident and forget to involve the management team. It is the responsibility of the management team to insure that proper notifications are made and that the necessary resources are made available to the team. It is a common practice to have the incident handler separate from the designated contact for management, so that the handler is able to focus on coordinating the technical activities. A management person should work closely with the handler in order to keep the management chain of command informed and involved.
 
Reference:
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institue, 2003

نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 18 مرداد 1393

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها:0