text:
Network Anomaly Detection: A Survey and Comparative Analysis of Stochastic and Deterministic Methods

We present five methods to the problem of network anomaly detection. These methods cover most of the common techniques in the anomaly detection field, including Statistical Hypothesis Tests (SHT), Support Vector Machines (SVM) and clustering analysis. We evaluate all methods in a simulated network that consists of nominal data, three flow-level anomalies and one packet-level attack. Through analyzing the results, we point out the advantages and disadvantages of each method and conclude that combining the results of the individual methods can yield improved anomaly detection results.

I. INTRODUCTION
A network anomaly is any potentially malicious traffic that has implications for the security of the network. It is of particular importance to the prevention of zero-day attacks, i.e., attacks not previously seen, and malicious data exfiltration. These are key areas of concern for both government and corporate entities.
From the perspective of methodology, network anomaly detection methods can be classified as stochastic and deterministic. Stochastic methods fit reference data to a probabilistic model and evaluate the fitness of the new traffic with respect to this model [7], [11], [12], [22], [29]. The evaluation can be done using Statistical Hypothesis Testing (SHT) [5], [13], [16], [19]. Deterministic methods, on the other hand, try to partition the feature space into "normal" and "abnormal" regions through a deterministic decision boundary. The boundary can be determined using methods like Support Vector Machine (SVM), particularly 1-class SVM [9], [21], [25], and clustering analysis [1], [6].
From the perspective of data, network anomaly methods can be either packet-based [7], [17], flow-based [2], [18] or window-based [12]. Packet-based methods evaluate the raw packets directly while both flow-based and window-based methods aggregate the packets first. Flow-based methods evalulate each flow individually, which is defined as a collection of packets with similar properties. Flows are considered as a good tradeoff between cost of collection and level of detail [26]. Window-based methods group consecutive packets or flows based on a sliding window. suspicious windows of time can be identified as anomalous.
Model-free and model-based methods are stochastic and the rest methods are deterministic.
A challenging problem in the evaluation of anomaly detection methods is the lack of test data with ground truth, due to the limited availability of such data. The most widely used labeled dataset, DAPRA intrusion detection dataset [14], was collected 14 years ago. Since then, the network condition has changed significantly. In order to address this problem, we developed software to generate labeled data, including a flow-level anomaly data generator (SADIT [28]) and a packet-level botnet attack data generator (IMALSE [27]). We evaluate all of our methodologies on a simulated network and compare their performance under three flow-level anomalies and one Distributed Denial of Service (DDoS) attack.
The rest of the paper is organized as follows. Section II describes the representation of network traffic data. Section III provides a mathematical description of the methods used to identify anomalies. Section IV provides an in-depth explanation of the simulated network and the anomalies. Section V presents the results of the five methods on the simulated network data. Finally, Section VI provides concluding remarks.

II. NETWORK TRAFFIC REPRESENTATION
Let S = {s 1 , . . . , s |S| } denote the collection of all packets on the server which is monitored, where each element of S is one packet. We focus on host-based anomaly detection, in which case we only care about the user IP address, namely the destination IP addresses for the outgoing packets and the source IP addresses for the incoming packets. Denote the user IP address in a packet s i as x i , whose format will be discussed later. The size of s i is b i ∈ [0, ∞) in bytes and the start time of transmission is t i ∈ [0, ∞) in seconds. Using this convention, the packet s i can be represented as Due to the vast number of packets, we consolidate this representation of network traffic by grouping series of packets into flows. We compile a sequence of packets s 1 = ( . . , n and some prescribed δ F ∈ (0, ∞). Here, the size b is simply the sum of the sizes of the packets that comprise the flow. The value d t = t n − t 1 denotes the flow duration. The value t = t 1 denotes the start time of the first packet of the flow. In this way, we can translate the large collection of traffic packets S into a relatively small collection of flows F = {f 1 , . . . , f |F | }.
In some applications in which large numbers of users frequently access the server under surveillance, it may be infeasible to characterize network behavior for each user. Different methods deal with this dilemma differently.
For both statistical and SVM methods, we first distill the "user space" into something more manageable while enabling us to characterize network behavior of user groups instead of just individual users. For simplicity of notation, we only consider IPv4 addresses. If . . , 255} 4 are two IPv4 addresses, the distance between them is defined as: d(x i , x j ) = k=1,...,4 256 4−k |x i k − x j k |. This metric can be easily extended to IPv6 addresses if needed. Suppose X is the set of unique IP addresses in F. We apply typical K-means clustering on X [8], [15]. For each x ∈ X , we thus obtain a cluster label k(x). Suppose the cluster center for cluster k isx k , then the distance of x to the corresponding cluster center is d a (x) = d(x,x k(x) ). Using user clusters, we can produce our final representation of a flow as: For the ART clustering method, distilling the user space beforehand is not required. However, instead of using the IP address directly, we use a compact representation. Let n f (x) be the number of flows transmitted between the user with IP address x and the server. Define d b (x) = d(x, x * ), ∀x ∈ X , where x * is the IP address of the server we are monitoring; then the alternative flow representation we use is: (2)

A. Statistical Methods
Let h be the interval between the start points of two consecutive time windows and w s be an appropriate window size; then the total number of windows is be the flow attributes in f i without the start time t i and G j = {g 1 , g 2 , . . . , g |Gj | } be the flows in window j. Let G ref be the set of all flows used as reference. The window-based methods will compare G j with G ref for all j = 1, . . . n w . Both statistical methods we will present in this section fall into this category and can work in supervised as well as unsupervised modes. In supervised mode, G j is generated by removing suspicious flows from a small fragment of data through human inspection. In unsupervised mode, we assume that the anomales are shortlived thus G j can be chosen as a large set of nework traffic.
Since the approach introduced in what follows applies to all windows as well as to nominal flows, we use . We can then define a discrete alphabet Σ da = d min a where |Σ da | is called quantization level. Σ b and Σ dt can be defined similarly for b i and d i t . We then quantize d a (x i ), b i and d i t in g i to the closest symbol in the discrete alphabet set Σ da and Σ b and Σ dt , respectively. Suppose the total number of user clusters is K. Then we can denote the quantized flow sequence discrete alphabet for quantization where each symbol in Σ corresponds to a flow state.
1) Model-free Method: In cases in which all flows emanating from the server under surveillance are i.i.d., we construct the empirical measure of flow sequence G = {g 1 , . . . , g |G| } as the frequency distribution vector where 1{·} denotes the indicator function and σ(g i ) denotes the flow state in Σ that g i gets mapped to. We will denote the probability vector derived from the empirical measure of the form in (3) as Let µ denote the probability vector calculated from the reference flows G ref . That is, µ(σ) is the reference marginal probability of flow state σ. Using Sanov's theorem [16], [4], we construct a metric to compare empirical measures of the form in (3) to µ, thus a metric of the "normality" of a sequence of flows. For every probability vector ν with support Σ, let H(ν|µ) = σ∈Σ ν(σ) log (ν(σ)/µ(σ)) be the relative entropy of ν with respect to µ. Allowing η = − 1 n log , where is a tolerable false alarm rate, then the model-free anomaly detector is: where It was shown in [19] that (4) is asymptotically Neyman-Pearson optimal.
2) Model-based Method: As an alternative to the i.i.d. assumption on the sequence of flows under the model-free method, we now turn to the case in which the sequence of flows adheres to a first-order Markov chain. The notion of empirical measure on the sequence G = {g 1 , . . . , g |G| } must now be adapted to consider subsequent pairs of flow states. We assume no knowledge of an initial flow state σ(g 1 ) and define the empirical measure on G, under the Markovian assumption, as the frequency distribution on the possible flow state transitions, where 1{·} denotes the indicator function and σ(g l ) denotes the flow state in Σ which g l gets mapped to. We will denote probability matrices formed by the empirical measure in (5) ..,|Σ| . In the following, we will refer to matrices of the form Q = {q(σ i , σ j )} i,j=1,...,|Σ| as probability matrices with support Σ × Σ. By design, the empirical measures of the form (5) are probability matrices with support Σ × Σ. Each probability matrix, under the Markovian assumption, is associated with a transition probability matrix of the form Here q(σ i ) = |Σ| j=1 q(σ i , σ j ) denotes the marginal probability of flow state σ i in Q.
Let Π = {π(σ i , σ j )} i,j=1,...,|Σ| denote, under the Markovian assumption, the true probability matrix of sequences of flows. As in the i.i.d. case, we compute Π via (5) from G ref . Following a similar procedure as in the i.i.d. case, we use an analog of the Sanov's Theorem for the Markovian case, which appears in [4], as the basis for our modelbased stochastic anomaly detector. For every shift invariant probability matrix Q with support Σ × Σ, let be the relative entropy of Q with respect to Π. Then in the model-based method, the indicator of anomaly for G is: where and η = 1 n log with be an allowable false alarm rate. Again, the model-based detector has been proved in [19] to be asymptotically Neyman-Pearson optimal.

