Incident Handling Foundations

Chia sẻ: Huy Hoang | Ngày: | Loại File: PDF | Số trang:23

lượt xem

Incident Handling Foundations

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Hello. The material we are going to cover this next hour is central to understanding the theory and practice of information security. This is a foundational course, developed for the SANS Security Essentials program. When you complete this course there will be a quiz available from the SANS web page to help reinforce the material and ensure your mastery of it.

Chủ đề:

Nội dung Text: Incident Handling Foundations

  1. Incident Handling Foundations Security Essentials The SANS Institute Information Assurance Foundations - SANS ©2001 1 Hello. The material we are going to cover this next hour is central to understanding the theory and practice of information security. This is a foundational course, developed for the SANS Security Essentials program. When you complete this course there will be a quiz available from the SANS web page to help reinforce the material and ensure your mastery of it. So many companies and people worry about their network or computer systems being compromised, but few address what they would do if they were compromised. If a company is connected to the Internet they will never be able to prevent all attacks. The motto I like to use is “prevention is ideal but detection is a must.” Being able to detect and react to an attack in a timely matter is key. This module covers the fundamentals of incident handling and shows what a company needs to do to properly address an incident. 4-1
  2. Agenda • What is incident handling? • Why is it important? • What is an incident? • Fundamentals • The Six Step process Incident Handling Foundations - SANS ©2001 2 On the Agenda slide for this module we are going to address various aspects of incident handling. We are going to start with the basics and look at what incident handling is and what it means to your company. We are then going to cover why it is important and why a company needs to be concerned and have proper procedures for dealing with an incident. Being able to identify an incident in a timely manner and react is very important. Just as important is knowing what is not an incident so a company does not have to waste any of their time. The fundamentals of incident handling will also be covered along with the 6 step process for dealing with an incident. The six step process is taken from the “Incident Handling, Step-by-Step guide” published by the SANS Institute. For additional details on how to handle an incident, the Step-by-Step guide is recommended along with a full day course offered by the SANS Institute on Incident Handling. 4-2
  3. Incident Handling • Incident Handling is an action plan for dealing with intrusions, cyber- theft, denial of service, fire, floods, and other security-related events • Having proper procedures in place so you know what to do when an incident occurs Incident Handling Foundations - SANS ©2001 3 As stated on the slide Incident Handling, incident handling is an action plan for dealing with intrusions, cyber-theft, denial of service, fire, floods, and other security-related events. This slide makes it clear that the scope of incident handling is greater than just intrusions, it covers insider crime, and intentional and unintentional events that cause a loss of availability. In fact, fires and floods are every bit as much an incident as a hacker attack. A lot of people only think an incident is a hacker attacker but it is a lot more than that. The other key point of the definition is the notion of action. Sitting there watching is not incident handling. You do not want to move too fast, but you do need to get in motion in an incident! Identifying an incident is important but you must act on that information to secure your systems in a timely manner. The best way to act on an incident and minimize your chance of a mistake is by having proper procedures in place. Well-documented procedures make sure that you know what to do when an incident occurs and minimizes the chances that you will forget something. 4-3
  4. Why is it Important? • Sooner or later an incident is going to occur. Do you know what to do? • It is not a matter of “if” but “when” • Planning is everything • Similar to backups – You might not use it every day, but if a major problem occurs you are going to be glad that you did Incident Handling Foundations - SANS ©2001 4 It does not matter how big your company is or what type of business you are in, sooner or later you are going to have an incident. Companies of all sizes and types have had incidents and those that were not prepared and did not handle it correctly in some cases are no longer around to talk about it. When it comes to having to deal with an incident, it is not a matter of IF an incident is going to occur but WHEN is it going to occur. Another important point is the way some companies choose to deal with an incident is by ignoring it, but as you can image this is very risky to do. I bring this up because some companies I talk to say, “I have never had an incident in 2 years, why do I have to worry about it?” In this case the truth of the matter is they probably have had several incidents, but since they failed to detect them they took a stance of ignoring each incident. As we stated, this is very dangerous and it is only a matter of time until this catches up with you. One of the main reasons for a module on incident handling is, planning is everything. If you are prepared and know what to do, dealing with an incident can be fairly straightforward. On the other hand, if it catches you off-guard, there can be many sleepless nights. The key thing with incident handling is planning is very important but not to get discouraged if you do all of this planning and do not use it right away. Do not say, “I have done this planning and have not had an incident in 3 months.” Think of it as backups, you might not need to use them every day but if a problem ever occurs, and it will, you will be so glad that you did it. 4-4
  5. What is an Incident? • An “incident” is an adverse event in an information system, and/or network, or the threat of the occurrence of such an event. • Examples of incidents include: – unauthorized use of another user’s account – unauthorized use of system privileges – execution of malicious code that destroys data • Incident implies harm, or the attempt to do harm – Incident handler reduces or minimizes harm Incident Handling Foundations - SANS ©2001 5 The slide “What is an Incident?” is for the purpose of defining what we mean when we use a word like incident or event. Incident, as we are using it, refers to harm or the significant threat of harm. There are several important points for an incident handler that flow from this definition. • Since we are dealing with harm or potential harm, our task is to limit the damage. We want to be careful to choose courses of action that do not cause further harm. • If the incident is not what is termed an act of God, your organization may well have a legal right. In either case, the incident handler should proceed in a manner that does not preclude using the evidence gathered in a court setting. Some examples of incidents are: •unauthorized use of another user’s account •unauthorized use of system privileges •execution of malicious code that destroys data Notice the key word in several of these examples, “unauthorized”. If a user openly and willingly gives their account information to another user with the intent that they will use the account to access the network, it is not an incident. It is only when someone uses that account without the permission of the owner in an unauthorized manner. 4-5
  6. What is an Event? • An “event” is any observable occurrence in a system and/or network • Examples of events include: – the system boot sequence – a system crash – packet flooding within a network • These observable events compose an incident • All incidents are composed of events, but not all events are incidents Incident Handling Foundations - SANS ©2001 6 Since an incident is composed of events, lets look at what an event is. An event is something that happened in time that you either directly experienced or that you can show actually occurred. An event is something that you saw flash on the screen or that you heard. It can also be something that you know occurred because it was collected in a log or audit file. As part of the incident handling process, you should create forms that you use to record events. These forms can help you write down the information that should be documented. They can help you to be alert for the things you should be looking for. If you need a starting point, the SANS Incident Handling Step-by-Step guide has sample forms you can use and they are not copyrighted. Make all the copies you want and if you have suggestions for improvement, please email these to If there is any chance of the incident ending in a court case, having correlating information is better than a single source claiming the event happened. For instance, if two people saw a message flash on a screen, that will likely have more validity in court than if one person saw it. Further, attackers sometimes use tools to alter or delete their traces in log files. If you can produce two independent sources for the information, this has more validity. This is one reason we really push intrusion analysts to become familiar with a large number of log formats. The key thing to remember when looking at what an incident is, versus an event, is all incidents are composed of events but not all events are considered incidents. For example, an unauthorized logon is considered an incident, while an authorized logon is not considered an incident, yet both of these are network events. 4-6
  7. Examples of an Incident • Which of the following is an incident: 1. An attacker running NetBIOS scans against a Unix system. 2. An attacker exploiting Sendmail on a Unix system. 3. A backup tape containing sensitive information is missing. Incident Handling Foundations - SANS ©2001 7 On the slide “Examples of an Incident,” lets look at a couple of examples to see what is and what is not an incident. The following are three events. Which ones would you consider to be an incident? 1) An attacker running NETBios scans against a Unix system. 2) An attacker exploiting Sendmail on a Unix system. 3) A backup tape containing sensitive information is missing. Actually the correct answer is all 3 would be considered incidents. In the first example, some might not consider it an incident because an attacker running an NT exploit against a Unix system would not be successful and therefore you do not have to worry about it. Remember our definition of what an incident is, a threat or occurrence of an event. So even though this attack was not successful, it should still be taken as a threat and the next time you might not be so lucky. Remember a lot of these attackers are running scripts against a wide range of systems, so in this case you were lucky because the attack was not successful but what if they ran this NT exploit against an NT system that you have or what if they come back and run a Unix exploit against your Unix system? Wouldn’t you rather deal with an incident when it is not successful than when it is? The second example is a successful attack against a Unix system and should be fairly obvious that this is an example of an incident. Someone successfully compromised your system without authorization or permission. The third example is also an incident because a tape containing all of your company’s data has been compromised. This has the same net impact as if someone broke into your system over the Internet and stole all of your information. Even though stealing a tape is not as glamorous as a hacking attack, it is still considered an incident and must be acted upon. Now that we have a good idea of what an incident is and looked at some examples, lets look at the incident handling process in the next slide. 4-7
  8. Overview of the Incident Handling Process Incident Handling is similar to first aid. The caregiver tends to be under pressure and mistakes can be very costly. A simple, well- understood approach is best. Keep the six stages, (preparation, detection, containment, eradication, recovery, and follow-up) in mind. Use pre-designed forms, and call on others for help. Incident Handling Foundations - SANS ©2001 8 A good way to get an overview of the incident handling process is to compare it to first aid. In both cases, time is not on your side. You are under a lot of pressure and mistakes are very costly. To give you an example, my first real job out of college was working at a Defense Mapping Agency. At that time, they wanted to have an internal rescue squad. I volunteered and completed the training and was pretty excited for my first call. They gave me a pager to carry out so I could be notified when there was a problem. Remember this is back in the day when pagers and cell phones were not that popular, so to carry one around was very impressive. I could not wait for my pager to go off. Finally my pager went off and I was racing to the scene. I passed the chief of the squad and he reached out and grabbed me. He said, “Son, if you hurt someone else or yourself, when you get to the scene, you will not be any good to anyone. Now let’s walk down together”. Now, many years later, I am the grizzled old veteran and I want to pass this advice on to you. Law enforcement agents tell story after story of the well-meaning system administrator that ruined the evidence and usually just a couple minutes after the incident. You do need to act, but take time to think. There is a crucial point to this story. No one can run so fast they can outrun a computer with a 650Mhz Pentium III chip attached to a 100Mb Ethernet network. More importantly, when one is working as root, or administrator, or supervisor, there are many operations that do not have an “undo”. Several times we will draw the analogy between incident handling and first aid. It is a solid analogy. In some sense, first aid is a form of incident handling. So to review this slide the three things you have to remember when dealing with an incident is that it will be very stressful. Every minute will count and mistakes need to be minimized. Putting these three things together means you need to work but not so quick that you make matters worse. Remember the saying, “If you do not have enough time to do it correctly the first time, how will you have enough time to do it again?” 4-8
  9. Incident Handling – 6 Steps • Preparation • Identification • Containment • Eradication • Recovery • Lessons Learned Incident Handling Foundations - SANS ©2001 9 On the slide “Incident Handling - 6 Steps,” we list the six steps in incident handling, which are preparation, identification, containment, eradication, recovery, and lessons learned. The steps serve you, the handler, as a compass or a roadmap, a way to keep in mind what you should be trying to do and the things you need to do next. The key thing with this list is, in order to be successful, you must follow all 6 steps. Some people think if they follow only some of the steps they will be in good shape, but in order to be successful at incident handling, this requires following all of the steps. Now each of the steps need to be customized to a particular company and the industry they work in and the following slides will help you do that. 4-9
  10. Preparation • Planning is everything • Policy – Organizational approach – Inter-organization • Obtain management support • Select team members • Identify contacts in other organizations (legal, law enforcement) Incident Handling Foundations - SANS ©2001 10 When it comes to incident handling, planning is everything and preparation plays a key role. It is very important that you have a policy in place that covers an organization’s approach to dealing with an incident. Things that it needs to cover is whether a company is going to notify law enforcement agencies or run silent or whether a company is going to contain and clean an incident or watch and learn. One thing you really want to avoid is having an incident happen and finding yourself in a debate about whether to contain the incident and clean up, or to watch the attackers and try to gather more evidence. The time to make these (career affecting) decisions is before the incident, keeping senior management and your legal staff apprised. The policy should also contain what the policy is for inter organization approach and how a company works with other companies on an incident. It is very important that an incident handling team has management support and buy-in. The last thing a company wants is for senior management to be questioning or doubting the decisions that were made during an incident. Not everybody makes a good incident handler. There are some very smart people that I have worked with whose personalities do not lend themselves to being a good incident handler. People that like to work solo and be heroes usually do not make good team members. You want someone who works well in a team environment and thinks out solutions and not make rash decisions. 4 - 10
  11. Preparation (2) • Update disaster recovery plan • Compensate team members • Provide checklists and procedures • Have emergency communications plan • Escrow passwords and encryption keys • Provide training • Have a jump bag with everything you need to handle an incident Incident Handling Foundations - SANS ©2001 11 During preparation, a company needs to make sure they update their organization’s disaster recovery plan to include computer incident handling. A large organization with over ten thousand computers is going to rack up some incidents. This can cause the incident handlers to burn out. It is kind of interesting; they tend to burn out just as they get really good. After training and seasoning, they do a bang up job on a couple hot problems and the next thing you know they are suffering from various stress effects. The solution seems to be a set of things, rewards and compensation that includes time off. This may run afoul of your organizational culture, but consider this. When do incidents occur? On Friday afternoons at 3:30 PM. Do the handlers and administrators go home and wait until Monday to start on the clean up? No, in almost every case they stay until the job is done. So we need to reward these people and let them get some rest. Our computing environments are complex, no one knows every variant of Unix and so forth. While we are trying to make sure you have a solid grounding in the basics of handling systems, memory fades over time. Having a checklist to refer to on how to bring down a system or back a system up can help prevent errors and reduce the stress on the handler. If they are following the checklist and it blows up in their face, it is not their fault. It is simply time to update the checklist. When I have been the system administrator of a production system, I have never been really comfortable making privileged passwords available to others. However, in an emergency, a handler may need access to critical systems. One organization has a policy where they are kept in sealed envelopes in locked containers. After several years of implementation they report that while sometimes cumbersome, this system has worked well for them. Note well that there is a two-fold responsibility here. The system administrators must make sure the envelopes are kept up-to-date. The handlers must make sure they tread lightly on the systems, keep the administrators up-to-date on any changes they made and above all, never use a privileged password unless they are qualified on that operating system. One thing that is nearly certain to make an incident worse is to have someone who has no clue what they are doing fumbling around as administrator or root. Not many of us can change the way our entire organization does business, but we can certainly be responsible for the way that we do business. Encourage people to write down critical passwords and encryption keys and store them safely so they can be accessed if required. As encryption becomes ever more prevalent, an organization must set policy as to who owns the secret keys and passphrases and under what circumstances they can be used and accessed. Also, being able to react when an incident occurs is very important. Therefore having a jump bag that contains everything you will need to handle an incident will enable you to react in a more timely fashion. 4 - 11
  12. Identification • How do you identify an incident • Be willing to alert early but do not jump to a conclusion – “Boy that cried wolf” syndrome – Look at all of the facts • Notify correct people • Utilize help desk to track trouble tickets to track the problem Incident Handling Foundations - SANS ©2001 12 Bad things can happen when an unqualified, unauthorized person makes the call on an incident and is wrong. Fifty thousand dollars later, after three days off-line, you question that individual, “What were you thinking?” The answer is usually the same, “I, uh, thought it was nothing.” After a fire alarm is pulled, qualified firefighters who know the signs to look for come to the site and investigate. Only then, does the person in charge at the scene authorize re-entry into the building. This should be the paradigm we work under, be willing to alert early, have trained people look at the situation, and be able to stand down if nothing is wrong at a minimum of expense. Either way, make sure you have mechanisms in place to identify an incident. There is nothing wrong with alerting early if you maintain situational awareness and everyone understands that it might not be an incident. You want to avoid screaming it is an incident and an hour later say, “ Oh never mind.” If you do this several times, you will be a victim of the “boy that cried wolf” syndrome, which is when there is actually an incident, no one will believe you because you were wrong so many times before. Also when it comes to identifying an incident, do what you are good at and utilize others in the organization to help you. Why should an incident handling team go through all of the trouble of tracking issues when the help desk is setup and they do this on a regular basis? Let the help desk and others help you track issues and this will help make sure, in the end, that all of the issues have been resolved. 4 - 12
  13. Signs of an Incident • IDS tool has an alert • Unexplained entries in a log file • Failed events, such as logon • Unexplained events (new accounts) • System reboots • Poor performance Incident Handling Foundations - SANS ©2001 13 There are many different signs of an incident, but this slide lists some of the more common ones. •IDS tool has an alert •Unexplained entries in a log file •Failed events, such as logon •Unexplained events (new accounts) •System reboots •Poor performance Some additional signs of an incident are: Suspicious entries in system or network accounting (e.g. a UNIX user obtains root access without going through the normal sequence necessary to obtain this access). Accounting discrepancies (e.g. someone notices an 18-minute gap in the accounting log in which no entries whatsoever appear). Unexplained, new files or unfamiliar file names. Unexplained attempts to write to system files or make changes. 4 - 13
  14. Identification (2) • Assign a primary handler • Determine whether an event is an incident • Maintain a provable chain of custody • Make a clean backup of the system Incident Handling Foundations - SANS ©2001 14 When it comes to handling an incident, if one person isn’t in charge, no person is in charge. For smaller incidents, often of the “would you check this out” category, there is no need to send core incident handlers. It is recommended practice to have a core team of well-trained handlers, and also have incident handling skills and training as part of the job for security officers or system administrators. An organization that does this, benefits by having multiple levels of trained “firefighters”. However, in such a case, it is important to set up assignments in a way that encourages the system administrator to succeed. A non-full time handler should be given the assignment in a way that it is clear what is expected of them: the quality of their investigation, what documentation they should produce, and when it is due. It is also very important that they know who they can call if they feel they need additional guidance or support. Once you determine whether an event is actually an incident, it is important that you maintain a provable chain of custody. In order to do that and make sure you do not destroy any evidence, always make a clean binary backup of the system before you start making any modifications. 4 - 14
  15. Containment • An incident handler should not make things worse • Secure the area • Make a backup • Possibly pull the system off the network • Change passwords Incident Handling Foundations - SANS ©2001 15 An incident handler should not make things worse, they should make things better. In containing an incident, the first thing that should be done is to secure the area. In doing so, a backup should be made of all infected systems and if the original hard drive can not be kept for evidence, multiple copies of the backups should be made. One should be kept for evidence and the other used to analyze the incident. At some point in the containment process a decision needs to be made of whether the systems should be pulled off of the network or if the entire network should be pulled from the Internet. Also, passwords should be changed to make sure a compromised account cannot be used as a re-entry point into the system. 4 - 15
  16. Eradication • Must fix problem before putting it back online • Determine cause and symptom • Improve defenses • Perform vulnerability analysis Incident Handling Foundations - SANS ©2001 16 Before the system goes back online, an incident handler must make sure that they fix the problem or the vulnerability that the attacker used to compromise the system. Nuking the operating system from high orbit may be considered a shortcut in the handling process. While it is certainly true that total destruction of the contents of the disk will take care of any malevolent code, the opportunity for re-infection via the same channel after you reload the operating system still exists. There are tons of cases where handlers have taken systems down, reloaded the operating system, only to have the box compromised again a couple days later. The best course of action is to determine what the cause of the incident was, to find the vector of infection, and take action to prevent this from happening again. Once your system is hacked, the word gets out and every pea-brained hacker on the planet lines up to take another shot at you. It is not enough to simply recover the system; the security of the affected system(s) needs to be upgraded. If it is a production system, you may hear arguments that the organization cannot take the risk of modifying a production system. This is an important, and to some extent, a valid argument. The counter to it is that if the system was compromised, it must have some vulnerability. If we do not remove the vulnerability, the system may become compromised again. The simple trick of changing the name and IP address of the system can solve a lot of problems. If your organization has the time and resources, this can be a wonderful opportunity to play with a “honeypot”, a system that is designed to collect information about an attacker without yielding any useful data. One of the most interesting sources of software for building a honey pot is Fred Cohen’s deception toolkit, available from: Vulnerability scanners such as the NAI Cybercop, Internet Security Scanner, Cisco’s Net Sonar, Nessus, Nmap and Saint can identify weaknesses in your organization’s internal network. The commercial software packages listed are somewhat expensive. If money is an issue, you can pay a consultant to run the software for you on a one time, or on a reoccurring basis, and provide a report. Nmap, a free tool, is becoming one of my favorite tools and I have also had good success with Saint, another free tool. After placing a suspect system on a small hub and doing the backup, I have sometimes found it helpful to run Nmap on the target computer from another system on the hub. Several times, this has given me insight into the potential problems I may be dealing with. Running a security scanner on the neighboring systems in a compromise can help you make sure you have full and complete eradication. If one system is compromised, there is every chance the number is actually two or more. 4 - 16
  17. Recovery • Make sure you do not restore compromised code • Validate the system • Decide when to restore operations • Monitor the systems Incident Handling Foundations - SANS ©2001 17 How do you restore from backups and ensure you are not reloading compromised code? There is no easy solution, but you can use file integrity software in reverse. Use a software package like Tripwire on the compromised system and then do a restore from backups, possibly on a clean system. Run Tripwire again and compare the results. This can help you find the compromised code. For best results mount the disk that you are running Tripwire on from a system with a known-good operating system. This way kernel modules will fail to protect the compromised code. Remember again that after you have touched the machine, everything that breaks is your fault. Be sure to get the owner of the machine to sign that it is back in full operation. Make every effort to ensure the system is working properly before leaving the scene. The decision of when to put the system back into business has to be made by the system owner. As a handler, you can give them advice and try to be helpful, but this is their call. They are the ones that depend on this system. Needless to say, if the eradication was not complete or the infection vector was not closed off, the earlier you detect re-infection the better off everyone is. It is also politically better if the handlers detect the problem and show up to fix it, than if the problem comes to light because business operations are affected. This is a serious problem. Many times handlers take some shortcut along the way, or there is something you never discovered about the trust relationship and the problem comes back. 4 - 17
  18. Follow-up • Develop a report – Try to get consensus • Conduct lessons learned meeting • Send recommendations to management • Follow-up meeting Incident Handling Foundations - SANS ©2001 18 The only one that really can or will write the report is the on-site handler. They submit the draft, but we should allow everyone involved to review the draft. If they have a strong disagreement about the facts of the matter, they can submit that and their statement can remain a part of the incident record. It is far better to find out that you have a lack of consensus before going to court than during court! After the report has been reviewed, schedule a lessons learned meeting. In general, the main purpose of such a meeting is to get consensus on the executive summary of the report. What is the most important thing for an executive summary to cover? How much the organization saved by having an effective incident handling procedure! During every incident, mistakes occur. We learn from these, improve our process for the future, and move on. Sometimes, we run into policy or other organizational problems that hinder bringing the incident to a close. We note these and submit them to management for their consideration. Follow-up meetings are never the most popular of events. Everyone is tired; they have been under stress. The system is now back in operation and the last thing anyone wants to do is have a meeting to rehash painful memories. However, this is a valuable tool for organizational improvement. This is the hardest time not to blame people. The focus should be on process improvement however. 4 - 18
  19. Putting the Steps Together • Steps must be customized for your environment • Every incident is different • Planning is everything • Make things simple with checklists and tested procedures Incident Handling Foundations - SANS ©2001 19 We just covered the general 6 steps for handling an incident, but since every company and every incident is different, they must be customized for your particular environment. Remember planning is everything and by utilizing written checklists and tested procedures, it helps ensure that mistakes are minimized. 4 - 19
  20. Key Mistakes in Incident Handling • Failure to report or ask for help • Incomplete/non-existent notes • Mishandling/destroying evidence • Failure to create working backups • Failure to contain or eradicate • Failure to prevent re-infection • Failure to apply lessons learned Incident Handling Foundations - SANS ©2001 20 On this slide, we have a list in probably time order, of the mistakes that are most likely to occur in the incident handling process. The key mistakes often made are the following: •Failure to report or ask for help •Incomplete/non-existent notes •Mishandling/destroying evidence •Failure to create working backups •Failure to contain or eradicate •Failure to prevent re-infection •Failure to apply lessons learned A good handler thinks a few steps ahead and tries to avoid the problems. Of course things happen. Don’t lose your cool if a re-infection occurs or anything like that. It doesn’t mean you are not a good handler, but if you can avoid mistakes, you might well be able to get home, get that shower, and jump into bed several hours earlier. 4 - 20
Đồng bộ tài khoản