ITS-834: Emerging Threats & Countermeasures. Discussion, Final Research Project.

XXX-X-XXXX-XXXX-X/XX/$XX.00 ©2019 IEEE

Cybersecurity Culture in Computer Security Incident Response Teams

Investigating difficulties in communication and coordination

Marios Ioannou Applied Cybersecurity Research Lab

University of Central Lancashire Cyprus

Larnaka, Cyprus [email protected]

Dr. Eliana Stavrou Applied Cybersecurity Research Lab

University of Central Lancashire Cyprus

Larnaka, Cyprus [email protected]

Dr. Maria Bada The Department of Computer Science

and Technology Cambridge Cybercrime Centre

University of Cambridge Cambridge, UK

[email protected]

Abstract— This study aims to identify the factors related to developing a cybersecurity culture at an organizational context and the difficulties faced in communicating and cooperating within a CSIRT. Specifically, our aim is to identify: 1) The issues which may limit the communication and the coordination of incident management process inside a CSIRT, 2) the issues which may limit the cooperation from top management to employees and reverse and 3) approaches towards addressing the issues that limit the communication and the cooperation of a CSIRT. The research was conducted using an online survey and study participants were experts within the existing CSIRT community. In total, 25 participants responded to the questionnaire, from 23 different countries in the world. The questions of the survey queried the personal knowledge and experience of participants regarding CSIRTs. In our analysis, issues such as communication, cooperation, coordination, trust and information sharing are discussed as crucial factors that affect the development of a cybersecurity culture. Several issues and weaknesses in terms of communication, coordination and cooperation within CSIRT are outlined and a set of recommendations and key elements are defined.

Keywords—cybersecurity, culture, CSIRT, incident management, communication, cooperation

I. Introduction The number of attacks in recent years has risen

dramatically. Last year Equifax, one of the largest credit agencies in U.S. was breached and the personal information of approximately 143 million individuals were exposed. After the leak of NSA and the “Vault 7” database of exploits, a number of these exploits was widely used by popular ransomware, such as “WannaCry”, “NonPetya” etc., and the families of ransomware grew up dramatically. In 2016 there were 638 million incidents from ransomware, whereas in 2017 there were 2,2 billion incidents [1].

According to Ponemon Institute [2], financial costs of security breaches may include both direct costs (such as loss of data, intellectual property etc.) as well as indirect costs (such as loss of reputation etc.). To eliminate, or at least minimize the impact, organizations should have the capacity to effectively manage an incident, including implementing proactive and reactive measures. Incident Management is the process of detection and response to incidents related to computer security as well as the protection of data, assets and systems which are critical in order to prevent incidents from occurring. Incident management processes in an organization

are typically being managed and coordinated by a Computer Security Incident Response Team (CSIRT) [3].

The weakest link in the chain is still the humans. The investment and the development of a cybersecurity culture within organizations can minimize the risk from the human factor; this can provide a positive impact to security and efficiency and at the same time mitigate the financial risks. It is important to establish effective communication, collaboration and coordination within the CSIRT in order to have an effective and efficient incident handling. These targets are challenging to be achieved, so our aim with this work is to identify internally at a CSIRT: 1) The issues which may limit the communication and the coordination of incident management processes; 2) The issues which may limit the cooperation from top management to employees and reverse and 3) Approaches towards addressing the issues that limit the communication and cooperation of a CSIRT.

Section II discusses related work. Section III presents the methodology followed and section IV presents the results of this research work. Section V provides recommendations to address the issues identified and section VI concludes the work.

II. Related Work A. Cybersecurity Culture

A cybersecurity culture refers to the procedures laid down by an organization to all its employees, directing their course of action in all situations related to data integrity, whenever in the line of duty. The dominant part of information breaches inside the organizations are aftermath of human actors [4] and keeping in mind that cybersecurity policies are ordinary among the organizations. Against this background, the improvement of a cybersecurity culture accomplishes an adjustment in outlook, cultivates security mindfulness and hazard observation and keeps up a nearby hierarchical culture, instead of endeavoring to constrain secure conduct.

Developing a cybersecurity culture therefore starts with the formulation of policies which guide the employees who handle information, on how to react in the case of different situations. These policies or guidelines are then made aware to all employees, depending on the type of data they handle. Awareness is usually followed by a constant examination of compliance [5]. The development of a cybersecurity culture involves “addressing cyber threats using technology and complimentary factors such as policy guidelines, information

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:03 UTC from IEEE Xplore. Restrictions apply.

sharing on threats and creating awareness” [6]. Also, the role of executive leaders should not be merely selecting a team to create awareness [7]. Rather, the executive leaders should actively take part in the training process.

B. Factors Affecting the Development of a Cybersecurity Culture The following are some of the factors which influence the

development of a cybersecurity culture:

a) Clarity of policies: For the cybersecurity culture to be effective, it is paramount for the organization’s management to create policies which clearly address the potential threats in the immediate working environment, the available preventive measures and how to respond in case a potential or actual attack has been detected [8].

b) Assumptions made by management members: The assumptions made by policy makers with regard to the roles played by different people in the culture development process could determine whether the culture becomes effective or not.

c) Points of focus for policy makers: In the development of a cybersecurity culture, the main aim of cybersecurity policies is to condition people within the organization into doing what is required so as to safeguard data integrity [9].

d) Communication development efforts: The efficiency of communication determines whether the policies will be perceived as laws which they must comply with or a culture which needs to be cultivated for the greater good of the organization [10]. A main component of organizational culture and managerial culture [11] is the managerial communication. Employee’ satisfaction and commitment is defined by the organizational culture [12]. Welch and Jackson [13] concentrate on the fourth dimension which is the internal corporate communication. The main role of this type of communication is to “transfer” the goals and the objectives of the organization and aims to reach four goals: the understanding of business environment, the belonging, the commitment and the awareness [13].

e) Cooperation development efforts: Cooperation is a basic component in order to aggregate activities, as well as to keep up a beneficial general workplace. The business workplace groups showing lack of teamwork may lead to unwanted results at business operations [14]. For every stakeholder to play their role in cultivating a cybersecurity culture, they must understand the dire importance of their role as well as the ultimate collective goal.

f) CSIRT’s effectiveness improvement: Bada et al. [15] argued that the measurement of the effectiveness of information security will assist in increasing accountability, improving the effectiveness of information security, as well as the demonstration of compliance. The researchers also argue that in order to improve the effectiveness of CSIRTs, relevant information issues such as trust, data-sharing, better communication and cooperation are necessary to be explored, which are important in achieving the highest levels of performance.

III. Methodology In order to investigate the factors that challenge the

communication and coordination efforts within a CSIRT, an online questionnaire was conducted. All the participants were

experts that were currently, or used to, work in a CSIRT at various positions. The participation in the study was voluntary. In total, 25 participants responded to the questionnaire, from 23 different countries across United States of America, Europe, Asia, Australia and Africa.

The information collected was considered sensitive, was treated as confidential and was immediately anonymized. The questions where grouped in various categories. Replies to the questionnaire ranged from 1 low level to 5 high level. In this paper, we will focus on the results concerning the team management, training and performance evaluation of a CSIRT. A descriptive analysis of the questionnaire’s results was performed to gain insights of CSIRTs’ operation, identify challenges and best practices.

IV. Results Following, the results are presented, and the challenges

faced by CSITRs regarding communication and coordination aspects are identified.

A. Team Management A key aspect to create a cybersecurity culture in CSIRTs

is team management. Managers need to have the ability to coach their teams, set goals, provide directions and coordinate each group of individuals to successfully complete a task, while maintaining a high level of teamwork spirit. All these aspects are primarily based on communication and coordination abilities of individuals.

The research revealed that despite the fact that CSIRT management tries to improve communication and coordination between the different teams within each organization, there are many obstacles that employees encounter during an event. These are listed in Table I.

TABLE I. OBSTACLES IN COMMUNICATION / COORDINATION DURING AN INCIDENT

Obstacles identified % Not all employees are being kept informed during an incident 48

The right information is not being sent to the right people 44

Functional Areas not collaborating 40

Roles are not clearly defined from Policy 36

Lack of Trust between the teams 32

Fear not to expose CSIRT from an incorrect initiative 32

Not very good relationships between the employees and the managers 20

Fear from an employee that is not approaching the right solution 16

People take roles that are not assigned to them 4

Most of the obstacles identified in Table I relate to communication and coordination issues. Communication and coordination issues are reported across two levels: between management and employees and between teams. The key issue identified across the two levels, is that there is lack of

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:03 UTC from IEEE Xplore. Restrictions apply.

appropriate information flow about an incident that can assist employees to effectively and efficiently address it. Information sharing about an incident can solve this challenge not only internally but also within the trusted CSIRT community. The fact that a high percentage of answers (32%) reported that there is luck of trust, can explain the fact that there is lack of information sharing between people and that functional areas are not collaborating (40%). Also, a significant % has indicated that the relationships between the managers and employees are not appropriate, which further contributes to the problem. Moreover, people are taking up roles that are not supposed to be undertaking, which means that they are not fully prepared to perform certain tasks. This can explain the lack of confidence that is reported, as a high percentage of responders (36%) fear that they will expose their organization from an incorrect action taken.

In order to establish a successful collaboration, trust is necessary among the individuals of a team [16]. Managers need to be very careful when they are forming the various teams that compose an organization. Inherit relationships increase the chance of a successful team. New teams who are only staffed with new employees find it more difficult to collaborate than those with established relationships [16]. Newly formed teams are investing significant time and effort to build relationships of trust. However, when there are employees who already know and trust existing employees that are part of a new team, they can become nodes which evolve into networks overtime. Our study indicated that 36% of the CSIRTs have teams that are fully staffed by new employees (Fig. 1). This is a factor that further contributes to the obstacles identified in Table I and needs to be addressed accordingly to improve the communication and collaboration within CSIRTs.

