Understand how to identify and manage an incident. Lisa Bock covers the steps to take after an incident or breach. Explore to the impact of an incident. Move through the process to identify and respond to an incident. Learn possible causes of an incident, to help develop a solution, and resolve and document the problem.
- [Voiceover] An incident is something that disrupts operational or day-to-day activities and is generally unplanned. An incident should not be confused with the disaster which is large scale and involves multiple agencies and recovery can take weeks or worse yet, months. Although an incident is on a much smaller scale, it can lead to a disaster if left unchecked. That is why incident management is an important concept.
Incident management is responding to a disruption in information technology services or business processes. Managing an incident begins as soon as an incident is reported and continues until operation has resumed normal activity. Respond quickly to an incident to prevent an escalation of a problem. For example, if there is a bottleneck at a server, the rest of the network will soon be affected and in a fear with productivity.
React and respond before this happens. Each IT team can generate their own set of procedures for managing incidents. However, there are several published guidelines to follow. Some examples include the Open Group Architecture Framework, Information Technology Infrastructure Library, and Control Objectives for Information and Related Technology. The standards are in line with supporting the needs of business which are not a requirement but a set of well-defined standards and good practice that can be applied to any type of organization and can be fine-tune to meet their own needs.
In addition to procedures, some type of ticketing system should be in place. To log and analyze events. There are many open-source and free help desk software applications that are available. Let's review some of the guidelines for incident management. Identify the incident. Respond to the incident. Consider possible causes. Develop a solution. And then resolve and document. Train users to identify and log incidents.
If someone calls to report an incident, make sure an entry has been made. Some common items on a Help Desk Ticket include unique ID. Who reported the incident? Description, date and time, priority, location, category, and in some cases a subcategory. Although all field values can be use in data analysis, location and meaningful categories and subcategories might be of more help as they might be useful in correlation of events that might signal something larger.
When responding to the incident, either make a call or in some cases physically go to where the problem is being reported. More questions might have to be asked in order to narrow the scope such as, is anyone else in your department having the same problem? Are all applications affected or just the ones you are currently using? Has this happened before? Or, have you recently upgraded your software? Once the scope has been narrowed, determine what possibly cause the incident.
At this point, the priority may have to be modified either higher or lower depending on the incident. In some cases, the problem may require escalation whereby the problem is handed off to a more experienced technician for resolution. Some incidents resolve quickly such as restoring power or rolling back from an upgrade but some take more time as testing before deployment is sometimes required. Some guidelines before implementing a solution include run a baseline before changes are made, save device and wiring closet configuration files, and run a baseline afterwards for comparison.
Once the solution has been implemented, close the incident. Allow for feedback possibly in a form of a survey to ensure the problem has been resolved. Documentation should be non-subjective and state only the facts. Include the following. Problem identification, implementation and resolution, and any testing that took place and possibly some suggestions for preventative action such as check other host for appropriate configuration on software build 3.2.
Other suggestions in order to have a strong incident response team include remain calm even if a major outage has occurred, assign clear roles and work together as a team by communicating frequently. If the incident is to be communicated to customers, have a plan and place to keep them apprised of the situation. Keep in mind incident management is reactive. Steps should be taken to have a more proactive approach to prevent or at least minimize incidents.
Maintain security policies. Ensure that they are visible and up-to-date for today's trends. Promptly install security patches and virus updates and maintain access control lists. Perform security assessments such as table top exercises to rehearse responses and possible incidents. And analyze captured data. Look for trends, patterns and any hidden problems that can reduce the incident volume and diminish risk.
Security expert Lisa Bock starts with an overview of ethical hacking and the role of the ethical hacker. She reviews the kinds of threats networks face, and introduces the five phases of ethical hacking, from reconnaissance to covering your tracks. She also covers penetration-testing techniques and tools. The materials map directly to the "Introduction to Ethical Hacking" competency from the CEH Body of Knowledge, and provide an excellent jumping off point for the next courses in this series.
Note: Our Ethical Hacking series will map to the 18 parts of the EC-Council's certification exam. Find more courses in the series on Lisa's author page.
- Ethical hacking principles
- Managing incidents
- Creating security policies
- Protecting data
- Conducting penetration testing
- Hacking in phases