Sentient-based Access Control model: A mitigation technique for Advanced Persistent Threats in Smartphones

Journal of Information Security and Applications 51 (2020) 102431

Contents lists available at ScienceDirect

Journal of Information Security and Applications journal homepage: www.elsevier.com/locate/jisa

Sentient-based Access Control model: A mitigation technique for Advanced Persistent Threats in Smartphones Zakiah Zulkefli, Manmeet Mahinderjit Singh∗ Universiti Sains Malaysia, Penang, Malaysia

a r t i c l e

i n f o

Keywords: Smartphone Role-centric access control Social engineering Advanced persistent threat (APT) Sensor Context aware

a b s t r a c t This research sheds light on the nature of an advanced persistent threat (APT) on smartphones by analysing real APT attack cases targeting smartphone users. Based on the research, context-aware access control is the best technique to minimise APT instigated by social engineering attacks in smartphones. Therefore, this research proposes an access control model known as sentient-based access control model (SENSATE), which combines role- and attribute-based and multi-level security to maintain information integrity and confidentiality that can be infringed through social engineering attacks. The implementation of existing smartphone sensors in the design of SENSATE is a novel approach in the fight against smartphone cybercrimes, such as APT. © 2019 Elsevier Ltd. All rights reserved.

1. Introduction Internet of Things (IoT) device is assigned with its IP address where information can be exchanged with the server. An example of an IoT device is the smartphone. A smartphone comprises multiple sensors and services, which are crucial in supporting the daily activities of the user and may include sensitive data. Thus, a smartphone has become the main target of attackers to perform advanced persistent threat (APT) attacks, such as AndroRat [18], FinSpy [21] and Asacub [41]. Therefore, controlling user activities towards the utilisation of sensors, particularly when the use of personal smartphones is permitted in an organisation, which is known as bring your own device (BYOD). Several challenges must be addressed to protect the use of smartphones in a BYOD environment. Firstly, a company might hold multiple device architectures and environments simultaneously (e.g. Android OS and Apple OS). Secondly, different users might have a different understanding of smartphone security and varying awareness regarding APT attacks. Lastly, an attacker may use sensors to gather information regarding the targeted victim. Several methods, namely, encryption [1], network monitoring [25,45] and malware behaviour monitoring [24,46], have been proposed to minimise APT attacks. These solutions, which include encryption, malware and network monitoring, are focused on the network part. Encryption also

∗

Corresponding author. E-mail address: [email protected] (M. Mahinderjit Singh).

https://doi.org/10.1016/j.jisa.2019.102431 2214-2126/© 2019 Elsevier Ltd. All rights reserved.

has an intensive computation that takes a considerable amount of memory and easily drains the battery [23], which could end controlling the activity of the user. These solutions also does not focused on the end user. Thus, if user awareness remains low, then the APT attack can still occur despite these mitigations taken by the end-user (the human). This occurrence is due to vast information sharing through social networks and the integration of work and personal environments [48]. According to Morrow [26], the main factor of data leak in the device used within the BYOD environment is the carelessness of the user. Thus, access control is the best solution because it can manage the activities at the endpoint. Based on previous research, existing access controls [12,17,27,42] for mitigating APT attacks focus on the computer; hence, focus on the smartphone is lacking. Therefore, this research aims to examine effective access control that can combat an APT attack on the smartphone. The objectives of this research are as follows: 1) investigate and explore the specifications of access control necessary to mitigate APT; 2) design and model an access control named sentient-based access control model (SENSATE) to mitigate APT, which can occur by manipulating context-aware parameter and the smartphone’s sensor; 3) validate the request access specification for an object to maintain confidentiality and integrity of information. The contributions of this research include the new requirements and a new technique to reduce APT due to social engineering attacks on the smartphone. This paper comprises seven sections. Section 2 discusses the behaviour of users on a smartphone that could lead to an APT attack and the access control specifications necessary to prevent such an attack along with the research methodology. Section 3 details the architecture and data structures

2

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

of SENSATE. Section 4 provides an overview of the results of test cases. Section 5 presents the discussions and benchmarks. Finally, Section 6 offers the conclusion and future work. The research will provide additional details regarding the APT attack in the BYOD environment. 2. State-of-the-art BYOD is a trend where employers allow employees to use their device, including smartphones, for corporate work. This trend highlights that smartphone stores valuable information assets. These assets can be classified into five types [8]: corporate intellectual property, classified information, financial assets, political reputation and service availability and functionality. However, secure data handling is an issue due to employee behaviour, which can lead to an APT attack that benefits from smartphone sensors and services. 2.1. Importance of sensors and services to smartphone The sensors of smartphones can be categorised into three [9]: inertial, positioning and ambient sensors. Interface orientation and event detection (e.g. the device is either dropped or tilted) control on a smartphone requires inertial sensors (e.g. gyroscope and accelerometer). Positioning sensors [e.g. global positioning satellite (GPS) and WiFi] are important for the detection of location and exchange of information. Ambient sensors (e.g. microphone and camera) must identify or process the environment surrounding the user, transfer files and connect to other IoT devices using the same technology. Telephony services (e.g. SMS & MMS), telecommunication (e.g. call log, voice call) and utilities (e.g. Calendar) provide a continuous flow of information. Several services require access to the sensors. Information security can be compromised once the attacker gains access to or reads this information because these services largely depend on the interest of the user [49] and the attacker can generate a highly successful APT attack in the smartphone. 2.2. APT An APT is an information leak attack that relies on social engineering and information collection [15]. The characteristics of APT attack are as follows: 1) persistent willingness of the attacker to wait until the targeted information is received [39]; 2) intelligent and can change attack strategies when a certain event does not occur as planned [40]; 3) difficult to detect because the attacker knows the specific details of the targeted machine [40]. APT smartphone attacks can be defined as sophisticated data leak attacks by social engineering attacks that benefit from smartphone features because smartphones rely on sensors and services to support information management. Next, the research will present the actual cases of APT attacks in a smartphone to expound on this definition. 2.2.1. Real cases of APT attacks in smartphones Numerous previously reported APT attacks on smartphones are shown in Table 1. Table 1 shows that the APT attacks on the smartphone are initiated through social engineering attacks. The attackers employ spear phish (four out of eight cases) and repackage the application (three out of eight cases) to access a victim’s smartphone. These cases show that the attackers take advantage of the user’s trust. According to Zulkefli et al. [49], sensors employed for social engineering are those that can act as a medium for file transfer and share services. These sensors include Bluetooth connectivity and Android beam. The social engineering attack later leads to the installation of malware. The malware used for the APT attack targets

