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 which 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 defences, 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 lifecycle
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.
A.16.1 Management of information security incidents and improvements
To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.
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 do 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 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, presentation, 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.16.1.1 Responsibilities and procedures
Management responsibilities and procedures should be established to ensure a quick, effective and orderly response to information security incidents.
The following guidelines for management responsibilities and procedures with regard to information security incident management should be considered:
a) management responsibilities should be established to ensure that the following procedures are developed and communicated adequately within the organization:
- procedures for incident response planning and preparation;
- procedures for monitoring, detecting, analyzing and reporting of information security events and incidents;
- procedures for logging incident management activities;
- procedures for the handling of forensic evidence;
- procedures for assessment of and decision on information security events and assessment of information security weaknesses;
- procedures for response including those for escalation, controlled recovery from an incident and communication to internal and external people or organizations;
b) procedures established should ensure that:
- competent personnel handle the issues related to information security incidents within the organization;
- a point of contact for security incidents’ detection and reporting is implemented;
- appropriate contacts with authorities, external interest groups or forums that handle the issues related to information security incidents are maintained;
c) reporting procedures should include:
- preparing information security event reporting forms to support the reporting action and to help the person reporting to remember all necessary actions in case of an information security event;
- the procedure to be undertaken in case of an information security event, e.g. noting all details immediately, such as type of non-compliance or breach, occurring malfunction, messages on the screen and immediately reporting to the point of contact and taking only coordinated actions;
- reference to an established formal disciplinary process for dealing with employees who commit security breaches;
- suitable feedback processes to ensure that those persons reporting information security events are notified of results after the issue has been dealt with and closed.
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.
Information security incidents might transcend organizational and national boundaries. To respond to such incidents there is an increasing need to coordinate response and share information about these incidents with external organizations as appropriate.
Preparation involves identification of resources needed for incident handling and having trained individuals ready to respond, and by 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
• 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, to monitor suspicious activity, and the requirements for reporting certain types of incidents.
• Prioritization or severity ratings of incidents
• Performance measures
• Reporting and contact resources
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 what 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 what 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 to incidents and use tools for recovering and examining data.
A.16.1.2 Reporting information security events
Information security events should be reported through appropriate management channels as quickly as possible.
All employees and contractors should be made aware of their responsibility to report information security events as quickly as possible. They should also be aware of the procedure for reporting information security events and the point of contact to which the events should be reported. Situations to be considered for information security event reporting include:
a) ineffective security control;
b) breach of information integrity, confidentiality or availability expectations;
c) human errors;
d) non-compliance with policies or guidelines;
e) breaches of physical security arrangements;
f) uncontrolled system changes;
g) malfunctions of software or hardware;
h) access violations.
Malfunctions or other anomalous system behaviour may be an indicator of a security attack or actual security breach and should therefore always be reported as an information security event.
Designing an effective means of the detection of incidents is also essential, using both trained users and trained system administrators, and various technical controls. 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
• 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 developed and implemented. The most fundamental approaches to detecting intrusions are to monitor server logs for signs of unauthorized access, to monitor firewall or router logs for abnormal events, and to monitor network performance for spikes in traffic. Since intruders can alter or destroy local logs, a best practice is to take the precaution of sending logs to a remote log server. This includes a combination of host-level and network-level detections, which when used together provide the most powerful system for detecting problems.
Al 16.1.3 Reporting information security weaknesses
Employees and contractors using the organization’s information systems and services should be required to note and report any observed or suspected information security weaknesses in systems or services.
All employees and contractors should report these matters to the point of contact as quickly as possible in order to prevent information security incidents. The reporting mechanism should be as easy, accessible and available as possible.
Employees and contractors should be advised not to attempt to prove suspected security weaknesses. Testing weaknesses might be interpreted as a potential misuse of the system and could also cause damage to the information system or service and result in legal liability for the individual performing the testing.
Even if an organization installs a network intrusion detection system or other monitoring systems, the resulting alerts can quickly overload personnel. An effective approach is to use analysis tools to help manage intrusion detection systems and summarize the data. Even when log summarization is used, maintaining and monitoring intrusion detection systems can require resources and technical skill that are beyond some organization’ means. A less expensive alternative to developing your own IDS capabilities is to collaborate with other higher education institutions, helping each other deploy intrusion detection systems and even having a single person monitoring all systems, or to contract for the service with your ISP. Two major weaknesses of network IDS are that they cannot detect attacks in encrypted traffic and they cannot determine what is occurring within a targeted compromised host. Host-based intrusion detection systems (HIDS) can address both of these issues and can be used to monitor systems processes, file system changes, and log files for suspicious activities. Many commercial endpoint security offerings now include HIDS functionality, and servers can utilize open source monitoring tools. Communicating security alerts through an interface that system administrators use to monitor the status and performance of their systems increase the likelihood that they will notice problems quickly.
A. 16.1.4 Assessment of and decision on information security events
Information security events should be assessed and it should be decided if they are to be classified as information security incidents.
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.
Identification and prioritization of incident, and performing a timely assessment of the situation
|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)
|Follow up (Improvements)||
A.16.1.5 Response to information security incidents
Information security incidents should be responded to in accordance with the documented procedures.
Information security incidents should be responded to by a nominated point of contact and other relevant persons of the organization or external parties.
The response should include the following:
a) collecting evidence as soon as possible after the occurrence;
b) conducting information security forensics analysis, as required;
c) escalation, as required;
d) ensuring that all involved response activities are properly logged for later analysis;
e) communicating the existence of the information security incident or any relevant details thereof to other internal and external people or organizations with a need-to-know;
f) dealing with information security weakness(es) found to cause or contribute to the incident;
g) once the incident has been successfully dealt with, formally closing and recording it.
Post-incident analysis should take place, as necessary, to identify the source of the incident.
The first goal of incident response is to resume ‘normal security level’ and then initiate the necessary recovery.
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 to 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. 16.1.6 Learning from information security incidents
Knowledge gained from analyzing and resolving information security incidents should be used to reduce the likelihood or impact of future incidents.
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 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. 16.1.7 Collection of evidence
The organization should define and apply procedures for the identification, collection, acquisition and preservation of information, which can serve 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:
a) chain of custody;
b) safety of evidence;
c) safety of personnel;
d) roles and responsibilities of personnel involved;
e) competency of personnel;
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
• Cryptographic hashes of critical files
- Incident Mitigation Resources:
• Media (OS and application software)
• Security patches
• Backup images
If you need assistance or have any doubt and need to ask any question contact me at email@example.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.