Evaluation of security framework for BYOD device in cloud environment

Abstract

The widespread practice of Bring your own device (BYOD) to work significantly raises cybersecurity risks. All organization’s employees and employers will greatly benefit from this trend. The growth of spyware, malware and other dubious downloads on individual devices has compelled the government to review its data security guidelines. Without user knowledge, hazardous apps are downloaded to personal devices. Both people and governments could suffer tragic consequences as a result of this. In this situation, BYODs are problematic since they can alter policies without permission and release private information. The main goal of the research was to detect fraudulent communications coming from BYOD environments. A network monitoring and managing information configuration settings of mobile devices in the network is established by providing policies and authenticating endpoint devices in the BYOD network using a mix of NAC and MDM. This framework deals with Security Manager (SaaS) as the second module is briefly described. The study's early results were positive and suggested that the framework would lessen access control-related issues.

KEYWORDS:

• Bring your own device (BYOD)
• privacy and security
• security manager (saas)
• data security
• NAC and MDM

1. Introduction

Employees utilize personal devices like smartphones and tablets for work-related tasks under the “BYOD” policy, which is a standard business practice. By 2021, it's predicted that 11 billion people will use personal mobile devices at work. Employee-owned devices in the BYOD environment have access to company data, creating a variety of unique risk profiles that need additional investigation [1].

Mobile devices can be utilized for both personal and business reasons due to their versatility and widespread availability. All industries use BYOD, with the healthcare sector being one of the main drivers of its adoption [2]. The business prefers to permit employees to access company information and network resources using personal devices solely for work or personal purposes [3].

The business's data keeps expanding due to the phenomenon known as “BYOD”. Employees want to work from “any device, anywhere” and integrate personal and professional activities whenever they choose. It is a by-product of using computers [4]. A study discovered that 97% of participants in a different survey utilized their gadgets for work-related tasks [5]. Due to its many advantages, BYOD usage has recently grown in popularity. This trend enhances employee satisfaction, productivity, work ownership, flexibility, and mobility [6].

When employees continue utilizing the government network without the necessary official approval, this is referred to as “shadow IT.” Additionally, since governments are unable to regulate employee access during working hours, the adoption of BYOD in the workplace increases security vulnerabilities, particularly the possibility of cyber-attacks [7]. BYOD devices are unmanaged and may be more vulnerable, lack a basic security defense system, and include malicious material. Once BYOD is implemented, these become company-trusted devices, and insiders are more dangerous because they are responsible for 63% of digital mishaps [8].

Network Access Control (NAC) gives visibility control the ability to enforce access control policies on devices linked to corporate networks, monitor and examine configured network devices, and notify network administrators about policy violations [9]. It has been discovered that malware, keyloggers, and other cyberattacks increase unauthorized users’ access to company networks, potentially resulting in data theft or corporate espionage [10].

A networking solution called NAC is made up of a collection of protocols that establish and carry out a policy for securing devices’ first access to network resources.

Major contributions of the research:

1. This study's objective is to propose a novel architectural framework for reducing BYOD risk.

2. Enforcing access control regulations and only permitting authorized user access. MDM protects company data by encrypting it and limiting access, hence enhancing security.

3. The main goal of the research was to detect fraudulent communications coming from BYOD environments.

4. A network monitoring and managing information configuration settings of mobile devices in the network is established by providing policies and authenticating endpoint devices in the BYOD network using a mix of NAC and MDM.

The suggested system design is explained in the sections: A quick overview of the concepts and advantages of BYOD is provided in Section I, and the related work involved is covered in Section II. In Section III, the recommended system explains the procedure for securing BYOD devices. The results are provided in section IV, which is then followed by a discussion of the suggested technique. Finally, the article's conclusion is presented in Section V, which also offers research implications for the future.

2. Related work

Organizations require more integrated, methodical processes for controlling threats, maintaining staff devices, and considering the legal ramifications of the BYOD strategy to maximize the benefits for the enterprise [11]. The evaluation would aid in understanding the issues and growing needs of BYOD for organizations and IT professionals [12].

A new framework will be suggested in a separate article, and an experiment will be built to test and assess the findings [13]. In this study, a system for enforcing instantiated policies that are created on-the-fly inside of businesses using reliable BYOD technology is proposed. A role-based access control mechanism is developed using the suggested framework depending on user identity and the present situation [14].