B. 1-class SVM
We turn now to deterministic methods based on the construction of a decision boundary. We focus on one popular technique named 1-class SVM [16], [24]. The premise behind 1-class SVM is to find a hyperplane that separates the majority of the data Z = {z 1 , . . . , z |Z| } from the outliers by solving a Quadratic Programming (QP) Problem [19], [24]. The hyperplane can be generalized to a nonlinear boundary by mapping the inputs into high-dimensional spaces with a kernel function K(·, ·) [9]. There is a tunable parameter ν effectively tuning the number of outliers.
1) Flow 1-class SVM: We consider a set of flows G = {g 1 , . . . , g |G| } that need to be evaluated. According to (1), each flow has the format of g = (k(x), d a (x), b, d t ), which has already provided a rather compact representation of network traffic. The only additional process required is to remove the label of the cluster each user belongs to. The new data are: The reasoning for this is that, since we are measuring departures from nominal users, the actual cluster a user belongs to is less important than the distance between the user the cluster center. Besides, as a categorical attribute, cluster labels make 1-class SVM method more unstable in practice. Besides, we choose the radial basis as the kernel function [16].
2) Window 1-class SVM: We combine the techniques described in Section III-A and the 1-class SVM into a window-based 1-class SVM method. For each window j with flows G j , we can get the model-free empirical measure E Gj and the model-based empirical measure E Gj B . Let the feature vector for window j be Y j = E Gj , E Gj B , |G j | . Let Y = {Y 1 , . . . , Y |Y| } be a time series consisting of the features for all windows, then an 1-class SVM can be used to evaluate Y, resulting in a window-based anomaly detector. Note that since the dimension of feature Y j is usually very large, it often helps to apply Principal Component Analysis (PCA) [20] to reduce the dimensionality first.

C. ART Clustering
In this section, we present a clustering algorithm based on ART theory [3] and apply it to network anomaly detection. The algorithm first organizes inputs into clusters based on a customized distance metric. Then, a dynamic learning approach is used to update clusters or to create new clusters.
Assume a set of flows F = {f 1 , . . . , f |F | } with form in (2). Similar to the statistical methods, we define to be the attributes in f i without the start time t i and G is the counterpart of F. Suppose g ij is the jth attribute of flow g i for all i = 1, . . . , |G| and j = 1, 2, 3, 4. Defining f min (j, G) and f max (j, G) to be the minimum and maximum of the set {g ij : ∀i = 1, . . . , |G|}, we can normalize G according toĝ ij = g ij −fmin(j,G)) fmax(j,G)−fmin(j,G) for all i = 1, . . . , |G|, and j = 1, 2, 3, 4. In this section we assume that the data in G has already been normalized.
Define the distance metric for two m-dimensional vectors p = (p 1 , . . . , p m ) and q = ( represent the center of cluster k and c j k be its j component. Let C be the set of all cluster centers. For every c ∈ C and a prescribed r, defines an ellipsoid in R m . A higher vigilance in one dimension means the ellipsoid is more shallow in this direction. The ART clustering algorithm is shown in Algorithm 1. Initially C is empty. For each flow g i ∈ G, we calculate the set D which consists of all clusters whose ellipsoid defined by (8) contains g i . Suppose E(g, c) is the Euclidean distance between g and c. If D is not empty, g i is assigned to the cluster whose center has the smallest Euclidean distance with g i and the corresponding cluster center is updated; otherwise a new cluster is created. Suppose that flow g i will be assigned to cluster k, let c j k and c j k be the jth component of the center of cluster k before and after the assignment, then where p is the number of flows in cluster k before the assignment. Because of the adaptive update (9), some assignments may become unreasonable after update as some flows may become closer to other cluster centers. As a result, the algorithm processes flows in G again until an equilibrium is reached. Once a stable equilibrium is reached, small outlying clusters are identified as anomalous based on the rule where I A (T k ) is an indicator of anomaly for T k , τ ∈ [0, 1] is a prescribed detection threshold, |C| and |G| are the total Algorithm 1 ART clustering Algorithm Recalculate cluster center of T k using (9) end if end for end while central node number of clusters and flows, respectively. τ determines how small a cluster must be to be considered as anomalous, thus it influences the number of alarms. We will discuss the relationship of τ and the false alarm rate further in Section V.

IV. NETWORK SIMULATION
The lack of annotated data is a common problem in the network anomaly detection community. As a result, we developed two open source software packages to provide flow-level and packet-level validation datasets, respectively. SADIT [28] is a software package containing all the algorithms we described above. It also provides an annotated flow record generator powered by the fs [26] simulator. IMALSE [27] uses the NS3 simulator [10] for the network simulation and generates packet-level annotated data. Simulation at the packet-level takes more computation resources but can mimic certain attacks, like botnet-based attacks, in a more realistic way. We validate our algorithms with the help of these two software packages. The packets generated by IMALSE, which is of pcap format [27], are transformed into flow records first. Then the flows generated by SADIT and IMASLE are tested independently with each algorithm.
The simulated network is partitioned into an internal network with a hub and spoke topology that connects to the Internet via a gateway (Fig. 2). The internal network consists of 8 normal users (CT1-CT8) and 1 server (SRV) with some sensitive information. We monitor the traffic on the server.

A. Flow-level Anomalies
First, we generate a dataset with flow-level anomalies. The size and the transmission of the nominal flows for user i is assumed to follow a Gaussian distribution N (m i , σ 2 i ) and Poisson process with arrival rate λ i , respectively. We investigate three most common types of flow-level anomalies.
The first one mimics the scenario according to which a network intruder or unauthorized user downloads restricted data. A previously unseen user who has a large IP distance to the rest of the users starts transmission for a short period. The second one is a user i with suspicious flow size distribution characterized by a mean m a i higher than a typical value m i . Usually flows with substantially large flow size are associated with the situation when some users try to download large files from the server, which can happen when the attacker tries to download the sensitive information packed into a large file. The last one is a user increasing its flow transmission rate to an unusual value λ a i , which could be indicative of the user finding an important directory on the server and downloading, repeatedly, sensitive files within that directory.

B. Packet-level Anomalies
A second anomalous dataset is created using the tool IMALSE [27]. The nominal traffic is generated using the on-off application in NS3 [10], [27] in which the user sends packets for t on seconds and the interval between two consecutive transmission is t of f . The traffic is a Poisson process, which means the on time and off times are exponentially distributed with parameter λ on and λ of f , respectively.
We assume there is a botnet in the network. There is a botmaster controlling the bot network and a Command and Control (C&C) server issuing control commands to the bots. In our simulation, both the botmaster and C&C server are the machine INT2 in the Internet, and CT1-CT5 in the internal network have been infected as bots. We investigate a DDoS Ping flood attack in which each bot sends a lot of ping packets to the server SRV upon the request of the C&C server, aiming to exhaust the bandwidth of SRV. The attack is simulated at the packet-level and the data are then transformed into flow records using techniques described in Section II. With appropriate δ F , the t on becomes the flow duration of nominal flows and the t of f determines the flow transmission rate of nominal flows. The initiating stage of the attack is similar to the first case in the previous section. During the attack, both the flow transmission rate and the flow size of the bots may be affected. First, the flow transmission rate is increased as the bots ping SRV more frequently. Second, the ping packets have different sizes from normal network traffic. Also, consecutive ping packets may be combined together if they are sent over a short time interval. The resulting flows may be very large in size if these combinations are common or very small otherwise, depending on the attack pattern.

V. RESULTS
A. Flow-level Anomalies 1) Atypical User: Figure 3 shows the response of all methods described above when there is an atypical user trying to access the server between 1000s and 1300s. For window-based methods, the interval between the starting point of two consecutive time windows is h = 30s and the window size is chosen as w s = 200s, so there is overlap between two consecutive time windows. We also distill the user space by using K-Means clustering with 3 clusters. The quantization levels for flow size, distance to cluster and flow duration are 3, 2, 1, respectively, thus |Σ| = 18. The x-axis in all graphs corresponds to time (s) and the total simulation time is 5000s. The first two graphs depict the entropy metric in (4) and (6) of the model-free and model-based methods, respectively. For both graphs, the green dashed line is the threshold when the false alarm rate is = 0.01. The interval during which the entropy curve is above the threshold line (the red part) is the interval the method reports as abnormal. The x coordinates of the red points with a '+' marker correspond to the start point of the flow or the window the method reports as abnormal. The parameter ν for the flow 1-class SVM and window 1-class SVM is 0.002 and 0.1, respectively. The threshold τ for ART clustering is 0.05.
We can observe from Figure 3 that stochastic methods, including our model-free and model-based methods, tend to produce more stable results in the sense that they generate fewer false alarms. At the same time, the flow 1-class SVM and ART clustering methods, both of which are flow-based, can provide higher identification resolution in the sense that they can identify the suspicious flows, which is beyond the capabilities of the stochastic methods. In the window 1-class SVM method, we can tune the window size to adjust the tradeoff of resolution and stability. However, the window size in the model-free and model-based methods has to be reasonably large since the optimality of the decision rule (4) and (6) relies on the assumption of a large flow number in each window.
This observation indicates that these methods are complementary to each other. One way to combine them is to use stochastic methods and window-based deterministic methods to get a rough interval of an anomaly. Then, only the flows that are both identified as suspicious by flow-based deterministic methods and belong to the interval need to be further evaluated. The first subfigure in Figure 4 shows the Receiver Operating Characteristic (ROC) curve of the ART clustering method, which is a flow-based method, and the combination of the ART clustering and the model-free method. The ROC curve has been substantially improved after combining the two methods. The second subfigure in Figure 4 shows the relationship between the threshold τ defined in (10) and the false alarm rate. The x-axis is the false alarm rate and y-axis corresponds to the threshold. As we can see, the false alarm rate increases when the threshold increases and they are almost linearly related to each other.  2) Large File Download: Figure 5 is the output of all methods in the case where a user doubles its mean flow size between 1000s and 1300s. Again, the first two graphs show the entropy curve and threshold line of the model-free and model-based methods. The total simulation time is 5000s. The common window parameters h and w s are the same as in the previous case. The false alarm rate is = 0.01 for both model-free and model-based methods. The parameter ν for flow 1-class SVM and window 1-class SVM is 0.0015 and 0.1, respectively. τ = 0.01 for ART clustering.
3) Large Access Rate: Figure 6 shows the response of model-free, model-based, window 1-class SVM and ART clustering methods when a user suspiciously increases its access rate to 6 times of its normal value during 1000s and 1300s. The total simulation time is 2000s. The parameters for the algorithms are the same in the atypical user case.
Note that flow 1-class SVM cannot work for this type of anomaly since it is purely temporal-based. The flow itself does not change but its frequency does. There is no way to identify the frequency change by just observing the individual flows with representation in (1). ART clustering works fairly well for this case because the attacker will have larger n f (x) as it transmits more flows. Interestingly, the model-based and model-free methods can work very well since the portion of traffic originating from the attacker changes, influencing the empirical measure defined in (3) and (5). The two methods will not be effective in the very rare case when all users increase their rate by the same ratio synchronously.  Figure 7 shows the response of model-free, model-based, window 1-class SVM and flow 1-class SVM methods when there is a DDoS attack targeting SRV between 500s and 600s. The total simulation time is 900s. For window-based methods, the interval between consecutive time windows is h = 10s and the window size is w s = 100s. The false alarm rate for the model-free and model-based method is = 0.01 and ν = 0.05 for window SVM.