the positioning sensor, ambient sensors and services with access to sensitive information. This approach indicates that the attacker might plan an attack or information gathering during a certain event. For example, open camera and audio for recording whilst the targeted victim is in the office. This type of attack is due to the motive of the attacker, which focuses more on gaining confidential information than being familiar with the user’s physical activities (e.g. sitting) that can be obtained through inertia sensor. As discussed in Section 1, the majority of APTs in smartphones rely on social engineering attacks through sensors. Based on the comparisons of existing solutions presented in Section 1, the best solution is to control user behaviour on the usage of sensors through access control [48]. This solution is selected because social engineering attacks can change according to the interests of users. The research will then discuss the required component of the access control to mitigate APTs in smartphones. 2.3. Specification requirement to mitigate APT in smartphones Referring to the real cases of APT attack in the smartphone is important to identify suitable access control, as discussed in Section 2.2.1. Based on the analysis, access control should have the following properties: • Three entities: user, environment and object: Based on Table 1, APT is initiated through social engineering attack, and the information is gathered based on a certain event or environment. For example, user accessing banking information while at restaurant using public network. This information gathering is realised by using GPS and WiFi. This phenomenon highlights the importance of controlling the three entities. A user entity is defined as something that belongs to the user (e.g. phone number) and needed for recognition of certain event. Environment entity is the current context or the situation of the surrounding (e.g. current time). Object entity is defined as sensors and services that must be controlled or protected against attacker collection (e.g. camera). These entities are needed because the attackers tend to 1) plan an attack on the target victims, 2) gather information based on the user and 3) collect confidential information through sensors and services. • Attribute-based: The entity must be recognized through certain characteristic. This is known as attribute. The attribute is necessary for flexible control of certain events because smartphones can be carried by employees anywhere. Hence, access towards sensitive information can change based on a certain situation, and generating new attacks would require broad information from the sensors. Thus, making it more complex for the attacker to generate new attack. • Separation of duty and least privilege: Various roles might benefit the attackers differently because they may have varying interests, knowledge and awareness. Hence, access to the object should be limited based on role. For example, the creation of a new attribute requires a high knowledge of the smartphone’s background. Thus, an administrator (the person responsible for managing the access control system) is only allowed to select the attributes from the user, the environment and the object that will be used. However, creating and deleting are only limited to the developer (the person responsible for programming the access control system). The employee is responsible for executing the policy. Dynamic duty separation (DSD) is necessary when a user has several roles in a session. • Capability to change automatically: The characteristics of the smartphone have led users to access the information anywhere without considering information sensitivity. Some automatic mechanisms are needed to prevent this activity because the attacker may collect these sensor data during a certain event

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

3

Table 1 APT cases in smartphones. Real cases of APT Attacks

Target

Baumgartner, Raiu & Maslennikov [3]

Tibetan activist

AndroRAT [18]

United States and Turkey

CloudAtlas [38]

CEO of oil and financial industries and civil servants Middle east civil servant

Desert Falcon [7]

Method

Sensor Types

Vulnerability point

Effects

SMS, contact, device information and call log Phone log, internal and external storage Contact, browser’s history

Loss of trust between the activists An attacker can control the device

Inertial

Positioning

Ambient

Spear phish email with attachment Application repackaging

-

GPS, WiFi

-

-

GPS, WiFi

Camera, microphone

Application repackaging

-

GPS, WiFi

Microphone

Spear phish through social media Spear phish through email

-

WiFi∗

-

SMS, call logs

-

GPS, WiFi, Bluetooth and WAP

Microphone

SMS, MMS, contact, device information, voice call, boot information and Internet browser Contact, list of application, device activities, SMS and call log Video, credentials, screenshots

Finspy [21]

Bahraini human rights activists

Asacub [41]

Banks

SMS spam

–

GPS

Camera

Adwind [44]

Aerospace industry

Spam email with malicious URL

-

WiFi∗

Camera

Hacking Team Remote Control System [22]

Political organisation in Saudi Arabia

Application repackaging

-

GPS, WiFi

Camera, microphone

without knowledge by the user. Thus, some automatic mechanisms are necessary to prevent this activity; for example, automatically disabling Bluetooth sensors during work hours. • Preserve privacy: The usage of environment and user attributes highlights the importance of protecting the privacy of the smartphone user while using the access control. In general, in order to provide the access control, the process needs to be done in both server and smartphone local database. The server is used to perform all of the important functions such as creation of attributes and assignment of policies. Meanwhile, SQL calls to the local application database in Smartphone is needed to enable fast access to information and function in the absence of Internet connection. Therefore, if all attributes is used then, then the attacker might compromise the access control easily. Thus, the policy must be defined by one or several existing attributes. • Maintain information confidentiality and integrity: Access control should preserve the confidentiality and integrity of the information by preventing low-role users from reading highrole level user information. The user is also prohibited from writing information to the low-level user. This situation occurs when a user may hold more than one role simultaneously. • Context-awareness: The access control should have the context aware ability by allocating the permission to access certain object based on the subject’s environment. This is essential because most attacks use GPS (Table 1). This indicates the attack might be based on user’s environment. The selected access control must have the following properties. Role- and attribute-based access are necessary to correctly set the

Device information, device activities, SMS, MMS, Gmail messages, call log, credential, calendar, network state

Leak sensitive information

Turn infected machine into a botnet, leak sensitive information Unauthorised information surveillance

task that a particular user can perform. Multi-level further acts as a security constraint to the attribute and roles provided to prevent information leak when a user holds more than two roles at a time. Context-aware access control can be achieved by requiring access made by observing the role clearance, object attribute and current environment. Context-aware access control is needed for changes in information sensitivity based on a certain event. Furthermore, context-aware access control is necessary to realise the following: to 1) impede the reading of sensor data from unauthorised application installed before the user enters the company, 2) control the user from enabling certain functions of sensors to prevent any unknown attack from collecting user information and 3) reduce the chance of social engineering attacks that could result in APT. The next subsection will provide the existing works related to the specification. 2.3.1. Related works Context-aware access control is a technique to control user (subject) access to information based on the user context (e.g. time and location). Several variants of access control are available in the smartphone: attribute-based access control (ABAC), role-based access control (RBAC) and context-based access control. ABAC provides access to an object based on the attributes of users, objects or environments [10]. ABAC has been used by mode-of-use separation in smartphones [33,47]. However, ABAC is difficult to audit [16]. RBAC provides access to an object based on the subject’s role [11,36]. However, pure RBAC is not a context-aware access control; hence, RBAC is inapplicable to the smartphone [30]. Instead, researchers combined RBAC with other contexts, namely, spatial, temporal and location. For example, dynamic role-based