Fig. 1. Percentage of CSIRTs that have teams fully staffed by new employees

B. Trainings Skills development is usually achieved through

appropriate trainings and through work experience. CSIRTs require the development of both hard and soft skills to successfully resolve an incident. Often, people might consider that it is more important to develop hard skills, but often this is not true; in the context of CSIRT operation, soft skills are equally important as hard skills. Survey results (Fig.2) indicated that there is a high percentage of CSIRTs (40%) that don’t offer training to their employees related to collaborative behaviour (e.g. appreciate others, productively and creatively resolve conflicts etc.). The lack of such training explains some of the obstacles that are listed in Table I. The main reasons, that were reported for the lack of collaborative training,

included insufficient funding (53.3%) and insufficient time (46.7%).

Fig. 2. Percentage of CSIRTs that carry out collaborative behaviour trainings

C. Performance Evaluation It is not only critical for an organization to have its

procedures documented and driven by appropriate security policies, but it is equally important to evaluate their effectiveness and efficiency. In the context of CSIRTs, it is vital to assess the performance of CSIRT incident management capabilities and improve them, if needed. A key evaluation aspect to consider, is the communication and coordination of the teams within the CSIRT, as these aspects play a key role in fulfilling successfully the mission of a CSIRT.

A performance measurement that can evaluate the success of a particular activity, are Key Performance Indicators (KPIs). Based on this, the participants were asked, if their CSIRT have KPIs about the effectiveness of internal communication/cooperation and the coordination for incident management. The results in Fig. 3 show that a high percentage of CSIRTs (44%) do not have KPIs and are not able to evaluate the internal communication and coordination of incident management processes. This is considered a major issue, as a CSIRT that does not utilize KPIs cannot identify the factors that lead to a poor performance and unresolved incidents.

Fig. 3. Percentage of CSIRTs that have KPIs for communication and coordination

V. Recommendations Αs outlined above, the current study has revealed several

issues and weaknesses in terms of communication, coordination and cooperation within a CSIRT that can affect the efforts of the organization to build a cybersecurity culture. Below we summarize the challenges that have been identified along relevant suggestions to address them.

Challenge 1: Lack of teamwork spirit & trust

Recommendation 1: Managers should invest in creating a culture of collaboration but also make this type of behavior

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:03 UTC from IEEE Xplore. Restrictions apply.

visible to everyone in the CSIRT. They should spend time within the teams during their work, provide the employees with advice, “listen” to them and enhance the feeling of trust and support that each employee should feel with their manager.

Furthermore, human resources in cooperation with the leaders of the CSIRT should organize as many team building activities as possible, outside of the working environment, such as team games, excursions, social nights etc.

Challenge 2: Lack of confidence & fear of personal exposure

Recommendation 2: Staff working in a CSIRT and dealing with specialized technical issues should be accredited with internationally recognized certifications in this field and be fully trained. The CSIRT should ensure that all staff are continuously trained and certified in accordance with their position and duties. In addition, specialized trainings should be organized in such a way to educate all employees involved in a specific issue and not selectively educate only few members of a team. By providing a holistic training to staff, the experience and constant improvement of staff skills is ensured, as well as ensuring that the staff itself feels confident to perform their duties.

Challenge 3: New teams do not include existing staff

Recommendation 3: Managers must not create teams that consist of new employees only. New teams should consist of a sufficient percentage of existing CSIRT employees, who can become nodes and promote the development of relationships of trust between new and existing employees.

Challenge 4: Lack of collaborative behaviour training

Recommendation 4: It is vital for CISRTs to consider that the combination of technical and collaborative behaviour training, can produce an overall knowledgeable staff. Such a training can also produce employees who can work on teams without continuously supervision from the management.

Leaders of CSIRTs should focus on providing trainings and seminars on collaborative behavior at least once every six months. They should target to cultivate a culture of collaboration to every employee and provide them with the social skills needed to achieve it.

Challenge 5: Lack of KPIs related to communication and coordination

Recommendation 5: Establishment of KPIs (e.g. amount of time to resolve an incident, downtime during an incident etc.) related to the internal communication / cooperation and coordination for incident management. This is necessary in order to evaluate the CSIRT's success in implementing the cooperation, communication and coordination processes.

Moreover, CSIRTs should perform frequent audits on incident management mechanisms and compare them to the results of unsolved or partially solved incidents to identify weaknesses in knowledge, personnel, software, hardware, etc., and take actions to improve them.

VI. Conclusion The cyber threat environment is continuously changing with threats constantly increasing in an arms race, while cyber threat actors are following the evolution of technology and develop new tactics, techniques and procedures to achieve their purpose. It is crucial therefore, to counter these threats by trying to stay one step ahead and actively defend ourselves. CSIRTs can assist this process but their tasks are challenging due to communication, cooperation and coordination issues. Our research identified a number of issues, which are all related to the human factor. CSIRTs should focus on addressing the identified issues, by starting with building a feeling of trust and teamwork among their personnel.

Acknowledgment We would like to thank all the staff members of CSIRTs

that have supported us by completing the questionnaire.