B. DDoS Attack
Since the nominal traffic in IMALSE is generated based on an i.i.d assumption, it is hard for the model-based method to capture a Markov model. Yet, the model-based method still detects the start and the end of the attack, during which the transitional behavior changes the most. Model-free and window 1-class SVM are more stable while the flow 1-class SVM method provides higher resolution.
The ART clustering method is also not suited to detect these type of attacks because the unsupervised learning model is based on the assumption that malicious network traffic represents a small percentage of total network traffic. A DDoS attack generates a large number of packets and without some prior knowledge of good or bad network traffic, the ART clustering algorithm cannot distinguish between the nominal and abnormal flows. It is also the reason for the relatively unsatisfactory performance of the flow 1-class SVM method. However, window 1-class SVM is not affected by this because despite the large number of abnormal flows, the number of abnormal windows is still very small.

VI. CONCLUSION
We presented five complementary approaches, based on SHT, SVM and clustering, that cover the common techniques for host-based network anomaly detection. We developed two open source software packages to provide flow-level and packet-level validation datasets, respectively. With the help of these software packages, we evaluated all methods on a simulated network mimicking typical networks in organizations. We consider three flow-level anomalies and one packet-level DDoS attack.
Through analyzing the results, we summarize the advantages and disadvantages of each method. In general, deterministic and flow-based methods, such as flow 1-class SVM and ART clustering, are more likely to have unstable results with higher false alarm rates but they can identify abnormal flows, namely they have better resolution. Stochastic and window-based methods, such as our model-free and modelbased methods, could yield more stable results and detect temporal anomalies better, but they have relatively poor resolution as they are not able to explicitly detect the anomalous network flows. In addition, deterministic and window-based methods, like window 1-class SVM offer parameters to adjust the tradeoff of resolution and stability. This observation suggests that combining the results of all, instead of just using one method, can yield better overall performance.


Mutation Analysis for Security

Security has become, nowadays, a major concern for the organizations as the majority of its applications are exposed to Internet, which increases the threats of security considerably. Thus, the solution is to improve tools and mechanisms to strengthen the protection of applications against attacks and ensure the different security objectives. Among solutions we will talking about, in this paper, there is Mutation Analysis which is a technique of test that evaluates the quality of software tests and their ability to detect errors, It also compares the criteria and test generation strategies. In this study we will use the Mutation Analysis as a mean to qualify the penetration tests, and then, apply this technique in the security mechanisms and exactly on the mechanisms of access control. At the end we will propose a method for the elimination of hidden mechanisms for access control that will allow the access control policy to evolve.

INTRODUCTION
Web applications become a need for companies and organizations as main communication tools and commercial windows. Yet, this need is limited by security threats that increase significantly every year. Among security threats cited, there are security flaws which the number of announced ones continues to rise, according to statistics of the Common Vulnerabilities and Exposures dictionary (CVE) that counts more than 5000 new security flaws every year and until May 2012, there are more than 2000 new security attacks detected. Thus, the solution to this problematic is to develop security tools and mechanisms, and improve the existing ones to strengthen the protection of applications against attacks, taking into consideration the different security objectives (integrity, confidentiality, availability, authentication and nonrepudiation). Among security techniques there are Access Control that ensures users access to resources respecting a well defined security policy. This technique reinforces the confidentiality, integrity as well as availability of information, hence its importance in the security in general. One of the mechanisms that we will propose for the security problems mentioned in this study is the Mutation Analysis, considered as a testing method that evaluates quality software testing and its ability to detect errors, also compares the criteria and test generation strategies. This technique is detailed in the second part of the first section. In this paper, we will talk in general, about the Mutation Analysis applied in the computer security with two different ways. The first one is the qualification of penetration test detailed in the last part of the first section and the second one is ensuring conformity between the code which implants security and the Policy of Access Control. We will use this study of Mutation Analysis application to propose approaches and solutions to test access control mechanisms and interpret their robustness, as well as to detect hidden ones. Then, we will give a concrete method for the evolution of security policy without any problems that will prevent modification of access control mechanisms. This method is detailed in the last part of the second section. The first part of first section explains the basic principles and provides a brief overview of some popular tools and approaches in relation with securing applications. In parallel, the first part in the second section gives introduction and definitions for Access Control and its mechanisms.