4

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

access control for Android (DR BACA) [34] combines RBAC with location, time, day and event, and Geo-RBAC [4,6] combines RBAC with the geographical location of users. However, these combinations do not cover the attribute of users. Context-based access control focuses on controlling application activities [37]. Thus, this research topic is beyond the current research, which focuses on restricting smartphone users (humans) towards accessing a certain resource. RBAC and Bell–La Padula (BLP) become the focus to mitigate APT. BLP is a mandatory access control (MAC) variant that allows access to an object based on an operation on an object that reads and writes the basic operation [43]. However, rules govern BLP; a subject with a low clearance level is not allowed to read an object with a high clearance level (no read-up), and a subject with a high clearance level is not allowed to write an object with a low clearance level (no write-down). Osborn, Sandhu and Munawer [29] proposed to solve this issue by assigning a level to each role and directly designating read and write permission access levels to each role. However, this technique may violate the integrity of information as it does in real life. It is because, a role may not be allowed to perform both read and write to a certain object. Kim, Kim, Lu, Park and Kim [14] applied the no read-up and write-down rules to the highest and lowest levels of role hold in the session, respectively. However, their work did not integrate RBAC with the subject’s environment and used the old version of NIST RBAC (2001 NIST RBAC), which may contain errors in the RBAC specification. Balamurugan, Shivitha, Monisha & Saranya [2] proposed an access control in cloud computing by combining BLP with RBAC. Similar to Kim et al. [14], read and write access were provided based on the level assigned to a role. However, access control did not integrate with the subject’s environment. Ismail and Mahinderjit– Singh [12] introduced an access control that uses RBAC to mitigate APT in the E-learning website environment. Mustafa [27] proposed using BLP to mitigate APT through the shared device in an organisation. Another work that focused on access control to mitigate APT was that of Lau et al. [17]. They compared existing access controls and found that MAC is the best access control to be implemented. However, RBAC and BLP are not context-aware. The aforementioned works demonstrated that combining RBAC and ABAC is necessary. According to Coyne and Weil [5], the best combination of RBAC and ABAC is through role-centric access control, in which access to an object should be made by looking at the user’s role followed by the user attribute. This approach preserves the fine-grain property of ABAC and the auditable property of RBAC [5,16]. Existing role-centric access controls have several variants in the existing literature. These variants include rolecentric attribute-based access control (RABAC) [13] and attributeenhanced role-based access control (AERBAC) [32]. However, compared with AERBAC, RABAC is unsuitable with a system dependant on a dynamic environment’s attributes, such as day and date [32]. AERBAC addresses this issue by coupling the permission with the user’s context. Thus, the context of the user will be a prerequisite for permission execution. The research gap will be identified in this research.

2.3.2. Research gap Based on current research, the result of RequestAccess to an object is the most important part of access control because it is the part where a user’s request to access an object is allowed or denied by checking the permissions given to the user. Thus, if the specification for RequestAccess to the object is wrong, then information confidentiality and integrity can be compromised. This case is further complicated when attributes are used to determine whether the request is permissible. Hence, understanding how permission and request access are performed in AERBAC is crucial.

In AERBAC, the permission is specified as perm = action x obj_exp. Obj_exp is a relation that links an attribute to value. For example, a user with a role of an employee may read a file in a webpage called File_A, File_B and File_C from 10 am until 5 pm. The object has two attributes: medium and filename. The value medium is the webpage, whilst the values of the filename are File_A, File_B and File_C. Thus, the permission could be Perm = (read,(medium, web)). For permission to be executed, the current user’s environment must be checked in the list of assigned environments. If the condition is true, then the object requested will be fetched based on its attribute and assigned value. The result of the permission will return File_A, File_B and File_C. The permission evaluation process of AERBAC can further be divided into two: identifier- and attribute-based request. The identifier- and attribute-based requests mean that the object’s id and attribute are specified upon request for permission, respectively. The request method based on the attributes can be divided into two: object attribute expression and value. Object attribute expression and value work by respectively supplying object expression and attribute value in the access request. For example, a person wants to access an object with an attribute of context_id = ‘work’ and role = ‘employee’. For a request with object attribute expression, a subject will send context_id = ’work’∧ role = ’employee,’ whilst a subject will send context_id = ’work’; role = ’employee’ for a request made with an attribute value. In this research, the attribute-based request with object attribute value is used because it reduces the attacker’s chance of predicting the query by allowing parameterised query. This is more secure as the object attribute expression contains a conditional expression (e.g. and (∧)) that can make the process of predicting the SQL queries become easier. Thus, by using attribute-based request the chance of having SQL injection is minimised. However, AERBAC cannot maintain information confidentiality and integrity due to inconsistency to the object returned during request access to an object (This issue is discussed in Section 5). Thus, this research proposes a new role-centric access control that provides permission based on an attribute, protecting information integrity and confidentiality. Therefore, a formal specification for request access to objects for the proposed access control is introduced to demonstrate that the proposed access control can protect the integrity and confidentiality of information. Herein, formal specification is chosen to reduce the chance of encountering bugs and logic errors during implementation in the real environment. The current research utilised ProB software [19] to evaluate the specification and show that a correct object can be returned when a certain input is given. ProB is a software that allows an animated view of the proposed formal specification. Next, the research will comprehensively explain the methodology. Firstly, several real cases of APT attacks on the smartphone are analysed. Mitigating an APT attack is best performed through access control because it is likely initiated through social engineering attacks. Secondly, a set of features needed for the access control to mitigate the APT attack in smartphones are proposed. The proposed access control is implemented in B-Language. The request access to an object is also evaluated through test cases to show that the proposed access control can maintain information integrity and confidentiality. Lastly, the conclusions of this research will be provided. 3. Sensate This research named the proposed access control as a SENSATE model. Sentient is the capability to perceive or sense things [31]. This capability is provided by sensors and services on the smartphone. Thus, SENSATE constrains user access towards objects by using sensors. SENSATE is constructed using the specifications

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

5

Fig. 1. Sentient-based access control model (SENSATE).

Table 2 List of possible attributes for different users. User attributes used in the organisation

Att1

Att2

Att3

Attribute of user A Attribute of user B Attribute of user C

Att1 Att1 Att2

Att2 Att2 Att3

Att3