The current BYOD strategy is susceptible to APT (Advanced Persistent Threat) assaults, particularly when spear phishing exploits are used. One of the objectives of this study was to extensively explore the problem of spear phishing to combat APT through it. Security tools like the ACPT (Access Control Policy Tool) are used to examine various security rules to ascertain their functionality and attributes [15]. Numerous firms have adopted BYOD rules, although they are frequently ambiguous and ineffective. A three-tier enhanced policy architecture is suggested to address this drawback and details the rules that must be adhered to by organizations, apps, and devices [16].

Finally, it will suggest selecting a BYOD management solution that works with most mobile platforms [18]. Benefits, risks, and mitigation options for the security flaws present in mobile devices and BYOD programmes in particular are discussed in this study. BYOD programmes are growing in popularity among both large and small enterprises [17].

People, Policy Management, and Technology are the three pillars of the framework. These three pillars will be shown to be essential for securing BYOD installations in businesses. Validating the framework is the final goal [18]. The effectiveness and viability of this model need to be further investigated [19].

Research Gap

• BYOD research is relevant in tackling the above outlined problem by utilizing NAC (Network Access Control) and MDM (Mobile Device Management) technologies to secure the network from unauthorized access.

• A mobile management system, or MDM, monitors mobile device activities and performs compliance checks when a device attempts to connect to the network after being deployed with an agent.

3. Proposed method

The three primary types of cloud services are a software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). Novel SaaS-based security manager tools are suggested by available research. This framework can be used by the cloud manager of an enterprise to perform security tests before approving BYOD access to the cloud. The design of this framework must take into account several important factors. First and foremost, it is crucial to make sure the tool can be quickly and readily integrated into a cloud environment or BYOD system. Research recommends limiting operational requirements.

Before making any changes or developments, it provides a precise image of the prevailing system. Without attempting to read the entire code, it uses dependency relationships to find software setup errors and identifies implementation bottlenecks.

The recommender framework is built on a multi-component architecture, where the software runs independently for network users via bridges connecting various brokers. Owner device, security manager, and BYOD client are the three divisions of the framework. The second module of the framework is Security Manager (SaaS). This proposed framework is illustrated in Figure 1. The article outlines each software component's location within the framework.

Figure 1. The recommendation framework (security manager) for cloud and BYOD security environment.

3.1. Security manager (SaaS)

A key component of the suggested approach is the safety personnel. The main responsibility of a security manager is to supervise the ABAC (Attribute-Based Access Control) policy processes. It functions as a SaaS and can be hosted on the cloud. The framework's four key tasks are managing autonomous systems, analyzing the security of BYOD parts, securing access control regulations, and enforcing access control policies.

3.1.1. Check the security requirement component

Verify that the controller component has configured the security needs component. Utilizing cloud-based SaaS for organizations, its objective is to assess linked devices. The verification security component ascertains whether the BYOD is a trusted device that complies with the organization's security policies.

3.1.2. Authentication component

When the device satisfies the requirements of the security policy, the authentication component is activated. A distinct identifier is required for each user. Using two authentication techniques for increased security, the authentication component verifies the user's identity pf to access the system.

3.1.3. Check permission component

When the permissions checker has finished its scan, it will immediately scan the directory to confirm the security level given to the user. If the user's access has been denied, the component in charge of checking permissions expedites the process before submitting a request to the cloud.

3.1.4. Signature and signing verification components

Whenever a signing or signature verification is being done, portable parts are always used. These parts are in charge of checking requests to ensure that they come from authorized users and haven't been altered in transit. Digital signatures are used to sign each JSON regulation document and each data owner request (Figure 2). The signature verification feature of the security manager validates the digital signature. The resulting unencrypted, decrypted hash code is compared to the original JSON policy to make sure they are all the same. When the values are equal, the message remains the same.

Figure 2. Establishing a Cryptographic Key on a BYOD device.

3.1.5. Components responsible for encryption and decryption

Only authorized persons and parties can view and read the information provided by the components in charge of encryption and decryption. Its objective is to guarantee the message's content's confidentiality. Before transmitting the data, this component transforms it into an unintelligible format. When the data is ready, the procedure is reversed to make it readable by humans. To encrypt messages, the component employs an asymmetric technique. This is exchanged for symmetric cryptography, which is applied to the transmission of the ABAC rule to be decoded. Figure 3 illustrates the working model of digital signature.

