Integrating digital forensic practices in cloud incident handling
A conceptual Cloud Incident Handling Model
Nurul Hidayah Ab Rahmana,b; Kim-Kwang Raymond Chooa a Information Assurance Research Group, School of Information Technology and Mathematical Sciences, University of South Australia, Adelaide, Australia
b Information Security Department, Faculty of Computer Science and Information Technology, University of Tun Hussein Onn Malaysia, Batu Pahat, Johor, Malaysia
Abstract
Due to the increase in adoption of cloud storage services by organizations, ensuring the security and privacy of data stored in the cloud is of critical importance to these organizations. It is also important for organizations to have an effective cloud security incident handling strategy to minimize the impact of a security breach. In this chapter, we present a feasibility study of our proposed Cloud Incident Handling Model, which draws upon principles and practices from both incident handling and digital forensics. We demonstrated the utility of the proposed model using an ownCloud case study simulation. We also explained how the Situational Crime Prevention Theory can be used in our model to design mitigation strategies. Future work includes deploying the model in a real-world organization.
1 Introduction
The trend of organizations moving sensitive data to the cloud infrastructure has resulted in an urgent need to ensure that security and privacy safeguards are in place, as cloud services are potential criminal targets due to the amount of sensitive organization data stored in the cloud. A successful security incident occurrence or breach can cause direct (e.g., theft of intellectual property and customer data) and/or indirect losses (e.g., reputational and legal) (Böhme, 2010; Tsalis et al., 2013) to organization assets, and can have significant financial implications.
A proactive incident handling strategy is one key approach to mitigate risks to the confidentiality, integrity and availability of assets, as well as minimizing loss (e.g., financial, reputational, and legal) in a dynamic cloud environment. This is consistent with the Cloud Security Alliance (CSA) report entitled “Security Guidance for Critical Areas of Focus in Cloud Computing,” which highlights three critical focus areas, namely, incident response, notification, and remediation (Cloud Security Alliance, 2011). The National Institute and Standards Technology (NIST) defines incident handling as a lifecycle consisting of four phases as follows: (1) preparation; (2) detection and analysis; (3) containment, eradication, and recovery; and (4) postincident activity (Cichonski and Scarfone, 2012).
In investigating and responding to computer security incident, digital forensics can play a crucial role (Cichonski and Scarfone, 2012; Freiling and Schwittay, 2007; Gurkok, 2013). The collection, analysis, and interpretation of digital data associated with a computer security incident during an incident handling process, for example, overlap with the collection, analysis, and presentation of evidential data in a digital forensic process (Freiling and Schwittay, 2007). In addition, ensuring that a system is in a state of forensic readiness (i.e., capable of determining in advance what evidence is required when an incident occurs, Pangalos et al., 2010) will expedite incident handling as the incident responder would know where evidential data exists and how to go about collecting the required data. Forensic readiness also aligns with the proactive element of incident handling in the Preparation phase.
In this chapter, we propose a Cloud Incident Handling Model that integrates digital forensic practices into incident handling strategies, which would allow cloud service providers (CSPs) and organization cloud service users (CSUs) to respond to incidents more effectively. We then demonstrate the utility of the model using an ownCloud (an open-source private Storage as a Service solution) simulation (similar to the approach of Monfared and Jaatun, 2012).
In the following section, we will outline the background which includes challenges of incident handling in the cloud computing environment, as well as related work. We then present our proposed model in Section 3, before describing our case study in Section 4. The last section concludes this chapter.
2 Background
2.1 Cloud computing infrastructure
In cloud computing, there are four deployment models (i.e., private cloud, public cloud, community cloud, and hybrid cloud) and three architectures (i.e., Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS)) (Mell and Grance, 2011).
Buyya et al. (2013) explained that the underlying cloud computing infrastructure consists of several cloud stacks (see Figure 1). The lowest stack or system infrastructure, Cloud Resources, consists of hundreds to thousands of nodes to form a datacentre. Virtualization technology is deployed in the core middleware to create the distributed infrastructure, and the Cloud Hosting Platform supports main functions of infrastructure management such as usage metering, billing, and accounting. IaaS is formed from the underlying system infrastructure and core middleware. In user-level middleware, cloud service is offered as a development platform, referred to PaaS, and CSU develops applications to run on the core middleware infrastructure. The top stack represents user applications, or referred to SaaS, that deliver cloud applications to CSU.
One of the key differences between cloud and “traditional” (or in-house) infrastructure is the scope of user control as the roles and responsibility over cloud resources are segregated between the CSP and CSU (Pearson, 2013; Jansen and Grance, 2011). In Figure 1, we adopted the cloud stack architecture from Buyya et al. (2013) and the scope of control from Jansen and Grance (2011) to explain the control scope between the CSP and CSU, for each stack of the cloud architecture.
The range of scope and control over the stack of resources is represented by the arrows. The CSU will have more control over the resources as the stack gets lower. For example, the CSU will have less control over the resources in SaaS but more control in IaaS; and conversely the CSP will have more control in SaaS but less control in IaaS. The control over resources determines the scope of the capability of the entity (CSU or CSP) to implement and manage security mechanisms. In PaaS, for example, the CSU is responsible for their application security protection (e.g., secure coding, and encryption) while the CSP is responsible for hypervisor protection (e.g., hypervisor vulnerability management). The shared responsibility of security control implementation and management needs to be taken into consideration in planning cloud incident handling strategies.
2.2 Incident handling in cloud computing
A notable challenge between traditional incident response and cloud incident response is that different cloud architectures require different strategies. As highlighted in the report by CSA (Cloud Security Alliance, 2011), the identification control scope on cloud architecture can facilitate a mapping of roles and responsibilities of incident handling for both CSP and CSU.
As CSP has more control of cloud stacks in SaaS, CSU relies on the CSP to provide proactive mechanisms such as log and monitoring, vulnerability scanning, patch management, forensic readiness plan, and incident detection/prevention tool. As pointed out by Grobauer and Schreck (2010), CSU, particularly small-to-medium sized organizations, may have limited knowledge of the underlying infrastructure, thus it is not likely for them to conduct forensic analysis in-house. The European Network and Information Security Agency (Dekker et al., 2013) recommended that “to allow for a level playing field and a competitive single digital market it is important to harmonize the implementation of incident reporting legislation whenever possible,” particularly in cloud cross-border scenario. A standard or guidelines that include incident reporting format, terminology, knowledge-base, can facilitate the incident responder to obtain accurate event information. SaaS users (due to lack of control over resources) need to study the CSP’s policy in details and ensure that it complies with industry standards (e.g., ISO/IEC 27035:2011 Information Technology—Security techniques—Information security incident management).
In PaaS, the CSU is primarily responsible for implementing security controls and forensic readiness plan for user applications and at user-level middleware stack, while CSP is responsible for protection at the lower stack. During incident detection and analysis, identifying the affected stack and resources will help determine the scale of incident handling involvement between CSP and CSU. For instance, an attack targeting cloud resources stack (e.g., flooding attack) requires significant involvement from the CSP. Although the CSU has more control at user-level middleware stack and, most probably, can conduct client-side forensics (Zimmerman and Glavach, 2011), assistance from CSP, for example, to acquire the relevant log files from the server, is still required. For example, Amazon CloudWatch, a cloud application that can be deployed by the CSU to collect and track metrics, collect and monitor log files, and set event alarms (Amazon Web Services, 2014), but it would have added cost for the CSU.
IaaS most closely resembles the “traditional” in-house computing infrastructure. Generally, CSU can undertake forensic examination at their end using existing procedures and best practices such as those described in Martini and Choo (2014) and Quick et al. (2014). A virtual machine (VM) snapshot, for example, can serve as an acquisition image (Grobauer and Schreck, 2010; Zimmerman and Glavach, 2011). CSP incident handling responsibilities such as vulnerability and patch management rely on the system infrastructure stack.
When formulating incident handling strategy, one also needs to take into consideration the cloud deployment model. In a public cloud model, for instance, undertaking incident response and forensic examination will be most challenging due to geographical constraints.
2.3 Related work
Other studies focus on specific incident handling theme(s) such as incident detection and prevention (Modi et al., 2013; Patel et al., 2013; Khorshed et al., 2012), monitoring and vulnerability management (Kozlovszky et al., 2013; Monfared and Jaatun, 2011), and risk management (Aleem and Sprott, 2013; Albakri et al., 2014). Only a few studies, however, discuss cloud incident handling from a technical perspective. Grobauer and Schreck (Grobauer and Schreck, 2010) pointed out various cloud-specific challenges and suggested suitable approaches from both CSP and CSU perspectives. Monfared and Jaatun (2012) demonstrated that NIST incident handling guidelines can be adapted for cloud incident handling, in their case study. In the latter, the authors simulated an OpenStack environment (IaaS) and introduce cloud-specific strategies. Both studies (Pangalos et al., 2010; Monfared and Jaatun, 2012) adapt existing incident handling phases by introducing cloud-specific strategies in each phase.
In the automated cloud incident management system of Gupta et al. (2009), multi-dimensional knowledge is the key component while the system of Sarkar et al. (2011) designed for a PaaS environment used a finite state-based machine to deliver an integrated monitoring and event correlation system.
Cloud forensics research has received considerable attention in recent years (Quick et al., 2014; Ruan et al., 2011; Quick and Choo, 2013; Birk and Wegener, 2011; Martini and Choo, 2012), and a small number of studies have highlighted the need to integrate incident handling and digital forensics due to overlapping tools and processes (Freiling and Schwittay, 2007; Mell and Grance, 2011; Buyya et al., 2013). Although there have been attempts to integrate both incident response and digital forensics (Kohn et al., 2013; Mitropoulos et al., 2006; Pilli et al., 2010), there has been no published cloud incident handling strategy that integrates digital forensics practices. This is the gap we attempt to fill in this chapter. We also explained how the Situational Crime Prevention Theory (Clarke, 1997) can be used in our model to design mitigation strategies.
3 Cloud incident handling model: a snapshot
In our design of the proposed model (see Figure 2), we draw upon principles and practices from incident handling and digital forensics. The proposed model consists of six phases, namely, Preparation (integrated with forensic readiness principles), Identification, Assessment (integrated with forensic collection and analysis practices), Action and Monitoring, Recovery, and Evaluation (integrated with forensic presentation practices). This model is an extension of our recently published conceptual Cloud Incident Handling Model in Rahman and Choo (2015). The earlier work discussed the model in four major phases, namely, preparation, detection and analysis, incident response, and postincident, as well as the involved costs at each phase. In this study, the Detection and Analysis and the Incident Response phases are expanded to include Identification and Assessment, and Action and Monitoring, and Recovery, respectively.
Preparation phase integrates forensic readiness requirements. The phase has a proactive element such as understanding and preparing the necessary tools or resources required to protect and secure a cloud’s systems or networks. Activities associated with forensic readiness include the identification of potential sources of evidential data (e.g., log files, network traffic records, CSU devices, off-site data centers, continually tracking authentication) in a cloud environment (e.g., CSPs, internet service providers, and third parties) and deciding where identified potential evidence sources should be stored.
Identification phase begins immediately after an incident or vulnerability is detected and reported, either by human (cloud users or CSP’s personnel) or automated tool. Unlike Preparation, this phase consists of reactive incident handling strategies.
In the Assessment phase, information from the received reports will be assessed to determine if the incident is a false alarm, and the potential impact(s) to the cloud’s core services and assets. If it is determined to be a false alarm, the process will be terminated. The integrated conceptual cloud forensic framework from Martini and Choo (2013) is implemented to enable forensic investigations. Forensic examiners will undertake the evidence collection process from the potential sources identified in the Preparation phase. Once the evidence has been preserved and collected, the forensic analysis process will then commence.
Action and monitoring phase involves the execution and monitoring of the appropriate response strategy in an effective and timely manner as determined in the incident escalation strategy. It is important to note that the response strategy (i.e., action) may vary between incidents and incidents assigned to different priority levels.
Recovery phase involves the restoration of system operation back to normal at both logical and physical levels. Evaluation phase involves a formal evaluation (e.g., postmortem meeting) where issues such as the nature of the incidents, a review of what had occurred, the intervention techniques, and the (in) effectiveness and lessons learnt are examined.
4 Case study simulation: ownCloud
ownCloud allows users to deploy their own storage service in a private cloud environment (Saha, 2012). Users of ownCloud can access their account and data using the following options:
(i) Web-based front end application with username and password;
(ii) Client-based application such as a mobile application that allows files to be synchronized between the server and the client devices; and
(iii) WebDAV via Web browser.
In our case study, we deploy the Security Information and Event Management (SIEM) system that allows us the capability to have real-time monitoring, correlation of events, issuing of alert notification, and historical reporting of security events (e.g., by gathering data from many sources such as network, system, and appliances) (Suarez-Tangil et al., 2014). The cloud’s VM instances and internal network environment are simulated using Oracle VirtualBox.
For attack setting, we consider a malicious insider as an insider compromise usually has the greatest impact due to the likelihood of them circumventing existing controls (e.g., the incident involving Edward Snowden, a former US National Security Agency contractor). In 2013, for example, CSA identified the malicious insider as one of the top threats to cloud computing (Cloud Security Alliance, 2013). The simulation of an insider attack includes the following steps:
• Step 1: Reconnaissance—This is typically the first step in an attack lifecycle, which involves scanning activities such as port scanning of networks and machines to map the target network (Trček et al., 2010). An insider will be in an advantageous position due to his/her understanding of the system as well as having the appropriate credentials and rights to the internal system.
• Step 2: Define the target—Based on information from reconnaissance, the attacker will then select and define the target. For this study, the target will be the ownCloud server.
• Step 3: Discovery—Involves the identification of hardware and software vulnerabilities on the server that can be exploited.
• Step 4: Escalate privileges to conduct the attack—For this study, we will simulate an offline password attack.
• Step 5: Establish foothold by using tool(s) or other techniques to launch the password attack to gain unauthorized remote access.
• Step 6: Capture and exfiltration—The attacker will then capture username and password, and exfiltrate sensitive information from the ownCloud server. This results in the violation of data confidentiality and integrity.
• Step 7: Delete audit trails.
The findings of each phase of our proposed model are discussed in the next section.
4.1 Preparation and forensic readiness
Risk assessment is the key task in the Preparation phase and includes classifying assets, vulnerabilities, and threats. The first step is to identify important assets connected to the organization network and incorporate them into the SIEM database. The assets can be automatically discovered through network address range and classified into host, host group, network, and network group. Value of each asset must then be defined according to the asset criticality, for instance, ranging between 0 (not important) and 5 (very important). For this case study, the value of the ownCloud server is the highest due to the amount of sensitive data stored on the server as well as its role in ensuring service availability. The asset value of the Head of Department’s workstation (in an organization) is another example asset that should be set higher than the subordinates’ workstation due to the data confidentiality concern.
Vulnerability assessment process commences as soon as asset inventory tasks are completed. The Common Vulnerability Scoring System (CVSS) is one example approach to define vulnerability severity and determine urgency. From the identified vulnerabilities, we can attempt to address potential threats using appropriate mitigation strategies (e.g., system patching and installing security update). For instance, as ownCloud is a Web-based technology, existing Web vulnerabilities might expose the Web server to Cross-Site Scripting, a common Web attack.
Risk assessment outcomes facilitate forensic readiness decision in determining the required digital forensic practices and tools. For example, the assets' architecture specifies potential location of evidential data at the server and client devices (e.g., mobile devices used to access cloud services). Based on the findings from the first academic in-depth server and client forensic investigations of an ownCloud installation in Grobauer and Schreck (2010), for example, potential evidential data on client devices include sync and file management metadata, cache files, cloud service and authentication data, encryption metadata, browser artifacts, and mobile client artifacts. Identified potential evidential data on the ownCloud server include administrative and file management metadata, stored files uploaded by the user, encryption metadata, and cloud logging and authentication data.
Monitoring at both host-based and network-based levels must be proactive and continuous (e.g., by using Intrusion Detection and Prevention System) to minimize risk to data at-rest and in-transit. The identification of data at-rest and in-transit flow is essential to determine the required data protection mechanisms. For our case study, an open source of host-based intrusion detection system (i.e., OSSEC) is deployed at the host-based level, and an open-source network-based intrusion detection and prevention system (i.e., Snort) for network monitoring. Events generated by OSSEC and Snort are displayed on event logs in a real-time environment, which facilitate the detection of an attack or security breach.
4.2 Identification
During the reconnaissance stage (from attack simulation) in our case study, the OSSEC agent detected network scanning activities, originating from an internal IP address (see Table 1). This typically requires further investigation as the user is an internal employee.
Table 1
An Example of Insecure SSH Connection Attempt Event
| Signature | Date GMT+9:30 | Sensor | Source | Destination |
| ossec: SSH insecure connection attempt (scan) | 2014-08-18 05:40:55 | alienvault | Host-192-168-0-3 | alienvault |
To proceed to the next phase in our case study, we assume that no further action was undertaken to investigate the detected network scanning activities. Subsequently, Snort detected a “HTTP Password detected unencrypted” event targeting the ownCloud server (see Figure 3). Both events originated from the same legitimate user. An incident alarm should be created by generating the ticketing system that may include person in charge, status, priority, actions, and incident workflow tracking. Further investigation will be undertaken in the next phase, Assessment.
4.3 Assessment, forensic collection, and analysis
In this phase, the assigned personnel will conduct preliminary investigation of the reported incident. Activities in this phase diligently incorporate forensic collection and analysis processes. SIEM tools, such as OSSIM, can be used to facilitate incident investigations, for example, flagging known vulnerabilities and the associated patches. This is consistent with findings from Kohn et al. (2013) and Freiling and Schwittay (2007) which further support the suggestion that there are overlaps between incident handling and digital forensic practices.
In our case study using OSSIM, we were able to gather information relating to the host such as Asset Report, Traffic, and All Events from the Host. Further event information such as event detail, snort rule detection, Knowledge Database (KDB), and captured packet in pcap format can be viewed on OSSIM’s Forensic Console. From the captured packet (see Figure 4), it is determined that the attacker uses Hydra (an open-source tool to perform brute force on a remote authentication service). This suggests a deliberate attack by a malicious insider. Cloud logging and authentication data should be collected as they may offer further insights into the incident.
At this stage, management would need to decide whether to lodge a police report or proceed to internal disciplinary committee and (close the loophole), if the decision is to:
• lodge a police report—forensic investigation would likely be undertaken by law enforcement agencies and findings will be used in judicial proceedings, or
• internal disciplinary action—forensic investigation will be undertaken by an in-house forensic team or a third-party forensic organization. Results will be presented during the postmortem (or incident closure) meeting and may be used to dismiss the employee.
An overview of Assessment analysis and tasks is illustrated in Figure 5. The attack actor in our case study is a malicious insider who exploits technology as the attack vector to launch an offline password attack against the ownCloud Web server. Confidentiality and integrity of information assets are the potential consequences and this is considered a high priority incident. The compromised Web server, analysis data from IDPS (e.g., log capturing, event correlation), and the malicious VM are three potential evidential data sources in the forensic collection and analysis tasks. Findings from the investigation and the gathered evidence need to be updated into the ticket detail, and the ticket must now be assigned to the responsible team in the next phase, Action and Monitoring.
4.4 Action and monitoring
The Action phase is designed to contain the incident in a timely and effective manner. Cloud settings are able to facilitate response strategies (Grobauer and Schreck, 2010). For example, pause and snapshot, two VM features can facilitate the execution of strategies to prevent further exploitation in both the attacker’s VM (e.g., pause current activities for forensic analysis) and the compromised VM (e.g., block malicious activities).
As the incident identified in the previous phase was classified high priority, the response strategies must be undertaken immediately. It is important to note that new security incident might be discovered in this phase; thus, the flow will return to the Assessment phase (i.e., an iterative process). In our case study, however, no new event is detected.
Adopting the response strategy model of Anuar et al. (2012), we select the appropriate strategy based on the incident’s urgency and asset criticality level. The four response options are as follows:
• Avoidance (high urgency, high criticality)—eliminates risk by reducing factors that have direct influences.
• Mitigation (low urgency, high criticality)—reduces the size of the risk exposures to the lowest risk.
• Transfer (high urgency, low criticality)—reduces impact by transferring the incident to a new entity (e.g., honeypot).
• Acceptance (low urgency, low criticality)—involves passive response to low risk and low impact type of incident.
For the identified incident in our case study, both urgency and asset criticality are high, and, therefore, we undertake the Avoidance strategy. Potential avoidance options to be implemented are:
• Malicious insider’s host—terminate network connectivity (logical and physical) and the host must remain in operational model (for forensic investigation), pause or snapshot the VM image.
• Server—investigates the server instance for other malicious activities (e.g., file deletion). Based on the outcome of the investigation, actions such as termination or limiting network connectivity, and shutting down the compromised server may need to be undertaken.
4.5 Recovery
During the Recovery phase, we need to restore normal cloud service and avoid disrupting existing security protection mechanisms. Cloud infrastructures can facilitate recovery strategy. For example, having multiple server instances (particularly in Infrastructure as a Service) can minimize downtime impact if the compromised instance needs to be shut off.
In the context of our case study, one may undertake the following actions to avoid further compromise:
• Other server instances need to operate normally to ensure service availability and the cloud service needs to be monitored for any performance issue (e.g., due to the security breach or identified incident).
• Require users to change their ownCloud account password.
• Implement two-factor authentication.
• Install software and hardware patches.
• Deploy security mechanisms such as Secure Socket Layer to reduce attacks such as man-in-the-middle.
• Review priority and reliability value of events.
4.6 Evaluation and forensic presentation
A postmortem meeting will be held to discuss the chain of events and present outcomes from the disciplinary committee (if required to deal with a malicious insider). The meeting may encompass various cloud stakeholders depending on the particular cloud ecosystem. In the case of private cloud, for instance, external parties may not be involved as it is managed internally. Findings will need to be written up as a report according to the requirements of the jurisdiction that the organization operates in.
“Lesson-learnt” can be explained from the perspectives of People, Process, and Technology, for example:
• People—enforce separation of duties, organize information security awareness workshop (specifically in cloud computing as employees may lack of understanding of risks and threats in cloud-based workflow)
• Process—review and update policies of Human Resources, and Bring Your Own Device.
• Technologies—enforce better security mechanisms to internal and external networks.
In this phase, criminological theory such as the Situational Crime Prevention Theory (Clarke, 1997) can also be used to create conditions unfavorable to crime with the aim of deterring future incidents or breaches. Findings from the “Lesson-learnt” can then be integrated into the following five broad categories (comprising 25 techniques) of the Situational Crime Prevention Theory:
(1) Increasing perceived effort: Target hardening, controlling access to facilities, screen exits, deflecting offenders, and controlling tools/weapons;
(2) Increasing perceived risks: Extending guardianship, assisting natural surveillance, reducing anonymity, utilizing place managers, and strengthening formal surveillance;
(3) Reducing rewards: Concealing targets, removing targets, identifying properties, disrupting markets, and denying benefits;
(4) Removing excuses: Reducing frustrations and stress, avoiding disputes, reducing emotional arousal, neutralizing peer pressure, and discouraging imitation; and
(5) Reducing provocations: Setting rules, posting instructions, alert conscience, assisting compliance, and controlling drugs and alcohol (which we will replace with “provocation factors”).
Measures that organizations can undertake to ensure a secure cloud environment are outlined in Table 2.
Table 2
Security Practices Based on Situational Crime Prevention Theory
| Increase the Perceived Effort | Increase the Perceived Risks | Reduce the Rewards | Remove Excuses | Reduce Provocations |
| Target hardening such as installing antivirus software and software updates on corporate devices regularly (e.g., daily) | Extending guardianship by not collecting personal information not related to the functions or activities of the device or users of the cloud service | Concealing targets by securing corporate devices when not in use, using a different e-mail address for suspicious account sign-up, etc. | Reducing frustrations and stress by providing a transparent online reporting system where users can report malicious activities including those of their colleagues for remediation action, etc. | Setting rules such as best practices to ensure the security and privacy of organizational data |
| Access control such as securing corporate devices when not in use | Assisting natural surveillance such as reporting lost or stolen devices and cyber victimization to appropriate authorities | Removing targets such as avoiding visiting Web sites of dubious repute or downloading apps from third-party app stores | Avoiding disputes between employees by allowing users to opt in or out to the collection or use of their personal information, and identifying third parties and including links to information in the privacy policy about how employees can modify or delete the data used by those parties, etc. | Posting instructions such as limiting dissemination of sensitive and personally identifiable information on public forums such as enterprise or social networking sites |
| Screen exits such as deleting personal information from corporate devices before disposing of the devices | Reducing anonymity by registering employees or vendors who access the organization network (e.g., no guest account) | Identifying properties such as physical marking of corporate devices or use of remote wiping and locating apps | Reducing emotional arousal by banning or removal of programs that encourage violence or facilitate criminal behavior | Alert conscience by providing regular user education to train them to be vigilant and for managers to conduct due diligence on their employees |
| Deflecting offenders by reducing their possibility or incentive to commit a crime such as prompt installation of patches to software and hardware | Utilizing place managers that will be responsible for vetting corporate devices and apps before they are approved for use within the organization (e.g., Bring your Own Device (BYOD)/Apps), secure the data collected from users, etc. | Disrupting markets by reporting the lost or stolen devices to authorities and wiping lost or stolen devices with remote wiping apps | Neutralizing peer pressure such as avoid creating situations that could lead to collusion between malicious employees and vendors or external parties to target the organization | Assisting compliance by encouraging users to report cyber victimization, and discouraging employees to collect and store personal information unnecessarily |
| Controlling tools such as using privacy enhancing tools or opt out of sharing personal information with third parties | Strengthening formal surveillance such as monitoring of network activities (e.g., is a user's movements and activities collected through the use of integrated location and movement sensors without informed consent?) | Denying benefits such as using encryption and alphanumeric and nonguessable password, and prosecution of offenders | Discouraging imitation | Controlling provocation factors using measures such as setting of rules to discourage noncompliant behaviors |
5 Concluding remarks
One may say with confidence that our increasing reliance on cloud services means that the cloud infrastructure will continue to be exploited for criminal purposes by malicious actors, both terrestrial and cyber. Although both CSP and CSU need to take cyber threats seriously, it would be unrealistic to expect an incident-proof cloud computing environment or infinite resources to action upon all potential threats and risks identified. One key measure that CSP and CSU can adopt is having in place an effective incident handling strategy that provides guidance on what to do when incidents occur, the actions that need to be undertaken when incidents are detected, how can the identified incidents be mitigated, what evidential data should be collected, etc.
In this chapter, we proposed a Cloud Incident Handling Model that incorporates incident handling, digital forensic practices, and the Situational Crime Prevention Theory (Clarke, 1997). We then explained how the proposed model can be implemented using a case study in the private IaaS cloud environment. Cloud attributes of relevance to the formulation of an incident handling response that were identified included (i) how cloud-based workflow affects risk assessment, (ii) the need to identify the flow of data at-rest and in-transit required in proactive security controls and forensic acquisition, and (ii) potential attack vectors which are also sources of evidential data (e.g., desktop, laptop, tablet, smartphone). Further research includes further validation and refinement of the proposed model in different context, particularly in a real-world deployment.