outlined in Section 2.3. Next, the component of SENSATE will be discussed. SENSATE is an access control specifically designed for smartphones and can change its policy based on certain events. Fig. 1 highlights the components of SENSATE. SENSATE comprises a combination of BLP and AERBAC and is informally described in Fig. 1. SENSATE has the same semantics as RBAC [11], namely, users (USERS), roles (ROLES), action (ACTION), object (OBJ), permission (PRMS), sessions (SESSION) and DSD. SENSATE also has similar semantics to AERBAC [32], namely object’s expression (OBJ_EXP), user attribute (UA) and environment attribute (EA). The following elements are added to SENSATE. • Fixed entity attributes: The attribute used for each entity should be fixed. Without this constraint, uncertainty will exist in the object(s) return, which could later compromise information confidentiality and integrity. Table 2 highlights the issues that could occur when the attributes assigned to the user entity are not fixed. • shows the following three user attributes: Att1, Att2 and Att3. When a user attribute is not fixed, multiple combinations will exist in terms of user access to information. Similar things also occur for environment entity. As a result, an attacker can easily masque the user, especially when the user attribute restricts permission for a role. For example, if Att2 restricts permission, then user B and C access is ambiguous because it has no value, proving the importance of the fixed attribute entity. • Subject/Object clearance level: A session can hold more than one role at a time. Breach of information confidentiality can occur during the flow of information from a high- to a lowlevel role. This breach occurs because the object expression results from the accumulation of permission by role(s) are held in a session. Thus, SENSATE applies the concept of no read-up and write-down (BLP) whilst allowing the request access to objects to prevent the object output from becoming substantially broad or narrow. In other words, it prevents the subject from

accessing the object more than they are allowed to and preventing the subject from getting less object than they are allowed to. This approach is performed by requiring all objects and roles to be assigned a level. • Permission–Condition relationship: In AERBAC, a role is needed to track the permissions and conditional constraints assigned to the user r (RPA ∈ Roles ↔ Permissions ∗ Cond_id). Conditional constraints can be defined as any environment, object and user attribute that is used to limit the access of the user to object. Therefore, in the event of an attack (e.g. SQL injection), the aforementioned components will be affected. SENSATE addresses this issue by introducing permission–condition relationship (Perm_Cond). This relationship allows the administrator to check the permissions related to the conditional constraint without specifying the role (Perm_cond ⊆ Permissions ∗ Cond_id ∧RPA ∈ Roles ↔ Perm_cond), which will ease auditing. • Conditional constraint based on the entity: In SENSATE, only environment and user attributes (e.g. phone number or device IMEI) may act as a conditional constraint. However, the conditional constraint for the environment entity is made by specifying the environment id, whereas that for user entity is made by using attributes. The rationale of such a rule for the environment entity is to prevent the occurrence of logic error, especially when a range of numbers is used to identify a certain event. For example, constraining user access to information based on time without considering other environmental attributes, such as location. This condition can lead to the return of an unauthorised object. Different situations occur to the user entity due to its unique value. This is discussed in Section 4. • Restriction on role inheritance: A role hierarchy is created by using parent–child relationship, RH = Role x Role, with transitive but asymmetric closure. If no level is assigned, then the attacker (e.g. malicious admin activity) can freely create a role hierarchy. A user can easily make high- and low-position roles as a child and a parent, respectively. For example, consider two roles, Cadet and Lance Corporal, where a Lance Corporal holds a higher position than that of a Cadet. Thus, two combinations of role inheritance are possible: Cadet as a parent with Lance Corporal as the child and Lance Corporal as a parent with Cadet as a child. SENSATE requires that the parent must hold a higher role clearance than that of its child to solve the uncertainty.

6

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

Fig. 2. Sets and functions related to the user component of SENSATE.

Fig. 5. Sets and functions related to the CoreTool component of SENSATE.

Fig. 3. Sets and functions related to the environment component of SENSATE.

• Object’s attribute grouping: The object attribute should not be easily viewed through the object expression to preserve privacy and confidentiality of information. For example, obj_exp = {Att1, Att2}. SENSATE addresses this issue by making the object group as part one of the object attribute. For example, obj_exp = {obj_group}. The object group can later be used by the user to recognise the attribute of the object indirectly through the expression of the object. These specifications are used because the entities (user, environment and object) have their attributes that must be used as prerequisites. These attributes and conditional constraints will have their own create and delete operations. However, the actions that can be performed are limited to the role of the user because of different comprehension levels. Section 5 highlights these issues. The current research will then further explain the data structure of SENSATE. 3.1. Data structure of sensate The rules for each component are highlighted in to 5. Figs. 2–5 highlight the rules in Section 4. For environment and object entities, the value can be divided into two: string and integer. The main difference between string and integer is that the integer value must specify comparisons or operators to determine if a certain value is within a given range. By contrast, a string value only requires a Boolean comparison (e.g. true or

Fig. 4. Sets and functions related to the object component of SENSATE.

false). Thus, two different relations that hold different types of values are specified to allow the identification between attribute that uses a string and an integer value: attribute that holds string type (EATTVAL, OATTVAL and Obj_exp_val) and attribute that holds integer type (EATTVAL_NUM, OATTVAL_NUM and Obj_exp_val_num). A relation with the attribute is used (EATTOP and Obj_exp_op) to link the value (integer type) with an operator. Notably, the rules for role inheritance used in SENSATE are similar to those in RBAC [11]. This rule applies to all SENSATE functions, especially when authorising the access of an object from a subject. (Note: The reader can refer to the appendix for the structure and component of AERBAC). When a subject seeks access to an object, it must go through a function called RequestAccess. SENSATE requires the following five parameters to access the function: current session, operation performed, object’s attribute(s) and its value, object’s level and environment’s attribute(s) and its value. All these items are then processed in compliance with the following rules. (1) Check if the user request to read∗ the object and read is allowed for the associated role. ∗ (2) If (1) is true, then check if identifier (id) of object expression(s) is related to the role associated with the session. The object expression must meet the rules as written in (2.1) until (2.3) (shown in the next rows). ∗ (2.1) All attributes associated with the object expression id should be similar to the object attributes sent by the requester. (2.2) All attribute values associated with the object expression id matching the object attribute sent by the requester must comply with these rules: i) If the attribute of the object expression is of type string, then a) The value of the attribute must be similar to that of the requested attribute b) The value of the attribute must not be equal to a natural number ii) If the attribute of the object expression is of type natural number, then a) The value of the attribute must be equal to a natural number b) An operator must be assigned to the attribute c) The value of the attribute requested has the following relationships: I If the operator is larger than or equal, then the value of the requested attribute should be larger than or equal to the value of the attribute associated with the object expression.

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

7