THE MUTATION ANALYSIS AND PENE-TRATION TESTS 2.1 The steps for securing the applications
There are several approaches that aim the application level security, among these approaches are those that seek to directly secure the code,using static analysis and proof techniques. These techniques vary from parsing to the formal verification code and much more others. In our article, we will present some examples of formal approaches like the Proof-Carrying Code [2] and the "Splint" tool [6]. A second type of approaches is to secure modeling in an abstract way based on the requirements and security policy arXiv:1309.6149v1 [cs.CR] 24 Sep 2013 that we will establish using the Or-Bac model presented.

Proof and static analysis applied to security
As part of formal approaches we will mention two ones. The first approach is the PCC (Proof-Carrying Code) introduced by Necula and Lee as a new oncoming in which the producer provides, at the same time, a compiled program and validity proof (certificate)of this software. Before the client implements the program, the proof will be automatically verified by the user that possesses the tool (an installed base called Trusted Computing Base or TCB) which gives if the proof is valid for the provided program or not. The proof can concern any security policy defined by the consumer, and any property of the program such as security memory, as well as limiting access to the disk, or bank transfers verification. It proves easy to check the certificate than creating it ; hence, the use of PCC is promising because it can adapt to consumer needs, requires less blind confidence and does not involve time overhead at execution, as example, the case of mobile phone.
The second approach is the Static Analysis used to identify security flaws in the code. Most tools that use this approach are generally based on an abstract compilation, data streams and interpretation techniques to calculate an approximation of program behavior. One of these tools is Splint, it has the capacity to identify places in the code which may represent security flaws. The mentioned tool is based on annotations made in the source code. These annotations are the assumptions of developer concerning the progress of the execution (non-null parameter, dynamic memory allocation ...). Therefore, Splint examines the code and ensures that these assumptions are verified by Static Analysis. It helps to list the places in the code that are vulnerable to buffer overflow attacks ; hence the use of such approaches is recommended during the development cycle but they are complex to implement and difficult to reach, which justify that they are little used in practice. For example, Splint produces many negatives faults. This is unfortunately the case with most tools for detecting buffer overflow as ARCHER, BOON, Splint, UNO, ... The second disadvantage of these tools is that they fail to distinguish between the vulnerable code and the corrected code (detection alert even after the correction of the problem location).

Modeling of requirements and security policies
The conception approach of security models is interesting because it identifies new types of threats other than ones on code level. In principle, a security policy is based on a mix between security needs and logic job (This answer is generally given as result of consultation between security experts and business experts). Indeed, there are a lot of security models, among them the model (Organization Based Access Control) [8,5] that was developed as part of the RNRT MP6 (Models and Security Policies of Information Systems and Communication in Health and Social). This model is one of the most interesting ones because it addresses the modeling of security policies in an abstract way at the organizational level independently of implantation, which means that the established OrBAC policy (called concrete) is derived from organizational policies. This conceptual approach makes all retrieved policy in the Or-BAC model, reproducible and scalable. Indeed, it doesn't require any readjustment at the concrete level that could introduce an incoherence which is difficult to recover. Consequently, everything is done at the organizational level. First of all, it's worth to mention what is an Access Control model. Access Control is the fact to grant privileges to subjects in order to perform actions on objects.
-Subjects can be users, which means individuals and the process they are using. -Objects are also called resources, they can be system files, relations in a database, printers, ... -The possible actions in an information system are "read", "write", "execute", or in a database "select", "update"... The OrBAC objective is to enable modelling of variety of security policies based on the context of the organization. To achieve this purpose, and to reduce the complexity of managing access rights, the OrBAC model relays on four main principles : -The organization is the main entity of the model. It is an organized group of active entities ; which means, subjects that plays some roles. Note that a group of subjects isn't necessarily considered as an organization. In other words, each subject playing a role in the organization, corresponds to a certain agreement between subjects to form an organization. In particular, organization can be structured into several sub-organizations, each one with its own security policy. As the structure of real organizations can be made up of departments, services, ... A project or a work group can be modelled by an organization. -Two levels of abstraction (OrBAC Interactions) : -a concrete level : subject, action, object -an abstract level : role, activity, view -The opportunity to express permissions, prohibitions, and obligations. -The opportunity to express contexts. Thus, in addition to have a security policy independent of its implementation, OrBAC has other advantages, it can express permissions, prohibitions and obligations, it also takes in consideration the contexts, hierarchies and delegation. The introduction of a level also allows the structuring of entities as seen in the following diagram : Thus in OrBAC, a role is a set of subjects on which we applied the same security rules. Similarly, an activity is a set of actions which are applied on the same security rules, and the view is a set of objects which are applied on the same security rules. The context is defined for an organization, a subject, an action and the given objects. Furthermore, Contexts can express permissions or prohibitions under certain circumstances (emergency hospital, hours of work in a company, ...). It is easy to imagine that in an emergency context, we desire that a nurse can access the lambda patient records without having to call the administrator, that should gives her the access rights (perhaps too late after). This possibility of varying authorizations is not offered by models like DAC, MAC, RBAC, while in several organizations (hospital, business, ...) there is a real need to grant privileges only in specific circumstances. To conclude, a security rule is defined in OrBAC as follows : P (O, R, A, V, C) where : -P : is a permission, prohibition, or obligation. That is to say, give permission to the administrator of the department to consult the card during office hours. OrBAC model has been implemented in a prototype called MotOrBac made by SERES the team of ENST. MotOrBac allows to specify the modelling and define security policies based on OrBac.

Security tests
Establishing mechanisms to protect an application depends on two phases : code securing and modeling the security policy of the application ; likewise, verifying the security of an application is made with security tests. Thus, we will apply different kinds of security tests on applications to determine the effectiveness of security mechanisms. Figure 3 shows that the stage of security testing is the final step in securing application. If test results are negative then the application is more or less secure. on the other side, if results are positive we must retry the steps in order to cancel security vulnerabilities that are detected during the phase of security testing. then you must repeat the tests and the steps until do not detect any security breach. Modelling of Attacks. We can model and describe attacks using UML diagrams [10,7], the use case diagrams show the roles (the actors are both the attackers and the victims), while the state transition diagrams describe the steps of realizing an attack, also sequence diagrams complement the model by describing in details and step by step the progress of the attack. Figure 5 describes the website Cross Site Scripting attack (XSS) using sequence diagram. Modeling attacks in the form of diagrams aims to create a Figure 4: XSS diagram sequence support to penetration testing by teams of special testers (also called Red Team). They model in high-level(rather coarse), the actions to realize to execute these attacks. It should be able to refine these diagrams to consider automation.
Attack simulator. The role of an attack simulators [3] is to automate security tests. Among simulators that exist, we can note the one which offers an original method to test the robustness of security mechanisms, that protect against buffer overflow attack. It is important to know that the simulator does not reproduce the progress of the attack but simulates its consequences on the execution stack ; and to accomplish this task, it uses a dynamic compiler that allows it to modify the execution stack. The simulation steps of buffer overflow attack are the following : -Launching the program to test in the dynamic compiler.
-The simulator determines if the block of elementary code is vulnerable to attack : the process is to detect if the code uses a predefined risky function, i.e that potentially, code can cause a buffer overflow (copy functions of buffer, unsecured array ...) -The simulator modifies the execution stack to simulate the attack : this step consists on modifying the data stack to create an overflow, as a potential hacker will do. -The processor executes the instructions : The impacts of stack overflow that simulates the attack are propagated in the system, as a real attack.
-Observing the reaction of the protection mechanism to determine if the simulation of attack will fail.

Figure 5: The working of buffer overflow attack simulator
This simulation attacks approach is interesting since it's automated, rapid and systematic. It should be noted that it is very recent and still limited to a particular type of buffer overflow attack. Even if, the inventors propose to generalize their approach for other types of buffer overflow attacks as well as the whole of attacks, it still not usable ; for example, we cannot simulate the code injection attacks because they are beyond the scope of simulator use.
Penetration tests. The penetration test [1] is an offensive method for evaluating information systems against most famous attacks. In order to apply this type of tests, we will be in need of a team that will play the role of a pirate, and we should follow the steps below : -Analyze the system to evaluate, to well understand the conception of his different components and have an idea about the attacks that can be used and the scripts employed. -Before applying scripts of attacks, it is necessary to adapt these ones to the systems evaluated. These scripts are programs using the best and well known attacks in the world, that was successful in the past on other system information and which we strongly encouraged to test in this system. The application of penetration tests gives us two results, which we will present in the following : -If the script succeeds the attack against information system (since most developers repeat the same security errors), then the system is vulnerable. -If the information system succeeds the penetration test, we cannot judge whether the system is secure or not because : -It remains vulnerable to new exploits (Zero Day Exploits). -Or the attack script is unable to attack the information system and in this case there is a problem of confidence and quality of scripts attacks. Problematic : The lack of confidence and quality given to the attack scripts of penetration tests. Solution proposed : Applying the technique of mutation analysis used in the field of software test.

