Software complexity, near-universal worldwide connectivity, and the criminals determined to profit from these factors make information security incidents inevitable. The goal of an effective information security incident management strategy is a balance of driving the impact of the incidents down while processing incidents as efficiently as possible. Good incident management will also help with the prevention of future incidents. How this plays out is to develop a program that prepares for incidents. From a management perspective, it involves the identification of resources needed for incident handling, as well as developing and communicating the formal detection and reporting processes. An effective security program includes important aspects of detecting, reporting, and responding to adverse security events as well as weaknesses that may lead to events if they are not appropriately addressed. The primary elements of incident management are:
Effective incident response in many organizations other than IT, involve having trained personnel equipped and ready for response. So it is with information security incident management. Having trained individuals ready to respond with advance preparation is the first task. Designing an effective means of the detection of incidents is also essential and this often consists of trained users and administrators, together with technical controls. Effective, appropriate communication at all levels of an organization is essential for limiting the impact of security events, using formal detection and reporting processes. All members of the community should be trained and comfortable regarding procedures for reporting failures, weaknesses, and suspected incidents; methods to recognize and detect problems with security protections; as well as how to escalate reporting appropriately. In addition, technical controls must be implemented for the automated detection of security events, coupled with as near real-time reporting as possible, to investigate and initiate immediate responses to problems. For new IT systems, often the best time to develop automated detection of security events is when the preventive security controls are being architected. Confirmation of an adverse security event is an inevitable outcome in any organization. A formal management procedure and policy for incident response, including roles and responsibilities for each aspect of the response, is essential. Aspects include funding and cost models, analysis, containment, and recovery responsibilities, decision-making authority for notifications; legal and/or law enforcement involvement; forensic investigations; responsibility for after-incident debriefing; and policy, procedure, and process improvements.
No matter the extent of the defenses, it inevitable that Information Security Incidents will occur. For this reason, establishing, periodically assessing, and continually improving incident management processes and capabilities is very important. If you are just getting started in this area of your security program, then the following areas are very useful stepping stones that are covered in this chapter:
1. Define what constitutes an information security incident and review how varied incidents can be classified.
2. Consider what constitutes an information security incident that requires special handling (vs. common security events). Review incident classification schemes that allow for aligning handling procedures to potential impacts and risks.
3. Identify and establish essential roles and procedures needed for effective incident management.
4. Evaluate the technical and operational capabilities of your organization to detect and respond to security incidents. Consider how senior management support can be gained to formalize effective incident management processes. Formulate procedures and workflow for effectively addressing incidents throughout the life cycle
5. Create effective communication, coordination, and reporting plans for a broad spectrum of incidents including data breach events.
6. Identify key partners and stakeholders and levels of communication and engagement. Review the legal and contractual communication requirements associated with data types that may be involved in Information Security Incidents.
7. Adapt and learn from security incidents and strive for continual improvement by identifying and planning for training needs and enhancement of response capabilities.
The reality of security incidents, breaches, and loss of data has become all too familiar to a growing number of organizations. Efforts to be prepared need to be engaged prior to these episodes occurring through a comprehensive approach involving on-premise, qualified team construction, vendor participation, appropriate insurance or retainers, and organizational counsel. The best reaction to an information security incident is being proactive and the worst is proceeding without caution, expertise, and proper guidance. If qualified personnel does not exist on staff, external assistance needs to be contracted and ready to employ. Without previous agreements, even qualified vendors may have difficulties meeting your required timeline. Proceeding without a consistent, fully-developed response plan can lead to lost evidence, data, and inability to verify loss and recovery leading to a false sense of containment and resolution of the event. The incident management plan should be clear, concise describing the steps to be taken, resources utilized and their respective roles, and the timelines under which the tasks are to be performed. The getting started section included articles, papers, presentations, sample policies flowcharts, and checklists to help an organization get the process started. The remainder of this document provides resources and processes to help ensure that a proper and complete assessment, analysis, containment, and response are in order.
A 5.24 Information security incident management planning and preparation
Control
The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.
Purpose
To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events.
ISO 27002 Implementation Guidelines
Roles and responsibilities
The organization should establish appropriate information security incident management processes. Roles and responsibilities to carry out the incident management procedures should be determined and effectively communicated to the relevant internal and external interested parties.
The following should be considered:
a) establishing a common method for reporting information security events including point of contact;
b) establishing an incident management process to provide the organization with capability for managing information security incidents including administration, documentation, detection, triage, prioritization, analysis, communication and coordinating interested parties;
c) establishing an incident response process to provide the organization with capability for assessing, responding to and learning from information security incidents;
d) only allowing competent personnel to handle the issues related to information security incidents within the organization. Such personnel should be provided with procedure documentation and periodic training;
e) establishing a process to identify required training, certification and ongoing professional development for incident response personnel.
Incident management procedures
The objectives for information security incident management should be agreed with management and it should be ensured that those responsible for information security incident management understand the organization’s priorities for handling information security incidents including resolution time frame based on potential consequences and severity. Incident management procedures should be implemented to meet these objectives and priorities. Management should ensure that an information security incident management plan is created considering different scenarios and procedures are developed and implemented for the following activities:
a) evaluation of information security events according to criteria for what constitutes an information security incident;
b) monitoring , detecting , classifying , analysing and reporting of information security events and incidents (by human or automatic means);
c) managing information security incidents to conclusion, including response and escalation according to the type and the category of the incident, possible activation of crisis management and activation of continuity plans, controlled recovery from an incident and communication to internal and external interested parties;
d) coordination with internal and external interested parties such as authorities, external interest groups and forums, suppliers and clients ;
e) logging incident management activities;
f) handling of evidence;
g) root cause analysis or post-mortem procedures;
h) identification of lessons learned and any improvements to the incident management procedures or information security controls in general that are required.
Reporting procedures
Reporting procedures should include:
a) actions to be taken in case of an information security event (e.g. noting all pertinent details immediately such as malfunction occurring and messages on screen, immediately reporting to the point of contact and only taking coordinated actions);
b) use of incident forms to support personnel to perform all necessary actions when reporting information security incidents;
c) suitable feedback processes to ensure that those persons reporting information security events are notified, to the extent possible, of outcomes after the issue has been addressed and closed;
d) creation of incident reports.
Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures.
Other information
Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate. Detailed guidance on information security incident management is provided in the ISO/IEC 27035
series.
Preparation involves the identification of resources needed for incident handling and having trained individuals ready to respond, and developing and communicating a formal detection and reporting process. Effective, appropriate communication at all levels of an organization is essential for limiting the impact of security events. The policy can have the following components:
- Statement of management commitment
- Purpose and objectives of the policy
- Scope of the policy (to whom and what it applies and under what circumstances)
- Definition of computer security incidents and their consequences within the context of the organization
- Prioritization or severity ratings of incidents
- Performance measures
- Reporting and contact resources
Organizational structure and delineation of roles, responsibilities, and levels of authority should include the authority of the incident response team to confiscate or disconnect equipment, monitor suspicious activity, and the requirements for reporting certain types of incidents.
Prioritization of incidents is an important element, as are escalation procedures. Interestingly, incident priorities differ between organizations depending on their culture and other policies, and there are certain types of incidents that one organization may tolerate while another may not. In addition, policies are required to outline permitted monitoring of system and network activities, and under specific circumstances. It is also advisable to have policies that specify who can access data relating to an incident under what circumstances and what auditing is required to document the access. Separate policies should be considered describing the data retention of non-incident-related log data and data preserved during the investigation of an incident. The term forensic is used to describe a characteristic of evidence that satisfies its suitability for admission as fact and its ability to persuade based on proof (or high statistical confidence). This applies to Prioritization of incidents is an important element, as are escalation procedures. Interestingly, incident priorities differ between organizations depending on their culture and other policies, and there are certain types of incidents that one organization may tolerate while another may not. In addition, policies are required to outline permitted monitoring of system and network activities, and under specific circumstances. It is also advisable to have policies that specify who can access data relating to an incident under what circumstances and what auditing is required to document the access. Separate policies should be considered describing the data retention of non-incident-related log data and data preserved during the investigation of an incident. Once you have decided what types of data you are going to maintain, it is prudent to take steps to preserve their integrity and document their location, format, and any other associated details. A simple hash algorithm can be used to document the integrity of log files. Documenting the location of important data sources, and outlining how these data can be accessed and interpreted, will help use the data efficiently when necessary. Marking the location of important data sources on a network topology map is a useful way to summarize this information graphically, facilitating evidence gathering during high-pressure incidents. This type of graphical view of data sources on a network can also be useful for finding gaps in coverage and developing better approaches to monitoring system activities and preserving existing data. In addition to preparing data sources for incidents, it is also important to be operationally prepared for incidents. This involves purchasing the necessary equipment and training at least one individual to handle incidents and use tools for recovering and examining data.
A. 5.25 Assessment of and decision on information security events
Control
The organization should assess information security events and decide if they are to be categorized as information security incidents.
Purpose
To ensure effective categorization and prioritization of information security events.
ISO 27002 Implementation guidance
A categorization and prioritization scheme of information security incidents should be agreed for the identification of the consequences and priority of an incident. The scheme should include the criteria to categorize events as information security incidents. The point of contact should assess each information security event using the agreed scheme. Personnel responsible for coordinating and responding to information security incidents should perform the assessment and make a decision on information security events. Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification.
Other information
The ISO/IEC 27035 series provides further guidance on incident management.
The point of contact should assess each information security event using the agreed information security event and incident classification scale and decide whether the event should be classified as an information security incident. Classification and prioritization of incidents can help to identify the impact and extent of an incident. In cases where the organization has an information security incident response team (ISIRT), the assessment and decision can be forwarded to the ISIRT for confirmation or reassessment. Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification.
A formal management procedure and policy for incident response, including roles and responsibilities for each aspect of the response, is essential. Aspects to document include funding and cost models; analysis, containment, and recovery responsibilities; decision-making authority for notifications; legal and/or law enforcement involvement; forensic investigations; responsibility for after-incident debriefing; and policy, procedure, and process improvements. The primary goals of security incident response are to determine the cause and effect of incidents, including any sanctions which may be appropriate and any new preventive measures that may need to implement, as well as to restore the affected infrastructure to an operational state in a timely manner. The general activities or stages to an effective response and improvement are described in the table below. Some may of necessity be serially processed and some may run as concurrent activities. For example, once an event has been identified, the prioritization and assessment may occur at the same time as containment for an active intrusion situation.
| Stages: | Activities: |
|
Identification and prioritization of incident, and performing a timely assessment of the situation | 1. Determine the scope/impact. The number of users affected, or a number of devices or segments of the network should be considered. Is a single user or account involved? 2. Assess the severity. What is the sensitivity of the data involved? What is the criticality of the service, or system, or application? What is the potential for damage or liability? Is there potential for harm? 3. Assess the urgency of the event. Is it an active problem, threat, or event-in-progress? Was the problem discovered after the fact? Is the intrusion “dormant”, or completed? Does this involve the use of an account rather than a system? Is this involve the safety or privacy of individuals? |
| Containment of the event | 1. Does the system need to be removed from the network? Does active memory need to be imaged or captured? 2. Are there user accounts or system-level accounts that need to be disabled or changed? Are there sessions that need to be dropped? |
|
Investigation of what occurred and how (includes “root cause” analysis) | 1. An incident tracking record needs to be created. If deemed necessary, due to the scope, seriousness, or complexity of the incident, an incident notes log should also be created. 2. Gathering and preserving relevant information should be conducted by trained security personnel. 3. Evaluation of evidence commences. It may be a “forensic” calibre assessment, or a less comprehensive analysis, depending on the type of incident and organization’s policies. Decisions with respect to the appropriate resolution and response should be discussed with decision-makers and key stakeholders. |
| Response (effect) | 1. Eradication of the problem and associated changes to the system need to be applied. This includes technical actions such as operating system and application software installs new or changed firewall rules, custom configurations applied, databases created, backup data restored, accounts created and access controls applied 2. Recovery to a fully operational state always follows appropriate testing or assurance of the system integrity and stability. Effective customer service includes regular communications with stakeholders who may be anxious for recovery. 3.Outcomes, including possible sanctions, should be determined. Sanctions, if they are deemed appropriate to the response, maybe internal, such as disciplinary action, or they may be external, such as referral to law enforcement |
| Follow up (Improvements) | 1. After incident debriefing. It is important to review the process and how it could have been better after an incident is closed. This is especially valid for new types of incidents, and particularly severe or costly incidents. 2. Consider policy and process changes. Were any procedures missing, communications unclear, or stakeholders that were not appropriately considered? Did the technical staff have appropriate resources (information as well as equipment) to perform the analysis and/or the recovery? 3.Consider controls improvements, leading to prevention. What can we do to ensure this does not happen again? What improvements can we implement to make our response and recovery more timely? |
A.5.26 Response to information security incidents
Control
Information security incidents should be responded to in accordance with the documented procedures.
Purpose
To ensure efficient and effective response to information security incidents
ISO 27002 Implementation guidance
The organization should establish and communicate procedures on information security incident
response to all relevant interested parties.
Information security incidents should be responded to by a designated team with the required
competency (see 5.24).
The response should include the following:
- containing, if the consequences of the incident can spread, the systems affected by the incident.
- collecting evidence as soon as possible after the occurrence.
- escalation, as required including crisis management activities and possibly invoking business continuity plans.
- ensuring that all involved response activities are properly logged for later analysis.
- communicating the existence of the information security incident or any relevant details thereof to all relevant internal and external interested parties following the need-to-know principle.
- coordinating with internal and external parties such as authorities, external interest groups and forums, suppliers and clients to improve response effectiveness and help to minimize consequences for other organizations.
- once the incident has been successfully addressed, formally closing and recording it.
- conducting information security forensic analysis, as required.
- performing post-incident analysis to identify root cause. Ensure it is documented and communicated according to defined procedures.
- identifying and managing information security vulnerabilities and weaknesses including those related to controls which have caused, contributed to or failed to prevent the incident.
Other information
The ISO/IEC 27035 series provides further guidance on incident management.
It is always good to assign owners, be clear on actions and timescales, and as with everything for ISO 27001, retain the information for audit purposes (also essential if you have other stakeholders and regulators to consider). The individual placed in charge of dealing with the security event will be responsible for restoring a normal level of security whilst also:
- collecting evidence as soon as possible after the occurrence;
- conducting an information security forensics analysis (grand term but at least being clear on the root cause and related aspects or what happened and who was involved, why etc);
- escalation, if required, for example to relevant regulators;
- ensuring all that all involved response activities are properly logged for later analysis;
- communicating the existence of the information security incident or any relevant details to the leadership for them to be further communicated to various individuals or organizations on a need-to-know basis; and
- dealing with information security weaknesses found to cause or contribute to the incident.
In many cases, a more in-depth evaluation of the incident and circumstances is warranted. It may be to determine if confidential information was involved in, or stored on, the system in question. It may also be an effort to determine the vulnerability or action that enabled the incident to occur. This is typically where a forensic evaluation comes into play. Unfortunately, in some cases, an incident will involve or expose confidential information, such as PII (personally identifiable information) that is protected by law, other policy, or local practices. When this occurs there is often some sort of requirement in the response stage for notification to affected persons.
A. 5.27 Learning from information security incidents
Control
Knowledge gained from information security incidents should be used to strengthen and improve the information security controls.
Purpose
To reduce the likelihood or consequences of future incidents.
ISO 27002 Implementation guidance
The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents.
The information gained from the evaluation of information security incidents should be used to:
a) enhance the incident management plan including incident scenarios and procedures.
b) identify recurring or serious incidents and their causes to update the organization’s information security risk assessment and determine and implement necessary additional controls to reduce the likelihood or consequences of future similar incidents. Mechanisms to enable that include collecting, quantifying and monitoring information about incident types, volumes and costs.
c) enhance user awareness and training by providing examples of what can happen, how to respond to such incidents and how to avoid them in the future.
Other information
The ISO/IEC 27035 series provides further guidance on incident management.
It is always good to assign owners, be clear on actions and timescales, and as with everything for ISO 27001, retain the information for audit purposes (also essential if you have other stakeholders and regulators to consider). The individual placed in charge of dealing with the security event will be responsible for restoring a normal level of security whilst also. There should be mechanisms in place to enable the types, volumes, and costs of information security incidents to be quantified and monitored. The information gained from the evaluation of information security incidents should be used to identify recurring or high-impact incidents.The evaluation of information security incidents may indicate the need for enhanced or additional controls to limit the frequency, damage, and cost of future occurrences, or to be taken into account in the security policy review process. With due care of confidentiality aspects, anecdotes from actual information security incidents can be used in user awareness training as examples of what could happen, how to respond to such incidents, and how to avoid them in the future.
This is an important control, and your policy needs to demonstrate that knowledge gained from analyzing and resolving information security incidents will be used to help reduce the likelihood or impact of any future incidents. As part of the commitment to continuous service improvement, you should ensure that you learn from the lessons of any security incident to therefore help evolve and adapt the ISMS to meet the changing landscape that is worked in. Once an incident has been resolved, it should be placed into a status of review and learning, where the lead responder for that incident will discuss any changes required to the processes of the ISMS policies as a result. Any relevant recommendations should then be put to the ISMS Board for further discussion. Once the review and learning have been completed, updates have been made to the policies as required, the relevant staff must be notified and re-trained if required, and the cycle of information security awareness and education continues. The purpose of metrics here is to identify the major causes and sources of incidents, to measure the damage caused by incidents, and to observe trends in both. If metrics show that a particular vulnerability is causing the most losses, you may decide to reconfigure the network to protect vulnerable systems and make an exerted effort to fix them. If an increasing number of attacks are coming through the VPN, you may decide to install a dedicated firewall and/or intrusion detection system to block these attacks. If metrics show that the total annual cost of incidents is increasing steadily, the organizations may decide to devote more resources to preventative security measures. Metrics may include the total incidents handled, time spent on incidents, the number of different types of incidents, and the number of Windows versus UNIX systems impacted. It is not sufficient to just count the number of incidents because as your program improves, these increase. Some useful incident measures to consider are:
• the number of detected but unsuccessful intrusion attempts to compare with the number of successful ones
• the damage/losses caused by disruptive incidents, to help develop plans for reducing outages and the staff hours spent responding to incidents
• reductions in downtime of the network or critical systems
• metrics for any special security initiatives such as alarms or monitoring of systems, to help in assessing their effectiveness
A. 5.28 Collection of evidence
Control
The organization should establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events.
Purpose
To ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions.
ISO 27001 Implementation guidance
Internal procedures should be developed and followed when dealing with evidence related to information security events for the purposes of disciplinary and legal actions. The requirements of different jurisdictions should be considered to maximize chances of admission across the relevant jurisdictions.
In general, these procedures for the management of evidence should provide instructions for the identification, collection, acquisition and preservation of evidence in accordance with different types of storage media, devices and status of devices (i.e. powered on or off). Evidence typically needs to be collected in a manner that is admissible in the appropriate national courts of law or another disciplinary forum. It should be possible to show that:
a) records are complete and have not been tampered with in any way;
b) copies of electronic evidence are probably identical to the originals;
c) any information system from which evidence has been gathered was operating correctly at the time the evidence was recorded.
Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence.
Digital evidence can transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as digital evidence.
Other information
When an information security event is first detected, it is not always obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve legal advice or law enforcement early in any contemplated legal action and take advice on the evidence required.
ISO/IEC 27037 provides definitions and guidelines for identification, collection, acquisition and preservation of digital evidence.
The ISO/IEC 27050 series deals with electronic discovery, which involves the processing of electronically stored information as evidence.
Internal procedures should be developed and followed when dealing with the evidence for the purposes of disciplinary and legal action. In general, these procedures for evidence should provide processes of identification, collection, acquisition, and preservation of evidence in accordance with different types of media, devices, and status of devices e.g. powered on or off. The procedures should take account of:
- chain of custody;
- safety of evidence;
- safety of personnel;
- roles and responsibilities of personnel involved;
- competency of personnel;
- documentation;
- briefing.
Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence. Forensic evidence may transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as forensic evidence. The requirements of different jurisdictions should also be considered to maximize the chances of admission across the relevant jurisdictions.Identification is the process involving the search for, recognition, and documentation of potential evidence. The collection is the process of gathering physical items that can contain potential evidence. The acquisition is the process of creating a copy of data within a defined set. Preservation is the process to maintain and safeguard the integrity and original condition of the potential evidence. When an information security event is first detected, it may not be obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve a lawyer or the police early in any contemplated legal action and take advice on the evidence required.
The organization has to define and apply controls for the identification, collection, acquisition, and preservation of information, which can be used as evidence, especially if there are criminal or civil proceedings likely to happen from the incident. Where the organization suspects or knows that a security incident may result in legal or disciplinary action, they should carry out the collection of evidence carefully, ensure a good chain of custody and avoid any threat of being caught out by poor management. It’s sensible to tie information security incident management clearly to disciplinary procedures too. Everyone should know to take precautions whilst also being clear on the consequences for those who fail to take it seriously.
Recommended Tools and Resources for Incident Handlers
- Incident Handler Communications and Facilities:
• Contact information including after hours (on-call) information
• Incident reporting mechanisms
• Pagers and/or cell phones
• Encryption software
• Secure storage location/area
• Work area - Incident Analysis Hardware and Software:
• Computer forensic workstations and/or backup devices, laptops
• Spare (workstations servers and networking) devices
• Blank media, cables, housings, converters, and write blockers
• Portable printer
• Packet sniffers and protocol analyzers
• Computer forensic software
• Removable media
• Evidence gathering accessories (such as notebooks, cameras, recorders, chain of custody forms, evidence collection bags) - Incident Analysis Resources:
• Port lists
• OS documentation
• Network diagrams
• Lists of critical assets
• Baselines
• Cryptographic hashes of critical files - Incident Mitigation Resources:
• Media (OS and application software)
• Security patches
• Backup images
Back to Home Page
If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.