II If the operator is less than or equal, then the value of the requested attribute should be less than or equal to the value of the attribute associated with the object expression. (2.3) For the associated action and object expression id, the conditional constraint(s)∗ is/are obtained. (2.3.1) For each conditional constraint identifier (id), check whether an environment matches all the current requester environments. (2.3.2) If user authentication is required, then check whether the user’s attribute matches the user’s attribute constraint assigned using conditional identifier. (3) The requested object(s) or resource(s) is/are returned if the following are met: i) The resource holds all attributes assigned by the developer. ii) All attributes and attribute values of the resource hold values similar to the requested attribute and attribute’s value. iii) For a read operation, access to the resource is provided if the resource level is less than or equal to the session’s lowest level role. iv) For a write operation, access to the resource is provided if the resource level is larger than or equal to the role that has the highest level in the session. ∗ Note:

The user’s role within the session is dependant on the action. If the action is read, then the user’s role will hold the lowest level; otherwise, if the operation is write, then the user’s role will hold the highest level. As shown in specifications 1–3, the main component of BLP is applied in this research. If the user has more than one role in a session and wants to perform a read operation, then no read-up is performed. If the user holds more than one role in a session and wants to perform a write operation, then the user applies no write-down. Next, the research will discuss the results and evaluation of RequestAccess to an object SENSATE. 4. Evaluation and analysis The AERBAC is formalised into B-method based on the formal specification provided by Mahmood Rajpoot and Jensen [20] to evaluate SENSATE. SENSATE is then formalised into B-method. In each case, the RequestAccess function is tested to verify that the declared specification can maintain information confidentiality and integrity. 4.1. Evaluation of requestaccess through test cases The following case is considered to test access control. An organisation allows its employees to use their smartphones. In the smartphone, he/she uses SENSATE or AERBAC, where RequestAccess is the main function that controls user behaviour and is called every 15 min. The organisation has three important roles: administrator, cadet and lance corporal. During business hours, company policy only allows access to proprietary applications and disables access to sensors that could lead to a social engineering attack (e.g. Android beam and Bluetooth). These sensors are activated when employees are away from work. Meanwhile, browser history access is constantly disabled. Changing the date and time also disabled all times to prevent any misaligned policy. Fig. 6 illustrates the attributes. Figs. 6(a) and (b) show that the user has three attributes and the environment has four attributes. AERBAC uses three object attributes (d), whilst SENSATE uses two additional attributes (c).

Fig. 6. Attributes used for each entity

SENSATE uses the object group to recognise an object, whereas AERBAC uses the subset of existing attributes, such as object policy id and sensor. SENSATE also uses the object level to control the flow of information from high- to low-level user. Fig. 7 indicates that roles, object expressions and environmental restrictions for SENSATE and AERBAC are different. SENSATE uses the environment identifier to identify the context (Fig. 7(g)), whereas AERBAC uses attributes of the environment (e.g. Ctx a24 or Ctx office) (e.g. start_time or end_time). For object expression, AERBAC uses object attributes (shown in (e)), whereas SENSATE focuses on the object group (shown in (d)). SENSATE and AERBAC use the user attribute to authenticate the user (shown in (f)). The following policies are considered to test RequestAccess (refer to (a)): • Session 3 is held by the administrator, Session 2 is held by the lance corporal and session 1 is held by the cadet (b). • An administrator is allowed to write obj_exp_1 under Cond_1. • An administrator is allowed to read obj_exp_3 under Cond_1. • A cadet is allowed to read obj_exp_2 under Cond_2. • A lance corporal is allowed to read obj_exp_2 under Cond_2 and obj_exp_1 under cond_1. Assume an attacker is planning an attack on the RequestAccess function. An attacker is a person who knows the target well and uses social engineering attacks to perform APTs. The attacker can be a hacker, insider or outsider with intent to collect or leak sensitive information from their target. As discussed in Sections 1 and 2, APT is performed by someone who knows the organisation well. APT can be performed by an employee. Thus, cases 1 and 2 highlight the possible case when the employee misbehaves. APT can also occur through spear phishing, SQL injection and application repackaging. Thus, cases 3, 4 and 5 highlight the usage of SQL injection. Lastly, cases 6, 7 and 8 highlight the case that can occur when spear phishing and application repackaging are used. The cases that can occur are as follows (Note: For case 2 only, the user constraints for cond_1 are emeiNum1 and emeiNum2.

8

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

Fig. 7. Components declared in access controls

Otherwise, the user constraints for cond_1 are emeiNum1, emeiNum2 and emeiNum3. Refer to the data provided in the file for test cases and output of the experiment): Case 1: An attacker attempts to perform RequestAccess using legitimate action, object, attributes and attribute values in an unauthorised environment. For example, a person steals a lance corporal device and attempts to read the data in the proprietary application at a place other than the office. Discussion 1: For AERBAC, this case will depend on how the environmental constraint is set up by conditional expression. The problem will not occur if the user environment is within the declared environmental constraint (e.g. start_time and end_time). Otherwise, if the user environment involves a combination of declared and undeclared environmental constraints (e.g. start_time, end_time and X), breach of information confidentiality may occur because this situation may lead to logic error. This situation is not a problem for SENSATE because all attributes are combined under one environmental identifier to prevent logic errors. Case 2: An attacker attempts to perform RequestAccess using legitimate object attribute and values in an unauthorised device. For example, a cadet installs the application to control access on an unauthorised device and monitor (e.g. read) policies whilst in the office. Discussion 2: (f) shows that SENSATE and AERBAC can perform user authentication through the user attribute. A cadet uses another device, which has a different Emei number from that registered under Cond_1. This type of activity is not permitted. Case 3: An attacker uses a session with more than one role to read the high-level role information using legitimate action, object attributes and low-level role environment. For example, an attacker can gain access to the administrator account (e.g. through the stolen device), in which the administrator can hold the role of lance corporal (applicable through inheritance) in Session 3.

