dataesr/scientific-paragraphs-categorization huggingface dataset:
We also note that Cloud Computing (CC) security requirements are being usually implemented through a methodology in which threats are tackled and tested incrementally. Therefore, synthetic data can be useful to confirm that a system detects a particular type of anomaly when that anomaly can be defined and measured. Consequently, by integrating the business logic to the generated model, a portion of the company's behavior is analyzed. To add ground-truth labeling to the dataset, a flight operator provided us with a real use case, namely a flight scheduling multi-cloud application. For this reason, we added insider activity based on several realistic threat scenarios into the generated data. The main contributions of this paper are: • A dataset generation methodology that takes into account various issues and changes including statistical analysis as well as the creation of cloudrelated user scenarios.
• A dataset validation criteria based on a set of predefined rules that include statistical evaluation. • A design and presentation of a cloud-based proofof-concept with malicious insider attacks. The structure of the paper is as follows. Section 2 presents the related work. Section 3 presents of the threat of study, while Section 4 describes the dataset design and generation approach. Section 5 presents a proof of concept of our methodology. Finally, Section 6 concludes the paper and presents the future work.
RELATED WORK Many insider-threat datasets have been proposed in the literature. Authors of  (Kholidy and Baiardi, 2012)  proposed a cloud-based dataset for masquerade attacks, i. e. , where an attacker assumes the identity of an authorized user for malicious purposes. They utilized network and host traces from two machines of the DARPA dataset (Lincon Laboratory MIT, 2017), consisting in host-based audits from Windows NT and Unix Solaris, along with their corresponding TCP dump data. They correlated a seven week dataset and labeled the users from both machines into different roles according to their login session time and the characteristic of the user task (e. g. , programmer, secretary, system administrator). Later they assigned every user to a labeled VM. Additionally, non-cloud related literature on dataset generation shows a variety of approaches.
RUU dataset was provided by  (Salem and Stolfo, 2011) , also concerning masquerade attacks. They built a sensor host for Windows OS that captured user's registry actions, process execution and window touches. They collected normal users and analyzed differences of masquerade users, following a controlled exercise. Carnegie Mellon's Computer Emergency Response Team (CERT) generated a collection of synthetic insider threat test datasets  (Brian et al. , 2014)  to produce a set of realistic models. Authors of  (Shiravi et al. , 2012)  proposed the ISCX dataset, under the notion of profiles that contained detailed descriptions of intrusions and abstract distribution models for applications, protocol and lower level network entities. The ADFA dataset (UNSW, Australian Defense Force Academy, 2017) was proposed by  (Creech and Hu, 2013)  with modern attack patterns and methodology.
This dataset was composed of thousands of system call traces collected from a contemporary Linux local server, with six types of upto-date cyber attacks involved. The literature mentioned above raises many questions about the proper characterization of malicious insider threat and which features could adequately describe it for later detection techniques' analysis. Additionally, most of the presented datasets correspond to one-time implementations, which limits the generation and analysis to that particular testbed configuration. In this respect, we aim at an automatic dataset generation that can establish different scenarios with more dynamics taken into consideration. This feature also makes the analysis modifiable, extensible and reproducible. The following sections present this approach.
DATASET GENERATION This section contains the methodology for deriving a configurable and automatic dataset for malicious insider threat in cloud environments. We note that in thise case, the anomalous events are generated from a semantically distinct process than the generated from normal Events. For example, as mentioned in  (Emmott et al. , 2013) , anomalous events should not just be points in the tails of a Normal distribution. Moreover, to provide heterogeneous data, they should be generated from different criteria.
Context consists of attributes related to specific time and location conditions where the Profile is performing its Role (e. g. , location, time of the day, IP from where jobs are being executed, cloud instance trying to access, among others). Asset consists of any valuable hardware or software component, property of a CSP or CSC in the CC stack (e. g. , physical servers, VMs, applications, databases, communication infrastructure), depending on SaaS, PaaS or IaaS models. Permission is the type of authorization a Role has for a given Asset (e. g. , read, modify). On the other hand, the simulation also includes the event-related entities: Sequence of actions is a list of sequential Actions performed by the same Profile under a given time interval. The approach generates three types of Sequences: (i) Pseudo-randomly selected Actions, following a specified distribution, (ii) Predefined normal and anomalous Sequences of Actions, under realistic scenarios, (iii) Hybrid sequences, composed by fixed actions in arbitrary positions, filled with pseudo random actions for the rest of the sequence.
Generation Algorithm The Algorithm 1 presents the dataset generation methodology. This process is initiated by a list of Profiles, the inter-arrival time between agents (tba) and the timeout (to). The tba parameter has relation with the amount of Agents to generate, and therefore with the Event generation process. Below, we provide more details related to the proposed algorithm referring to the corresponding lines of it. Lines 2 to 7: Algorithm defines the delay for which it will create an Event from a pseudorandomly chosen Profile. This generation is done with an exponential distribution, in order to model the pseudo-random generated sequences as a Poisson process (Line 6). Lines 10 to 14: An agent function takes the form of a Profile assigned by a Role and Time Between Events (tbe) (e. g.
Dataset Validation Defining suitable criteria for dataset validation is a complex process, since there are no general method-  end for 26: end function ologies in the literature  (Claycomb and Nicoll, 2012). To this end, we have defined three validation criteria. The first two (namely, items 1 and 2) add an a priori degree of realism to detect plausible attacks, as the result of consulting with the CSC use-case experts. The third (namely, item 3) rely on an a posteriori verifica-tion and is used to prove the applicability of the proposed approach given the nature of the data for prediction or detection techniques: 1. Statistical similarity of events: the generated Events, should be statistically based in realistic behaviors for every Profile entity and each threat scenario. Such statistical data can be either provided by an oracle aware of the activities for each Role, or from traces of real case studies for later extrapolation.
One example could be a number of actions an employee should do on a monthly basis. In this case, an expert knows that a security administrator can initiate an action at any given time (e. g. , 24x7 service availability) while a Database Administrator (DBA) Role should not initiate more than N Events per month, that consider a database back-up Sequence. 2. Sequences realism: the pseudo-random generated set of sequences for each event, should be validated to make sense in the context of the Permission-Asset tuple. In other words, independent actions to a given asset, for example, data elimination or tampering from a database, might not have a pre-defined order. In the case of other tuples, such as actions to a VM asset, it might be intuitive to generate Sequences with a given order (i. e. , an action of shuttingVMDown(), this action cannot be followed by any other operation that assumes the VM is operational).
The latter means that the set of invariants from the second group includes the ordering of the actions performed, i. e. , action B in a Sequence cannot be executed by a given Profile unless the action A has been processed. 3. Anomaly detection techniques benchmarking: For an accurate prevention of this threat, proper anomaly detection benchmarking can be performed. For this matter, the dataset should contain "well distributed" labeled Events and its technique should recognize possible label imbalance (malicious Events are less frequent than normal). This is relevant at the moment of experimenting with detection techniques such as supervised machine learning models, as they can try to fit anomalies with normal events. Also, performance indicators such as AUC (Area Under the ROC curve) provide better understanding of the variability, where accuracy is divided into sensitivity and specificity, and better configurations can be chosen based on the balance thresholds of these values.
PROOF OF CONCEPT The proof of concept is performed based on an airline scheduling cloud application provided by a CSC operator. Today's airlines need to permanently revise their flight schedule plans in response to competitor actions, while constantly maintaining operational integrity. In this case study, we are particularly interested in researching how insider threats can attempt to perform malicious activities towards the Database Management System (DBMS) component, as it stores very relevant data about the flights and personal client information. The feasibility and effectiveness of our approach are evaluated through the validation criteria given in Section 4. 3 and are presented in Section 5. 2. To perform our experiments, we have designed a testbed composed of two Linux instances in Open-Stack, as depicted in Figure  2.
These instances define the functionalities of an airline service, where the "Server Instance" consists of several application artifacts and system components, and communicates with the DBMS application. The created dataset contains generated events from five consecutive years. The chosen design criteria for the Profiles generated is outlined in Table  1. The description of the a five-month period is depicted in Figure  3 , with the different nature of the normal and anomalous event generation i. e,. different frequency given by the Factor attribute for each Profile.
Profile's Behavior Representation As mentioned in the definition of entities, we represent each profile's behavior following a role-based approach. We utilize as an example a DBA, defined as a user in charge of administrative actions towards the database, such as installation, patching and upgrade of the database. This includes the ownership of all objects of the database and the ability to create and modify roles and users. As defined in Section 4. 1, each Role has pseudorandom, predefined and hybrid group of generated Sequences followed by a normal behavior. The following statements represent the examples of the events a DBA can perform and, therefore, define the DBA normal behavior: • A DBA in a working day, logs into the DBMS and enrolls a new user with write permission over a database.
• A DBA regularly works remotely on Wednesdays, logging into the DBMS from location a , while the rest of the week from location b. On the other hand, the following sequences can represent the examples of the generated Sequences for an anomalous DBA behavior: • A DBA logs in from a public IP that does not belong to the company and performs a sequence of actions. • A DBA outside Working Hours (WH), logs in and performs numerous sequences of actions on the database. We have outlined three types of Profiles (DBA 1 , DBA 2 and DBA 3 ) with the same DBA Role, differentiating them by a created Factor named "skill level" as described in Table  1. This Factor defines the time taken to perform a Sequence of actions with low, medium and high skills and prompts the sequences' length. We also have modeled the three profiles with the Factor of being malicious, with different probabilities or discontent.
Results The validation criteria presented in Section 4. 3, allow us to determine the usability of the generated dataset. We verify these criteria with the given proofof-concept in the following steps. For the first criteria, we refer to Figure  3  and Table  2  for the average and standard deviation of the generated Events. The second criteria studies the realism of the sequences performed by each Profile, with respect to their Role in the company. We have validated our  generation methodology by using the sequence alignment algorithm and obtained scores for our predefined sequences i. e. , Create (C), Read (R), Update (U), Delete (D), treated as sub-sequences among all the generated sequences. This other group of sequences and their pseudo-random generation, derive in a heterogeneous dataset with the length showed in Table  3.
The Table  4  shows the results for the last item of the validation criteria, where we addressed the well-known machine learning classifier Support Vector Machine (SVM) to estimate the quality of the generated dataset with respect to their classification performance: Recall (T P/(T P + FN) where TP and FN are True Positive and False Negative values, respectively) and Precision, which shows the ability of the  classifier not to label as positive a sample that is negative (T P/(T P + FP), where FP is False Positive). Additionally, the AUC score is a plot of the TP rate versus FP rate for a binary classifier as its discrimination threshold varies. The area under the ROC curve (AUC) therefore reflects the relationship between sensitivity and specificity. Below, we present a 3 experiential setup, namely Exp.
CONCLUSION In this paper, we have presented a methodology for dataset generation and a validation approach including several criteria such as statistical evaluation, sequence realism and benchmarking of detection techniques. Even more, we have implemented a proofof-concept with anomalous malicious insider attacks, which has been validated on a realistic use-case. As a conclusion, we can say that the results obtained will be very useful for intrusion detection techniques and, in particular, for these working on malicious insider threats. As a future work, we plan to extend the results presented in this paper by the addition of social engineering factors to our model and the benchmarking of new scenarios, to evaluate the impact of data variability. Another future research will be to use the cloudbased dataset we have created to compare the detection ability of different anomaly-based intrusion detection techniques.
Concept & Technical Setup The loop sequencer is comprised of two user interfaces: (1) an individual interface used by each participant through their smartphone allowing them to alter the sound emitted from it, as illustrated in Fig. 1,  and  (2) a shared, floorprojected, circular visualization (of approx. 3m in diameter) showing all participants' choices as well as the current position of the sequencer's reading head (represented by a bright moving sector), as depicted in Fig. 2a. The CoSiMa platform, and consequently Collective Loops, is developed using open Web technologies such as Node. js, WebGL, and the Web Audio API. The Collective Loops installation is composed of three main software components: (1) a local server managing inter-device synchronization and communication, (2) a mobile web application accessible via a local Wi-Fi hotspot handling the individual user interfaces, and (3) a web application running on a local machine connected to a video projector handling the floor-projected shared interface.
Indeed, the charts reveal that most participants deemed that they were able to follow their own actions, but were not fully aware of others' actions and did not pay attention to others' choices very often. They also indicated that they rarely communicated with their peers and did not quite feel engaged in a collaborative process. Data collected from system logs, illustrated in the diagrams of Fig. 4 , reveal that the average number of simultaneous participants was slightly lower on NSloop (2. 8) than on RHloop (3. 1). And, against our expectations, the total time spent per participant on the installation was on average shorter on NSloop (4'27") than on RHloop (7'05"). This might have been a consequence of the lack of shared information on RHloop forcing one to spend more time to apprehend the system.
INTRODUCTION The number of malwares is significantly increasing. In 2014, there were more than 317 million new pieces of malwares 1 compared to 286 millions in 2010. It is estimated that there are nearly a million of new malwares released every day. Thus, malware detection is a big challenge. The well-known technique to detect malware is signature matching. It consists on searching for patterns in the form of binary sequences (called signatures) in the program. Signatures are manually introduced in a database by experts. If a program contains a signature in the database, it is declared as a virus. If not, it is declared as benign. It is very easy for virus writers to get around these signature matching techniques. Indeed, obfuscation techniques can change the structure of a malware so that it will not have a known signature anymore while keeping its same behavior.
Indeed, API (which stands for Application Programming Interface) is a collection of functions supported by the operating system that allow users to interact with the system. These API functions are mediators between programs and their running environment (user data, network access. ) that are mostly used to access or modify the system by malware authors. According to a statistic study 2  , over 5TB of different samples of malwares, there are 527, 992 samples that did import at least one API, compared to 21, 043 samples with no import. Thus, API functions and their usages in the program are crucial to specify malicious behaviors. Let us consider a typical malicious behavior. In order to represent this behavior we use an API call graph, which is a graph whose vertices are pairs (n, f ) consisting of an API function f and a control point n, and whose edges ((n, f ),(n , f )) express that there is a call to the API function f at the control point n, followed by a call to the API function f at the control point n , such that between the calls f and f , there is no other call to another API function.
In this work, we use a variant of the random walk graph kernel that measures graph similarity as the number of common paths of increasing lengths. The main contribution of this paper is the application of graph kernel based learning techniques for malware detection in a completely static way (no dynamic analysis). As far as we know, this is the first time that these techniques are applied for malware detection in a static manner. We implemented our technique in a tool and tested it on a dataset of 6291 malwares, that are collected from Vx Heavens 3  , and obtained encouraging results. Our tool can achieve a high detection rate with only few false alarms (98. 93% for detection rate with 1. 24% of false alarms). Moreover, we show that our techniques are able to detect several malwares that could not be detected by well-known and widely used antiviruses such as Avira, Kaspersky, Avast, Qihoo-360, McAfee, AVG, BitDefender, ESET-NOD32, F-Secure, Symantec or Panda.
BINARY CODE MODELING Malwares are usually executables, i. e. , binary codes. Thus, we show in this section how to extract an API call graph from a binary code. Given a binary code, we apply the disassembly tools IDA Pro (Eagle, 2011), Jakstab  (Kinder and Veith, 2008)  and BePum  (Nguyen et al. , 2013)  to extract a control flow graph (CFG) (a standard representation of programs in the program analysis community). Then, we use this CFG to construct an API call graph. Since mal-wares contain a huge number of instructions in their codes, the obtained API call graphs are huge (more than 854 vertices in our dataset). Thus, the learning technique we applied took a lot of time. To be more efficient, we introduce an abstraction of the API call graph, called abstract API graph, that consists in merging the vertices of the API call graph that correspond to the same API function.
Abstract API Graph As the size of the previous graph is quite huge in the case of malwares, we apply an abstraction to reduce the size of the API call graphs by merging vertices corresponding to the same API function in one vertex associated with the function name, i. e. , the vertices (n 1 , f ), (n 2 , f ),. , (n k , f ) are merged in a single vertex labeled by the API function f. By doing that, the size of graphs in our dataset is reduced by about a quarter while the accuracy is not changed so much. Thus, all our experiments are made on abstract API graphs (not on API call graphs). Given an API call graph G api = (V api , E api ), an abstract API graph is a directed graph G aapi = (V aapi , E aapi ), where V aapi ⊆ A is a set of vertices, and E aapi is a set of edges. Each vertex is labeled by an API function.
LEARNING MALICIOUS BEHAVIORS In order to detect malicious behaviors, we cast the problem of malware detection as graph classification. The goal is to check whether a given unseen data 4  belongs to the positive (malign) or the negative (benign) class. For that purpose, we build a classifier, that decides about this class membership using a labeled training set. The latter includes positive as well as negative examples. In what follows, we discuss the application of kernel-based support vector machines (SVMs) in malware detection. The choice of SVMs is motivated by their well established generalization ability in many pattern classification problems, especially those involving small or mid size training databases. More importantly, and in contrast to other well known training algorithms, SVMs are very suitable when handling semi-structured and non-vectorial data (such as graphs), through the use of well dedicated kernel functions as shown subsequently.
Dataset and Evaluation Measures In order to evaluate the performance of our kernelbased SVMs, we collect a dataset of 6291 malware samples from Vx Heavens and 2323 benign programs from system files and applications in Windows OS and Cygwin. The proportion of malware categories is shown in Figure  2. The dataset randomly split into two partitions, a training and a testing partition. For training partition, the quantity of malwares and benign programs is balanced with 2000 samples for each. The testing set consists of 4291 malwares and 323 benign programs. In order to capture the variability of the dataset, we use 5 random splits of training and test data, then we take the average of the performances. Computing the kernel matrix for the whole dataset of 8614 graphs takes 3 days, but this is an offline computation.
Online computation to classify a new program with size 15 KB takes 15 seconds. Using this dataset, we consider two subtasks for evaluation. • Malware detection. This is the principal task of our contribution. We train a single monolithic SVM classifier (h) using positive and negative data in the training set. This classifier h is used in order to check whether a given test graph G belongs to the malign (positive) or benign (negative) class depending on the sign of h(G), i. e. , τ = 0. • Malware category recognition. As a secondary task, the goal is to recognize the category of a given malign graph G. For that purpose, we train for each category (denoted c), a "one-versus-all" SVM classifier h c that separates graphs belonging to the c th category from all others. Given a test graph G with h(G) ≥ 0, the category of G corresponds to arg max c h c (G).