Presentation of Mutation analysis
The Mutation Test [4] is a technique that was proposed by De-Millo and it consists on creating a set of faulty versions of the test program called mutants. The goal for the tester is then to write a series of tests that can distinguish the original program from all its mutants. This technique aims to write relevant tests and involves injecting faults. If the tests applied to the program are able to detect these faults, they can be considered as relevant to disclose faults. The Mutation Analysis is based on the following steps : -Create from a program P, a set of programs Pi called mutants. -Pi should be different from p by one and only one elementary modification introduced in syntactically correct source code of P. This change is called mutation. -Mutations are defined by operators that can be : -Replacement of an operator by another operator.
-Changing a numerical value. -The elimination of equivalent mutants is important before proceeding with the analysis, as it is impossible for a test to detect the equivalent mutant. As a next step, we can run tests on the remaining mutants (after eliminating equivalent mutants). If the test performed on a mutant produces an output different from that of the original program, then the test detected the mutant and it is said that the test has killed the mutant. Otherwise the mutant is alive. When a mutant was killed, it can be removed from the testing process because the faults that it contained were detected and this allowed to locate the pertinent test. However, if we keep the mutant in the process, we will run each test on all mutants and we will be able to associate with each test a score of a mutation that corresponds to the proportion of mutants that the process has killed. This score is used as a quality index of a test. If a test T killed m mutants and there are a total of M mutants, the mutation score test T is :

SM (T) = m / M
The overall process of generation test by mutation is therefore consisting on generating all mutants of the program, then creating and executing tests on mutants. While some mutants are still alive, we check if they are not equivalent to the initial program, if they are not, we add tests to try killing them ; and we loop until getting a mutation score that satisfy us. This process of mutation analysis is described in Figure 6 : There are several tools of transformation, Figure 6: The working of mutation analysis but Mujava is the most available and most widely used tool, although it is not really effective.

Mutation Analysis and Securing applications
Giving an approach two fields, software tests (Mutation Analysis) and computer security (Penetration Tests) will lead us to a correspondence between their elements. Thus, during this study we will focus on two important points : -The first one is the Mutation Operators dedicated to security, therefore, the creation of the security mutants. -The second one is the use of these mutants to qualify the Penetration Tests.

The Mutation Operators dedicated to security
A fault inside a security framework is seen as a security flaw. Therefore, the injection of a fault in the security is only an injection, but at this time, it is a security flaw. This latter is generally based on the perturbation of the application environment using the interaction points of the application such as variables, files and processes. Consequently, a Mutation Operator is a modification or a deletion of an interaction point, on condition that this will create a perturbation in the application environment, and more specifically in the security, which implies the creation a security flaw. The following figure summarizes the procedure of the identification and the creation of the mutation operators. The main disadvantage of this technique consists on its difficulty to be automated. Once the point of interaction is perturbed, the conception of the attack scenario can be done only manually. Among the Mutation Operators that are needed to create mutants for the security tests : -The operators that will remove the verification code from user data that are put in dynamic requests, such as authentication code and distribution of access rights. -The operators that will eliminate the effect of input control code at the level of communication interfaces between the user and the application.

The qualification of Penetration Tests
The mutants are the variants of the original application which has released some of its protective mechanisms. A security mutant differs from the reference application by the introduction of errors in one or many of its security mechanisms. Thus, we can couple an error in the input user treatment with an error in the implementation of the security policy. We are therefore looking for creating mutants by mutating the control code of input. Moreover, we can couple a flaw in the security interfaces with vulnerability introduced voluntarily in the security policy (for example, in access to the database, we can give a write access to an application that has only read access).
To illustrate this approach, the figure 8 shows a simplified points in which we can voluntarily introduce a flaw in an information system connected to the Internet, such as : the communication interfaces with users, management of buffers, stacks of execution and implementation of the security policy (for example, defined with the model Or-Bac). We take as a prototype of test, a client-server application 3-tier type (so with database). This database will implement security policies (created from MotOrBAC for example).

Figure 8: Mutant model of testing attacks in 3-tier application
There are similarities between the software test and the pe-netration test. Both approaches aim to find bugs and errors in applications. However, there are some points of divergence. Bugs are easier to find, in view of that the application produces erroneous execution traces. Yet, security flaws are generally more subtle to detect. Indeed, the application having security flaws can behave in a normal way concerning features it ensures, this is the case of flaws related to the injection of code : The interpreted application code is correct, but it is vulnerable to attacks. So the attack scripts that will test cases must not only pass the level presentation, but also access the database (even modify it). For the evaluation of the test results of attack, the execution traces cannot be used (except for the stack overflow attacks when we get a segmentation error). This implies that the success of the attack depends on the access of test script to the database, in which it attempts to execute an operation, meaning that the success of the test depends on the success of this operation. We can summarize our approach in the following way : The elements : -An application that will be used to evaluate the security tests. -The script of penetration test that is the test subject. The steps : 1. The creation of mutants : (a) The identification of the interaction points in the application that will create security flaws. Therefore, the identification of mutation operators. (b) The creation of security mutants by using at least one mutation operator.

The evaluation of the penetration test :
(a) Applying the attack script of this penetration test to the mutants created. (b) Observing the effect of the evaluation : -If the attack script succeeds to do access of at least one mutant to the database. So, the penetration test corresponding to this script is considered a well qualified test . -Else, the penetration test is disqualified.

The access control
Access Control is the data protection against threats of confidentiality (disclosure unauthorized), integrity (Unauthorized modification)and availability (denial of service) when sharing data between multiple users. To ensure this protection, each data access must be controlled and obviously all unauthorized access must be strictly blocked. The development of an Access Control model is based on the definition of access control policies that determine access permissions to data. This model ensures that data are accessible only for users having the access rights. In gross, Access Control ensures that user access to resources must respect a well-defined security policy. The establishment of a general view, which is not limited to one existed access control model (DAC, MAC, RBAC, Gold-Bac, ...) will lead us to use a model for hierarchical architecture with two types of security requirements (permissions and prohibitions), and which incorporates the principle of constraints (temporary, Space, ...) that has as name "the context". A rule of our model is described as follows P(R, A, C) where : P : permission or prohibition ; R : role ; A : action ; C : context. Take the example of a faculty management system that offers management features of students, teachers and staff. In this application, the user can perform two operations : view their account and access to the courses. The resources that will be controlled are the accounts, marks and folders of users and staff. Entities A and R can be ordered hierarchically. For example in the management application of a faculty, there are two types of roles : user and personal. Concerning student and teacher roles, they inherit the user role. This hierarchy allows to define rules at the user's role level, to be then applied to the student and teacher roles. Finally, there are five temporal contexts : the work duration, the period of deliberation, studies, holiday and default, all this entities are detailed in Figure 9. Once the entities defined, the access control policy must be written. Examples of rules : R1 : Permission(Administrator, create account, work duration) R2 : Permission(user, user activities, work duration) R3 : Prohibition (Teacher, enter marks, studies) There are two types of rules : primary and concrete. The primary rules are the set of defined ones. By cons, concrete rules are all those obtained after deriving primary rules basing on the hierarchy (which is obtained by the relation : specification / generalization), it is the case of R2 rule, which is applied to "user activity" and designates all the actions that user can make (which are from Figure 9 : Consult his account, Benefit from services, Access to courses). We must Figure 9: The Entities of a management system of a faculty distinguish between primary and concrete rules. If an actor plays mostly the role of rule R2, he simultaneously plays the role of the rule R1. Therefore, we say that the rule R1 is primary and R2 is concrete. For Example in the hierarchy shown in the diagram above, the teacher is also a user. So, whenever a person is associated with the role of teacher, he also plays the role of the user.

