Comparative Analysis Of Existing Models

Published Date: 02 Nov 2017

The different models are analysed and compared based on their different activities carried out within each phase. This is shown in the table below.

Incident Handling Models

Features

CERT/CC

NIST

SANS Institute

ENISA

ISO

Preparing the organisation before an incident is detected

Conduct risk assessment or management

Creation of policies

Review and Evaluation of policies

Cyclic improvements are introduced to the process

Collecting and analysing comprehensive information about the incident

Conducting analysis on the impact of the incident on the organisation

Disaster Recovery and Business Continuity

Prioritisation and categorisation of the incident so that resources can be assigned to handle it.

Comparison is made between incidents to identify any dependencies

Various sources of information is used on the incident

Compliance with other standards – e.g ISO

Establishing external contacts (CERTs, law enforcement) for the purpose of acquiring information about the incident

Provision of legal components

Table : Comparison Matrix

From the table, it can be found that CERT/CC, NIST, SANS and ISO models put emphasis on the need to prepare the organisation before a security incident is detected. It can also be found that during the incident handling process, cyclic improvements are introduced in CERT/CC, NIST, ENISA and ISO models. To resolve any incident, it is very important to gather full details about it and not all models focus on the comprehensive gathering and analysis of information about the incident.

Analysing the impact of the incident on the organisation is significant to determine the actions to be taken to contain and prevent it from causing more damages. However, this aspect is only included in CERT/CC and NIST incident handling models. Prioritisation and categorisation of incidents are essential for the proper allocation of resources to handle the incident. Nevertheless, only CERT/CC, NIST and ENISA models put emphasis on these aspects. Comparisons between incidents are carried out to identify if there is any dependencies. This step is important as it enable incident handlers to refer to other incidents and know if there is any relation between the newly detected incident and previous ones. The table indicates that this component is present in two models – CERT/CC and ENISA.

As further analysis, a case study based on a security incident will be used to evaluate each phase of the models. This will help to show how the incident is treated at each phase and determine the effectiveness of the models. In this way, the strengths and weaknesses of each model will also be identified.

Application of the Incident Handling Models in Real Case Scenario

Incident Type: Phishing (Case Study 1)

CERT/CC Model

Phase 1: Prepare

In this stage, the organisation prepares itself in advance in case there is any security breach that can affect the confidentiality, integrity and availability of its business operations. This phase involves the measures taken by the bank to respond to an incident. From the case study, it can be found that the bank has a corporate security department in place and has personnel such as Information Security Analysts.

Phase 2: Detect

A customer of the bank reported the incident to the bank. She became suspicious after receiving in an email which seemed to originate from the bank. The customer became alerted due to grammatical mistakes found in the email.

Phase 3: Triage

In this phase, the CSIRT is assembled and the incident is categorised. Many customers of the bank were already targeted; therefore, the severity is high because there has been unauthorised access to confidential information. It is therefore a priority for the bank to respond to the incident as fast as possible to prevent more damages.

Phase 4: Respond

The CSIRT verifies whether the evidence used in the previous process is correct. The content of the email is analysed. The email contains a link, which upon clicking on, will redirect users to another website where they are asked to enter personal details such as PIN number, email address. The URL to which the website points to is also analysed. Screen shots are also be taken for reference. The damages caused by the incident are also noted. Since many customers already submitted their personal information to the phishers, the bank can now verify whether there has been monetary loss. The CSIRT can also trace the IP address of the website and this will enable them to know where the phishing website is hosted. These details will allow the CSIRT to take further actions to reduce the impact of the incident and resolve it.

To contain the incident and reduce its impact, customers are informed about the attack to prevent them from submitting information. In the meantime, necessary actions are taken to shut down the website. The bank can contact the website owners, if any. If the owners do not respond, the bank can contact the Web hosting company or ISPs and then contact the domain name registrar which is directing the IRL to a given IP address. The bank can also escalate the incident to the local Computer Emergency Response Team (CERT) for further actions. Follow up must be done to ensure that the incident is resolved.

Top management and other personnel of the bank are notified after the phishing website has been shut down. The incident is then documented and a report is submitted to management.

Phase 5: Protect