References [1] Zerto, “The growing threat of ransomware”, 2018. [Online], (Retrieved

3rd of July 2018, from: https://www.zerto.com/the-growing-threat-of- ransomware-infographic/

[2] Ponemon Institute, “Cost of cyber crime study and the risk of business innovation” p. 12, 2016. [Online], (Retrieved on 1st July 2018, from:http://www.ignitewestcoast.co.uk/media/Cost%20of%20Cyberc rime.pdf?utm_source=HPEBlogPost&utm_medium=Social&utm_ca mpaign=HPEServers)

[3] A. J., Dorofee, G., Killcrece, R., Ruefle, and M., Zajicek, “Incident management metrics version 0.1. Software Engineering Institute” 2007.

[4] Ponemon Institute, ”The human factor in data protection”, 2012 [Online]. (Retrieved on 2nd July 2018, from: https://www.ponemon.org/local/upload/file/The_Human_Factor_in_d ata_Protection_WP_FINAL.pdf)

[5] C., Veltsos, ”Building a cybersecurity culture around layer 8”, Security Intelligence, 2017.

[6] B., Contos, ”Cyber security culture is a collective effort”, IDG Contributor Network, 2015.

[7] F., Howarth, ”Top five tips for creating a culture of security awareness at work”, Security Intelligence, 2015.

[8] T., Sager, ”Developing a culture of cybersecurity with the CIS controls”, CIS- Center for Internet Security, 2017.

[9] M., Rajendran, ”Analysis of team effectiveness in software development teams working on hardware and software environments using Belbin Self-Perception Inventory”, Journal of Management Development, 24(8), 2005, pp. 738-753.

[10] D. M., Hasib, ”Cyber security, culture and compliance”, United States Cybersecurity Magazine, 2013, pp. 53-55.

[11] N., Burlacu, E., Graur, A., Morong, ”Comunicarea managerial, Editura Grafema Libris”, Chinu. US Department of Health and Human Services, 1979, The belmont report, 2003.

[12] R, Howard, ”Fostering a performance driven culture in the public sector, public manager”, The Manager's Musings, pp. 51-56, 2007.

[13] M., Welch, and P. R., Jackson, ”Rethinking internal communication: a stakeholder approach”, Corporate Communications An International Journal, pp. 177-198, 2007.

[14] S., Corbett, ”Teamwork: how does this relate to the operating room practitioner? ”, Journal of Perioperative Practice, pp.278-281, 2009.

[15] M., Bada, S., Creese, M., Goldsmith, and C. J., Mitchell, ”Improving the effectiveness of CSIRTs”, The Second International Conference on Cyber-Technologies and Cyber-Systems, pp. 53-58, 2017.

[16] L., Gratton, T. J., Erickson, ”Eight Ways to Build Collaborative Teams”, 2007.

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:03 UTC from IEEE Xplore. Restrictions apply.

Evaluating Database Replication Mechanisms for Disaster Recovery in Cloud Environments

Júlio Mendonça∗, Wilson Medeiros†, Ermeson Andrade†, Ronierison Maciel∗, Paulo Maciel∗, Ricardo Lima∗ ∗Informatics Center, Federal University of Pernambuco, Recife, Brazil

†Department of Computing, Federal Rural University of Pernambuco, Recife, Brazil [email protected], {wilson.medeiros, ermeson.andrade}@ufrpe.br, {rsm4, prmm, rmfl}@cin.ufpe.br

Abstract—Relational databases are the most popular database system worldwide. The occurrence of failures in these systems may produce severe consequences for the business, such as data loss, customer dissatisfaction, and subsequent revenue loss. Consequently, many organizations have adopted disaster recovery (DR) solutions as an attempt to prevent data loss and ensure business continuity. Data replication for databases is one of the most used DR solution employed to guarantee data safety and availability. However, the analysis regarding DR aspects has been less explored. Therefore, in this paper, we present an integrated model-experiment approach to evaluate replication mechanisms in relational databases for DR purposes. We performed experiments in a geo-distributed cloud environment and developed analytic models to evaluate DR key-metrics such as availability, downtime, Recovery Time Objective (RTO), and Recovery Point Objective (RPO). The results revealed that the adoption of replication mechanisms could increase the system’s availability significantly. It also revealed that the replication mechanisms can guarantee RPO and RTO within seconds.

Index Terms—Disaster Recovery, Fault-Tolerance, Database Replication, Petri Nets

I. INTRODUCTION

Organizations are spending an unprecedented amount of money towards the cost of providing highly available IT services [1]. In a global market where going offline means a significant revenue loss, companies are looking for efficient DR solutions capable of keeping their data safe and IT systems running. The adoption of such solutions is essential for every business supported by IT systems. Even big companies such as British Airways, U.S. Government, and HSBC bank have experienced unexpected outages [2]. It shows that regardless of size, all companies are prone to catastrophic events and need to be prepared to them. Several solutions have been used to provide DR capabilities for IT systems (e.g., data replication, VM migration, and snapshots) [3]. However, there is not a single blueprint solution that works for all organization, since different organizations have unique needs (e.g., budget or availability).

According to different reports [4, 5], relational database man- agement systems (RDBMS) are still the most popular database (DB) systems worldwide. Even with the growing adoption of cloud computing and non-relational databases (NoSQL) such as MongoDB and Cassandra, the RDBMS still play an essential role in the market. In this way, ensuring DR and availability of these systems is crucial.

Data replication is one of the most used mechanisms to provide DR capabilities for database systems [3]. However,

most of the studies available in the literature focus on either improving the performance of database or comparing differ- ent database distributions [6, 7, 8]. Therefore, motivated by the current scenario of cloud computing expansion and high adoption of RDBMS, we extensively analyze the replication mechanisms of RDBMS in cloud environments focusing on DR aspects. We performed experiments in the cloud and developed analytic models to analyze DR key-metrics: avail- ability, downtime, RPO, and RTO. The developed models can help individuals or organizations to choose the appropriate mechanism, compare with existing solutions, and also provide useful information for the decision-making process. In this way, our key contributions are: (i) A model-experiment approach to evaluate replication mechanisms of RDBMS; (ii) DSPN models that represents cloud environments and database replication mechanisms; and (iii) Analysis of DR key-metrics through stochastic modeling.

The remainder of the paper is organized as follows. Section II presents the related work. Section III introduces fundamental concepts used in this paper. Section IV discusses the adopted experimental architecture. Section V presents the proposed analytic models. Section VI discusses the numerical results. Finally, Section VII presents the conclusions and briefly intro- duces the future work.

II. RELATED WORK Although the evaluation of database systems have been

addressed in the literature, there is a lack of studies that focus on DR [3]. To position our paper and indicate its contributions, we first summarize related work that has been done in the area. Then, we provide a comparison of our work and the literature in terms of the evaluation of database systems.

Jogi and Sinha [6] evaluated the performance of the MySQL, Cassandra, and HBase for massive write operations regarding the average number of transactions per seconds. As expected, the results showed that NoSQL databases had better perfor- mance in the executed experiments (Cassandra and HBase, respectively). Santana et al. [7] presented a replication database study to elastic cloud environments. The authors evaluated different replication techniques focusing on performance met- rics such as response time and abortion rate. Azim et al. [9] proposed an offsite two-way database replication for low- quality network connections. The proposed approach creates a modified file to trace the changes in the databases. By creating this trace, the approach could reduce the update log

2019 IEEE International Conference on Systems, Man and Cybernetics (SMC) Bari, Italy. October 6-9, 2019

978-1-7281-4569-3/19/$31.00 ©2019 IEEE 2358

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

size, and consequently, reduce the time to replicate the data for all databases. Zhuang et al. [8] presented a model to forecast incoming traffic rates and predict the corresponding replication latency of LinkedIn database systems. The devel- oped approach could estimate the maximum replication latency for the database system and also the SLA (Service Level Agreement) of the service.

These studies presented above have mostly focused on ana- lyzing database systems regarding performance. However, none of them have analyzed relational database systems for DR purposes. Therefore, differently from these studies, we per- formed measurements using real-world cloud environments to analyze replication mechanisms in an RDBMS and developed analytic models to evaluate these mechanisms regarding DR key-metrics.

III. FUNDAMENTALS

A. Disaster Recovery

In modern business environments, IT systems should not spend hours or even minutes unavailable, in order to support business operations [10]. In order to achieve high-availability, an IT service should spend less than 5.25 minutes offline per year, meaning at least 99.999 % availability (commonly known as “five nines” availability). DR solutions have been employed to ensure normal business operation so that the IT system stays online and can sustain simultaneous failures and disasters [3]. Some studies state that the adoption of DR solutions is a determinant factor for a company’s survival and growth. [10, 11]. Two metrics are essential to evaluate the DR capabilities: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). The RTO is defined as the maximum time to bring a system or application to its operational state after a disaster event, while the RPO comprises the maximum amount of data that could be lost in a disaster event [10].

B. Data Replication Using MySQL 8

Replication is used to keep data synchronized among nodes and occurs when databases have modified data. Replication consists of sending data updates received by primary (master) nodes to secondary (slave) nodes. Therefore, different databases instances (nodes) can have the same data. These nodes with similar data can be used to provide DR capabilities for a database system. Figure 1 shows a typical implementation of database replication. In this example, if the primary node (DB server 1) running in the primary cloud fails, the slave node (DB server 2) executing in the secondary cloud infrastructure (DR cloud) can assume its place and keep the systems running with all the data available. As follows, we explain two replication mechanisms available in MySQL 8.

1) Group Replication: This replication mechanism aims to achieve consistency between the node’s data. A protocol must be adopted to ensure that all nodes receive the messages and that the messages were received in the right order. Atomic multicast is a protocol that can be adopted to ensure that all messages sent to a set of nodes are delivered to all or none of them. One-phase commit, two-phase commit, and three-phase commit are also presented as distributed commit protocols.

Users

D ata replication

Request

DR Cloud

Web servers

Primary Cloud

DB requests in case of failures

DB requests L oad Balancer

Internet

DB Server 1

DB Server 2

Fig. 1. Adopted solution using cloud database replication

One-phase commit, which is adopted by MySQL 8, is the one that the master only sends the updates. That is, it does not notice if the slaves committed the transaction. Two and three- phase commits add one more phase to allow nodes to decide about a transaction. So, the nodes try to reach a consensus about the transaction and commit it or discard the transaction.

2) Synchronization: The synchronization mechanism is used to synchronize the data stored on a master database with the data stored on slave databases. Differently from the group replication, it does not have automatic conflict detection and resolution. In the synchronization mechanism, when the slave receives updates, it writes them in its relay log and then the slave reads the relay log to execute the update. This synchronization takes place when an update is fully written in the relay log. The available configurations are asynchronous and semisynchronous:

• Asynchronous: In this configuration, no synchronization is guaranteed. The master will send the update to its slaves, but it does not wait for synchronization before commit. If the master crashes, there might result in data loss.

• Semisynchronous: This configuration waits for a given number of slaves to receive the updates and only commits after all of them send an acknowledgment or a timeout has occurred. In this way, there is no data loss be- cause the master only commits the request after receiving the acknowledgment from the slaves. Note that when a timeout occurs or the slave fails, the master changes its configuration to become asynchronous.

C. Modeling and evaluation with DSPNs

Availability is an essential dependability attribute, which has been largely adopted in the SLA contracts with many cloud providers. It is defined as the fraction of time that a system provides the service for which it is specified, and can be computed using the Equation 1 [12]:

A = MTTF

MTTF + MTTR (1)

where A is the resulting availability, MTTF (Mean Time to Failure) concerns the average time for the occurrence of failures in the system, and MTTR (Mean Time to Repair) corresponds to the average time taken to fix the system. The systems’ downtime is computed by D = (1 – A) × T, where D is the

2359

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

Data replicationDB Requests

DR Cloud

Internet

Workload Primary Cloud(MS Azure cloud – USA)

(Google cloud – USA) (Google cloud – USA/Europe)

Fig. 2. Testbed setup

computed downtime, A is the system availability, and T is the period of time adopted [12].

Petri nets are a formalism quite widespread to evaluate sys- tems focusing on dependability, concurrency, and performance [13]. Petri nets models are based on states (places) and activities (transitions). The transitions are responsible for performing the model state changing. In this work, we use an extension of Petri nets called Deterministic and Stochastic Petri nets (DSPNs) [13]. The DSPNs consider two types of transitions: timed and immediate. Timed transitions are deterministic or exponentially distributed and have the single-server or infinite- server semantics. In the single-server semantic a transition can only be fired once at a time, even if multiple tokens are enabling the transition firing, while for the infinite-server semantic a transition can perform n simultaneous firings if there are n tokens enabling the transition. For more information regarding DSPNs, the reader should refer to [13].

IV. EXPERIMENTAL ARCHITECTURE

This section details the testbed configuration, and the exper- iments carried out to obtain the parameters of database replica- tion mechanisms. Figure 2 shows how the setup was configured for the experiments, where two different public cloud providers in different geographic locations were adopted. The Microsoft Azure cloud was used to host a JMeter application [14]. The JMeter was used to generate workload for the RDBMS, so that it simulates users requests from a web server application (see Figure 1). In the Google cloud, we configured the Master database server in one location (primary cloud), and the Slave database server in another location (DR cloud). In this way, we created geographic data replication to avoid data loss due to disasters in the same location.

The testbed was configured as follows. The VM for the JMeter workload was hosted into the Microsoft Azure cloud and was located at USA (east US region). We used the VM type B1s, configured with one vCPU, RAM of 1 GB, a standard HDD of 30 GB, and the Ubuntu 16.04 LTS as the operating system (OS). The databases systems were hosted into the Google cloud. The master database was located in the USA (US-east1-b region), and the slave was located in two different regions (USA – US-west1-b, and Europe – Europe-west4-a). We used the same type of VM for both master and slave database servers. These VMs were of the type n1-standard-2, configured with two vCPUs, RAM of 7.5 GB, standard HDD of 40 GB, and Ubuntu 16.04 LTS as the OS. Lastly, the DB requests were of a fixed size of 500KB.