Integration of an access control policy Architecture in application
An application implementing an access control policy must have an architecture with two separate parts, the first named Business Logic (BL) contains the code that implants functional requirements of system, and the second called Access Control (AC). For instance, the management system of a faculty contains code to enter marks, modify accounts and update the database. The access control policy is encapsulated in a component called PDP (Policy Decision Point), which can store the access control policy either in a text file or a database, to implement security rules and then set or change the policy. The PDP is used by PEPs (Policy Enforcement Point) placed in points of application where they will execute the security rules, just before the execution of features that are monitored by the access control policy. PEPs have a dual role, first of all, they send requests to the PDP with information about the user's role, his activity, the view demanded and the contexts. The PDP then decides if the requested access is permitted or prohibited, basing on the rules of the access control policy and sends this decision to the PEP concerned that will apply it. The PDP is based on rules of an access control policy and as this latter is generated automatically, it is also automatically generated. By cons, the PEP operates in a manual way to adjust successfully to the code and application architecture.

Mutation operators designed for Access Control
The fact that the business logic party is separated from the access control policy, will simplify for us the injection of faults in the access control mechanisms. So, we proceed to the replacement of used policy by the PDP, to get an implementation of the mutant policy. The creation of mutants is performed systematically via mutation operators, where each one injects a particular type of error and only one error is injected at the same time to create each mutant. With [9], we proposed the following mutation operators : Basic operators changing the type PPR (permission to prohibition) replaces a rule of permission by a prohibition. PRP (prohibition to permission) replaces a rule prohibiting by permission. Basic operators changing parameters RRD (role replaced with different one) replaces the role of a rule by another role selected randomly. CRD (context replaced with different one) replaces the context of rule by another context selected randomly. Basic operators modifying the hierarchy RPD (parent role replaced with a descendant) replaces a role of a rule by one of its descendants (thus changing the derived rules) APD (Parent Action replaced with a descendant) replaces an action in rule by one of its descendants (thus changing the derived rules) Advanced Operator ANR adds a new rule not belonging to defined rules part.
It is important to emphasize that these operations do not produce equivalent mutants. Indeed, the mutants created by construction, contain different rules from the initial policy because they add a new rule or modify an existing one. There are two types of mutation operators, the basic operators (all operators except ANR) and the advanced mutation operators called ANR, that are special because they aim to test the default behavior of access control mechanism. Truly, any policy of access control contains X rules and a default one (permission or prohibition) that is applied when the other rules do not correspond to entities of a query. The ANR operator can create rules that replace the default rule and complement the X defined rules. That's why it's an advanced operator as it allows to test the robustness of the access control mechanism.

The creation of access control tests
There are two types of tests [9] : functional and security ones. The first type aims to test the functionality of an information system, while the second type is designed to test the security of an information system. Concerning security tests generated from the access control policy, they aim to validate the compliance of the security mechanism with its access control policy. Both types are interconnected as the functional tests also validate compliance with the access control policy. Figure 10 shows the three parts of a test, whether functional or security : The Generation of security tests is based on several criteria representing the test objectives to evaluate the information system and decide whether a problem exists or not. We propose the following three criteria : 1. All primary rules : Cover the primary rules, if the rule is differentiable, then test one of its derived rules.
2. All the concrete rules : Cover the entire concrete rules.
3. All default rules : This criterion is intended to validate all the default rules not specified in the security policy. Figure 11: The different types of tests and their criterias The definition of a primary rule accords to its differentiability or not, we can say that it's also concrete if it derives from itself. By cons, a concrete rule is a rule that inherits from an another one. With this logic, and using only the second criterion (all concrete rules), tests can cover all the rules of the access control policy, whether primary or concrete. That leaves, to cover the default rules and that is the objective of tests generated from the third criterion (all default rules).
To conclude, we must say that the right strategy is to use very specific security tests and to combine the two criteria covering both : all concrete and all default rules.

Mutation Analysis and hidden mechanisms for access control
The best approach to implement an access control policy is to separate PDP from the business logic part. However, separation is rarely perfectly clear, especially in older systems.
When it comes to change the access control policy of these applications, it is necessary to locate these places in the code that prevents the system evolution, because they implement directly the access control rules in the code.
In this section, we will outline the use of mutation as an effective way to detect hidden mechanisms. We will first describe the problem encountered which we are trying to solve and then present the approach based on the mutation. We will also present a general mutation approach to guide the evolution of system access control policy .

The hidden mechanisms of access control
The access control mechanisms can be of different natures. Thus, there are explicit visible mechanisms, and implicit hidden ones : -The explicit mechanisms are implanted in the code : -The explicit mechanisms are visible when you have a traceability link or documentation to establish a relationship with the access control policy (or part thereof). For example, in Figure 12 the visible explicit mechanism uses an external component (which is the "security Policy Service") responsible for applying security policy, this controllable component is based on an access control policy .
-An explicit mechanism is said hidden when we don't have any information to link this mechanism with a rule in the access control policy. For instance, in Figure 12 the hidden explicit mechanism directly applies an access control rule (denying access based on a condition). Figure 12: Example of explicit access control mechanisms -The implicit mechanisms represent access control constraints integrated into the architecture itself of the code or system. The figure 13 illustrates an example of an implicit mechanism, where by construction, the class "Secretary" does not have a method to modify an account. Note that the implicit implantation of an access control rule prohibits access to the secretaries to modify accounts. The access control policy is expressed implicitly via the "class" model, which makes its development more difficult. In this example, the fact of allowing secretaries to change the accounts is due to adding in the class "Server" a new method "Modify Account (secretary, account)". In this case modification is easy, but in other cases, the modification can be difficult and tedious even not impossible (especially when there is a significant coupling between classes).

Figure 13: Example of implicit access control mechanisms
Modifying an access control rule implicitly implemented by one of these mechanisms, involves doing the "refactoring" (rework)of architecture. The access control mechanisms whether explicit or implicit, must be taken into account during the evolution of the CA policy by following the steps noted below : 1. Explicit and visible mechanisms must be modified and tested.
2. Hidden and explicit mechanisms may be in conflict with the new policy. So, They must be located and removed.
3. Implicit mechanisms may prevent the development of policy. In this case the model must be modified or redesigned to make the application more flexible.
To Summarize, we can say that there are two hidden mechanisms for access control : explicit hidden mechanisms and implicit ones. These two mechanisms prevent the evolution of the access control policy. Therefore, detect and eliminate these hidden mechanisms will be the purpose of our method based on Mutation Analysis.

Detection of hidden mechanisms for access control via Mutation Analysis
We will present an approach that follows the detection method of hidden access control mechanisms. We should respect the order of these steps without forgetting any step : 1. Applying the mutation on the access control policy using the initial two change operators of types PRP and PPR, which simulates an incremental evolution of the policy.
2. Implementing and creating tests from the mutant policy. In other words, the tests created will cover the rules of the access control mutants.
3. Disabling all visible security mechanisms on the initial information system (ie : we want to evaluate its access control policy ), which is easy because the activated rules are known.
4. After disabling security mechanisms, the information system doesn't contain any prohibition. So, when launching tests on this system, if these tests are successful, there will be no hidden security mechanism, otherwise, the failed tests necessarily indicate the existence of hidden security mechanisms.
This approach gives us a solution based on tests to detect the hidden access control mechanisms and also the rules subsequently implanted by them. This method allows to find an indicator that estimates the flexibility of an information system. This flexibility is the number of visible rules divided by the total number of security rules (which is visible or hidden).

Evolution of Security Policy
A micro-evolution as the name suggests, is a small change in the access control policy. There are two types of microevolution : -δ + : which relaxes the policy by adding a permission or removing a prohibition. -δ − : which restricts the policy by adding a prohibition or removing a permission. A security policy is a set of permission and prohibition. Therefore, it is indeed a set of micro-evolution. As shown in the Figure 14 diagram, the evolution of an initial security policy to another final one is simply an application of a set of micro-evolution on the first one to reach a new security policy.

