Subject: ITS-834: Emerging Threats & Countermeasures
Reading Resources:
M. Ioannou, E. Stavrou and M. Bada, “Cybersecurity Culture in Computer Security Incident Response Teams: Investigating difficulties in communication & coordination,” 2019 International Conference on Cyber Security & Protection of Digital Services (Cyber Security), 2019, 1-4.
https://ieeexplore.ieee.org/document/8885240
J. Mendonça, W. Medeiros, E. Andrade, R. Maciel, P. Maciel and R. Lima, “Evaluating Database Replication Mechanisms for Disaster Recovery in Cloud Environments,” 2019 IEEE International Conference on Systems, Man and Cybernetics (SMC), Bari, Italy, 2019, pp. 2358-2363.
https://ieeexplore.ieee.org/document/8914069
M. Zeybek, E. N. Yılmaz and İ. Alper Doğru, “A Study on Security Awareness in Mobile Devices,” 2019 1st International Informatics and Software Engineering Conference (UBMYK), Ankara, Turkey, 2019, 1-6.
https://ieeexplore.ieee.org/document/8965476
Textbook Title: (ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide ISBN: 9781119475958, Authors: Mike Chapple, James Michael Stewart, Darril Gibson, Publisher: John Wiley & Sons, Publication Date: 2018-04-10
Discussion: Web Server Auditing
Word count: 300+ words
Chapters 17, and 18 in the course textbook
Web server auditing can go a long way in enforcing tighter security and ensuring business continuity. The power of log data is tremendous. Web server logs record valuable information pertaining to usage, errors, and other important security events. Using a specialized auditing tool can be extremely helpful during the audit of web servers. In your discussion this week, please discuss the methods of identifying weak web server configurations and how to mitigate them for a secure web server. Possible concepts to include are SSL certificates, HTTPS usage, attack surface, SQL injection, vulnerability migration, and least privilege. In at least one of your peer responses, provide an overview of how to audit the web server’s security and implement best practices.
– Make sure to back up your statements with scholarly support.·
– Please cite properly in APA 7·
– At least one scholarly source should be used. ·
– Use proper citations and references in your post.
Final
Research Pr
oject:
Number of pages: 6+
Develop a disaster recovery plan for an organization. There are many different templates available online for you to use as reference and guidance. Your plan should cover the following sections (these sections detail the elements in a DR plan in the sequence defined by industry compliance standards ISO 27031 and ISO 24762):
1. Important: This section should summarize key action steps (such as where to assemble employees if forced to evacuate the building) and list key contacts with contact information for ease of authorizing and launching the plan.
2. Introduction
3. Roles and Responsibilities
4. Incident Response
5. Plan Activation
6. Document History
7. Procedures
Your poject should meet the following requirements:·
– 6+ pages in length, not including the required cover page and reference page.·
– Follow APA 7 guidelines.
– Your paper should include an introduction, a body with fully developed content, and a conclusion.·
– Support your answers with the readings from the course and at least four scholarly journal articles to support your positions, claims, and observations, in addition to your textbook.
– Be clearly and well-written, concise, and logical, using excellent grammar and style techniques. You are being graded in part on the quality of your writing.
Note: plagiarism check required, APA7 format, include References, within 8hrsThis post has 2 individual assignments (discussion, and Final research project).
Please provide answers in separate documents.
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
mioannou4@uclan.ac.uk
Dr. Eliana Stavrou
Applied Cybersecurity Research Lab
University of Central Lancashire
Cyprus
Larnaka, Cyprus
estavrou@uclan.ac.uk
Dr. Maria Bada
The Department of Computer Science
and Technology
Cambridge Cybercrime Centre
University of Cambridge
Cambridge, UK
maria.bada@cl.cam.ac.uk
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 ?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 )
[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
jrmn@cin.ufpe.br, {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 (maste
r)
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.
[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
mbazer@gmail.com
Orcid: 0000-0002-8652-2082
Ercan Nurcan Yılmaz
Electrical and Electronic Engineering
Faculty of Technology, Gazi University
Teknikokullar Ankara 06500, Turkey
enyilmaz@gazi.edu.tr
Orcid: 0000-0001-9859-1600
İbrahim Alper Doğru
Computer Engineering
Faculty of Technology, Gazi University
Teknikokullar Ankara 06500, Turkey
iadogru@gazi.edu.tr
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
1
7%
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 . 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 .” 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 . 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.
<<
/ASCII85EncodePages false
/AllowTransparency false
/AutoPositionEPSFiles true
/AutoRotatePages /None
/Binding /Left
/CalGrayProfile (Gray Gamma 2.2)
/CalRGBProfile (sRGB IEC61966-2.1)
/CalCMYKProfile (U.S. Web Coated \050SWOP\051 v2)
/sRGBProfile (sRGB IEC61966-2.1)
/CannotEmbedFontPolicy /Error
/CompatibilityLevel 1.7
/CompressObjects /Off
/CompressPages true
/ConvertImagesToIndexed true
/PassThroughJPEGImages true
/CreateJobTicket false
/DefaultRenderingIntent /Default
/DetectBlends true
/DetectCurves 0.0000
/ColorConversionStrategy /LeaveColorUnchanged
/DoThumbnails false
/EmbedAllFonts true
/EmbedOpenType false
/ParseICCProfilesInComments true
/EmbedJobOptions true
/DSCReportingLevel 0
/EmitDSCWarnings false
/EndPage -1
/ImageMemory 1048576
/LockDistillerParams true
/MaxSubsetPct 100
/Optimize true
/OPM 0
/ParseDSCComments false
/ParseDSCCommentsForDocInfo true
/PreserveCopyPage true
/PreserveDICMYKValues true
/PreserveEPSInfo false
/PreserveFlatness true
/PreserveHalftoneInfo true
/PreserveOPIComments false
/PreserveOverprintSettings true
/StartPage 1
/SubsetFonts true
/TransferFunctionInfo /Remove
/UCRandBGInfo /Preserve
/UsePrologue false
/ColorSettingsFile ()
/AlwaysEmbed [ true
/AbadiMT-CondensedLight
/ACaslon-Italic
/ACaslon-Regular
/ACaslon-Semibold
/ACaslon-SemiboldItalic
/AdobeArabic-Bold
/AdobeArabic-BoldItalic
/AdobeArabic-Italic
/AdobeArabic-Regular
/AdobeHebrew-Bold
/AdobeHebrew-BoldItalic
/AdobeHebrew-Italic
/AdobeHebrew-Regular
/AdobeHeitiStd-Regular
/AdobeMingStd-Light
/AdobeMyungjoStd-Medium
/AdobePiStd
/AdobeSongStd-Light
/AdobeThai-Bold
/AdobeThai-BoldItalic
/AdobeThai-Italic
/AdobeThai-Regular
/AGaramond-Bold
/AGaramond-BoldItalic
/AGaramond-Italic
/AGaramond-Regular
/AGaramond-Semibold
/AGaramond-SemiboldItalic
/AgencyFB-Bold
/AgencyFB-Reg
/AGOldFace-Outline
/AharoniBold
/Algerian
/Americana
/Americana-ExtraBold
/AndaleMono
/AndaleMonoIPA
/AngsanaNew
/AngsanaNew-Bold
/AngsanaNew-BoldItalic
/AngsanaNew-Italic
/AngsanaUPC
/AngsanaUPC-Bold
/AngsanaUPC-BoldItalic
/AngsanaUPC-Italic
/Anna
/ArialAlternative
/ArialAlternativeSymbol
/Arial-Black
/Arial-BlackItalic
/Arial-BoldItalicMT
/Arial-BoldMT
/Arial-ItalicMT
/ArialMT
/ArialMT-Black
/ArialNarrow
/ArialNarrow-Bold
/ArialNarrow-BoldItalic
/ArialNarrow-Italic
/ArialRoundedMTBold
/ArialUnicodeMS
/ArrusBT-Bold
/ArrusBT-BoldItalic
/ArrusBT-Italic
/ArrusBT-Roman
/AvantGarde-Book
/AvantGarde-BookOblique
/AvantGarde-Demi
/AvantGarde-DemiOblique
/AvantGardeITCbyBT-Book
/AvantGardeITCbyBT-BookOblique
/BakerSignet
/BankGothicBT-Medium
/Barmeno-Bold
/Barmeno-ExtraBold
/Barmeno-Medium
/Barmeno-Regular
/Baskerville
/BaskervilleBE-Italic
/BaskervilleBE-Medium
/BaskervilleBE-MediumItalic
/BaskervilleBE-Regular
/Baskerville-Bold
/Baskerville-BoldItalic
/Baskerville-Italic
/BaskOldFace
/Batang
/BatangChe
/Bauhaus93
/Bellevue
/BellMT
/BellMTBold
/BellMTItalic
/BerlingAntiqua-Bold
/BerlingAntiqua-BoldItalic
/BerlingAntiqua-Italic
/BerlingAntiqua-Roman
/BerlinSansFB-Bold
/BerlinSansFBDemi-Bold
/BerlinSansFB-Reg
/BernardMT-Condensed
/BernhardModernBT-Bold
/BernhardModernBT-BoldItalic
/BernhardModernBT-Italic
/BernhardModernBT-Roman
/BiffoMT
/BinnerD
/BinnerGothic
/BlackadderITC-Regular
/Blackoak
/blex
/blsy
/Bodoni
/Bodoni-Bold
/Bodoni-BoldItalic
/Bodoni-Italic
/BodoniMT
/BodoniMTBlack
/BodoniMTBlack-Italic
/BodoniMT-Bold
/BodoniMT-BoldItalic
/BodoniMTCondensed
/BodoniMTCondensed-Bold
/BodoniMTCondensed-BoldItalic
/BodoniMTCondensed-Italic
/BodoniMT-Italic
/BodoniMTPosterCompressed
/Bodoni-Poster
/Bodoni-PosterCompressed
/BookAntiqua
/BookAntiqua-Bold
/BookAntiqua-BoldItalic
/BookAntiqua-Italic
/Bookman-Demi
/Bookman-DemiItalic
/Bookman-Light
/Bookman-LightItalic
/BookmanOldStyle
/BookmanOldStyle-Bold
/BookmanOldStyle-BoldItalic
/BookmanOldStyle-Italic
/BookshelfSymbolOne-Regular
/BookshelfSymbolSeven
/BookshelfSymbolThree-Regular
/BookshelfSymbolTwo-Regular
/Botanical
/Boton-Italic
/Boton-Medium
/Boton-MediumItalic
/Boton-Regular
/Boulevard
/BradleyHandITC
/Braggadocio
/BritannicBold
/Broadway
/BrowalliaNew
/BrowalliaNew-Bold
/BrowalliaNew-BoldItalic
/BrowalliaNew-Italic
/BrowalliaUPC
/BrowalliaUPC-Bold
/BrowalliaUPC-BoldItalic
/BrowalliaUPC-Italic
/BrushScript
/BrushScriptMT
/CaflischScript-Bold
/CaflischScript-Regular
/Calibri
/Calibri-Bold
/Calibri-BoldItalic
/Calibri-Italic
/CalifornianFB-Bold
/CalifornianFB-Italic
/CalifornianFB-Reg
/CalisMTBol
/CalistoMT
/CalistoMT-BoldItalic
/CalistoMT-Italic
/Cambria
/Cambria-Bold
/Cambria-BoldItalic
/Cambria-Italic
/CambriaMath
/Candara
/Candara-Bold
/Candara-BoldItalic
/Candara-Italic
/Carta
/CaslonOpenfaceBT-Regular
/Castellar
/CastellarMT
/Centaur
/Centaur-Italic
/Century
/CenturyGothic
/CenturyGothic-Bold
/CenturyGothic-BoldItalic
/CenturyGothic-Italic
/CenturySchL-Bold
/CenturySchL-BoldItal
/CenturySchL-Ital
/CenturySchL-Roma
/CenturySchoolbook
/CenturySchoolbook-Bold
/CenturySchoolbook-BoldItalic
/CenturySchoolbook-Italic
/CGTimes-Bold
/CGTimes-BoldItalic
/CGTimes-Italic
/CGTimes-Regular
/CharterBT-Bold
/CharterBT-BoldItalic
/CharterBT-Italic
/CharterBT-Roman
/CheltenhamITCbyBT-Bold
/CheltenhamITCbyBT-BoldItalic
/CheltenhamITCbyBT-Book
/CheltenhamITCbyBT-BookItalic
/Chiller-Regular
/Cmb10
/CMB10
/Cmbsy10
/CMBSY10
/CMBSY5
/CMBSY6
/CMBSY7
/CMBSY8
/CMBSY9
/Cmbx10
/CMBX10
/Cmbx12
/CMBX12
/Cmbx5
/CMBX5
/Cmbx6
/CMBX6
/Cmbx7
/CMBX7
/Cmbx8
/CMBX8
/Cmbx9
/CMBX9
/Cmbxsl10
/CMBXSL10
/Cmbxti10
/CMBXTI10
/Cmcsc10
/CMCSC10
/Cmcsc8
/CMCSC8
/Cmcsc9
/CMCSC9
/Cmdunh10
/CMDUNH10
/Cmex10
/CMEX10
/CMEX7
/CMEX8
/CMEX9
/Cmff10
/CMFF10
/Cmfi10
/CMFI10
/Cmfib8
/CMFIB8
/Cminch
/CMINCH
/Cmitt10
/CMITT10
/Cmmi10
/CMMI10
/Cmmi12
/CMMI12
/Cmmi5
/CMMI5
/Cmmi6
/CMMI6
/Cmmi7
/CMMI7
/Cmmi8
/CMMI8
/Cmmi9
/CMMI9
/Cmmib10
/CMMIB10
/CMMIB5
/CMMIB6
/CMMIB7
/CMMIB8
/CMMIB9
/Cmr10
/CMR10
/Cmr12
/CMR12
/Cmr17
/CMR17
/Cmr5
/CMR5
/Cmr6
/CMR6
/Cmr7
/CMR7
/Cmr8
/CMR8
/Cmr9
/CMR9
/Cmsl10
/CMSL10
/Cmsl12
/CMSL12
/Cmsl8
/CMSL8
/Cmsl9
/CMSL9
/Cmsltt10
/CMSLTT10
/Cmss10
/CMSS10
/Cmss12
/CMSS12
/Cmss17
/CMSS17
/Cmss8
/CMSS8
/Cmss9
/CMSS9
/Cmssbx10
/CMSSBX10
/Cmssdc10
/CMSSDC10
/Cmssi10
/CMSSI10
/Cmssi12
/CMSSI12
/Cmssi17
/CMSSI17
/Cmssi8
/CMSSI8
/Cmssi9
/CMSSI9
/Cmssq8
/CMSSQ8
/Cmssqi8
/CMSSQI8
/Cmsy10
/CMSY10
/Cmsy5
/CMSY5
/Cmsy6
/CMSY6
/Cmsy7
/CMSY7
/Cmsy8
/CMSY8
/Cmsy9
/CMSY9
/Cmtcsc10
/CMTCSC10
/Cmtex10
/CMTEX10
/Cmtex8
/CMTEX8
/Cmtex9
/CMTEX9
/Cmti10
/CMTI10
/Cmti12
/CMTI12
/Cmti7
/CMTI7
/Cmti8
/CMTI8
/Cmti9
/CMTI9
/Cmtt10
/CMTT10
/Cmtt12
/CMTT12
/Cmtt8
/CMTT8
/Cmtt9
/CMTT9
/Cmu10
/CMU10
/Cmvtt10
/CMVTT10
/ColonnaMT
/Colossalis-Bold
/ComicSansMS
/ComicSansMS-Bold
/Consolas
/Consolas-Bold
/Consolas-BoldItalic
/Consolas-Italic
/Constantia
/Constantia-Bold
/Constantia-BoldItalic
/Constantia-Italic
/CooperBlack
/CopperplateGothic-Bold
/CopperplateGothic-Light
/Copperplate-ThirtyThreeBC
/Corbel
/Corbel-Bold
/Corbel-BoldItalic
/Corbel-Italic
/CordiaNew
/CordiaNew-Bold
/CordiaNew-BoldItalic
/CordiaNew-Italic
/CordiaUPC
/CordiaUPC-Bold
/CordiaUPC-BoldItalic
/CordiaUPC-Italic
/Courier
/Courier-Bold
/Courier-BoldOblique
/CourierNewPS-BoldItalicMT
/CourierNewPS-BoldMT
/CourierNewPS-ItalicMT
/CourierNewPSMT
/Courier-Oblique
/CourierStd
/CourierStd-Bold
/CourierStd-BoldOblique
/CourierStd-Oblique
/CourierX-Bold
/CourierX-BoldOblique
/CourierX-Oblique
/CourierX-Regular
/CreepyRegular
/CurlzMT
/David-Bold
/David-Reg
/DavidTransparent
/Dcb10
/Dcbx10
/Dcbxsl10
/Dcbxti10
/Dccsc10
/Dcitt10
/Dcr10
/Desdemona
/DilleniaUPC
/DilleniaUPCBold
/DilleniaUPCBoldItalic
/DilleniaUPCItalic
/Dingbats
/DomCasual
/Dotum
/DotumChe
/DoulosSIL
/EdwardianScriptITC
/Elephant-Italic
/Elephant-Regular
/EngraversGothicBT-Regular
/EngraversMT
/EraserDust
/ErasITC-Bold
/ErasITC-Demi
/ErasITC-Light
/ErasITC-Medium
/ErieBlackPSMT
/ErieLightPSMT
/EriePSMT
/EstrangeloEdessa
/Euclid
/Euclid-Bold
/Euclid-BoldItalic
/EuclidExtra
/EuclidExtra-Bold
/EuclidFraktur
/EuclidFraktur-Bold
/Euclid-Italic
/EuclidMathOne
/EuclidMathOne-Bold
/EuclidMathTwo
/EuclidMathTwo-Bold
/EuclidSymbol
/EuclidSymbol-Bold
/EuclidSymbol-BoldItalic
/EuclidSymbol-Italic
/EucrosiaUPC
/EucrosiaUPCBold
/EucrosiaUPCBoldItalic
/EucrosiaUPCItalic
/EUEX10
/EUEX7
/EUEX8
/EUEX9
/EUFB10
/EUFB5
/EUFB7
/EUFM10
/EUFM5
/EUFM7
/EURB10
/EURB5
/EURB7
/EURM10
/EURM5
/EURM7
/EuroMono-Bold
/EuroMono-BoldItalic
/EuroMono-Italic
/EuroMono-Regular
/EuroSans-Bold
/EuroSans-BoldItalic
/EuroSans-Italic
/EuroSans-Regular
/EuroSerif-Bold
/EuroSerif-BoldItalic
/EuroSerif-Italic
/EuroSerif-Regular
/EUSB10
/EUSB5
/EUSB7
/EUSM10
/EUSM5
/EUSM7
/FelixTitlingMT
/Fences
/FencesPlain
/FigaroMT
/FixedMiriamTransparent
/FootlightMTLight
/Formata-Italic
/Formata-Medium
/Formata-MediumItalic
/Formata-Regular
/ForteMT
/FranklinGothic-Book
/FranklinGothic-BookItalic
/FranklinGothic-Demi
/FranklinGothic-DemiCond
/FranklinGothic-DemiItalic
/FranklinGothic-Heavy
/FranklinGothic-HeavyItalic
/FranklinGothicITCbyBT-Book
/FranklinGothicITCbyBT-BookItal
/FranklinGothicITCbyBT-Demi
/FranklinGothicITCbyBT-DemiItal
/FranklinGothic-Medium
/FranklinGothic-MediumCond
/FranklinGothic-MediumItalic
/FrankRuehl
/FreesiaUPC
/FreesiaUPCBold
/FreesiaUPCBoldItalic
/FreesiaUPCItalic
/FreestyleScript-Regular
/FrenchScriptMT
/Frutiger-Black
/Frutiger-BlackCn
/Frutiger-BlackItalic
/Frutiger-Bold
/Frutiger-BoldCn
/Frutiger-BoldItalic
/Frutiger-Cn
/Frutiger-ExtraBlackCn
/Frutiger-Italic
/Frutiger-Light
/Frutiger-LightCn
/Frutiger-LightItalic
/Frutiger-Roman
/Frutiger-UltraBlack
/Futura-Bold
/Futura-BoldOblique
/Futura-Book
/Futura-BookOblique
/FuturaBT-Bold
/FuturaBT-BoldItalic
/FuturaBT-Book
/FuturaBT-BookItalic
/FuturaBT-Medium
/FuturaBT-MediumItalic
/Futura-Light
/Futura-LightOblique
/GalliardITCbyBT-Bold
/GalliardITCbyBT-BoldItalic
/GalliardITCbyBT-Italic
/GalliardITCbyBT-Roman
/Garamond
/Garamond-Bold
/Garamond-BoldCondensed
/Garamond-BoldCondensedItalic
/Garamond-BoldItalic
/Garamond-BookCondensed
/Garamond-BookCondensedItalic
/Garamond-Italic
/Garamond-LightCondensed
/Garamond-LightCondensedItalic
/Gautami
/GeometricSlab703BT-Light
/GeometricSlab703BT-LightItalic
/Georgia
/Georgia-Bold
/Georgia-BoldItalic
/Georgia-Italic
/GeorgiaRef
/Giddyup
/Giddyup-Thangs
/Gigi-Regular
/GillSans
/GillSans-Bold
/GillSans-BoldItalic
/GillSans-Condensed
/GillSans-CondensedBold
/GillSans-Italic
/GillSans-Light
/GillSans-LightItalic
/GillSansMT
/GillSansMT-Bold
/GillSansMT-BoldItalic
/GillSansMT-Condensed
/GillSansMT-ExtraCondensedBold
/GillSansMT-Italic
/GillSans-UltraBold
/GillSans-UltraBoldCondensed
/GloucesterMT-ExtraCondensed
/Gothic-Thirteen
/GoudyOldStyleBT-Bold
/GoudyOldStyleBT-BoldItalic
/GoudyOldStyleBT-Italic
/GoudyOldStyleBT-Roman
/GoudyOldStyleT-Bold
/GoudyOldStyleT-Italic
/GoudyOldStyleT-Regular
/GoudyStout
/GoudyTextMT-LombardicCapitals
/GSIDefaultSymbols
/Gulim
/GulimChe
/Gungsuh
/GungsuhChe
/Haettenschweiler
/HarlowSolid
/Harrington
/Helvetica
/Helvetica-Black
/Helvetica-BlackOblique
/Helvetica-Bold
/Helvetica-BoldOblique
/Helvetica-Condensed
/Helvetica-Condensed-Black
/Helvetica-Condensed-BlackObl
/Helvetica-Condensed-Bold
/Helvetica-Condensed-BoldObl
/Helvetica-Condensed-Light
/Helvetica-Condensed-LightObl
/Helvetica-Condensed-Oblique
/Helvetica-Fraction
/Helvetica-Narrow
/Helvetica-Narrow-Bold
/Helvetica-Narrow-BoldOblique
/Helvetica-Narrow-Oblique
/Helvetica-Oblique
/HighTowerText-Italic
/HighTowerText-Reg
/Humanist521BT-BoldCondensed
/Humanist521BT-Light
/Humanist521BT-LightItalic
/Humanist521BT-RomanCondensed
/Imago-ExtraBold
/Impact
/ImprintMT-Shadow
/InformalRoman-Regular
/IrisUPC
/IrisUPCBold
/IrisUPCBoldItalic
/IrisUPCItalic
/Ironwood
/ItcEras-Medium
/ItcKabel-Bold
/ItcKabel-Book
/ItcKabel-Demi
/ItcKabel-Medium
/ItcKabel-Ultra
/JasmineUPC
/JasmineUPC-Bold
/JasmineUPC-BoldItalic
/JasmineUPC-Italic
/JoannaMT
/JoannaMT-Italic
/Jokerman-Regular
/JuiceITC-Regular
/Kartika
/Kaufmann
/KaufmannBT-Bold
/KaufmannBT-Regular
/KidTYPEPaint
/KinoMT
/KodchiangUPC
/KodchiangUPC-Bold
/KodchiangUPC-BoldItalic
/KodchiangUPC-Italic
/KorinnaITCbyBT-Regular
/KristenITC-Regular
/KrutiDev040Bold
/KrutiDev040BoldItalic
/KrutiDev040Condensed
/KrutiDev040Italic
/KrutiDev040Thin
/KrutiDev040Wide
/KrutiDev060
/KrutiDev060Bold
/KrutiDev060BoldItalic
/KrutiDev060Condensed
/KrutiDev060Italic
/KrutiDev060Thin
/KrutiDev060Wide
/KrutiDev070
/KrutiDev070Condensed
/KrutiDev070Italic
/KrutiDev070Thin
/KrutiDev070Wide
/KrutiDev080
/KrutiDev080Condensed
/KrutiDev080Italic
/KrutiDev080Wide
/KrutiDev090
/KrutiDev090Bold
/KrutiDev090BoldItalic
/KrutiDev090Condensed
/KrutiDev090Italic
/KrutiDev090Thin
/KrutiDev090Wide
/KrutiDev100
/KrutiDev100Bold
/KrutiDev100BoldItalic
/KrutiDev100Condensed
/KrutiDev100Italic
/KrutiDev100Thin
/KrutiDev100Wide
/KrutiDev120
/KrutiDev120Condensed
/KrutiDev120Thin
/KrutiDev120Wide
/KrutiDev130
/KrutiDev130Condensed
/KrutiDev130Thin
/KrutiDev130Wide
/KunstlerScript
/Latha
/LatinWide
/LetterGothic
/LetterGothic-Bold
/LetterGothic-BoldOblique
/LetterGothic-BoldSlanted
/LetterGothicMT
/LetterGothicMT-Bold
/LetterGothicMT-BoldOblique
/LetterGothicMT-Oblique
/LetterGothic-Slanted
/LevenimMT
/LevenimMTBold
/LilyUPC
/LilyUPCBold
/LilyUPCBoldItalic
/LilyUPCItalic
/Lithos-Black
/Lithos-Regular
/LotusWPBox-Roman
/LotusWPIcon-Roman
/LotusWPIntA-Roman
/LotusWPIntB-Roman
/LotusWPType-Roman
/LucidaBright
/LucidaBright-Demi
/LucidaBright-DemiItalic
/LucidaBright-Italic
/LucidaCalligraphy-Italic
/LucidaConsole
/LucidaFax
/LucidaFax-Demi
/LucidaFax-DemiItalic
/LucidaFax-Italic
/LucidaHandwriting-Italic
/LucidaSans
/LucidaSans-Demi
/LucidaSans-DemiItalic
/LucidaSans-Italic
/LucidaSans-Typewriter
/LucidaSans-TypewriterBold
/LucidaSans-TypewriterBoldOblique
/LucidaSans-TypewriterOblique
/LucidaSansUnicode
/Lydian
/Magneto-Bold
/MaiandraGD-Regular
/Mangal-Regular
/Map-Symbols
/MathA
/MathB
/MathC
/Mathematica1
/Mathematica1-Bold
/Mathematica1Mono
/Mathematica1Mono-Bold
/Mathematica2
/Mathematica2-Bold
/Mathematica2Mono
/Mathematica2Mono-Bold
/Mathematica3
/Mathematica3-Bold
/Mathematica3Mono
/Mathematica3Mono-Bold
/Mathematica4
/Mathematica4-Bold
/Mathematica4Mono
/Mathematica4Mono-Bold
/Mathematica5
/Mathematica5-Bold
/Mathematica5Mono
/Mathematica5Mono-Bold
/Mathematica6
/Mathematica6Bold
/Mathematica6Mono
/Mathematica6MonoBold
/Mathematica7
/Mathematica7Bold
/Mathematica7Mono
/Mathematica7MonoBold
/MatisseITC-Regular
/MaturaMTScriptCapitals
/Mesquite
/Mezz-Black
/Mezz-Regular
/MICR
/MicrosoftSansSerif
/MingLiU
/Minion-BoldCondensed
/Minion-BoldCondensedItalic
/Minion-Condensed
/Minion-CondensedItalic
/Minion-Ornaments
/MinionPro-Bold
/MinionPro-BoldIt
/MinionPro-It
/MinionPro-Regular
/Miriam
/MiriamFixed
/MiriamTransparent
/Mistral
/Modern-Regular
/MonotypeCorsiva
/MonotypeSorts
/MSAM10
/MSAM5
/MSAM6
/MSAM7
/MSAM8
/MSAM9
/MSBM10
/MSBM5
/MSBM6
/MSBM7
/MSBM8
/MSBM9
/MS-Gothic
/MSHei
/MSLineDrawPSMT
/MS-Mincho
/MSOutlook
/MS-PGothic
/MS-PMincho
/MSReference1
/MSReference2
/MSReferenceSansSerif
/MSReferenceSansSerif-Bold
/MSReferenceSansSerif-BoldItalic
/MSReferenceSansSerif-Italic
/MSReferenceSerif
/MSReferenceSerif-Bold
/MSReferenceSerif-BoldItalic
/MSReferenceSerif-Italic
/MSReferenceSpecialty
/MSSong
/MS-UIGothic
/MT-Extra
/MTExtraTiger
/MT-Symbol
/MT-Symbol-Italic
/MVBoli
/Myriad-Bold
/Myriad-BoldItalic
/Myriad-Italic
/Myriad-Roman
/Narkisim
/NewCenturySchlbk-Bold
/NewCenturySchlbk-BoldItalic
/NewCenturySchlbk-Italic
/NewCenturySchlbk-Roman
/NewMilleniumSchlbk-BoldItalicSH
/NewsGothic
/NewsGothic-Bold
/NewsGothicBT-Bold
/NewsGothicBT-BoldItalic
/NewsGothicBT-Italic
/NewsGothicBT-Roman
/NewsGothic-Condensed
/NewsGothic-Italic
/NewsGothicMT
/NewsGothicMT-Bold
/NewsGothicMT-Italic
/NiagaraEngraved-Reg
/NiagaraSolid-Reg
/NimbusMonL-Bold
/NimbusMonL-BoldObli
/NimbusMonL-Regu
/NimbusMonL-ReguObli
/NimbusRomNo9L-Medi
/NimbusRomNo9L-MediItal
/NimbusRomNo9L-Regu
/NimbusRomNo9L-ReguItal
/NimbusSanL-Bold
/NimbusSanL-BoldCond
/NimbusSanL-BoldCondItal
/NimbusSanL-BoldItal
/NimbusSanL-Regu
/NimbusSanL-ReguCond
/NimbusSanL-ReguCondItal
/NimbusSanL-ReguItal
/Nimrod
/Nimrod-Bold
/Nimrod-BoldItalic
/Nimrod-Italic
/NSimSun
/Nueva-BoldExtended
/Nueva-BoldExtendedItalic
/Nueva-Italic
/Nueva-Roman
/NuptialScript
/OCRA
/OCRA-Alternate
/OCRAExtended
/OCRB
/OCRB-Alternate
/OfficinaSans-Bold
/OfficinaSans-BoldItalic
/OfficinaSans-Book
/OfficinaSans-BookItalic
/OfficinaSerif-Bold
/OfficinaSerif-BoldItalic
/OfficinaSerif-Book
/OfficinaSerif-BookItalic
/OldEnglishTextMT
/Onyx
/OnyxBT-Regular
/OzHandicraftBT-Roman
/PalaceScriptMT
/Palatino-Bold
/Palatino-BoldItalic
/Palatino-Italic
/PalatinoLinotype-Bold
/PalatinoLinotype-BoldItalic
/PalatinoLinotype-Italic
/PalatinoLinotype-Roman
/Palatino-Roman
/PapyrusPlain
/Papyrus-Regular
/Parchment-Regular
/Parisian
/ParkAvenue
/Penumbra-SemiboldFlare
/Penumbra-SemiboldSans
/Penumbra-SemiboldSerif
/PepitaMT
/Perpetua
/Perpetua-Bold
/Perpetua-BoldItalic
/Perpetua-Italic
/PerpetuaTitlingMT-Bold
/PerpetuaTitlingMT-Light
/PhotinaCasualBlack
/Playbill
/PMingLiU
/Poetica-SuppOrnaments
/PoorRichard-Regular
/PopplLaudatio-Italic
/PopplLaudatio-Medium
/PopplLaudatio-MediumItalic
/PopplLaudatio-Regular
/PrestigeElite
/Pristina-Regular
/PTBarnumBT-Regular
/Raavi
/RageItalic
/Ravie
/RefSpecialty
/Ribbon131BT-Bold
/Rockwell
/Rockwell-Bold
/Rockwell-BoldItalic
/Rockwell-Condensed
/Rockwell-CondensedBold
/Rockwell-ExtraBold
/Rockwell-Italic
/Rockwell-Light
/Rockwell-LightItalic
/Rod
/RodTransparent
/RunicMT-Condensed
/Sanvito-Light
/Sanvito-Roman
/ScriptC
/ScriptMTBold
/SegoeUI
/SegoeUI-Bold
/SegoeUI-BoldItalic
/SegoeUI-Italic
/Serpentine-BoldOblique
/ShelleyVolanteBT-Regular
/ShowcardGothic-Reg
/Shruti
/SILDoulosIPA
/SimHei
/SimSun
/SimSun-PUA
/SnapITC-Regular
/StandardSymL
/Stencil
/StoneSans
/StoneSans-Bold
/StoneSans-BoldItalic
/StoneSans-Italic
/StoneSans-Semibold
/StoneSans-SemiboldItalic
/Stop
/Swiss721BT-BlackExtended
/Sylfaen
/Symbol
/SymbolMT
/SymbolTiger
/SymbolTigerExpert
/Tahoma
/Tahoma-Bold
/Tci1
/Tci1Bold
/Tci1BoldItalic
/Tci1Italic
/Tci2
/Tci2Bold
/Tci2BoldItalic
/Tci2Italic
/Tci3
/Tci3Bold
/Tci3BoldItalic
/Tci3Italic
/Tci4
/Tci4Bold
/Tci4BoldItalic
/Tci4Italic
/TechnicalItalic
/TechnicalPlain
/Tekton
/Tekton-Bold
/TektonMM
/Tempo-HeavyCondensed
/Tempo-HeavyCondensedItalic
/TempusSansITC
/Tiger
/TigerExpert
/Times-Bold
/Times-BoldItalic
/Times-BoldItalicOsF
/Times-BoldSC
/Times-ExtraBold
/Times-Italic
/Times-ItalicOsF
/TimesNewRomanMT-ExtraBold
/TimesNewRomanPS-BoldItalicMT
/TimesNewRomanPS-BoldMT
/TimesNewRomanPS-ItalicMT
/TimesNewRomanPSMT
/Times-Roman
/Times-RomanSC
/Trajan-Bold
/Trebuchet-BoldItalic
/TrebuchetMS
/TrebuchetMS-Bold
/TrebuchetMS-Italic
/Tunga-Regular
/TwCenMT-Bold
/TwCenMT-BoldItalic
/TwCenMT-Condensed
/TwCenMT-CondensedBold
/TwCenMT-CondensedExtraBold
/TwCenMT-CondensedMedium
/TwCenMT-Italic
/TwCenMT-Regular
/Univers-Bold
/Univers-BoldItalic
/UniversCondensed-Bold
/UniversCondensed-BoldItalic
/UniversCondensed-Medium
/UniversCondensed-MediumItalic
/Univers-Medium
/Univers-MediumItalic
/URWBookmanL-DemiBold
/URWBookmanL-DemiBoldItal
/URWBookmanL-Ligh
/URWBookmanL-LighItal
/URWChanceryL-MediItal
/URWGothicL-Book
/URWGothicL-BookObli
/URWGothicL-Demi
/URWGothicL-DemiObli
/URWPalladioL-Bold
/URWPalladioL-BoldItal
/URWPalladioL-Ital
/URWPalladioL-Roma
/USPSBarCode
/VAGRounded-Black
/VAGRounded-Bold
/VAGRounded-Light
/VAGRounded-Thin
/Verdana
/Verdana-Bold
/Verdana-BoldItalic
/Verdana-Italic
/VerdanaRef
/VinerHandITC
/Viva-BoldExtraExtended
/Vivaldii
/Viva-LightCondensed
/Viva-Regular
/VladimirScript
/Vrinda
/Webdings
/Westminster
/Willow
/Wingdings2
/Wingdings3
/Wingdings-Regular
/WNCYB10
/WNCYI10
/WNCYR10
/WNCYSC10
/WNCYSS10
/WoodtypeOrnaments-One
/WoodtypeOrnaments-Two
/WP-ArabicScriptSihafa
/WP-ArabicSihafa
/WP-BoxDrawing
/WP-CyrillicA
/WP-CyrillicB
/WP-GreekCentury
/WP-GreekCourier
/WP-GreekHelve
/WP-HebrewDavid
/WP-IconicSymbolsA
/WP-IconicSymbolsB
/WP-Japanese
/WP-MathA
/WP-MathB
/WP-MathExtendedA
/WP-MathExtendedB
/WP-MultinationalAHelve
/WP-MultinationalARoman
/WP-MultinationalBCourier
/WP-MultinationalBHelve
/WP-MultinationalBRoman
/WP-MultinationalCourier
/WP-Phonetic
/WPTypographicSymbols
/XYATIP10
/XYBSQL10
/XYBTIP10
/XYCIRC10
/XYCMAT10
/XYCMBT10
/XYDASH10
/XYEUAT10
/XYEUBT10
/ZapfChancery-MediumItalic
/ZapfDingbats
/ZapfHumanist601BT-Bold
/ZapfHumanist601BT-BoldItalic
/ZapfHumanist601BT-Demi
/ZapfHumanist601BT-DemiItalic
/ZapfHumanist601BT-Italic
/ZapfHumanist601BT-Roman
/ZWAdobeF
]
/NeverEmbed [ true
]
/AntiAliasColorImages false
/CropColorImages true
/ColorImageMinResolution 150
/ColorImageMinResolutionPolicy /OK
/DownsampleColorImages true
/ColorImageDownsampleType /Bicubic
/ColorImageResolution 300
/ColorImageDepth -1
/ColorImageMinDownsampleDepth 1
/ColorImageDownsampleThreshold 2.00333
/EncodeColorImages true
/ColorImageFilter /DCTEncode
/AutoFilterColorImages true
/ColorImageAutoFilterStrategy /JPEG
/ColorACSImageDict <<
/QFactor 0.76
/HSamples [2 1 1 2] /VSamples [2 1 1 2]
>>
/ColorImageDict <<
/QFactor 0.76
/HSamples [2 1 1 2] /VSamples [2 1 1 2]
>>
/JPEG2000ColorACSImageDict <<
/TileWidth 256
/TileHeight 256
/Quality 15
>>
/JPEG2000ColorImageDict <<
/TileWidth 256
/TileHeight 256
/Quality 15
>>
/AntiAliasGrayImages false
/CropGrayImages true
/GrayImageMinResolution 150
/GrayImageMinResolutionPolicy /OK
/DownsampleGrayImages true
/GrayImageDownsampleType /Bicubic
/GrayImageResolution 300
/GrayImageDepth -1
/GrayImageMinDownsampleDepth 2
/GrayImageDownsampleThreshold 2.00333
/EncodeGrayImages true
/GrayImageFilter /DCTEncode
/AutoFilterGrayImages true
/GrayImageAutoFilterStrategy /JPEG
/GrayACSImageDict <<
/QFactor 0.76
/HSamples [2 1 1 2] /VSamples [2 1 1 2]
>>
/GrayImageDict <<
/QFactor 0.76
/HSamples [2 1 1 2] /VSamples [2 1 1 2]
>>
/JPEG2000GrayACSImageDict <<
/TileWidth 256
/TileHeight 256
/Quality 15
>>
/JPEG2000GrayImageDict <<
/TileWidth 256
/TileHeight 256
/Quality 15
>>
/AntiAliasMonoImages false
/CropMonoImages true
/MonoImageMinResolution 1200
/MonoImageMinResolutionPolicy /OK
/DownsampleMonoImages true
/MonoImageDownsampleType /Bicubic
/MonoImageResolution 600
/MonoImageDepth -1
/MonoImageDownsampleThreshold 1.00167
/EncodeMonoImages true
/MonoImageFilter /CCITTFaxEncode
/MonoImageDict <<
/K -1
>>
/AllowPSXObjects false
/CheckCompliance [
/None
]
/PDFX1aCheck false
/PDFX3Check false
/PDFXCompliantPDFOnly false
/PDFXNoTrimBoxError true
/PDFXTrimBoxToMediaBoxOffset [
0.00000
0.00000
0.00000
0.00000
]
/PDFXSetBleedBoxToMediaBox true
/PDFXBleedBoxToTrimBoxOffset [
0.00000
0.00000
0.00000
0.00000
]
/PDFXOutputIntentProfile (None)
/PDFXOutputConditionIdentifier ()
/PDFXOutputCondition ()
/PDFXRegistryName ()
/PDFXTrapped /False
/CreateJDFFile false
/Description <<
/ARA
/CHS
/CHT
/CZE
/DAN
/DEU
/ESP
/FRA
/GRE
/HEB
/HRV (Za stvaranje Adobe PDF dokumenata pogodnih za pouzdani prikaz i ispis poslovnih dokumenata koristite ove postavke. Stvoreni PDF dokumenti mogu se otvoriti Acrobat i Adobe Reader 5.0 i kasnijim verzijama.)
/HUN
/ITA (Utilizzare queste impostazioni per creare documenti Adobe PDF adatti per visualizzare e stampare documenti aziendali in modo affidabile. I documenti PDF creati possono essere aperti con Acrobat e Adobe Reader 5.0 e versioni successive.)
/JPN
/KOR
/NLD (Gebruik deze instellingen om Adobe PDF-documenten te maken waarmee zakelijke documenten betrouwbaar kunnen worden weergegeven en afgedrukt. De gemaakte PDF-documenten kunnen worden geopend met Acrobat en Adobe Reader 5.0 en hoger.)
/NOR
/POL
/PTB
/RUM
/RUS
/SLV
/SUO
/SVE
/TUR
/ENU (Use these settings to create Adobe PDF documents suitable for reliable viewing and printing of business documents. Created PDF documents can be opened with Acrobat and Adobe Reader 5.0 and later.)
>>
>> setdistillerparams
<<
/HWResolution [600 600]
/PageSize [612.000 792.000]
>> setpagedevice