Necessary measures are taken to improve the organisation’s defenses against such types of attacks. Since phishing attacks on financial institutions are common, it is important for the bank to educate its customers and make them aware of such attacks so that they do not get victimised. For example, warnings about phishing attacks can be put on the website of the bank. Customers must be able to differentiate between a genuine and fake website. When customers apply for online banking, the bank can issue guidelines about make transactions safely and what are the symptoms of phishing attacks.

NIST Incident Handling Model

Phase 1: Preparation

This phase involves the measures taken by the bank to respond to an incident. From the case study, it can be found that the bank has a corporate security department in place and has personnel such as Information Security Analysts. This indicates that the preparation process had already started in the bank in case of a security incident.

Phase 2: Detection and Analysis

Detection

A customer of the bank reported the incident to the bank. She became suspicious after receiving in an email which seemed to originate from the bank. The customer became alerted due to grammatical mistakes found in the email. Since user provided indicators such as complaints are sometimes incorrect, the report received from the customer is evaluated to verify its authenticity. After the verification of the email by the bank, a phishing attack was detected.

Analysis

An initial analysis is performed to determine how the incident occurred, where it is originated and what are the damages caused. When the content of the email is analysed, it is found that the customers are requested to submit their personal information such as debit card number, card expiration date, PIN and e-mail address. In this case, the bank can submit some fake information to see which website and what message a user receives after submission. Screen shots can also be taken for reference. The CSIRT can trace the IP address of the website and to know where the phishing website is hosted. These details allow the bank to take further actions to reduce the impact of the incident and resolve it.

Since many customers already submitted their personal information to the phishers, the bank can now verify the number of customers who have been targeted. The bank accounts of these customers can be checked to know if there is monetary loss. The bank can also watches out for any unusual activity on the bank accounts of the victims. The information about the incident can be recorded such as the status, description, actions taken and impacts.

After gathering the information, the incident is prioritised in terms of its functional impact, information impact and recoverability from the incident. This is shown in the table below:

Impact

Category

Comments

Functional Impact

Low

The phishing incident has not affected the functions of the bank because it can still operate.

Information Impact

High

The confidentiality, integrity and availability of the customer’s information have been compromised. The phishers has gained access to customer’s sensitive information. As a result, it may lead to financial loss.

Recoverability from the incident

Low

Since confidentiality of information has been compromised, the bank should take actions to ensure that similar incident does not occur in the future.

Involved parties are notified and status updates are provided by the CSIRT. Since this incident involves external parties, communication methods such as website, email, and media to inform about the incident.

Phase 3: Containment, Eradication, and Recovery

Containment

In this situation, to prevent the incident from causing more damages, customers of the bank are notified about the phishing attack so that they do not submit any information. The incident is also communicated to the media.

During incident handling, it is important to identify the attacking host. The CSIRT confirms that the address was not spoofed by verifying connectivity to it. If there is no response, it does not mean that the address is not real. The team can also make use of search engines by to gather more information about the IP address. Continuous monitoring is carried out.

At this point, it is important to collect and document all evidence about the incident since it may be needed for legal proceedings. For the incident, the following details are kept:

The email

Screenshots of the phishing website

IP address of the website and hosting country

Attacking host

Time and date of each event

Location where the evidence is stored

Eradication

After the incident has been contained, eradication is necessary to eliminate components of the incident. At this point, necessary actions are taken to shut down the phishing website. Concerned authorities such as the national CERT are contacted to block access to the phishing website. This will restrict complete access to the fake website. Follow up is carried out with the CERT to ensure that the phishing website is blocked at the earliest.

Recovery

At this point, the phishing website is shut down. In this phase, online banking operations of the bank are returned back to normal. Usually, when phishing sites are blocked, phishers create other fake websites and conduct the attack again. Hence, monitoring is increased by the CSIRT to ensure that the attack does not happen again. The recovery phase also involves measures that the bank can take to prevent such type of attacks. Examples include customer education. This will help users to be on guard and recognise these types of attacks when they occur. Another action can be to introduce additional authentication layer at the original website in addition to the normal procedure.

Phase 4: Post Incident Activity

After the incident is resolved, a "lessons learned" meeting is held with involved parties. In the meeting, the following issues are discussed:

Details of the incident – what happened, time the incident occurred, its occurrences, damages caused.

The actions taken by management and technical people to deal with the incident.

The procedures that were followed to resolve the incident.

Information collected during incident handling.

Challenges and difficulties in handling the incident.

Corrective actions to prevent similar incidents from occurring again.

Precursors or indicators required to monitor to detect such type of incident.

Resources or tools required to detect, analyse and alleviate similar incidents in the future.

Holding a meeting after an incident has been resolved is beneficial in terms of identifying improvements for security measures. Updating incident policies and procedures is another important aspect of the post incident activity. Finally, a report is created on the incident, which can be used as a reference in the future.

SANS Institute Model

Phase 1: Preparation

This phase enables the bank to make the required resources and tools available whenever a security incident occurs. The amount of preparation done beforehand determines the success of handling an incident. This phase consists of other sub phases:

Selection of incident handling team members

A CSIRT is formed to handle security incidents at the level of the organisation. The purpose of the CSIRT will be to react in a timely manner in case of any security breach. From the case study, it can be found that the CSIRT consists of executives, business unit managers, attorneys and technical people.

Management support for the incident handling capability is developed

When the organisation experiences a security incident, it is very important to have management support. This is because during incident handling, there are decisions that need to be taken and they require consultation and agreement of management. For example, if the CSIRT needs external support such as law enforcement agencies, it is important to have the consent of top management.

An emergency communication plan

An emergency communication plan allows the bank to establish suitable means of communication with other internal groups and external groups. This enables the organisation to communicate the incident to customers and advise them accordingly.

Easy reporting facilities are provided

From the case study, it can be found that the bank has a call center which is responsible for attending customers’ requests and queries. The call center acts as the intermediary between customers and the bank. The phishing incident was reported to the call center by a customer of the bank.

Phase 2: Identification

A customer of the bank reported the incident to the bank. She became suspicious after receiving in an email which seemed to originate from the bank. The customer became alerted due to grammatical mistakes found in the email. The customer forwarded the email to the call center, which was sent to the bank for verification. In this way, a phishing attack targeting the bank was identified. SANS Institute argues that this phase is significant because it is at this point that the incident response team decides whether this event is critical enough to be classified as an incident. Since many customers had already submitted their personal information to the phishers, the confidentiality, integrity and availability of customer’s data has already been compromised. All facts about the incident are gathered.

Phase 3: Containment

The purpose of this phase is to reduce the harm done by the incident and prevent it from causing more damages. The incident is communicated to the customers to make them aware of the attack targeting the bank. In this way, customers will be cautious and will know that the email does not come from the bank and will not submit any personal information.

Phase 4: Eradication

At this point, the CSIRT ensures that the incident is resolved. To eliminate the phishing attempt, the fake website is blocked to prevent any submission of information. For this purpose, the assistance of external groups such as ISP, website administrator or CERT are required. This depends on the location that the fake website is hosted.

Phase 5: Recovery

After the eradication phase, this process aims at restoring the normal operations of the bank. Often, when the phishing site has been blocked, phishers can create other fake websites and conduct the attack again. Hence, the incident response team must increase their monitoring to ensure that the attack does not happen again.

Phase 6: Follow up

At this point, a meeting with the management is held to discuss about the incident. A report about the incident is made. The report indicates the progress of detecting and reacting to the incident. The meeting can also help in improving the security measures to minimise such types of attacks. Actions that be taken at the level of the bank include customer education, creating awareness on phishing attacks, increasing the security level with regards to online banking.

ENISA Model

Phase 1: Incident Report

The incident is reported by a customer of the bank who became suspicious over an email received on behalf of the bank. She found the email doubtful as there were plenty of grammatical mistakes in it. The incident was reported via to the call center of the bank. Afterwards, many customers started calling and enquiring about the email. The customer forwarded the email to the call center, which was then sent to the bank.

Phase 2: Registration

In this stage, the CSIRT registers the report of the incident in the incident handling system. The purpose of the registration process is to start recording initial details about the incident. Examples include reporting time of incident, date, name of reporting party and symptoms of incident.

Phase 3: Triage