Figure 14: The micro-evolutions
The following formula shows the evolution of an initial access control policy SPInit to a new access control policy SPNew : As was previously mentioned, the evolution of the system is a set of micro-evolution. If we can detect the hidden mechanisms that prevent the establishment of each microevolution, then we can modify the code to eliminate these hidden mechanisms, meanings that the access control policy can evolve using the set of micro-evolution evaluated. The approach adopted to modify the access control policy of an information system is : 1. Formulate new rules of access control policy in the form of a set of micro-evolution.
2. Create a single mutant from each micro-evolution.
3. Generate test cases for each mutant policy (ie : each mutant).
4. Disable visible access control mechanisms in the mutant that corresponds to the micro-evolution.
5. Start the test generating mutant policy. 6. There are two possible cases : -If the test passes. So, no hidden mechanism against micro-evolution. -Otherwise, the existence of hidden mechanisms. 7. In the second case, we must eliminate the hidden mechanisms since they are detected. Then repeat the method from beginning to end.
8. Implant and document the micro-evolution in the visible mechanism.
In this part of our study we have tried to give a detailed overview of the access control policies. Then, we have introduced the technique of Mutation Analysis specified in access control and used as a support to evaluate the criteria for generating tests.
On the other hand, to change the access control policy of an application, we have proposed a comprehensive approach based on tests and mutation to solve the problem of hidden access control mechanisms.

CONCLUSION
This article presents a summary of a study conducted in the field of computer security, specifically, web application security. This study will lead us to make a link between two aspects relating two research disciplines that are : Testing out different software and Security. During the process of collecting and research, we started working on security as a means for securing applications, which allowed us at the first time to see the different criteria and security aspects such as the three levels (application, system and network) and the five main objectives (integrity, confidentiality, availability, no-repudiation and authentication).
Thus, after a research conducted on the majority of existing attacks types so far, we are confident that the applications need a security that affects several points, starting with the code, through the modeling of security policies, and arriving to security tests that evaluate the security mechanisms implemented in applications.
In this regard, we thought to apply Mutation Analysis as a method of software test field on scripts of security tests, and that to qualify and ensure their ability to be a true evaluation tool that detects remained flaws in an application after the securing phase. In the second time, we decided to apply the technique of Mutation Analysis on other security disciplines such as access control. Access control tests are similar to other security tests, unless they have a specification to be based on rules established in the access control policy. Thanks to this specification we succeed to precise the exact types of criteria that can generate good quality of access control tests. Then, we have solved the problem of hidden access control mechanisms preventing the development of security policy, by proposing an approach applied during the phase of the evolution of access control policy. In this study, it remains to implement these techniques and to apply them on real cases to reach the experimental results with statistics, to be able to generalize our solution. As perspective, we will try to take the security from different points of view, to migrate the techniques and solutions that are successful in other fields, also to adapt them to the computer security field.


s2fieldsofstudy:
Computer Science
Business

text:
IEEE 802.15.4 transceiver for the 868/915 MHz band using Software Defined Radio

This paper reports an implementation of the PHY specifications of the IEEE 802.15.4 standard for the frequency band 868 915 MHz on a Software Defined Radio (SDR) platform. This standard is defined for low power, low data rate and low cost wireless networks. These specifications are used by the Zigbee technology for various applications such as home automation, industry monitoring or medical surveillance. Several hardware PHY 868/915 MHz band IEEE 802.15.4 transceiver implementations have been already reported on ASIC and FPG [1] [2]. SDR offers one possibility to realize a transceiver with high flexibility and reconfigurability [3]. The whole transmitter and receiver chain has been defined in software using the GNU Radio software project [4] and the USRP (Universal Software Radio Peripheral) platform from Ettus Research [5]. Two new blocks have been added to the GNU Radio project, one for the Direct Sequence Spread Spectrum and the second for the reconstruction of the packets. The experimentations have been performed in a noisy environment and the PER, BER and SNR have been computed. The obtained results are coherent with what can be expected from the theory.

I. INTRODUCTION
Most of the standards and protocols of lower layers of wireless transmissions (AM, FM, IEEE 802.11, IEEE 802.15.1, IEEE 802.15.4. etc.) are mainly implemented in hardware (HW). This lack of reconfigurability makes the adaptation to varying radio resources difficult, especially when multiple standards need to be often switched in order to take advantage of the scarce radio resources available. The purpose of Software Defined Radio (SDR) is to avoid these drawbacks of traditional wireless communications and replace the hardware equipment by software. The huge advantage of SDR platform lies in its flexibility, its multi-functionality and its low development cost. The reconfigurability of the platform ensures the reusability of the hardware [3], thus minimizing the design complexity of new RF terminals.
The ideal SDR allows the analog-to-digital (ADC) and digital-to-analog (DAC) conversion to be as close as possible to the antenna [?], eliminating the need of high-frequency radio subsystems. Subsequently, the CPU executes the software (SW) subsystem of the SDR, all signal processing operations are accomplished by SW. Unfortunately, today's technology is neither cost-effective for direct ADC conversion from the antenna nor enough power full to compute GSPS (Giga Samples-per-Second) in real-time. Therefore, the typical SDR platform available today uses HW high-frequency radio front-end, the SDR part being implemented in the baseband only. The HW supporting the SDR platform is typically based on FPGAs or DSPs (Digital Signal Processors) [6].
GNU Radio [7] and OSSIE [8] (Open-Source Software Communication Architecture Implementation Embedded) are the two open source software subsystems for the USRP (Universal Software Radio Peripheral) SDR from Ettus Research [5]. The USRP HW is available in different versions. In our implementation we used the USRP1 HW, featuring a sampling rate of 128 MSPS (Mega Samples-per-Second) for the transmitter and 64 MSPS for the receiver. By addition of different daughter-boards, the baseband signal can be transposed in frequency bands up to 6000 MHz. The USRP1 HW platform proves to be also cost-effective, compared to its competitors (Microsoft's SORA and Datasoft's Typhoon).
The IEEE 802.15.4 [9] standard defines the physical and link layers for low-rate Wireless Personnel Area Networks (LR-WPAN), used in wireless sensor networks applications with strong energy consumption constraints. The physical layer comprises three principal frequency bands allowing 49 channels: 16 channels in the 2450 MHz for the ISM (Industrial Scientific Medical) band, 30 for North America and 3 channels in the 868 MHz band for Europe [9]. The band of 2450 MHz operates at law data rates of 250 kb/s while the bands of 915 MHz and 868 MHz operate at 40 kb/s and 20 kb/s respectively.
A number of hardware implementations of the IEEE 802.15.4 have been reported on ASICs or FPGAs [1], [2], but they do not allow us to control the flexibility and the ability of all software stack layers. The first software implementation of the IEEE 802.15.4 using the GNURadio environment for the 2450 MHz band was reported in [10]. In wireless sensor networks, the transceiver in the 868/915 MHz band is more suitable when low data rate transmission are used between sensor nodes. Furthermore it presents a longer range than that of the 2450 MHz band for a given link budget. The objective of our work is to implement the specifications of the IEEE 802.15.4 standard for the 868/915 MHz band, which is not yet reported in the literature.
Our software transceiver was developed by closely following the IEEE 802.15.4 specifications for the 868/915 MHz bands. The implementation is similar to the one of 2450 MHz band presented in [?], [10]. To evaluate the transmitter/receiver performances, the BER (Bit Error Rate) and SNR (Signal-to-Noise Ratio) have been computed by changing the input power signal at the transmitter.
The rest of the paper is organized as follows. Section II presents a description of the SDR platform used. In Section III, we present the description of the developed transmitter/receiver chain. Section IV discusses the experimentations and the obtained results. Finally, in Section V we formulate some concluding remarks.

II. USRP AND GNU RADIO
In the following two subsections we describe briefly the USRP1 HW [5], used in our implementation as well as the GNU Radio [4] toolkit.