Figure 3. Work model of RSA with the digital signature technique.

The sender performs the following actions to sign a message:

1. Creates a message's hash value.

2. computes the signature using his/her private key (m,c) (1) $S=\mathrm{Nc}\mathrm{mod}m$(1)

3. Send S signature to the receiver

To verify the communication, the receiver takes the following actions:

1. Utilize the sender's public key (m,f) to compute the hash value (2) $V=\mathrm{Sf}\mathrm{mod}m$(2)

2. Retrieving the message's hash value

3. The signature is valid if both hash values match.

3.1.5.1. Key generation algorithm

1. It is necessary to create two gigantic random primes, i and j, that are almost identical in size for their product, $m=\mathrm{ij}$, to have the required amount of bits.

2. Calculate $m=\mathrm{ij}$ and $\phi =(i-2)(j-2).$

3. Select an integer $f,2<f<\phi ,$ such that $\gcd (f,\phi )=2.$

4. Calculate the secret exponent $c,2<c<\phi$, such that $\mathrm{fc}\equiv 2(\mathrm{mod\phi }).$

5. The public key is (m, f), and the private key is (c, i, j). Keep all c, i, j, and φ secret values. Where

   1. m is called the modulus

   2. f is called the public exponent or the cryptographic exponent or simply the exponent.

   3. c is called the secret exponent or the decryption exponent

3.1.5.2. Encryption

1. Get receiver B's public key (m, f).

2. Uses positive integer $n,2<n<m$ to represent the plaintext message. $h=\mathrm{nfmodm}$ is used to calculate the ciphertext.

3. Send ciphertext h to B

3.1.5.3. Decryption

1. Calculates $n=\mathrm{hcmodm}$ using his private key (m,c).

2. The message representation n is used to extract the plaintext.

The message is authenticated using the digital signature. If the signature is genuine, the recipient will be able to verify that the message was sent by the legitimate user and was unaltered by using an asymmetric encryption algorithm and again encrypting the message using the public key.

3.1.6. Policy enforcement component

A fixed system called an authorization policy uses access control policies to decide who has access to the cloud. It intends to improve access control. The security control component assesses the ABAC policy to determine whether the user satisfies the required categorization.

3.1.7. Components responsible for policy monitoring and integrity checks

The component in charge of the service keeps a copy of the original owner's hash each time it is generated or altered. It regularly compares these against manually generated hash values for an equivalent ABAC scheme.

3.1.8. Component responsible for auditing

The checked element has been corrected. Responsible for tracking all system accesses, both successful and unsuccessful. The component keeps track of all access decisions made by policy enforcement components, including those that grant and refuse access.

3.1.9. Policy encryption and decryption component

After being encoded and decoded by designated components, i.e. encoding and decoding components, the accessible data is transferred. When connecting to an access control database, the storage is protected using a symmetric encryption algorithm (AES).

3.1.10. Policy database component

The database is managed by a standalone application that communicates with a distributed DBMS (database management system) and the database as a service. This component exchanges data while transmitting messages using various software architecture designs and patterns.

3.2. Devices representing policy/Owner administrator

The person responsible for managing the BYOD customer access control policy also supervises the mechanism's application.

3.2.1. Access policies

The term “Attribute-Based Access Control” (ABAC) refers to a novel logical access control mechanism that restricts access to things after evaluating the regulations defining the characteristics of specific entities (i.e. subjects and objects), their behaviours, and the surrounding environment in connection with the request.

3.2.2. Data

Data includes documents sent over the internet and stored in the cloud.

4. Experimental results

To validate and confirm that the suggested framework is a workable solution, it must be put into practice and tested. Testing and implementation show that the system is error-free and faultless. Two processes are used in the prototype implementation: a client-side owner application and an online SaaS-operating security agent.

4.1. Trusted and untrusted users and devices testing

Four distinct cases are used to evaluate trustworthy and untrustworthy people or devices. As shown in Table 1, some cases discuss the results of implementing BYOD.

Table 1. Various cases of untrusted and trusted devices and users.

Status under various cases	Trusted devices	Untrusted devices
Allowed authorized access to Trusted	Case 2	Case 1
Unauthorized access by a trusted owner	Case 3	Case 1
Untrusted owners	Case 4	Case 1