By using the testbed setup mentioned above, we generate different workloads using JMeter to send requests for the master database. Next, we recorded in a log file how long it takes

TABLE I GUARD FUNCTIONS FOR THE DSPN MODELS OF FIGURE 3 AND 5

Guard Function

Gf1 , Gf2 , Gf3 (#Pc1_up = 0) Gfn1 (#Pc1_dis = 1) Gc1-lb , Gc1-db , Gc1-web , Gntw1 (#Pc1_up = 1) Gf4 (#Pc2_up = 0) Gfn2 (#Pc2_dis = 1) Gntw2 , Gdb2 (#Pc2_up = 1) Gf5 (#Pc1-db_up >0)AND(#Pc2-db_up =0) Gf6 (#Pc1-db_up >0)AND(#Pc2-db_up >0) Gdf (#Pc1-db_up = 0) GDB1b , GreturnDB1 (#Pc1-db_up =1) GchkBD2 (#Pc1-db_up =0)AND(#Pc2-db_up >0)AND(#Pntw2_up =1)

to replicate the data into the slave database. Note that for these experiments, we analyzed both asynchronous and semi- synchronous configurations for the synchronization mechanism of MySQL 8 (see Section III-B2).

V. PROPOSED MODELS

This section presents the proposed DSPN models for the adopted solution (see Figure 1) using database replication mechanisms. First, we present the availability models, then we explain the developed models for the RPO and RTO.

A. Availability models

The upper part of Figure 3 shows the DSPN models for the primary cloud. Figure 3 (a) represents the behavior of the primary cloud, while Figures 3 (b) and (c) exhibit the DSPN models for the network components and load balancer (LB), respectively. Lastly, Figures 3 (d) and (e) show the DSPN model for the web servers (WS), and database server, respectively. The core component models reproduce failure and repair behaviors (e.g.: DB servers and LBs). Figure 3 (c) presents the failure and repair behavior of a load balancer. In this model, a token in the place P_up means that the LB is operational. Otherwise, the presence of a token in the place P_down symbolize that the LB is unavailable. The transitions Tc1-lb_fail and Tc1-lb_rep are the ones responsible for the state change. Component redundancy is represented by the numbers of tokens in the DSPN model (see Figure 3 (d)).

Differently from the core components, the DSPN model for the primary cloud (Figure 3 (a)) has two transitions representing failures: one representing transient failures (Tc1_fail), and an- other one modelling disaster events (Tc1_dis). Note that transient failures are easily recoverable and demand a short recovery time, while disaster events require more time to be repaired [11]. The models also consider the dependency between the cloud and its components. When the primary cloud goes down, the VMs become unavailable at the same time. In the DSPN models, this dependency is modeled by the guard functions Gfn1, Gf1, Gf2, and Gf3 assigned to the immediate transitions Tfn1, Tf1, Tf2, and Tf3, respectively. Table I displays all guard functions used in the DSPN models of Figure 3.

The bottom part of Figure 3 presents the DSPN models regarding the DR cloud and its components. Figure 3 (f) shows the DSPN for the DR cloud. Figure 3 (g) and (h) display the DSPN models for the external network and the slave

2360

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

Primary cloud

DR cloud 1

(h) DSPN for the database server 2

Pc2-db2_up

Tc2-db2_fail

Pc2-db2_down

Tc2-db2_rep

1Pntw2_up

Tntw2_fail

Pntw2_down

Tntw2_rep

(g) DSPN for the external network

1

(a) DSPN for the Primary cloud (c) DSPN for the load balancer

Pc1-lb_up

Pc1-lb_down

Tf1Tc1-lb_rep Tc1-lb_fail

2

(d) DSPN for the web servers

Pc1-web_up

Pc1-web_down

Tf2Tc1-web_rep Tc1-web_fail

1

(e) DSPN for the database server 1

Pc1-db_up

Pc1-db_down

Tf3 Tc1-db_rep Tc1-db_fail

[Gc1-lb] [Gf1] [Gc1-web] [Gf2] [Gc1-db] [Gf3]1

Pc1_up

Pc1_fail

Tc1_rep

Tc1_fail

Pc1_dis

Tc1_dis

Tc1_rep-dis 1 Pntw1_up

Tntw1_fail

Pntw1_down

Tntw1_rep Tfn1

[Gfn1]

(b) DSPN for the network

[Gntw1]

1

Pc2_up

Pc2_fail

Tc2_rep

Tc2_fail

Pc2_dis

Tc2_dis

Tc2_rep-dis

(f) DSPN for the DR cloud

[Gntw2]

Tf4 [Gf4]

Tfn2 [Gfn2] [Gc2-db2]

1 Psemisync

Tfail-db2 Pdb2-down

Pasync

[Gf5]

Ttimeout

TbackSemisync [Gf6]

(i) DSPN for the semisync timeout

Fig. 3. Availability models for the adopted solution of Figure 1

TNR PDB1busy

PDB1capacity

TDB1process Treplicate

PrepCapacity

DBC

RC

PwaitRep

Fig. 4. RPO model for database asynchronous replication

TsetDB2

[Gdf]

[GchkDB2]

[GreturnDB1] 1 PwaitFail

TdetectFail PwaitDB2

[GDB1b]TDB1back

PDB2working

TreturnDB1

Fig. 5. RTO model for the database replication mechanism

database server (DB Server 2), respectively. Lastly, Figure 3 (i) represents the timeout behavior when the semisynchronous configuration is adopted. This model is only used when we need computing the system’s availability for the semisynchronous configuration. When the DB server 2 fails, and it is not possible to sustain semisynchronous configuration, the system waits for a particular time (Ttimeout) to set the asynchronous configuration to the DB server 1. Note that, similar to the primary cloud, there is a dependency between the DR cloud and its components. If the DR cloud is unavailable, the slave database server becomes unavailable, and it cannot receive data from the master database (DB Server 1). It is worthwhile to mention that the timed transitions representing failures events have an infinite-server semantics, while the transitions representing repair events have a single-server semantics.

B. Disaster Recovery Models for RPO and RTO

In order to compute the RPO and RTO of the database replication mechanisms, we developed more two DSPN models. Figure 4 shows the DSPN model designed to compute the RPO for the asynchronous configuration. Note that for the MySQL semisynchronous configuration, the RPO is zero since the mas- ter only commits a request after receiving an acknowledgment from the slave nodes (see Section III-B2). The DSPN model

for the RPO represents both the incoming requests on the DB server 1 and the replication process. The transition TNR models the incoming requests on the DB server 1. The requests arrive at the DB server 1 and are processed. The transition TDB1process represents the transactions processing. The requests can only be processed if the server has the capacity. The variable DBC defines the server capacity. After the request is processed, it can be replicated to the DB server 2 (TReplicate). The DB server 1 also has a replication capacity (RC) to send the requests to the DB server 2. We remark that the transitions TDB1process and TReplicate are defined with the infinite-server semantics.

The RPO model represents an M/M/m/K queue system. Then, to compute the RPO, we adopted the Little’s Law [12] defined by the Equation 2:

MeanResponseTime = NRequests

MeanThroughput (2)

where NRequests is the number of customers in the system, MeanThroughput is the arrival rate of customers, and Mean- ResponseTime is the system’s average response time. For the RPO model, MeanResponseTime represents the RPO because it represents the meantime that a request spends to be replicated. In this way, the MeanThroughput is the real throughput for the transition TReplicate, and the NRequests is the expected number of tokens in the place PwaitRep. The MeanThroughput can be computed by the Equation 3:

MeanThroughput = (λDB1 × (1 − pK)) × pC1up × pR (3) where pK represents the probability of the place PrepCapacity having no tokens, pC1up is the probability of the primary cloud to be operational, and pR is the probability of the external network, the DB server 1, and the DB server 2 all to be operational. Lastly, λDB1 is the real throughput of the transition TDB1process. It can be decomposed as shown in Equation 4:

λDB1 = (λA × (1 − pL)) × pDB1up (4) where λA is the rate of the transition TNR, pL is the probability of the place PDB1capacity having no tokens, and pDB1up is the probability of the DB server 1 to be operational. Note that the

2361

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

TABLE II RESULTS OF THE EXPERIMENTS FOR THE DATABASE REPLICATION

Parameter Slave node in the USA

Async Semi-sync

Processing time (St. dev) 240.162 (109.440) ms 482.951 (161.344) msm Replication time (St. dev) 270.887 (112.217) ms 240.970 (109.352) ms

Slave node in Europe

Async Semi-sync Processing time (St. dev) 233.648 (106.354) ms 850.222 (307.534) ms Replication time (St. dev) 486.748 (191.366) ms 579.383 (211.997) ms

values for the pDB1up, pC1up, and pR are achieved through the availability models.

Figure 5 displays the DSPN model to compute the RTO for both asynchronous and semisynchronous configurations. Note that the RTO is computed by the average elapsed time since the DB server 1 failure until the activation of the DB server 2 as the primary database. When a failure occurs in the DB server 1, the transition TdetectFail fires, starting the process to set the DB server 2 as the primary database (TsetDB2). If during such a process, the DB server 1 returns to the operational status a token returned to the initial place (PwaitFail) through the fire of the transitions TDB1back. If the DB server 1 is still down and the guard function GchkDB2 is satisfied, the transition TsetDB2 fires, generating a token in the place PDB2working. It indicates that the DB server 2 is now operating as the primary database. Table I exhibits all the guard functions adopted for the RTO model. We also adopted the Equation 2 to compute the RTO. For the RTO model, the MeanResponseTime represents the RTO value since it compute the meantime to activate the DB server 2 as the primary database. The MeanThroughput represents the throughput for the transition TsetDB2, and NCustomers represents the expected number of tokens in the place PwaitDB2.

VI. RESULTS AND DISCUSSION

This section discusses the numerical results achieved by the experiments and the DSPNs numerical analysis.

A. Experiments results

This subsection presents the results achieved with the ex- periments performed in the adopted testbed shown in Section IV. We performed the experiments to obtain the input param- eter values for the DB processing time (TDB1process) and DB replication time (TReplicate). Table II displays the results of the experiments for the two geographic locations used to config- ure the slave node (DB server 2). The results are presented in milliseconds for both asynchronous and semisynchronous configurations. Furthermore, the standard deviation (St. dev) for each result is exhibited between parentheses.

B. Analysis of the DSPN models

The analysis of the DSPN models was performed using the Mercury tool [15]. We used the input parameters based on [16, 11] displayed in Table III. Note that for the DB server processing time and the DB server replication time we employed the values obtained by the experiments (see

0.99786606

0.998540751 0.99854531

18.69

12.78 12.74

0 2 4 6 8 10 12 14 16 18 20

0.9950 0.9955 0.9960 0.9965 0.9970 0.9975 0.9980 0.9985 0.9990 0.9995 1.0000

w/o DR w/ DR – Semisync

w/ DR – Async

D ow

nt im

e (h

/y ea

r)

Av ai

la bi

lit y

(% )

Configuration

Availability Downtime

Fig. 6. Availability results achieved by the DSPN models of Figure 3

TABLE III INPUT PARAMETERS FOR THE DSPN MODELS

Parameter Assigned Transitions Value (h)

Clouds MTTF Tc1_fail , Tc2_fail 8760 Clouds MTTR Tc1_rep ,Tc2_rep 4 Mean time for a disaster Tc1_dis , Tc2_dis 17520 Mean time to repair a disaster Tc1_rep-dis , Tc2_rep-dis 12 Load balancer MTTF Tc1-lb_fail 8760 Load balancer MTTR Tc1-lb_rep 0.5 Web/Database servers MTTF Tc1-web_fail , Tc1-db_fail , Tc2-db_fail 2654 Web/Database servers MTTR Tc1-web_rep , Tc1-db_rep , Tc2-db_rep 1.25 Networks MTTF Tntw1_fail , Tntw2_fail 10000 Networks MTTR Tntw1_rep , Tntw2_rep 1 Mean time to arrival requests(MTTA) TNR 1.3888E-5 Timeout Ttimeout 0.00833 Time to activate DB2(CDB2 ) TsetDB2 8.3333E-3 DB mean processing time TDB1process variable DB mean replication time Treplicate variable

Table II). Besides, the parameters for the capacity for the DB server 1 were reasonably estimated as DBC=10 and RC=10. First, we analyzed the availability of the adopted solution considering the scenarios without and with the DR strategy using the DSPN models of Figure 3. Table IV details the adopted metrics and Figure 6 shows the availability results. The results revealed that without a DR solution, the availability achieved was 0.99786606, which means a downtime/year of 18.69h. By enabling the DR solution, the availability obtained was 0.99854075 for the semisynchronous configuration, and 0.99854531 for the asynchronous configuration, which means a downtime/year of 12.78h and 12.74h, respectively. Although the database replication was not capable of providing high- availability for the solution (“five nines”), it considerably in- creases the system’s availability, decreasing the downtime/year in almost six hours.

We also analyzed the RPO and RTO metrics using the DSPN models. To compute the RPO for the asynchronous configuration, we calculated the availability metrics (pDB1up, pC1up, pR, pL, and pK) and passed them as a parameter to the RPO metric on the DSPN model of Figure 4. On the other hand, to obtain the RTO, we executed the DSPN model of Figure 5 together with the availability models (see Figure 3). Table IV displays the expressions used to compute the RPO and RTO. We analyzed the DSPN models for the RPO and RTO according to the slave node location (USA and Europe). For each mechanism, we used the correspondent value for

2362

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

TABLE IV EXPRESSIONS USED TO CALCULATE THE METRICS IN THE DSPN MODELS

Metric Expression

Av w/o DR P{(#Pc1-lb_up >0) AND (#Pc1-web_up >0)AND

(#Pc1-db_up >0)AND(#Pntw1 =1)}

Av w/ DR (Async) P{((#Pc1-lb_up >0)AND (#Pc1-web_up >0)AND(#Pc1-db_up >0)

AND(#Pntw1 =1))OR((#Pc1-lb_up >0)AND (#Pc1-web_up >0)AND(#Pc2-db_up >0)AND(#Pntw2 =1)}

Av w/ DR (Semisync) P{((#Pc1-lb_up >0)AND(#Pc1-web_up >0)AND(#Pc1-db_up >0) AND(#Pntw1 =1)AND(#Pdb2-down =0))OR((#Pc1-lb_up >0)

AND (#Pc1-web_up >0)AND(#Pc2-db_up >0)AND(#Pntw2 =1)}

pDB1up P{#Pc1-db_up >0}

pC1up P{#Pc1_up >0}

pR P{(#Pntw2_up >0)AND(#Pc1-db_up >0)AND(#Pc2-db_up >0)}

pL P{#Pdb1Capacity =0}

pK P{#PrepCapacity =0}

λDB1 (1/MTTA) – ((1/MTTA) × pL ) × pDB1up RPO (Async) E{#PwaitRep } / ((λDB1 − (λDB1× pK )) × pC1up × pR )

RTO E{#PwaitDB2 >0} / (P{(#PwaitDB2 >0) AND (#Pc2-db_up >0)

AND (#Pc1-db_up =0)}) × (1/CDB2 ))

0.272595556

0.489817769

0.00 0.02 0.04 0.06 0.08 0.10 0.12 0.14 0.16 0.18 0.20 0.22 0.24 0.26 0.28 0.30 0.32 0.34 0.36 0.38 0.40 0.42 0.44 0.46 0.48 0.50

Slave node in the USA Slave node in Europe

RP O

– A

sy nc

re pl

ic at

io n

(s ec

)

Fig. 7. RPO results for the asynchronous configuration

the DB processing time and the DB replication time achieved by the experiments. Figure 7 displays the RPO results. The best results for the RPO was with the slave node in the USA (near the master DB), showing an RPO of 0.272595 seconds. With the slave node in Europe, the computed RPO was of 0.489817 seconds. We remark that even when the slave node was located on another continent, the RPO results were less than one second. It worth to stress that the RPO is zero for the MySQL semisynchronous configuration because the master only commits a request after receiving an acknowledgment from the slave nodes.

Regarding the RTO, this metric presented the same result for all configurations since we consider that the DR cloud has the same characteristic in both locations (USA and Europe). Therefore, the RTO only depends on the time to detect a disaster and the time that the DB server 2 takes to assume as the primary DB server. In this way, the computed value for the RTO was 41.499 seconds. Note that all the results follow a confidence interval of 95% and an error margin of 5%.

C. Assumptions and Limitations

Some assumptions and limitations were considered in this study: (i) During the experiments, the testbed did not have other workloads. These conditions may not match precisely a business scenario. (ii) The network speed was not considered

in the models since cloud providers usually have great con- nections. (iii) The primary cloud and DR cloud had the same dependability characteristics.

VII. FINAL REMARKS This work presented an approach based on experiments and

analytic modeling to evaluate replication mechanisms on rela- tional databases for DR purposes. We performed experiments in a real-world cloud environment and developed DSPN models to compute DR key-metrics: availability, downtime, RPO, and RTO. The cloud environment was set up in different continents for comparison. Our DSPN analysis revealed that the system’s availability increases when a database replication is used, but it does not achieve five 9’s of availability. Nevertheless, the adopted replication mechanisms can guarantee an RPO and RTO within seconds. For the scenarios studied, the best result was using the slave node at the same continent of the primary DB server. Besides, when the slave node was located on another continent, the RPO was still less than one second. The integrated model-experiment approach presented in this paper can help individuals or organizations to compare DR solutions under construction and provide inputs for the decision-making process. As future works, we consider to analyze different databases and study the trade-offs of the replication mecha- nisms in term of performance.

ACKNOWLEDGMENTS This research was partially funded by FACEPE – Brazil, grant

IBPG-0418-1.03/15.

REFERENCES [1] Zetta, “State of Disaster Recovery 2016,” 2016, [Online]. https://bit.ly/2H6TwhN. [2] IEEE Spectrum’s risk analysis blog, “The biggest it failures of 2018,” 2018.

[Online]. Available: https://bit.ly/2GTNEbj [3] J. Mendonça, E. Andrade, P. T. Endo, and R. Lima, “Disaster recovery solutions for

IT systems: A Systematic mapping study,” Journal of Systems and Software, 2018. [4] T. Shay, “Most popular databases in 2018 according to stackoverflow survey,”

2018. [Online]. Available: https://bit.ly/2DCwqhj [5] DB engines, “Db-engines ranking,” 2019, [Online]. https://bit.ly/2s90XvI. [6] V. D. Jogi and A. Sinha, “Performance evaluation of MySQL, Cassandra and HBase

for heavy write operation,” in 2016 3rd International Conference on Recent Advances in Information Technology (RAIT). IEEE, mar 2016, pp. 586–590.

[7] M. Santana, J. E. Armendáriz-Iñigo, and F. D. Muñoz-Escoí, “Evaluation of Database Replication Techniques for Cloud Systems,” Computing and Informatics, vol. 34, no. 5, pp. 973–995, 2016.

[8] Z. Zhuang, H. Ramachandra, C. Tran, S. Subramaniam, C. Botev, C. Xiong, and B. Sridharan, “Capacity Planning and Headroom Analysis for Taming Database Replication Latency,” in Proceedings of the 6th ACM/SPEC International Conference on Performance Engineering – ICPE ’15. ACM Press, 2015, pp. 39–50.

Having Trouble Meeting Your Deadline?

Get your assignment on ITS-834: Emerging Threats & Countermeasures. Discussion, Final Research Project. completed on time. avoid delay and – ORDER NOW

Get a 20% Discount

[9] N. Azim, A. Khan, F. Khan, A. Majid, S. Roohullah Jan, and M. Tahir, “Offsite 2- Way Data Replication towards Improving Data Refresh Performance,” International Journal of Engineering Trends and Applications (IJETA), 2016.

[10] W. J. Rooney, G. E. McBride, and T. Hanif, “IBM TotalStorage Productivity Center for Replication for z/OS,” IBM Systems Journal, vol. 47, no. 4, pp. 681–694, 2008.

[11] J. Mendonça, R. Lima, R. Matos, J. Ferreira, and E. Andrade, “Availability analysis of a disaster recovery solution through stochastic models and fault injection experiments,” in 2018 IEEE 32nd International Conference on Advanced Information Networking and Applications (AINA), 2018, pp. 135–142.

[12] C. Cassandras and S. Lafortune, Introduction to Discrete Event Systems, 2nd ed. Springer Publishing Company, Incorporated, 2010.

[13] M. Marsan and G. Chiola, “On petri nets with deterministic and exponentially distributed firing times,” in Advances in Petri Nets 1987, 1987, vol. 266, pp. 132–145. [Online]. Available: http://dx.doi.org/10.1007/3-540-18086-9_23

[14] The Apache Software Foundation, “Apache JMeter,” 2019. [Online]. Available: https://jmeter.apache.org

[15] B. Silva, R. Matos, G. Callou, J. Figueiredo, D. Oliveira, J. Ferreira, J. Dantas, A. Lobo, V. Alves, and P. Maciel, “Mercury: An integrated environment for performance and dependability evaluation of general systems,” in Proceedings of Industrial Track at 45th Dependable Systems and Networks Conference, DSN, 2015.

[16] F. Machida, E. Andrade, D. S. Kim, and K. S. Trivedi, “Candy: Component-based Availability Modeling Framework for Cloud Service Management Using SysML,” in IEEE 30th International Symposium on Reliable Distributed Systems, 2011.

2363

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:33 UTC from IEEE Xplore. Restrictions apply.

978-1-7281-3992-0/19/$31.00 ©2019 IEEE

A Study on Security Awareness in Mobile Devices

Mine Zeybek Information Security Engineering Institute of Natural and Applied

Sciences, Gazi University Teknikokullar Ankara 06500, Turkey

[email protected] Orcid: 0000-0002-8652-2082

Ercan Nurcan Yılmaz Electrical and Electronic Engineering

Faculty of Technology, Gazi University Teknikokullar Ankara 06500, Turkey

[email protected] Orcid: 0000-0001-9859-1600

İbrahim Alper Doğru Computer Engineering

Faculty of Technology, Gazi University Teknikokullar Ankara 06500, Turkey

[email protected] Orcid: 0000-0001-9324-7157

Abstract— With life becoming mobile in recent years, the use of smartphones is rapidly increasing in daily and business life. The increase in the use of mobile devices has made it increasingly difficult to ensure their security and privacy. Some of the attacks on mobile devices are related to social engineering. The main way to prevent such attacks is user awareness. In this study; A sample field study was conducted on the awareness of public institution personnel about the use of mobile devices. A questionnaire was developed and applied to 120 qualified public employees. Evaluations were made regarding the answers given in the questionnaire. The controls that can be evaluated to be included in the IT audit are specified and recommendations are made for the protection of mobile devices.

Keywords— Awareness, Mobile device, Cyber security, IT audit

I. INTRODUCTION Smart devices provide users with portable information

technology and make life easier for both personal and business use wherever they have internet access. Mobile phones are the most widely used smart devices in every aspect of our lives. However, these devices vary in terms of both operating systems and security systems and applications.

Looking at the smartphone operating systems in the world market, it is seen that 88% of all smartphones have Android OS in the second quarter of 2018 [1]. In the awareness research conducted within the scope of this study, it was found that 62% of the participants were a mobile device user with Android OS.

The purpose of these devices is to make life better and easier, but users often ignore the risk of security and privacy.

In the Nokia Threat Intelligence Report 2019, it is stated that among smartphones, Android devices are the most malware target. Furthermore, it is stated that 47.15% of malware distributions in mobile networks originate from Android, 35.82% from Windows / PCs, 16.17% from IoTs and less than 1% from IPhones [2].

According to the report published by Kaspersky, the number of attacks using malicious mobile software was 66.4 million in 2017 and 116.5 million in 2018. Researchers report that the number of attacks is increasing but unique malware is decreasing [3].

In this study, malware detection studies in the literature for mobile devices with the most used android operating system in the world market are examined, threats on mobile devices are specified, a field study was carried out for the awareness of the use of mobile devices by the personnel of a public institution, the answers given in the questionnaire were evaluated. In addition, controls that can be assessed for the inclusion of mobile devices for personal use as well as

corporate purposes in information technology audits to contribute to the management of additional risks for organizations specified, to protect mobile devices, systems and therefore institutions from threats; recommendations are presented, including the use of facilitator, consultancy and auditing roles by internal auditors.

II. LITERATURE REVIEW ABOUT MALICIOUS SOFTWARE DETERMINATION STUDIES

When we look at the mobile operating systems in the world market, it is basically the most Android users, so we searched the literature about the detection of malware for Android systems. The number of applications on Android platforms is increasing. However, since the control of applications is insufficient, users can download malware to a large extent. These malware can cause loss of data, money, and so on. Although there are various approaches for detecting malware, it is basically divided into three as static analysis, dynamic analysis and hybrid analysis.

Static analysis examines the downloaded application and source code to look for patterns such as permissions, function calls, and hard-coded variables. It allows detection of malware before it is installed on the device [4].

According to Moser, Kruegel and Kirda, the major advantage of static analysis is that this technique is simple and fast. However, it is a disadvantage that all patterns need to be known in advance and it is difficult to identify new malware without the use of expert or machine learning techniques [5]. Malware can also use confusion techniques in practice to make static analysis even more difficult. In a study by Liu and Liu, malicious software detection was performed with the help of machine learning techniques based on the permissions requested during application installation and the permissions used during application [6]. In a study by Liang and Du, a combination-based method for detecting malware is presented [7]. Droid Detective tool that works offline has been developed. Here, permission combinations that are often requested by malicious applications are obtained, and Droid Detective generates rule sets based on these permission combinations and shows the link between the corresponding malicious behaviors. In the study conducted by Arp, Spreitzenbarth, Hubner, Gascon and Rieck, Machine learning approach was added to the static analysis approach and a tool used to detect malware on Android was presented [8]. With the tool called Drebin, the source code of the android application and its various features, such as application permissions, application programming interface calls and network addresses, are collected using the AndroidManifest file. All of these features come together and are embedded in a vector space and malware detection is performed with the help of the resulting patterns.

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:56 UTC from IEEE Xplore. Restrictions apply.

Dynamic analysis does not examine the source code, but controls the behavior of the application during its use. The suspicious application is usually carried out in a controlled virtual environment, also called a sandbox. In the study conducted by Kurniawan, Rosmansyah and Dabarsyah, Logger, an application that can work within the Android platform, was developed [9]. The logger determines the internet traffic used per minute, the percentage of battery used and the temperature of the battery and sends it to the central server. The central server responds to the client by determining whether the application is malware based on the data in the signature database. In the Zhou and Jiang study, Android provides a systematic approach to malware detection [10]. In this study, data sets containing 1260 Android malware from 49 different malware families were used. Malware is characterized by a variety of behavior patterns, such as loading, activity, and transported data. In their study, Chau and Jung tried to solve existing problems such as the fact that emulators are generally slow in performance and contain traces of heuristic emulation, while the actual devices have limitations to improve the efficiency of analysis by the use of a restore mechanism and hardware. They have developed an android container called C-android using Linux container technology to provide a restore mechanism on the device and make the most of the available hardware. It has been found that C-Android can provide better compatibility than other platforms by making applications to compare other approaches with C android, but some applications have also failed [11]. Accordingly, the advantages;

• Since the analysis tools can be moved to the Linux layer, it is possible to create a normal Android environment without the need for internal analysis or rooting tools,

• Anti-emulator, antianalysis and anti-root control provided in some sensitive applications can be skipped,

• Hardware sharing can help provide both full Android and fewer environments,

are counted as. The disadvantage is that the container model is still core-based and vulnerable to container-based attacks. Sun et al. have implemented a system that identifies known and unknown malware because existing applications rely on the virus database [12]. In the system, certain applications that use the installation of a kernel module can be monitored, after detection, related documents are uploaded to the server and dynamic behaviors are recreated. As a result, a behavior diagram is produced. In addition, if the user needs to know if the application is malicious, the corresponding Android package can be sent to the server and analyzed. The results are then calculated and transmitted to the user.

Hybrid analysis is defined as the analysis method in which static analysis and dynamic analysis approaches are used together. In their study, Mao et al. emphasized the blocking of JavaScript function calls in hybrid applications [13]. When the JavaScripthibrit application is running, it reports the function level activity and extracts events from the WebView component to improve the behavior model. The solution in the Android system is prototyped and evaluated using real-world hybrid Android applications. However, it is noted that the detection in this approach is based on the function call relationship and triggering events, despite the effectiveness of the sample investigations, that attackers may be able to inject

and activate the code under the same condition as in the original application, and in such cases the approach may miss injections within the target function.

Li and colleagues in their study, to improve the efficiency of detection of malicious applications running on Android, propose a feature-based malware detection system [14]. A new android platform based on machine learning and feature integration, combining the advantages of static and dynamic detection, and a malware detection framework are proposed.

III. THREATS IN MOBILE DEVICES The fact that mobile devices are a part of our daily lives

has brought many threats and risks. In particular, related the use of mobile phones, in case of the lack of awareness about the devices we use and their security there may be material and moral losses in cases such as theft or loss.

Although the user-selected application does not contain harmful content, it can create security vulnerability if it is not a stable application. The application can be attacked through the wrong code snippets within the application code and these openings can be used against the user [15].

• By means of malicious code deliberately placed in the application, the user can be dominated [15].

• Some applications are able to perform what they intervene by running other applications without the user's approval [16].

• Some applications may access browser or application download services and download and run different applications to mobile devices without the user's permission [15].

• The user's searches, interests, frequently visited sites, shopping preferences, etc. all transactions on the mobile device are examined and according to these data, customized advertisements can be sent to the user without request [17].

• By sending a text message to the toll phone numbers that are unaware of the user, the user can spend money [18].

• In banking transactions, user identification and financial data records can be obtained [19, 20].

• Special information can be accessed by listening to the media via the microphone [19].

• Keylogger-style applications with unauthorized operation on the mobile device, clicked or touched by the user can record every movement [21].

• By capturing the session previously opened by the mobile user, it is possible to bypass the authentication part of the email system [21].

• By capturing the user's IMEI (International Mobile Device ID) number, GPS location information, phone book, device model and serial number, conversation records, installed applications, e-mail information, browser histories and photographs; can be used for blackmail, espionage or financial gain [22].

• By disrupting the service to the mobile device, the device can be rendered unusable or overloaded by

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:56 UTC from IEEE Xplore. Restrictions apply.

overloading, causing the device to discharge in a short time [23].

IV. FIELD RESEARCH ON MOBILE DEVICE USER AWARENESS

In this study, a field study was conducted to evaluate mobile device user awareness. The field research was conducted with 120 people among the employees of a public institution using the survey method. The basic topics in the survey are the operating system of the device used, whether the device has antivirus software or applications installed or in use, whether the screen lock is used to prevent unauthorized access to the devices physically, and whether or not the contents of the required access permissions are installed before the application is installed on the devices used for business purposes, and whether these devices used in work- related operations are allowed to be used by different people. In addition, it was assessed whether mobile devices used for personal or corporate purposes are included in the corporate network using wireless internet access provided by the organization. Figure 1 shows screen lock usage percentages by gender.

Fig. 1. Screen lock usage rates for women and men

In this context, 62% of the devices used by the users participating in the study, as shown in Figure 2, is stated to be a mobile device with Android OS while 5% of the users do not even know the operating system of the device they use.

Fig. 2. Operating system usage percentages

99% of the users participating in the study stated that their devices have internet access.

Figure 3 shows the percentages of corporate network usage on personel mobile devices.

In addition, as seen in Figure 4, it is found that users mostly use their mobile devices for internet browsing, personal e-mail access, banking transactions and social media tracking.

Figure 5 shows the permission reading percentage by gender. In this content, 44% of women read permissions, 34% read sometimes, 22% do not. 51% of men read permissions, 37% sometimes read, 12% do not. In addition, according to

the survey, 16% of respondents do not read the application permissions, and 68% of them refuse to install the application because of the application permissions.

According to the answers given, 65% of the users use their mobile devices for business purpose like reading e-mail. Furthermore, 90% of them had access to personal e-mail, 80% had social media tracking, and 65% had mobile shopping on their mobile devices (Figure 6). In addition, 83% did not install applications from outside Playstore or Appstore; 21% of them are currently using antivirus software (Figure 7).

Fig. 3. Corporate network usage

Fig. 4. Intended use of mobile devices

Fig. 5. Permission reading percentage by gender

However, it is seen that 3% of the users using their mobile devices in corporate transactions such as accessing corporate e-mail are IOS users and those people still do not have the antivirus software they use, and even those who emphasize that they are IOS users.

Yes 89%

No 11%

Screen Lock Usage (% of Male

Participants)

Yes 83%

No 17%

Screen Lock Usage (% of Female Participants)

Android 62%

iOS 33%

Not Known 5%

OS Usage (%)

58% 42%

Corparate WiFi Network Usage on Personal Mobile Devices

Using corporate WiFi Not using corporate WiFi

6 9

36 45

62

65

9599

104

107

# of Applications/Purpose Usage on the Mobile Devices

Other

Smart Devices Cont.

Business

Gaming

Corp. e-Mail

Shopping

Social Media

Pers. e-Mail

e-Banking

Web Surfing

0% 10% 20% 30% 40% 50% 60%

Reading Not reading

Sometimes reading

Men 51% 12% 37%

Women 44% 22% 34%

Permission reading percentage by gender

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:56 UTC from IEEE Xplore. Restrictions apply.

Fig. 6. Ratio of participants using mobile devices for business purposes and other uses of these users

Fig. 7. Awareness of participants about mobile devices using mobile devices for business purposes

V. AUDIT APPROACH FOR MOBILE DEVICES The widespread use of mobile devices enables people to

work independently of place and time and makes life easier with many applications.

For these reasons, in most institutions other than private life, users can also monitor, control and communicate business with their own devices or with the mobile devices that the institution gives them, even creating documents.

In this context, regulations are also made regarding the use of mobile devices in public institutions in our country.

First of all, in organizations that use mobile devices in their work, updating the information technology architecture structures to include mobile devices and systems, processes, policies, procedures, data, infrastructure and employees will ensure compliance, physical security and information security and privacy risks are considered at the level of mobile technology in investment, controls and audits.

When the threat areas related to mobile technology are considered in three categories as devices, infrastructure, people; while the risks in the threat area associated with people can only be reduced with awareness, control tests to reduce the risk of data loss, unauthorized access and fraud related to the device and infrastructure are proposed as follows [24]:

Tests to reduce the risks in the threat area associated with device;

• Encryption of the data at rest in the mobile device application is set to Advanced Encryption Standard (AES) 128, 192 or 256.

• Encryption of data is enforced for data in transit using Secure Sockets Layer (SSL) and strong security protocols such as:

a. Web access—HTTPS vs. HTTP

b. File transfer—FTPS, SFTP, SCP, WebDAV over HTTPS vs. FTP, RCP

c. Security protocols—Transport Layer Security (TLS).

• Binary protections are standard protocol for application development life cycle and enforced by the development team at time of application coding and maintenance.

• Mobile application management (MAM) is utilized to manage access and deployment of the application. Additionally, proper whitelists and blacklists are maintained. Examples of MAM services include MobileIron, Airwatch and Apperian, providing a central online location for distribution and tracking purpose.

• A governance structure is in place for mobile app life cycle management, specifically, the release of mobile applications to the application store and modification of future releases.

• The application is signed using the enterprise account of the company’s enterprise account certificate.

• Enterprise applications that are released to company employees or contractors using companyowned devices utilize a remote mobile management software, such as MobileIron, to facilitate remote wiping.

Tests to reduce the risks in the threat area associated with infrastructure;

• Transmission of data utilizes, at a minimum, SSL or TLS—both cryptographic protocols for secure transmission of data.

Using for Business

65%

Other 35%

Usage Rate

7%

10%

46%

65%

80%

90%

94%

94%

0% 20% 40% 60% 80% 100%

Other

Smart Devices Cont.

Gaming

Shopping

Social Media

Pers. e-Mail

e-Banking

Web Surfing

Other Uses of Business Users

21%

35%

49%

74%

83%

91%

94%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Antivirus App Using

Authorized Usage

Reading Application Permissions

Updating without Delay

Installing App from Official Store

Screen Lock Using

Installation Rejection due to App's Permissions

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:56 UTC from IEEE Xplore. Restrictions apply.

• Connection protocols for the uniform resource locator (URL) via TLS are through HTTPS rather than HTTP to securely connect to a URL.

• Proper packet filtering setup is built in to verify source address and blocking packets with conflicting source address. Utilization of TLS, Secure Shell (SSH) and HTTPS is enabled for secure communication protocol.

• Processes exist for the deployment of system patches for all applicable systems. Processes exist for identifying new patches or for notification of new patches from vendors. The system is current with the latest patches prescribed from central IT. If any vulnerability scans have been performed, patches have been applied to address any identified issues. Missing patches are identified and compared against documented formal exceptions from security team.

• All applicable web servers have been assigned both technical and business system owners, as required. The defined roles and responsibilities are adequate, especially for internal and thirdparty personnel.

• Lock-out protocols are enabled for accounts with multiple incorrect password attempts. Utilization of CAPTCHA (program that distinguishes between humans and computers) is recommended to avoid DoS.

• Access to database is limited to appropriate individuals, and proper access reviews and documented system accounts are kept on file. All default accounts and passwords are disabled by enforcing strict password controls.

• Input validation technique is in place; specifically defined rules for type and syntax against key business rules exist.

• Sanitization of application user data coming from the mobile application is properly protected through embedded logic checks within the application. Proper implementation of logic checks is enabled at the server side.

• The database server is properly tested and hardened against malicious attack. Login forms have HTTPS required. SSL connections are mandatory.

VI. RECOMMENDATIONS FOR THE SECURITY OF MOBILE DEVICES

Users should be aware of the value of mobile devices and the data inside, and be careful about moving them safely, and forgetting, losing or stealing. Furthermore, the measures that can be taken regarding security are listed below:

• User awareness of application permissions and requirements should be high, access rights should be queried and applications requiring unnecessary permissions should not be preferred [15].

• During application installation, the criteria of the application, such as certificates or electronic signatures, should be checked for reliability [16].

• Antiviral software and applications that detect both viruses and spyware should be used [25].

• The data considered to be important should not be kept in the device, if it is to be kept encrypted, [22, 26, 27].

• The data stored on the mobile device should be backed up regularly and very important data should never be kept only on the mobile device [23].

• Wi-Fi and bluetooth access should be turned off when not in use [23, 26].

• Application usage rate and battery information should be compared and sould be check whether the unaware application is running in the background [23, 26].

• Applications not to be used should not be downloaded to the phone [15].

• Gift phone should not be taken [28].

• The remote data wipe and lock feature must be activated [28].

• Passwords used in mobile devices should not be easily predictable [23, 27].

• The IMEI number must be registered against the risk of theft or loss of the mobile device [23].

• All files copied and downloaded to the mobile device should be used after virus scanning [23].

• Mobile device application developers should be aware of vulnerabilities in operating systems and develop applications accordingly [29].

• Mobile device manufacturers should deliver the device to the user with antivirus software installed [30].

• Telephone operators should educate their customers on how to identify and protect mobile viruses [30].

• The “secure internet” service provided by the operators must be utilized [15].

• In mobile devices using network and internet connections, the firewall should be installed and kept open at all times [22].

• The network applications of the devices should be turned off or the ‘visibility’ option should be set to ‘hidden’. Sales personnel should provide information to users to ensure that these features are used [23].

• Mobile devices must be set up to require authentication for access [23].

• The scope of crimes committed in mobile environments should be determined and legal regulations should be made on this issue [23].

• Rights related to downloaded applications should be known [15].

• Awareness should be raised that users themselves are responsible for all actions taken, even if they do not have the knowledge and permission [15, 23].

• Awareness trainings should be organized in order to raise the awareness that the security of mobile devices is a part of personal and corporate information security.

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:56 UTC from IEEE Xplore. Restrictions apply.

VII. RESULT The use of smart phones in daily life and business life is

increasing rapidly with the life becoming mobile in recent years. Occasionally, confidential information or documents can be received by malicious people via mobile phones. Only applications that analyze malware cannot block malicious people. User awareness is very important here. Awareness training and malware analysis are required. In general, awareness training is provided through external institutions. However, internal audit mechanisms exist in the institutions and there are internal auditors who are knowledgeable about this subject. Internal auditors in institutions should be used at this point, and given roles such as consultants, facilitators or trainers on risk analysis and awareness issues. Internal auditors should consider that the mobile systems integrate with the information technologies in their institutions. They should assist senior management to provide reasonable assurance that the risks are appropriately controlled in their audits. Most importantly, it should be remembered that it is very important for users to become aware of the data security practices and their permissions.

REFERENCES [1] A.Host, 2019 “Global mobile OS market share in sales to end users from

1st quarter 2009 to 2nd quarter 2018” Available from URL: https://www.statista.com/statistics/266136/global-market-share-held- by-smartphone-operating-systems/ . Site last visited April 2019.

[2] “Nokia_Threat_Intelligence_Report”, White_Paper, 2018. Available from URL: https://www.wisdominterface.com/wp- content/uploads/2019/01/Nokia_Threat_Intelligence_Report_White_Pa per_EN.pdf. Site last visited April 2019.

[3] “The number of mobile malware attacks doubles in 2018, as cybercriminals sharpen their distribution strategies”, Kaspersky, Available from URL: https://www.kaspersky.com/about/press- releases/2019_the-number-of-mobile-malware-attacks-doubles-in- 2018-as-cybercriminals-sharpen-their-distribution-strategies. Site last visited April 2019.

[4] A.T. Kabakuş, İ.A. Doğru, A. Çetin “Android kötücül yazılım tespit ve koruma sistemleri” Erciyes Üniversitesi Fen Bilimleri Enstitüsü Dergisi, 2015, pp. 9-16.

[5] A. Moser, C. Kruegel, E. Kirda, “.Limits of Static Analysis for Malware Detection.” IEEE, 2007. pp 421-430.

[6] X. Liu, J. Liu, “A Two-layered Permission-based Android Malware Detection Scheme.” IEEE, 2014. pp 142-148.

[7] S. Liang, X. Du, “Permission-Combination-based Scheme for Android Mobile Malware Detection.” IEEE, 2014. pp 2301-2306.

[8] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, K. Rieck, “Drebin: effective and explainable detection of Android malware in your pocket.” In: Symposium on network and distributed system security (NDSS), 2014. pp 1-15.

[9] H. Kurniawan, Y. Rosmansyah, B. Dabarsyah, “Android anomaly detection system using machine learning classification.” IEEE, 2015. pp 288-293.

[10] Y. Zhou, X. Jiang, “Dissecting Android Malware: Characterization and Evolution.” IEEE, 2012. pp 95-109.

[11] N.T. Chau, S. Jung. “Dynamic analysis with Android container: Challenges and Oppprtunities.” Digital Investigation, 2018. pp 38-46.

[12] S. Sun, X. Fu, H. Ruan, X. Du, B. Luo, M. Guizani, “Real-Time Behavior Analysis and Identification for android application.” IEEE, 2018. pp 38041-38051.

[13] J. Mao, J. Bıan, G. Baı, R. Wang, Y. Chen, Y. Xıao, Z. Lıang, “Detecting malicious behaviors in javascript applications.” IEEE, 2018. pp 12284- 12294.

[14] J. Lı, Z. Wang, T. Wang, J. Tang, Y. Yang, Y. Zhou, “An android malware detection system based on feature fusion.” Chinese Journal of Electronics, 2018. pp 1206-1213.

[15] B. Arslan, M. S. Gündüz, Ş. Sağıroğlu. “Güncel Mobil Tehditler ve Alınması Gereken Önlemler.” Conference: International Symposium on Digital Forensics and Security 2015.

[16] S. M. Dye, K. Scarfone, “A standard for developing secure mobile applications.” Computer Standards & Interfaces, 2014. pp 524-530.

[17] N. Şahin, N. Tuna, S. İ. Tütüncü, “Yeni Ekonomi Sürecinde Bilgi İletişim Teknolojileri (Bit) Tabanlı Reklam Uygulamalarına Yönelik Bir İnceleme.” Uşak Üniversitesi Sosyal Bilimler Dergisi, 2014.

[18] K. Dunham, “Mobile Malware Attacks and Defense,” syngress 2009. [19] A. Ekim, “Mobil Cihazlarda Adli Bilişim ve Malware Analizi,” Elazığ:

1st International Symposium on Digital Forensics and Security, 2013. [20] M. D. Cano, G. D. Asensi, “A secure energy-efficient m-banking

application for mobile devices.” The Journal of Systems and Software, 2011. pp 1899-1909.

[21] E.İ. Tatlı, 2005, “Saldırı Ağaçları (Attack_Trees)” Available from URL: “https://www.researchgate.net/profile/Emin_Tatli/publication/2615107 89_Saldiri_Agaclari_Attack_Trees/links/0f3175346f77293a82000000/ Saldiri-Agaclari-Attack-Trees.pdf.” Site last visited April 2019.

[22] E. Masum, R. Samet, “Mobil BOTNET ile DDoS Saldırısı.” Bilişim Teknolojileri Dergisi, 2018, pp 111-121.

[23] Ş. Sağıroğlu, H. Bulut, “Mobil Ortamlarda Bilgi ve Haberleşme Güvenliği Üzerine Bir İnceleme,” Gazi Üniv. Müh. Mim. Fak. Der, 2009. pp 499-507.

[24] M.J.Khan, “Mobile App. Security Audit Framework.” ISACA Journal, 2016.

[25] G. Shaw, “Spyware & Adware: the Risks facing Businesses.” Network Security, 2003. pp 12-14.

[26] S. Mohite, R. S. Sonar, “A Survey on Mobile Malware: A War without End.” International Journal of Computer Science and Business Informatics, 2014. pp 23-35.

[27] G. Karataş, A. Akbulut, A. H. Zaim, “Mobil Cihazlarda Güvenlik – Tehditler ve Temel Stratejiler.”Istanbul Commerce University Journal of Science, 2016. pp 55-75.

[28] E. Karaarslan, M. Demir, V. Fetah. “Akıllı Telefonlarda Gizlilik ve Mahremiyet: Durum Saptaması ve Öneriler.” Available from URL: https://ab.org.tr/ab16/bildiri/42.pdf . Site last visited April 2019

[29] A. P. Felt, M. Finifter, E. Chin, S. Hanna, D. Wagner, “A Survey of Mobile Malware in the Wild.” SPSM’11, 2011.

[30] M. Hypponen “Malware goes mobile.” Scientific American, 2006. pp 70-77.

Authorized licensed use limited to: University of the Cumberlands. Downloaded on February 16,2022 at 00:34:56 UTC from IEEE Xplore. Restrictions apply.