In this stage, the priority of the incident is decided based on the severity of the incident. This phase consists of three sub-phases - verification, initial classification and assignment.

Verification

In this process, the bank verifies whether the event is a security incident. The contents of the email are analysed and it was found that customers were required to provide sensitive information such as debit card, card expiration date, PIN and email address. Since the email was sent on behalf of the bank and customers were targeted, it indicated a phishing attack.

Initial classification

Initial classification refers to the severity of the incident. In this case, it consists of a phishing attack against a financial institution and since many customers have already submitted their personal information, CIA has been compromised. Hence, the severity of the incident is very high.

Group

Severity

Status

Red

Very High

New

At this stage, the attack is spreading rapidly because many customers still do not know they have been targeted.

Assignment

In this process, the CSIRT is gathered to handle the incident.

Phase 4: Incident Resolution

This stage leads to the resolution of the incident. The process consists of several sub processes and they are:

Data Analysis

In this process, data is collected from the reporting party (the customer). In this case, the CSIRT gathers evidence about the attack, which includes:

Source of the attack

Medium used to conduct the attack

Severity of the incident

Group

Severity

Status

Red

Very High

In progress

Date and time

Information requested by attackers

The hosting location of the fake website

IP address

After gathering all the information, the CSIRT has a better idea of how the incident can be resolved.

Resolution Research

During this phase, observations and ideas about the attack are exchanged among the team. The information gathered from the previous process will allow the CSIRT to discuss and decide on actions plan that can be used to resolve the incident.

Actions proposed

The CSIRT suggests measures that should be taken to prevent the incident from causing more damages. In this case, the actions that can be taken are:

Notifying customers

The first action is to inform customers about the phishing attack. Customer notification is important to avoid any further damages. This is because when customers will know that there is a phishing attack on the bank, they will become more cautious and will not submit further information.

Shut-down of phishing website

The CSIRT must take the necessary actions to shut-down the phishing link. The team can take the help of law enforcement agencies, ISPs or CERTs to bring down the phishing website. Once access to the phishing website has been blocked, customers will not be able to submit any information.

Eradication and Recovery

Shutting-down of the fake website leads to the eradication of the incident. After the elimination of the incident, it is very important for the bank to return back to its normal operations. A phishing attack on a financial institution where its customers have been targeted can have a negative impact on the operations of the organisation. Customers do not understand these types of attacks and often blame the financial institution. As a result, this can tarnish the image of the bank. The recovery process aims at restoring the operations back to the normal. This can be achieved by informing customers that the incident has been resolved.

Phase 5: Incident Closure

The resolution of the incident leads to its closure. The following sub-processes form part of the incident closure phase:

Final Information

The management can issue a communique to inform customers and the stakeholders that the incident has been resolved. During this process, information about the incident such as the description, results and findings are provided. Recommendations are also given to make customers cautious about such type of attacks in the future.

Classification of the Incident

ENISA argues that classification is done at three stages throughout the incident handling process – beginning, during the resolution period and at the end. The classification of the incident at this point is:

Group

Severity

Status

Green

Low

Resolved

Archiving

This is the step which leads to the end of the incident closure phase. At this stage, all information and evidence about the incident is archived. This is important because certain incidents can act as reference in the future. The CSIRT can then refer to the whole incident handling process. Encryption and back up can be used to protect the data stored.

Phase 6: Post Analysis

During this process, the incident can be further analysed. Team members also interchange information between them and engage in a self-learning session. This phase is divided into such as proposals for improvement and incident taxonomy. As improvement, the bank can invest into customer education and introduce additional authentication or multi-factor authentication. This can be helpful to avoid or reduce the impact of such attacks in the future. Incident taxonomy is an effective method that can help the bank to develop awareness services. This involves having the latest statistics, observing incident trends and categorizing incidents. This can help the bank to be proactive.

International Standard Organisation (ISO) Model

Phase 1: Prepare

According to ISO, in this phase, policies such as incident management and the establishment of a team are created to deal with security incidents. In line with the recommendations of ISO, it can be found that the bank has a corporate security department in place and has qualified staffs such as Information Security Analysts to deal with incidents. In addition, the existence of a call center shows that there is a channel through which customers can report incidents.

