SLIDE 1 Mamdoh Alzhrani 0900

Mamdoh Alzhrani
Legal issues associated with incident handling

According to research by the World Travel and Tourism Council (WTTC) (2008), more than 922 million international tourist arrivals occurred in 2008. Consequently, the hotel industry faces real incident risks. These incidents can result in businesses facing legal issues such as privacy and personal data leak issues. Thus, measures and procedures are needed to ensure that information resources are legally secure in order to avoid any legal threats against businesses in the future. Risks can include third parties involved in the industry, such as Cranberry Cloud Company. They must know what to do in the case of a security incident, and what legal implications may arise.

An incident can be defined as any unplanned event that has the potential to significantly affect the well-being of a company, community, image, operations, or network, or which may cause legal or economic liability (Arizona, 2007). Stephenson (2005) identifies incidents as elements of risks, such as threats, vulnerabilities, impacts, countermeasures and communication channels. The results of general threats may be, but are not limited to, “Computer viruses, worms, denial of service attacks, equipment failures, vandalism, theft and other unwelcome events” (Richard, 2003). By knowing what threats may jeopardise a business’s assets, a responsible group or administrator can manage the effects. Such events may also violate laws and regulations, as will be discussed later in this presentation (Dodson, 2001).

The response to an incident can start with managing the event correctly. To do this, Richard (2003) suggests implementing a system that offers a framework for the orderly response to unpredicted events. Therefore, Cranberry Cloud Company should employee the best staff to develop such a system, split the incident phases into smaller pieces, and manage each stage in a proper way to achieve efficiency. In the following slides I will suggest who, when and how an incident should be handled, demonstrating legal implications.


All companies need a computer incident response team (CIRT), especially if the company is an Internet provider to European hotels. This team must contain internal parties. The company should assign the response team (CIRT) responsibility for handling security incidents and developing incident prevention programs (Petersen, 2009). The team should establish trusted connections with third parties so as to stay informed and updated about the latest incidents and how to respond to them properly. The team should manage information gathering, analysis, recovery and administrative functions to ensure a controlled, coordinated response to incidents (Richard, 2003).

It is crucial to state that responding to a security incident is not a technical issue only. Different departments may have to be involved, including executive management, the legal department, legal counsel, public relations, the information security officer (ISO) or manager, human resources, law enforcement, CFO and financial auditor, and external parties such as enforcement agencies, Incident Response and Security Teams (FIRST) and Coordination Centres (CERT) (FIRST, 2009; Budge et al., 2005).

The ISO should be informed of all incidents without delay, and the proposed team should be organised in a way that it uses members’ experience to focus on the nature of each incident. Technical assistance might often be needed; the ISO and the IT department might advise the team on the right action or explain security breaches. Their help in assessing the nature and severity of the incident is required, along with the provision of legal views. It is highly recommended that the legal consultant be present from scratch to paint a clear picture on what legal obligations might arise, Lastly, the legal department, being responsible for compliance with the law and provision of legal advice during the various phases of the incident response, are responsible for informing the team leader and advising him on any legal matters related to the incident and the actions that need to be taken (Himanshu et al., 2009).
Professionals from diverse departments outside the IT department will also have to contribute any response. A clearly-defined, easy to implement and execute management structure is necessary. Figure 1 presents a management schema foran incident response that contains the basic parties (also known as Contacts) that should participate in the company’s incident response plan, along with their main associations and communications. One can see the relationship between the ISO, the corporate investigations group and the legal adviser. They are connected straight to the team leader, who is supposed to be the centre of all communications and contacts, as is obvious in the figure (Mitropoulos et al., 2006).

The ISO is forced to deal with all types of incidents. However, risks can often be reduced using comprehensive risk assessment. Even if these risks are reduced, the company may still face various incidents. Thus, it is vital to know how to handle each incident properly. More precisely, policies and procedures should be known by teams and set prior to any incident occurring. They should also know regulations regarding the best course of action (Grange et al., 2004).