A. Universal Software Radio Peripheral
The USRP1 HW consists of a motherboard and optional add-on RF daughterboards. It is connected to a host computer via USB 2.0. The USRP's motherboard supports up to four daughterboards: two for transmission (TX) and two for reception (RX). The motherboard has four 12-bits ADCs (with a maximum sampling rate of 64 MSPS), four 14-bit DACs (with a maximum conversion rate of 128 MSPS), and an Altera FPGA for simple but high-speed operations such as up-conversion, down-conversion, interpolation, and decimation [5]. The ADCs and DACs allow us to receive baseband signals up to 32 MHz and are able to generate baseband signals up to 50 MHz. Unfortunately, the USB tunnel limits these performances to 8 MHz. The USRP1 provides buffer in both the USB controller and the FPGA at 2 KB and 4 KB respectively. Fig. 1 depicts the USRP1 blocks from the motherboard. Fig. 1. USRP1 block diagram [5] B. GNU Radio GNU Radio is an open source project toolkit for building software radios that run on host computers [4]. It provides signal processing blocks for modulation, demodulation, filtering and various Input/Output operations. New blocks can be easily added to the toolkit. The software radio platform is created by connecting these blocks to form a flowgraph. The blocks are written in C++ and they are connected through a Python script. The Verilog HDL layer is dedicated to configure the FPGA.
The advantage of Python in connecting these processing blocks is that it allows the data flow to be at maximum rate, without being interpreted. The integration of the C++ blocks into the scripting language is provided by the SWIG (Simplified Wrapper and Interface Generator), which is an interface compiler. Many signal processing blocks are available to the GNU Radio community to facilitate the development.
To create a flow graph we can proceed by the graphical interface called gnuradio-companion or directly through the python code. The C++ blocks are described by the XML code to facilitate the use and the visibility of the block chains, the XML is interpreted to the python code by the cheetah tools 1 . In Fig. 2 we depict the programming language layers of the GNU Radio. The IEEE 802.15.4 [9] standard is the definition of wireless physical (PHY) and medium access control (MAC) protocols for low-data rate and low power applications. It specifies two families of bands: the first one is centered at 868 and 915 MHz with 20 and 40 kbps, the second one at 2450 MHz with 250 kbps.
The specifications from [9] define the use of different modulation techniques and data rate for the specified channels.

A. Transmitter
Our transmitter comprises eight processing blocks, as depicted in Fig. 3. The definition of the packet messages is based on that of the IEEE 802.15.4 standard. The packet format is detailed in Fig. 4. At the output of the transmitter, the maximum packet size is 133 bytes. Due to the USB 2 tunnel, the packet size should be a multiple of 128 samples, therefore, zero padding with the x/00 (representing the "NUL" character) is performed. The number of padded bytes is conditioned by the parameter called Byte M odulus which depends on the sampling rate and on the number of bits per symbol. The Byte M odulus is given by:   The packets are divided into chunks of symbols by the gr.packed_to_unpacked block, each symbol representing 1 bit. Since the C++ programming language does not allow us to have a data type of 1 bit, the bits in the bytes of an input stream are grouped into chunks of 1 byte. The MSB (Most Significant Bit) of 8 output bits represents the one bit at the input of gr.map_bb. After that, the differential encoder gr.diff_encoder_bb encodes a current symbol modulo-2 of the previous one. Then, the symbols are mapped by gr.symbols_to_chips into 15 Pseudo Number Sequence chip as specified in Table I. The output of mapping is short-type (16 bits carrying the 15 chips). With the same technique the stream is unpacked to a chunks of 16 bits representing the chips stream. Each chip is represented by a complex constellation point in 1 dimension for the BPSK modulator by gr.chunks_to_symbols_sc. The stream is then fed through a Root Raised Cosine gr.interp_fir_filter_ccf filter which up-samples the signal, after which it is sent from the host computer via USB to the transmitting USRP.

B. Receiver
The receiver begins with an USRP source connected to a squelch filter gr.pwd_squelch which admits only signals with a certain dB strength. The squelch filter in GNU Radio outputs 0 when the incoming signal is too weak. The stream result of the squelch is passed to the Automatic Gain Control gr.agc_cc (AGC) of a D-BPSK demodulator, it regulates the gain in a way that does not have a large or small amplitude and to avoid distortions. After that, the result enters to two filters in gr.interp_fir_filter_ccf, FIR (Finite Impulse Response) and RRC (Root Raised Cosine) allowing the receiver to process the change of the transmitted pulse and minimize symbol interference. The RRC filter makes the correlation between the received signal and the expected one. It calculates a FIR filter coefficient or a tap weight. The demodulator synchronizer is composed by two blocks, a Costas Loop gr.costas_loop_cc (Phase Locked Loop) and the Mueller and Müller gr.clock_recovery_mm_cc [11]. The Costas Loop recovers the carrier and improves the Bit Error Rate of BPSK demodulator. The Mueller-Müller Timing recovery block recovers the symbol timing phase of the input signal. After the demodulator, the stream is converted from complex to real in order to send it to our developed block ieee.ieee802_15_4_packet_sink which slices real stream from chips to bits. With the knowledge of the packet length field, the packets are decoded. The first information decoded is the preamble with four 0x00 bytes, it is followed by the rest of the fields. If the preamble is not detected, the preamble search is re-launched. The receiver performs the error detection without correction. After the packet construction, Fig. 4. IEEE 802.15.4 packet format for the USRP a CRC-16 value is processed and compared to that carried by the CRC field of the received frame. If they are not equal, the received packet is incorrect.
The packet queue is observed by an external python thread. When a message arrives to the queue, a thread starts to call a function that process the packet, e.g: like printing the packet content.

IV. EXPERIMENTAL CONDITIONS AND RESULTS
The experimentations are performed in an indoor environment. We use two USRP1 platforms coupled with RFX 900 daughterboards covering a frequency range from 750 MHz to 1050 MHz. The GNU Radio software stack is executed on a host computer having one Core 2 Duo CPU running at 2.4 GHz and 2 GB of RAM. The distance between the two USRP1 boxes was greater than 2 meters.
The principal USRP1 parameters are the transmitter Interpolation I and receiver Decimation D, they are calculated according to a symbol rate r, DAC s and ADC s sampling, and a number of samples per symbol sps, such as: where : Otherwise, when the data bit rate is equal to 40 kbps, the I and D take the same values but with sps = 8. The amplifier amplitude is defined by a dimensionless scalar with values ranging from 0 to 32767.
The results shown in Fig. 6 depict the power spectrum of the transmitted signal from the GNURadio transmitter. They correspond to the output of the FFT spectrum-analyser tool that is included in the GNURadio framework. A peak is visible with our software transceiver when we choosing the channel at 916 MHz, with a number of 35 samples per symbol which allow us to have an intermediate frequency of 1.5 MHz. This value is in concordance with the values taken by the transmitted power spectral density of the IEEE 802.15.4 standard (see Fig. 6). Furthermore, frequencies at the edge of the main band are visible but strongly attenuated. These imperfections may be due to the roll-off characteristics of the interpolation filter in the up-conversion processing of the FPGA.
We use a D-BPSK modulation and the receiver constellation is depicted in Fig. 7. The performance of D-BPSK modulation is evaluated without packet generation. The flexibility of the GNU radio permits the reconfigurability of the transmitter/receiver chain by adding or replacing blocks. In a first experiment, we use the modulator and demodulator chains to measure the BER and SNR parameters. Fig. 8 illustrates the average BER versus the input SNR (dB) for the frequency 868.3 MHz and for the MFB Matched Filter Bound of D-BPSK modulation. The results have been computed by changing the amplifier amplitude values from 1000 to 12000 with the step of 100 for a time period of 400 seconds. Although noisy, the results are in concordance to the theory, proving that the implementation is working. In the second experiment, the packet generator and packet sink are connected to the transmission chain and we measure a PER parameter as a function of SNR (dB). The measures are obtained by sending for each amplifier amplitude 100 packets apart from 0.2 s between two successive packets. The PER decreases when the amplifier amplitude increases. The shape of the curve is compliant to that of the BER (show Fig.9). The PER depends on the synchronization between the transmitter and the receiver. We noticed that the synchronization does not occur at every execution. This issue may arise when the USRP does not clear its buffer memory.

V. CONCLUSION
In this paper, we report the implementation of the IEEE 802.15.4 standard on a SDR transceiver for the 915/868 MHz band. The SW stack is based on the GNURadio open-source project and the HW is based on an USRP1 platform from Ettus Research. The BER and PER of the 802.15.4 have been calculated independently in an indoor environment by changing the signal amplitude. The results are coherent with the lower theoretical bound that is expected. The obtained performances of the PER are degraded compared to the BER because the successful receiving packets depend on the synchronization and the BER.