Through this property, the attacker wants to read the policies executed in obj_exp_3 during office hours (cond_1) by requesting the object policy id of dis_browser_history for AERBAC or group D for SENSATE. Discussion 3: For AERBAC, access is allowed because the requested attribute (object policy id) is a part of the permission given to the accumulated role (admin and lance corporal). Therefore, in one session, permissions to read obj_exp_3 and obj_exp_1 are allowed. Thus, the confidentiality of information can be violated. For SENSATE, this kind of request is not allowed. In SENSATE, in which a session has more than one role, the low-level role cannot read the high-level information. The session only holds the permission to read the lowest-level role. Case 4: The attacker uses a session with more than one role to write the information of low-level role using legitimate action, object attribute and values and environment assigned to a high-level role. For example, data of obj_exp_1 for lance corporal are modified (write) during Session 3, which holds the role of administrator and lance corporal simultaneously (through inheritance). Discussion 4: AERBAC allows such a request because it is part of the authorisation of the accumulated role. Thus, a breach of information integrity can occur. For SENSATE, such a request is not allowed because if a session holds more than one role, then the high-level role is not allowed to write to the low-level role. This session only holds the permission to write to the highest-level role in the session. Case 5: An attacker attempts to disrupt the information flow by inserting malicious values either to the object or the environment entity or by using multiple combinations of attributes that do not exist in the object expression to get the object returned. For example, for AERBAC, the correct policy id is requested with a sensor of Bluetooth (not assigned in the permission); for SENSATE, object group A is requested with a sensor of Bluetooth. Discussion 5: In AERBAC, such a request is allowed if the object expression is a subset of the requested object’s attribute. The remaining attribute that is not part of the object expression will act as a filter for the returned object. Hence, SQL injection can occur. SENSATE does not allow this request because the request must be similar to the assigned object expression. If the requested attribute is less, different or more than the attribute assigned to the object expression, then access is not granted. Case 6: An attacker attempts to access some of the sensors used in spear phishing during work hours to read confidential information. Case 7: An attacker attempts to obtain permission to access the browser’s history to generate a successful spear-phishing attack. Case 8: An attacker attempts to gather information regarding the proprietary application through malicious non-proprietary applications. Discussion 6, 7 and 8: For AERBAC, policies assigned are only executed well when all policy ids are called due to the uniqueness of the policy id. Otherwise, compromising the returned objects is easy. Moreover, if an additional attribute(s) matches the object, then the policy execution is interrupted. In SENSATE, a call to the object group is sufficient to execute all policies required to enable securing the smartphone. Based on the aforementioned cases and discussions, SENSATE can provide access controls that can maintain the confidentiality and integrity of information. In the next section, detailed discussions regarding the achieved results will be provided. 5. Discussion on sensate The effect and the relevance of using attributes to the access control and benchmark SENSATE with RBAC and AERBAC are discussed in this section.

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

9

Table 3 Differences between SSD and user conditional value. Items

Static separation of duty (Ssd)

User conditional value

Dependency Activation time Function Can the user be authenticated?

User id with role Session or role–permission assignment Prevent conflict of interest No

User attribute with role Permission–condition assignment Prevent conflict of interest or control access based on a certain event Yes

5.1. Secure approach to deal with context-aware access control

5.2. Benchmark

In a context-aware environment, three entities must be considered: user, object and environment. Different approaches for dealing with these entities are based on research as discussed in this section.

Several points can be highlighted from these access controls: 1) efficiency in the management of APT attack, 2) rules or invariant specification and 3) accessibility to the requested objects. Each component is discussed as follows.

5.1.1. Object entity An object entity is recognised through object expression, which has no limitations on the number of attributes that can be assigned with an object expression. This object expression is used to call numerous objects that can be accessed in certain events. Thus, making the object expression well is crucial. Based on testing, the best object recognition method is conducted through grouping. Grouping allows ambiguity for the selected associated attribute, in which selected attributes are placed in a single group. Thus, predicting which attribute has been selected becomes complex. The group is placed as part of the attribute, which is identified by ‘obj_group’. For example, consider an object with a set of attributes identified as {A1 , A2 … AN, obj_group}. Herein, the obj_group is where the grouping is stored. By using obj_group, any combination of attributes may be stored in a single attribute. Thus, the attacker will have a probability of N / (N×V), where N is the number of attributes, and V is the number of values to consider. This method is safer compared with assigning the correct name of attribute and attribute values as object expression. According to NIST 800–53 [28], concealment is one of the best methods to mitigate the APT attack because the attacker will take a long time to make predictions. 5.1.2. User entity The user entity is recognised through a session and can be used as one of the user’s requirements to access an object. Utilising user attributes in the condition can replace static separation of duty (SSD) because the user attribute will further restrict access to the object based on the session. It can also be a form of user authentication. highlights the differences between SS and user conditional value or user constraint (recognised through Cond_exp_usr and Cond_exp_usr_val). Table 3 shows that user conditional value can prevent conflict of interest but in a detailed manner because it depends on the characteristic or attribute of the user. This section is not covered in this research because no conflict of interest exists. The conditional constraint of users ensures secure access control and performs user authentication, which is the best way to control access to certain information. 5.1.3. Environment entity The environment serves as a condition for the user to access the object and acts as a rule for policy execution. Thus, the environment is unsuitable to be recognised through attributes only. The environment should be recognised through an attribute id that covers all its attributes for application because the associated event, which is neither broad nor narrow, can become recognisable to compromise information confidentiality. In SENSATE, the environment is a required component for access control.

• Efficiency in the management of APT attack – A contextaware access control is necessary to minimise social engineering attacks to reduce APT. Based on the current research, RBAC does not have this property, whereas AERBAC and SENSATE do. However, AERBAC can be considerably broad and narrow (depending on its set up) and can affect information confidentiality and integrity. For example, the RequestAccess for AERBAC is substantially broad when a single attribute that uses numeric value is declared as the object expression. Therefore, this RequestAccess is easily compromised by SQL injection. SENSATE addresses this issue by integrating level to the object output and using object group, returning only the authorised object(s). • Rules or invariant specification - AERBAC is dependant on attributes, which can cause logical errors and further complicate the auditing process. SENSATE solves this issue by requiring only the inclusion of environment and user in the conditional expression. In SENSATE, the environment is recognised via its id, and the user entity is recognised via the attribute rather than using attributes in the conditional expression. Object entity is not included in the conditional expression because it has already been declared as object expression and can further complicate the problems (e.g. logic errors). • Accessibility to object - In RBAC, access to the object can be directly determined through the role–permission assignment. In AERBAC and SENSATE, access to an object must be preprocessed firstly through the operation of RequestAccess. However, AERBAC only requires a subset of the object attributes and object attribute values requested to match the object expression assigned in the permission. This condition can compromise information confidentiality. SENSATE solves this issue by requiring the matching of object attribute and object attribute’s value with the one assigned to the object expression, as declared in the permission. Access to objects also depends on operation at the role level at a certain session to preserve the confidentiality and integrity of information. 6. Conclusion and future work The authors proposed SENSATE to mitigate smartphone APT, which is initiated via social engineering attacks. The proposed access control is proposed by analysing several real cases of APT attack. The experiment shows that SENSATE can preserve the confidentiality of both data. However, additional works are needed to convert the mathematical notation into a high-level programming language. Future work includes the research plan to implement SENSATE in a real-world system. The formal specification can be converted into code by using Samsung KNOX [35]. The research will discuss additional details to address the issues of policy execution during events, such as scarcity of Internet connectivity, unplanned event,

10

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431