The “check security requirement component” analyzed these cases and found an untrusted device that did not meet the firm's standards. In Figure 4, this is depicted. In this instance, connecting to the cloud is not allowed for the application.

Figure 4. Untrusted BYOD interface.

In the second instance, the “check security requirement component” has been activated, allowing the gadget to connect to the Google cloud since it is a trusted gadget. The system recognizes users who want to use unauthorized resources in the third case, as depicted in Figure 5. This is accomplished through contrasting ABAC policies.

Figure 5. An interface displaying the classification of forbidden access to illegal resources.

The final scenario concerns untrustworthy users who are permitted to access the system but do not meet the ABAC security requirements. In this case, the “Authenticator component” identifies these operators and denies them access to the network. Figure 6, is depicted.

Figure 6. An interface showing the prohibition of unauthorized users from accessing the system.

4.2. Malicious activity detection

This study has investigated detection mechanisms and implemented appropriate security controls to identify internal infrastructure risks.

4.2.1. Byod users face malicious internet traffic detection

This section's main focus was on BYOD mobile roaming customers who were entirely connected to the internet. Results are sequentially recorded and examined. The main issues with remote users are a variety of harmful behaviours, data leaks, security events, and security compliance.

The BYOD device information that was further explored is also shown in this result. Finally, it examined the summary of attack vectors, threat variables, and event classifications for the entire infrastructure and discovered crucial information that was helpful in the overall scheme of things, as depicted in Figure 7.

Figure 7. An overview of all thread-related variables, attack vectors, and events.

All BYOD endpoints adhere to security standards, regardless of the functionalities of the various technologies they employ. Results are displayed in Figure 8. The Security Compliance Dashboard also showed all BYOD devices, the top threats, hazards, and security incidents. This dashboard offers guidance on security policy for the entire platform.

Figure 8. Security compliance dashboard.

4.2.2. Internal segment connected BYOD users for malicious traffic detection

Figure 9 depicts the connection between an android smartphone's mac address 2E:79:8E:93:DF:5A and the IP address 182.27.61.137 for the testing username Indra.

Figure 9. User recognition using the detected mac address.

4.2.3. Detection of malicious internet traffic facing BYOD users with VPN

The Prisma cloud gateway then verified any communications that were directed at an Internet destination. The following image shows the DNS security landscape, with 5.96 K of the traffic falling under the Spyware DNS security category. Threats that would be investigated and blocked are listed in Figure 10.

Figure 10. Threat landscape from Prisma.

4.3. BYOD policy configuration

For this particular policy, Figure 11 shows editing the identity source sequence. Go to MyDevices _Portal _Sequence in ISE by selecting Administrative > Identification Management > Identity Source sequences. At the top of the selected column, place the AD (Active Directory) server on this policy.

Figure 11. Editing the MyDevices_Portal_Sequence and the identity source sequence.

After saving this Identity Source Sequence, Figure 12 demonstrates how to alter the Guest _Portal _Sequence and place the AD server at the top of the selected column.

Figure 12. Edit the Guest_Portal_Sequence after saving this identity source sequence.

Make sure to choose MyDevices _Portal _Sequence from the Authentication technique drop-down on the Portal Settings page, as depicted in Figure 13.

Figure 13. Selecting MyDevices_Portal_Sequence from the authentication method.

After finishing up the MyDevices portal's modifications, as seen in Figure 14, it will make a native supplicant profile. Place a native supplicant profile by selecting Add > Native Supplicant Profile under Policy > Policy Components > Outcome > Client Provisioning > Resources.

Figure 14. Native supplicant profile.

As seen in Figure 15, it will configure the client provisioning policy after saving this profile. Go to Policy > Client Provisioning.

Figure 15. Configures the client provisioning policy.

It is crucial to observe that in the graphical depiction of the case in Figure 16, as the number of interactions rises, the increase in the ratio between $H_f$ and $T_v$ becomes progressively crucial. This suggests that if a node has continuously maintained a secure profile throughout time, it is highly likely that it will do so in the future, and making a security choice on this assumption will most likely lead to a positive outcome.

Figure 16. Effect of Favourable (secure) Interactions (H_f) on Trust Value (T_v) and access decision.