Once procedures, mechanisms and policies are put in place to handle incidents, it becomes necessary to start with standard protection and detection programmes such as intrusion detection systems and firewalls (Dodson, 2001). Grance (2004) argues that incidents fall into one of two categories: the first is indication, which is defined as a sign that an incident that has occurred or which may occur right now; the second is the precursor, which is a sign that an incident may occur in the future. These indications are many and various, as shown in the figure of Anna (2009). Most activities can be caught as future incidents, but not all precursors can! The figure describes malefactors and the goals of an attack (Anna et al., 2009).

The response is what happens after detecting and identifying an incident. Therefore, when an indication shows up in a company’s IDS, firewalls or is noticed by an employee, the incident response process starts and escalates. Most importantly, it preserves any evidence that might be useful in the future for legal reasons or even to be used as evidence in court. Lastly, careful documentation is required to support after action reviews and ease necessary changes in procedures (Dodson, 2001).

This slide introduces the concept in three stages. The first is before an incident occurs, the second during an incident, and third after an incident. The process used to handle incidents is described by Dhar (2003) as comprising 6 phases, ranging from preparing the company for incidents to documenting and reporting what lessons have been learnt from incidents. In the case of Cranberry Cloud Company, there should be records of all previous incidents; as such information can provide guidance for formulating a plan for the company (Research, 2009).

The preparation phase includes preparing for an incident with an incident response policy, which must be supervised be a legal consultant so as to regulate and organise all legal matters that might emerge in later phases, or which might arise during evidence collection and investigations. It also includes system availability, legal prosecution, incident recovery, and deciding who will be on the Incident Response Team, who needs to be notified, and in what manner and how often parties who may be included in the incident team need training and incident response tests (Budge, 2005).

The phase includes preventing incidents through security measures designed to reduce of the number of incidents. The potential benefits of these measures can be critical for the impact they provide in ensuring integrity, availability and confidentiality of the company recourses. Thus, it is essential to emphasise taking these security controls seriously and regularly (Grange et al., 2008). Lastly, Himanshu et al. (2009) list a number of elements that need to be set in the preparation phase, as shown in the slide.


The initial report indicates whether the potential incident comes from the firewall, IDS or virus protection, alerting the responsible employee of a dangerous threat or security breach (Richard, 2003). Consequently, the signs that identify the incident may vary from people to logs.

The critical exposing operation is the assessment process, whereby each indication should ideally be evaluated to determine whether an incident is occurring or not, what the incident source is, whether it is internal or external, and what the legal matters are related to it. If the team believes an incident has occurred then there should be a quick assessment to find out the scope of the incident. The team should respond by documenting every step of the incident (Grange et al., 2008).

Giving a priority to an incident is the most influential decision in the process of handling an incident. An incident should not be handled immediately; instead, it should be based on two factors:
1) The current and future effect
2) The impact on resources
Combining these two elements when prioritising an incident results in an incident being rated correctly as described in Table 1 (Grange et al., 2008).

After deciding on the level of the incident, it becomes necessary to inform responsible people and any other third parties who should be informed about the incident, which is why there should already be a policy stating that clearly.


In the contaminate stage, damages must be limited and stopped. To do this properly there must be a specific strategy detailing how to handle each type of incident. It should consider the potential damage, the need for evidence preservation, service availability, time and recourses needed, and the duration of solutions. The strategy will be helpful if, for example, attackers try to use a company’s systems to attack others, which would result in possible legal action being taken against the company (Kruse et al., 2001).
If evidences are collected for future legal matters after a forensic investigation, the process of taking and preserving these evidences has to be recognized by the law and courts to be used during the legal process. The company must be aware of its legal rights and compliance when data/personal data are being divulged to third parties during a corporate forensic investigation. Standards must be considered so as to preserve privacy, such as the Data Protection Act (1998) and Regulation of Investigatory Powers Act (2000).