policy conflict, processing time and space consumption, which can lead to the disruption in policy execution. Author declaration template We wish to confirm that there are no known conflicts of interest associated with this publication and there has been no significant financial support for this work that could have influenced its outcome. We confirm that the manuscript has been read and approved by all named authors and that there are no other persons who satisfied the criteria for authorship but are not listed. We further confirm that the order of authors listed in the manuscript has been approved by all of us. We confirm that we have given due consideration to the protection of intellectual property associated with this work and that there are no impediments to publication, including the timing of publication, with respect to intellectual property. In so doing we confirm that we have followed the regulations of our institutions concerning intellectual property. We understand that the Corresponding Author is the sole contact for the Editorial process (including Editorial Manager and direct communications with the office). She is responsible for communicating with the other authors about progress, submissions of revisions and final approval of proofs. We confirm that we have provided a current, correct email address which is accessible by the Corresponding Author and which has been configured to accept email from ([email protected]) Declaration of interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. CRediT authorship contribution statement Zakiah Zulkefli: Conceptualization, Data curation, Formal analysis, Methodology, Resources, Software, Validation, Visualization, Writing - original draft, Writing - review & editing. Manmeet Mahinderjit Singh: Conceptualization, Supervision, Investigation, Project administration, Resources, Funding acquisition, Writing original draft, Writing - review & editing. Acknowledgement This project is funded by the Fundamental Research Grants Scheme of Universiti Sains Malaysia (FRGS) No: 203/PKOMP/6711424) and the The Ministry of Higher Education Supplementary materials Supplementary material associated with this article can be found, in the online version, at doi:10.1016/j.jisa.2019.102431. References [1] Au MH, Liang K, Liu JK, Lu R, Ning J. Privacy-preserving personal data operation on mobile cloud - chances and challenges over advanced persistent threat. Fut. Gener. Comput. Syst. 2017. doi:10.1016/j.future.2017.06.021. [2] Balamurugan, B., Shivitha, N.G., Monisha, V., & Saranya, V. A honey bee behaviour inspired novel attribute-based access control using enhanced belllapadula model in cloud computing. 2015. International Conference on Innovation Information in Computing Technologies (ICIICT). pp 1-6. [3] Baumgartner, K., Raiu, C., & Maslennikov, D. Android trojan found in targeted attack. (accessed on 25 September 2016).

[4] Bertino E, Kirkpatrick MS. Location-based access control systems for mobile users: concepts and research directions. In: International Workshop on Security and Privacy in GIS and LBS, Chicago, Illinois. Springer; 2011. [5] Coyne E, Weil TR. ABAC and RBAC: scalable, flexible, and auditable access management. IT Prof. 2013;15(3):14–16. doi:10.1109/MITP.2013.37. [6] Damiani ML, Bertino E, Catania B, Perlasca P. GEO-RBAC: a spatially aware RBAC. ACM Trans. Inf. Syst. Secur. 2007;10(1):2. doi:10.1145/1210263.1210265. [7] Donohue, B. Desert falcons: the middle east’s preeminent apt. 2015. https:// www.kaspersky.com/blog/desert- falcon- arabic- apt/7678/ (accessed on 20 July 2017). [8] Hogben, G., & Dekker, M. (2010). Smartphones: information security risks, opportunities and recommendations for users. https://www.enisa. europa.eu/publications/smartphones- information- security- risks- opportunitiesand- recommendations- for- users. (accessed on 27 July 2018). [9] Hoseini-Tabatabaei SA, Gluhak A, Tafazolli R. A survey on smartphonebased systems for opportunistic user context recognition. ACM Comput. Surv. 2013;45(3):1–51. doi:10.1145/2480741.2480744. [10] Hu, V.C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., & Scarfone, K. 2014. Guide to Attribute Based Access Control (ABAC) Definition and Consideration. https://nvlpubs.nist.gov/nistpubs/specialpublications/ NIST.SP.800-162.pdf (accessed on 20 August 2017). [11] Huynh, N., Frappier, M., Mammar, A., Laleau, R., & Desharnais, J. (2014). Validating the RBAC Ansi 2012 standard using B. International Conference on Abstract State Machines. Alloy, B, TLA, VDM, and Z. ABZ 2014. Lecture Notes in Computer Science, vol 8477. Springer Berlin, Heidelberg. pp 255–270. [12] Ismail, K.A., Mahinderjit Singh, M., Mustaffa, N., Keikhosrokiani, P., Zulkefli, Z. 2017. Security Strategies for Hindering Watering Hole Cyber Crime Attack. Procedia Computer Science. Volume 124. pp 656–663, ISSN 1877-0509 Sciencedirect. https://doi.org/10.1016/j.procs.2017.12.202. [13] Jin X, Sandhu R, Krishnan R. RABAC: role-Centric attribute-based access control. In: Kotenko I, Skormin V, editors. Computer network security: 6th international conference on mathematical methods, models and architectures for computer network security, mmm-acns 2012, st. petersburg, russia, october 17-19, 2012. proceedings. Berlin, Heidelberg: Springer Berlin Heidelberg; 2012. p. 84–96. [14] Kim, S., Kim, D.-.K., Lu, L., Park, S., & Kim, S. A feature-based modeling approach for building hybrid access control systems. 2011. Fifth International Conference on. Secure Software Integration and Reliability Improvement (SSIRI). Jeju Island. pp. 88–97. doi: 10.1109/SSIRI.2011.16. [15] Krombholz K, Hobel H, Huber M, Weippl E. Advanced social engineering attacks. J. Inform. Secur. Appl. 2015;22:113–22. doi:10.1016/j.jisa.2014.09.005. [16] Kuhn DR, Coyne EJ, Weil TR. Adding attributes to role-based access control. Computer 2010;43(6):79–81. doi:10.1109/mc.2010.155. [17] Bann, L.L., Mahinderjit Singh, M., Samsudin, A. Trusted Security Policies for Tackling Advanced Persistent Threat via Spear Phishing in BYOD Environment. 2015. Procedia Computer Science, Volume 72, 2015, pp 129–136, ISSN 18770509, doi: 10.1016/j.procs.2015.12.113. [18] Lelli, A. Symantec official blog: remote access tool takes aim with android apk binder. 2013. https://www.symantec.com/connect/blogs/ remote- access- tool- takes- aim- android- apk- binder (accessed on 26 July 2017). [19] Leuschel M, Butler M. ProB: an automated analysis toolset for the B method. Int. J. Softw. Tools Technol. Trans. 2008;10(2):185–203. doi:10.1007/ s10 0 09-0 07-0 063-9. [20] Mahmood Rajpoot, Q., & Jensen, C.D. Enhancing security and privacy in video surveillance through role-oriented access control mechanism. 2016. (Ph.D.), Kgs. Lyngby: Technical University of Denmark. DTU Compute PHD-2016, No. 399. [21] Marquis-Boire, M., Marczak, B., & Guarnieri, C. (2012). The smartphone who loved me: finFisher goes mobile (accessed on 28 June 2016). [22] Marquis-Boire, M., Scott-Railton, J., Guarnieri, C., & Kleemola, a.K. (2014). Police story: hacking team’s government surveillance malware. https://citizenlab.ca/ 2014/06/backdoor-hacking-teams-tradecraft-android-implant/ (accessed on 28 June 2016). [23] Masoud M, Jannoud I, Ahmad A, Al-Shobaky H. The power consumption cost of data encryption in smartphones. International Conference on Open Source Software Computing 2015; (OSSCOM). 1–6. doi:10.1109/OSSCOM.2015.7372685. [24] Moon D, Im H, Kim I, Park JH. DTB-IDS: an intrusion detection system based on decision tree using behavior analysis for preventing apt attacks. J. Supercomput. 2015:1–15. doi:10.1007/s11227-015-1604-8. [25] Moon D, Im H, Lee J, Park J. MLDS: multi-Layer defense system for preventing advanced persistent threats. Symmetry 2014;6(4):997. [26] Morrow B. BYOD security challenges: control and protect your most sensitive data. Netw. Secur. 2012;2012(12):5–8. doi:10.1016/S1353-4858(12)70111-3. [27] Mustafa, T. Malicious data leak prevention and purposeful evasion attacks: an approach to advanced persistent threat (APT) management. 2013. International Conference of Electronics, Communications and Photonics Conference (SIECPC). pp. 1-5. doi: 10.1109/SIECPC.2013.6551028. [28] NIST. (2013). Security and privacy control for federal information systems and organizations (NIST 800-53): national institute of standards and technology (NIST). https://nvd.nist.gov/800-53 (accessed on 23 March 2017). [29] Osborn S, Sandhu R, Munawer Q. Configuring role-based access control to enforce mandatory and discretionary access control policies. ACM Trans. Inform. Syst. Secur. (TISSEC) 20 0 0;3(2):85–106.