It relates the amount of favourable interactions to α and the amount of unfavorable interactions to$\beta ;\alpha =H_f+2,\mathrm{and}\beta =H_u+2$. Consequently, the predicted beta distribution value E(p) or $T_v$can be stated as follows; (3) $T_v=E(p)=\frac{H_f+2}{H_f+H_u+3}$(3) Where $H_f$ = Amount of favourable interactions for a particular device, $H_u$ =  Amount of unfavourable interactions with the same device, and $T_v$ =  the devices’ level of trust.

$E(p)$ =  predicted likelihood of node behaviour (favourable or unfavourable)

The interaction history of device A is shown in Table 2, with an increasing number of favourable interactions ($H_f$). The trust value ($T_v$) is calculated using Equation (3). Increase in the value of trust as the amount of interactions rises shows that trust increases with the number of favourable (secure) encounters.

Table 2. History of interactions with device A, with increasingly favourable behaviour.

Amount of prior interactions	Amount of prior unfavourable interactions (${\mathit{H}}_{\mathit{u}}$)	Amount of prior favourable interactions (${\mathit{H}}_{\mathit{f}}$)	Computed trust value (${\mathit{H}}_{\mathit{v}}$)	Access Decision
20	1.6	4	0.7	Pass
30	1.6	20	0.823	Pass
40	1.6	29	0.829	Pass
50	1.6	36	0.938	Pass
60	1.6	40	0.950	Pass

The scenario is illustrated graphically in Figure 17, which explains that the steeper slope at the beginning of the curve shows how trust quickly declines when a node starts acting unfavorably.

Figure 17. Effect of Unfavourable (malicious) Interactions (H_u) on Trust Value (T_v) and access decision.

Table 3 displays a decrease in trust as a result of malicious node interactions in the past. To prevent these nodes from endangering the entire network, this led to access denials to the network. Trust can be lost as rapidly as it can be acquired. The trust value ($T_v$) in the table is also determined using equation (3(3) $T_v=E(p)=\frac{H_f+2}{H_f+H_u+3}$(3) ).

Table 3. History of interactions between device B and rising unfavorable (malicious) behaviour.

Amount of prior interactions	Amount of prior unfavourable interactions (${\mathit{H}}_{\mathit{u}}$)	Amount of prior favourable interactions (${\mathit{H}}_{\mathit{f}}$)	Computed trust value (${\mathit{H}}_{\mathit{v}}$)	Access Decision
20	1.7	3	0.7	Pass
30	19	3	0.1655	Deny
40	29	3	0.0908	Deny
50	34	3	0.0654	Deny
60	42	3	0.0475	Deny

4.4. Performance testing

To assess performance and scalability, it made use of a variety of software tools. For instance, Visual Studio 2017 includes practical tools for designing experiments that measure CPU and memory usage.

The response time for each function in the suggested framework is shown in Figure 18 together with the time taken to store and retrieve information from the database.

Figure 18. Response time for all functions in the suggested framework.

4.5. Integrity testing

After three weeks of testing, it found that the documents contained 2,850 access requests. During this time, there would be 21 policy attacks, but none of them succeeded because the system stopped them all. Understanding the likelihood that a specific type of attack will take place during a given period is crucial to assess the integrity of that attack. The integrity threat is generally recognized: (4) $\begin{array}{rl}& 2-\text{threat attack }(2-\text{security attack equals }2\\ & -\text{integrity attack})\end{array}$(4)

The integrity of a software program is also determined by the total number of integrity attacks. (5) $\sum \text{attack }(\text{integrity attack})=\text{ Integrity}$(5)

In this instance, the threat attack would be (21/2850) = 0.0073684, whereas the security attack would be (0/21) = 0.00. As a result, the integrity would be (1–0.0073684x (1–0.00)) = 0.9926316 * 100 $\approx$ 100%.

5. Conclusion

Investigators offer solutions to access control problems caused by BYOD and cloud environments. They aimed to develop a technique that would preserve BYOD characteristics like better portability and flexibility. This solution was built based on four key requirements: recognizing the BYOD device security, practicing the access control policy, utilizing independent platforms, and protecting the access control policy.s To protect user privacy, they also oppose the introduction of MDM technology. The investigators performed and evaluated their suggested design under real-world conditions to create a prototype for their system. When their systems were validated and verified, the outcomes were positive. In the future, the researchers plan to increase the speed of the system by permitting access and improving the existing architecture to support federated cloud computing.

Disclosure statement

No potential conflict of interest was reported by the author(s).