These evidences must be handled like all other evidences; in a careful manner in a way that guards evidential integrity, with a chain of custody and comprehensive documentation of all activities that have been carried out whilst handling the incident must be ready for use during any further procedures if legal action is to taken (Himanshu et al., 2009) (Taylor et al., 2007). Thus, it is necessary to have the opinions of legal experts/department (Kruse et al., 2001). Legal implications, however, might emerge from privacy leaks when handling an incident. For instance:
* Could data concerning customers in hotels have been leaked?
* Could customer credit card data have been involved?
* Could financial records have been tampered with?

In the eradication phase, the company should eliminate the threat from the network entirely using forensic analysis and identifying the vulnerability that caused the incident in the first place (Research, 2009; Jones, 2003). In some cases, third parties such as Visa, American Express, MasterCard, and Discovery, or law enforcement agencies such as the FBI and Police, require notification of the incident with the incident details (Moldes, 2009).

In the recovery phase, the system should be back in use and all services should be restored by installing and any backdoors, trojans and hacking tools should be removed. The last task to do is to patch and update all software that the company runs. There has to be a monitoring process to highlight any abnormal behaviour and report it to help teams and the IT department (Dhar, 2003).

There should always be a follow-up meeting to consider the incident and make suggestions to improve the incident handling plan. The first action to take in this phase is to gather all data obtained from the incident and document it in a draft for all participants to see. After this, meetings with representatives from all departments should take place to discuss areas that worked well and others which may not have (Dodson, 2001). The next step is to encourage and recommend changes to policies, procedures and plans for handling incidents. Finally, any updates should be implemented after management approval so as to keep the company secure and safe (Hong, 2007).

Incident handling has a clear framework to manage potential incidents; this structure may change if the company plans to go to court, or the law requires legal prosecution for any matter. Different approaches are needed to sustain and evaluate various legal issues related to the incident occurrence (Arizona, 2007). The company will have to focus on essentials first and worry about perfections later. There has to be a monitoring process to log details and other alerts. Staff also have to be trained and the company should promote their awareness of how to handle incidents (Baker et al., 2009).
It is highly important to include a legal adviser/attorney at all stages, starting from the preparation phase. The team/company should keep the “need to know” concept in mind when dealing with both internal and external parties (Washington, 2005; Abimbola, 2007). Whilst handling an incident, data might be exposed to certain third parties, such as enforcement agencies, forensic investigation teams and others. The data must remain confidential in such circumstances and there should be compliance with the Data Protection Act 1998, Regulation Investigatory Powers 2000, Copyrights, Designs and Patents Act 1988, and Telecommunications, Interception of Communications Regulations 2000 (LBPR) (Abimbola, 2007). There should also be other measures taken to protect users’/company information and resources.
Other legal issues may need extra care to avoid legal action being taken against the company in case an incident is taken to court. All evidences and investigation processes have to comply with the acts shown in the slide, and the company must protect the integrity of the evidence, as this is a serious legal matter. Lastly, personal data might become the source of legal threat to the company if it is captured by an intruder. Thus, the team must prepare policies and procedures to handle such a situation (Abimbola, 2007).

Göteborg University had a security breach in 2005 that could result in serious legal issues. The university has 51,000 students and a $600 million revenue. It has a central IT department and the breach hit an IT supporting unit containing 4 persons and 400 users, with 250 PC-clients plus 150 thin-client users. All servers compromised in a single Windows domain. The incident response team reacted quickly but with an incorrect assessment.

The logs were reviewed and an incident was declared, notifying the CIO and the affected unit. The IT support though the service was secured and restored, but it was not. The incident team discovered that the IT support did not fix the service perfectly and the damages escalated more than had been assessed previously. The CIO asked for a shutdown and disconnection of the entire compromised domain, and then a rebuilding of the domain.

The losses amounted to more than $590,000. In addition, the credibility and reputation of the university were seriously affected. After the incident many lessons were learned, such as the need to involve different departments and representatives when deciding on incidents, and training staff and educating them on how to act properly according to procedures and policies. Most importantly, the need to be prepared for incidents was realized. The university also discovered that unnecessary privileges being distributed can or may cause breaches (Hong, 2007).