Z. Zulkefli and M. Mahinderjit Singh / Journal of Information Security and Applications 51 (2020) 102431 [30] Ouaddah A, Mousannif H, Elkalam AA, Ouahman AA. Access control in the internet of things: big challenges and new opportunities. Comput. Netw. 2017;112:237–62. [31] Press, O.U. (2018). Definition of sentient in English. https://en. oxforddictionaries.com/definition/sentient (accessed on 20 Jan 2016). [32] Rajpoot QM, Jensen CD, Krishnan R. Integrating attributes into role-based access control. In: Samarati P, editor. Data and applications security and privacy XXIX: 29th annual ifip wg 11.3 working conference, DBSec 2015, fairfax, VA, USA, july 13-15, 2015, proceedings. Cham: Springer International Publishing; 2015. p. 242–9. [33] Ray, I., Alangot, B., Nair, S., & Achuthan, K. (2017). Using attribute-based access control for remote healthcare monitoring. Paper presented at the Software Defined Systems (SDS), 2017 Fourth International Conference on. [34] Rohrer F, Zhang Y, Chitkushev L, Zlateva T. DR BACA: dynamic role based access control for android. In: Paper presented at the Proceedings of the 29th Annual Computer Security Applications Conference, New Orleans, Louisiana, USA; 2013. [35] Samsung. (n.d.). Knox standard sdk. https://seap.samsung.com/sdk/ knox- standard- android (accessed 20th Jan 2016). [36] Sandhu RS, Samarati P. Access control: principle and practice. Commun. Mag. IEEE 1994;32(9):40–8. doi:10.1109/35.312842. [37] Shebaro B, Oluwatimi O, Bertino E. Context-based access control systems for mobile devices. IEEE Trans. Depend. Secure Comput. 2015;12(2):150–63. [38] SonicWall. (2014). SonicWall security center. https://www.mysonicwall.com/ sonicalert/searchresults.aspx?ev=article&id=768 (accessed on 26 June 2018). [39] Sood AK, Enbody RJ. Targeted cyberattacks: a superset of advanced persistent threats. Secur. Privacy, IEEE 2013;11(1):54–61. doi:10.1109/MSP.2012.90. [40] Tankard C. Advanced persistent threats and how to monitor and deter them. Netw. Secur. 2011;2011(8):16–19. doi:10.1016/S1353- 4858(11)70086- 1.

11

[41] Unuchek, R. The asacub trojan: from spyware to banking malware. (2016). https://securelist.com/the- asacub- trojan- from- spyware- to- banking- malware/ 73211/ (accessed on 21 January 2018). [42] Wang L, Alexander CA. Big data in distributed analytics, cybersecurity, cyber warfare and digital forensics. Dig. Technol. 2015;1(1):22–7. [43] Whitman ME, Mattord HJ. Principles of information security. 4 ed. Cengage Learning, Inc; 2012. CENGAGE Learning. [44] Wu, R., & Chen, M. Spam campaign delivers cross-platform remote access trojan adwind. 2017. http://blog.trendmicro.com/trendlabs-security-intelligence/ spam- remote- access- trojan- adwind- jrat/ (accessed 25 April 2017). [45] Xenakis C, Ntantogian C. An advanced persistent threat in 3 G networks: attacking the home network from roaming networks. Computers & Security, 40 2014:84–94. doi:10.1016/j.cose.2013.11.006. [46] Zhao G, Xu K, Xu L, Wu B. Detecting APT malware infections based on malicious DNS and traffic analysis. IEEE Access 2015;3:1132–42. doi:10.1109/ ACCESS.2015.2458581. [47] Zhauniarovich Y, Russello G, Conti M, Crispo B, Fernandes E. MOSES: supporting and enforcing security profiles on smartphones. Depend. Secure Comput. IEEE Trans. 2014;11(3):211–23. doi:10.1109/TDSC.2014.2300482. [48] Zulkefli Z, Mahinderjit-Singh M, Malim N. Advanced persistent threat mitigation using multi level security – Access Control framework. In: Gervasi O, Murgante B, Misra S, Gavrilova ML, Rocha AMAC, Torre C, Taniar D, Apduhan BO, editors. Computational science and its applications – ICCSA 2015, 9158; 2015. p. 90–105. Springer International Publishing. [49] Zulkefli Z, Singh MM, Shariff ARM, Samsudin A. Typosquat cyber crime attack detection via smartphone. Procedia Comput. Sci. 2018.