Phase 2: Identify

This phase starts with the identification of the incident which was reported by a customer of the bank. The customer of the bank received an email which seems to originate from the bank. In the email, the customer is requested to submit some information such as debit card number, card expiration date, PIN and e-mail address. In addition, there were a lot of grammatical mistakes in the email. This raised suspicions in the mind of the customer and the latter reported it to the call center of the bank. The customer forwarded the email to the bank for verification. In this way, a phishing attack targeting the bank was identified.

Phase 3: Assess

The purpose of this phase is to assess the incident and allow the CSIRT to make decisions about how the incident can be addressed. During the assessment of the incident the following information are collected:

The medium used to conduct the attack (email)

IP address of the fake website and the hosting location.

Attacking host.

Screenshots of the phishing website.

Time and date of each event during the handling of the incident.

Name of the incident handlers.

Location where the evidence is stored.

The collected information allows the incident handlers to respond to the incident in a more effective way.

Phase 4: Respond

In this process, the incident is contained to prevent it from causing more damages to the bank. Since in this scenario, the customers of the bank are targeted, they are informed about the attack. This will make them cautious about the email and will prevent them from submitting information to the phishers. By taking this measure, the CSIRT prevents the incident from causing more damages.

Secondly, to resolve the incident the phishing website must be blocked. The information gathered at the previous phase helps the incident response team to take the necessary actions to shut down the fake website. For this purpose, the assistance of external groups such as ISP, website administrator or CERT can be required.

Phase 5: Learn

In the last phase of this model, the CSIRT learns lessons from the incident. This process serves as a learning point where incidents are kept as reference in case such type of incident produces again in the future. Reports about the incident are created where all the processes from detection to responding the incidents are listed. At this point, meetings are held with management to discuss about the incident. The aim of the meeting is to find ways to improve on security measures and in the way incidents are handled in the organisation. In this case, the management of the bank can improve on how customers can be better informed about such type of attacks. Phishing attacks on financial institutions are becoming more common and frequent. The bank can be targeted in the future. Hence, the bank can conduct customer awareness and increase the level of security of its online banking.

Strengths and Weaknesses of the Existing Incident Handling Models

The application of the incident handling models to solve the incident helped in identifying the strengths and weaknesses of each model. This is shown in the figure below:

MODELS

STRENGHTS

WEAKNESSES

CERT/CC

The model provides a complete guidance of dealing with security incidents.

The model puts emphasis not only on prioritising and categorising the incident, but also on improving security measures after the resolution of the incident.

Incident handling capability is separate and distinct from the operational units. In small organisations, this would not be a problem. But, it may be difficult for the team to integrate and coordinate across a large organisation

NIST

There is comprehensive gathering of information in the analysis, Containment, Eradication and Recovery stages. For example:

There is incident prioritisation based on functional and information impact and the recoverability of the incident.

Emphasis is also laid on notification of concerned parties in the middle of the incident handling process.

The model also focuses on evidence gathering and handling in case there is any prosecution.

The NIST model sets higher requirements for proper planning and technical skills. This model requires resources and therefore might not be appropriate for small enterprises.

SANS

This model put emphasis on eradicating the incident rapidly. Thus, restoring normal business operations is possible in a short time.

The model provides a generic approach for handling incidents that can be easily adopted by organisations such as SMEs.

The incident is handled separately and without prioritisation. Complete information about the incident is not gathered and analysed.

The model also fails to analyse the impact of the incident on the organisation.

ENISA

This model offers a clear picture of the incident management process. There are other factors that form part of the incident handling process, which are excluded in other models. Examples include:

Classification of the incident is done at three stages – beginning, resolution research and at the end.

Incident taxonomy – in the post analysis process provides a methodology for the organisation to observe trends about incidents and statistics.

The model is more guided towards institutions that operate a CSIRT or CERT to protect their own IT infrastructures or of their stakeholders.

The model does not have any preparation phase before an incident is detected or reported.

ISO

The ISO model presents a systematic approach to detect and react to the incident. Other strength of the model is that it is compliant with other ISO standards.

The ISO is the most generic incident handling model as compared to other models. It does not provide any extra factor that might contribute to solve an incident more effectively.