The final part is the response plan. As the saying in the real estate industry goes, its all about ‘location, location, location’. In this case its all about ‘plan, plan, plan’. A plan has to be made together with a team of legal advisers at all times. Thank you for listening and I hope you enjoyed the presentation.

ABIMBOLA, A., (2007), Information Security Incident Response. Network Security, 2007 (12), pp.10-13.
ANNA, K.; M. NATALIA and T. ALEXANDER, (2009), Information Security Incident Management Process. IN: Proceedings of the 2nd international conference on Security of information and networks, Famagusta, North Cyprus. ACM.
ARIZONA, U.N., (2007), Incident Management Plan. In: UNIVERSITY, N.A., ed. Arizona
BUDGE, C. and N.V. DADELSZEN, (2005), Incident Handling :Considerations in Approach [online]. [Accessed 29 Dec 2009]. Available from World Wide Web:
DHAR, S., (2003), Compromise Recovery and Incident Handling. Data Security Management, 26 (5), pp.1-9.
DODSON, R., (2001), Information Incident Management. Information Security Technical Report, 6 (3), pp.45-53.
FIRST, (2009), Forum for Incident Response and Security Teams [online]. [Accessed 1 Jan 2010]. Available from World Wide Web:
GRANCE, T.; K. KENT and B. KIM, (2008), Computer Security Incident Handling Guide. In: COMMERCE, U.S.D.O., ed. 1 ed. WASHINGTON: U.S. GOVERNMENT PRINTING OFFICE.
H.BAKER, W.; C.D. HYLENDER and J.A. VALENTINE, (2009) 2008 Data Breach Investigations Report : A Study Conducted by the Verizon Business Risk Team.
HIMANSHU, K.; B. JIM; B. MEHEDI; F. MIKE; W. VON and B. RANDY, (2009), Palantir: A Framework for Collaborative Incident Response and Investigation. IN: Proceedings of the 8th Symposium on Identity and Trust on the Internet, Gaithersburg, Maryland. ACM.
HONG, S. (2007), Security Incident Handling [online]. [Accessed 5 Jan 2009]. Available from World Wide Web:
JONES, G., (2003), Computer Security Incident Handling Forms [online]. [Accessed 9 Jan 2010]. Available from World Wide Web:
KRUSE, W.G. and J.G. HEISER, (2001), Computer Forensics: Incident Response Essentials. Addison-Wesley.
MITROPOULOS, S.; D. PATSOS and C. DOULIGERIS, (2006), On Incident Handling and Response: A State-of-the-Art Approach. Computers & Security, 25 (5), pp.351-370.
MOLDES, C.J., (2009), Pci Dss and Incident Handling What Is Required before, During and after an Incident [online]. [Accessed 7 Jan 2009]. Available from World Wide Web:
PETERSEN, R., (2009), Incident Handling and Forensics [online]. [Accessed 1 Jan 2010]. Available from World Wide Web:
RESEARCH, P., (2008), Airline, Hotel & Travel Industry Overview [online]. [Accessed 1Jan 2010]. Available from World Wide Web:
RESEARCH, S.W., (2009), Managed Security Services and the Incident Handling Process [online]. [Accessed 5 Jan 2010]. Available from World Wide Web:
RICHARD, L.R.-R., (2003), Incident Handling: An Orderly Response to Unexpected Events. IN: Proceedings of the 31st annual ACM SIGUCCS conference on User services, San Antonio, TX, USA. ACM.
STEPHENSON, P., (2005), Managing an Incident. Computer Fraud & Security, 2005 (1), pp.17-19.
TAYLOR, M.; J. HAGGERTY and D. GRESTY, (2007), The Legal Aspects of Corporate Computer Forensic Investigations. Computer Law & Security Report, 23 (6), pp.562-566.
WASHINGTON, S., (2005), Preparing for a Transportation Security Incident: Organizing the Legal Response Team [online]. [Accessed 12 Jan 2010]. Available from World Wide Web:

09001603, Mamdoh Alzhrani – Legal Issues associated with Incident handling- IS4S04 CW2

Glamorgan University 2010 Cranberry Cloud Presentation