Sanaz Rahimi

Mehdi Zargham

SECURITY ANALYSIS OF VPN CONFIGURATIONS IN INDUSTRIAL CONTROL ENVIRONMENTS

Keywords: Control systems, virtual private networks, security analysis

Virtual private networks (VPNs) are widely recommended to protect otherwise insecure industrial control protocols. VPNs provide confidentiality, integrity and availability, and are often considered to be secure. However, implementation vulnerabilities and protocol flaws expose VPN weaknesses in many deployments. This paper uses a probabilistic model to evaluate and quantify the security of VPN configurations. Simulations of the VPN model are conducted to investigate the trade-offs and parameter dependence in various VPN configurations. The experimental results provide recommendations for securing VPN deployments in industrial control environments.

Introduction

Virtual private networks (VPNs) are widely used to provide secure communications over insecure public networks. VPNs provide security services such as confidentiality, integrity and availability by creating encrypted tunnels between the communicating parties.

VPNs are recommended in the literature and by many critical infrastructure protection standards to secure process control, SCADA and automation protocol communications [14-16, 21, 22]. Although these protocols are generally very reliable, they were not designed to resist malicious attacks. As a result, it is recommended to wrap industrial protocols such as DNP3 [START_REF] Majdalawieh | Security Framework for DNP3 and SCADA, VDM Verlag[END_REF], 61850 [START_REF]IEC 61850 Standard[END_REF] and Modbus [START_REF]Modbus-IDA, Modbus Application Protocol Specification V.1.1b[END_REF] within VPN tunnels to protect them from unauthorized access. These configurations supposedly offer confidentiality, integrity and availability [START_REF] Patel | Improving the cyber security of SCADA communication networks[END_REF], but little work has focused on the secure configuration of VPN tunnels and the maintenance required for their secure operation [START_REF] Patel | Improving the cyber security of SCADA communication networks[END_REF].

VPNs are attractive targets for attackers. Because VPNs carry sensitive information over public networks, successfully breaking into a VPN tunnel enables an attacker to alter sensitive data and commands without physical access to the industrial facility. If other protection mechanisms such as strong access control are not deployed properly, the attacker can gain access to the internal SCADA systems through a VPN tunnel. Also, as industrial systems implement more security mechanisms, VPNs can become the weakest link in the security chain.

VPNs have several vulnerabilities. According to Hills [START_REF] Hills | Common VPN Security Flaws, White Paper[END_REF], most VPN implementations suffer from serious security flaws that can be easily exploited by attackers to fabricate, intercept, modify and interrupt traffic. Some of these vulnerabilities are implementation specific; they are the result of flaws in a specific protocol implementation due to bad coding, incomplete implementation or poor implementation choices for conditions that are not specified in the standard. However, vulnerabilities in the underlying protocols cannot be addressed by good implementation [START_REF] Hills | Common VPN Security Flaws, White Paper[END_REF]. Finally, as recent incidents have shown, sophisticated malware [START_REF] Brown | Stuxnet worm causes industry concern for security firms[END_REF] can stealthily modify the configurations of a control system (including a VPN) and seriously impact its operation. The solutions to these security problems are proper configuration, continual configuration validation and regular maintenance, all of which are effective only if system administrators fully understand the internal details of the protocols.

This paper models VPNs using stochastic activity networks [START_REF] Sanders | Stochastic activity networks: Formal definitions and concepts[END_REF], which are an extended form of Petri nets [START_REF] Balbo | Introduction to stochastic Petri nets[END_REF], and analyzes the probability of a successful breach against various VPN configurations. VPN security is quantified for different choices of parameters such as key length, mode of operation, number of users and maintenance frequency. The results provide recommendations for securely deploying VPNs in industrial control environments.

VPNs and VPN Vulnerabilities

VPNs are categorized with respect to their layer, i.e., transport layer (SSL), network layer (IPSec) and link layer (L2TP). This paper focuses on IPSec VPNs. As an underlying VPN protocol, IPSec [START_REF] Paterson | A cryptographic tour of the IPSec standards[END_REF] provides confidentiality and integrity services in the network layer (i.e., on a per packet basis) using two main sub-protocols (AH and ESP) in two different modes (transport and tunnel). The detailed description of IPSec is beyond the scope of this paper. We only describe the features that are relevant to our discussion. Interested readers are referred to [START_REF] Paterson | A cryptographic tour of the IPSec standards[END_REF] for additional information about IPSec.

IPSec

IPSec provides security services via the Authentication Header (AH) and Encapsulation Security Payload (ESP) protocols. AH provides integrity by adding the HMAC [START_REF] Bellare | Keying hash functions for message authentication[END_REF] of the entire packet (payload and full IP header); however, it does not provide confidentiality because it leaves the packet in plaintext. ESP encrypts the packet payload and some fields of the IP header, and adds the ESP header and trailer to the IP packet, providing confidentiality and limited integrity.

IPSec can operate in the transport or tunnel modes. The transport mode is used when end-to-end security is desired, and both end nodes support IPSec. In the transport mode, the original IP header is preserved for routing purposes and the AH/ESP headers are added under the IP header. The tunnel mode is used when the end machines do not support IPSec or when the identities of the communicating entities have to stay hidden. In the tunnel mode, the entire IP packet is encrypted and a new IP header is added to the packet. The gateway on the border of each organization provides the security services by adding and removing IPSec headers.

Security Association (SA) is the concept used in IPSec for connection management between two communicating entities. An SA comprises a secure communication channel and its parameters, including the encryption algorithms, keys and lifetimes. Each SA is unidirectional and can provide one security service (AH or ESP). Two SAs are required for bidirectional communications.

IPSec uses the Internet Key Exchange (IKE) protocol to manage and exchange encryption keys and algorithms. IKE is a hybrid of three sub-protocols: Internet Security Association and Key Management Protocol (ISAKMP), Versatile Secure Key Exchange Mechanism for Internet (SKEME) and Oakley. ISAKMP provides the framework for authentication and SA management, but does not define the specific algorithms and keys. IKE uses the SKEME and Oakley protocols for key exchange and agreement with the acceptable cryptographic algorithms.

Because IKE is commonly used to establish VPN channels, many VPN vulnerabilities are in one way or another related to it. For a better understanding of these vulnerabilities, we provide an overview of IKE and its modes of operation.

IKE has three important modes: main mode, aggressive mode and quick mode. The main mode is used for authentication and key exchange in the initial phase of IKE. This phase assumes that no SA is present and that the two parties wish to establish SAs for the first time. It involves three pairs of messages. The first pair negotiates the security policy and encryption algorithms to be used. The second pair establishes the keys using the Diffie-Hellman key exchange protocol. The third pair authenticates peers using signatures or certificates. Note that the identities of the peers in the main mode are often their IP addresses.

The aggressive mode is also used for the initial key exchange, but it is faster and more compact than the main mode. This mode involves a total of three messages that contain the main mode parameters, but in a more compact form. Key and policy exchange are performed by the first two messages while the third message authenticates the initiator to the responder. Note that the identity of the responder (sent in the second message) is not protected, which is a vulnerability in the aggressive mode of operation.

The quick mode is used for the negotiations in the secondary phase of IKE. This mode assumes that the peers have already established SAs and that the exchange can update the parameters or renew the keys. The quick mode messages are analogous to those in the aggressive mode, but the payloads are encrypted. If the quick mode operates with the perfect-forward-secrecy option, the shared secrets are renewed with a fresh Diffie-Hellman exchange.

IKE authenticates peers using a pre-shared key (PSK), public key encryption or digital signature. In the PSK method, which corresponds to the traditional username/password authentication, the peers share a secret through a back channel and exchange the hash value of the secret for authentication. Unfortunately, although this method has known vulnerabilities, it is the only mandatory authentication method according to the RFC [START_REF] Harkins | The Internet Key Exchange (IKE)[END_REF]. Public key encryption is another method of authentication in which the peers digitally sign their identities; however, the keys are required to be provided beforehand by some other means. Digital certificates may also be used for authentication in IKE; in this mode, the peers exchange certificates to mutually authenticate each other.

VPN Vulnerabilities

VPNs have several vulnerabilities. The common username enumeration vulnerability refers to an implementation flaw in which the username/password authentication mechanism responds differently to invalid usernames and passwords. By exploiting this vulnerability, an attacker can identify valid usernames that can be used later in password discovery.

When IKE is used in the aggressive mode with a pre-shared key (PSK), the client sends an IKE packet to the server containing, among other things, the identity (username) of the client. The server then responds with another packet that contains the hash of the identity and the PSK (password). When an incorrect username is received, many VPN implementations send an error message, send a packet with NULL PSK or do not respond at all. This enables an attacker to infer whether or not a username exists by sending a single packet (enumerate username). Upon discovering the first username, attacker can generate likely usernames with the same pattern (e.g., first letter of the first name concatenated with the last name). When a VPN is used in the main mode, the identity is an IP address, not a username.

Hills [START_REF] Hills | Common VPN Security Flaws, White Paper[END_REF] proposes that a secure VPN implementation return the hash of a randomly-generated password each time it receives an invalid username. However, this does not solve the problem because an attacker can still send two different packets with the same username; if two different hashes are received, then the attacker knows that the username does not exist and vice versa. Furthermore, attacker can delay these two packets using a number of packets for other usernames to flush a buffer that the server may employ to track such an attack. The solution is for the server to encrypt the username with a secret key (generated and kept on the server only for this purpose) and to return the hash of this value. Thus, the server always responds to a username with a unique hash value, which foils the attack.

When the attacker discovers a valid username, he/she can receive the hash of the username's password from the server (using PSK in the aggressive mode). The attacker can then apply an offline algorithm to crack the hash value and obtain the password. Offline cracking can be very fast because the probabilistic model of VPN password hashing is not hidden. This poses a serious threat to short passwords. The vulnerability exists even if IKE operates in the main mode with PSK; it can be exploited by a man-in-the-middle attack (e.g., using DNS spoofing [START_REF] Nayak | Different flavors of man-in-the-middle attack: Consequences and feasible solutions[END_REF]) to gain the Diffie-Hellman shared secrets. The only difference is that, in the main mode, the identity of each peer is its IP address.

When a username/password pair is successfully found, the first phase of IKE is breached. If the VPN configuration does not require extra authentication, the breach is enough to setup a VPN channel with the server. In some other cases, the configuration requires an extra XAUTH step to complete the second phase of IKE, but this phase is vulnerable to a man-in-the-middle attack as mentioned in the standard [START_REF] Pereira | Extended Authentication within ISAKMP /Oakley (XAUTH)[END_REF]. The reason for the vulnerability is that XAUTH must be used in conjunction with the first phase of IKE; if this phase is not performed properly, XAUTH cannot provide any security guarantees. Therefore, an attacker who performs a man-in-the-middle attack would be able to authenticate successfully.

Other VPN implementation vulnerabilities include VPN fingerprinting (inferring information about a device from its behavior); insecure password storage (e.g., in the registry, as plaintext in memory, etc.); lack of account lockout; poor default configurations; and unauthorized modification of configurations. We do not consider these vulnerabilities in this paper because they are implementation specific and may require other flaws to be exploited in a successful attack (e.g., insecure password storage would be exploited by the installation of malware).

VPN Security Model

This section describes the probabilistic model used to analyze VPN security. The model helps quantify the security of a protocol and provides suggestions for its secure implementation, configuration and operation. This is important because, as Hills [START_REF] Hills | Common VPN Security Flaws, White Paper[END_REF] notes, VPN tunnels are misconfigured approximately 90% of the time.

VPN security is modeled using a stochastic activity network (SAN) [START_REF] Sanders | Stochastic activity networks: Formal definitions and concepts[END_REF], which is an extension of a Petri net [START_REF] Balbo | Introduction to stochastic Petri nets[END_REF]. The Mobïus tool [START_REF] Deavours | The Mobius framework and its implementation[END_REF] is used to specify the model and to perform numerical simulations. This section explains the details of the SAN model and its parameters; all times in the model are expressed in minutes.

The model comprises two sub-models (atomic models), one models the implementation and configuration of a VPN tunnel, and the other models its environment and operational details. The two sub-models are joined into a composed VPN model using the Rep/Join representation [START_REF] Deavours | The Mobius framework and its implementation[END_REF]. The first atomic model (ike) models the weaknesses of the protocol (Figure 1). A global variable identifies if the VPN is operating in the main mode or in the aggressive mode. If the VPN is configured in the aggressive mode, an activity models the username enumeration attack. We consider usernames that consist of alphabetic characters and have a length of at most six characters (approximately 309 million possibilities).

If the roundtrip time between the scanner and server is in the order of tens of milliseconds [START_REF] Li | Getting the real-time precise roundtrip time for stepping stone detection[END_REF] and a window of ten packets is used, then, on the average, it takes 1 ms to check for each username; so we assume that 1,000 usernames can be checked per second. If the roundtrip time is larger, an appropriate window can be chosen to achieve this rate. With this rate, it is possible to exhaustively scan the username space in approximately 3.5 days. A sophisticated attacker can do better using a fast connection to the server and/or an intelligent guessing algorithm after a username is found. However, in this paper, we consider an unsophisticated attacker in order to obtain an upper bound on VPN security. Note that, because username scanning does not typically cause account lockout, this process is not stopped by the server.

The rate of username enumeration is proportional to the number of system users (more users result in a faster enumeration using exhaustive search). This is modeled by multiplying the base rate (1 per 3.5 days = 1.94E-04 per minute) by the marking of (the number of tokens in) the usernames place. Whenever a username is found, it is moved from the pool of unknown user-Table 1. Password complexity and password space size.

Password Complexity

Space Size 6 characters a-z 3.1E+08 6 characters a-z, A-Z, 0-9 5.7E+10 8 characters a-z 2.1E+11 8 characters a-z, A-Z, 0-9 2.1E+14

names to usernames found using the output gate username found. Note that usernames found is a place that holds the number of usernames enumerated at a given point in time, whereas username found is the output gate that transfers the discovered username from the unknown usernames place (usernames) to the usernames found place. When a username is found, the attacker can start an offline attack to obtain the password. To crack the password, the attacker has to hash different values exhaustively. The cracking speed for MD5 hashes using an AMD Athlon XP 2800+ is around 315,000 attempts per second (∼1.9E+07 attempts per min) [START_REF] Hills | Common VPN Security Flaws, White Paper[END_REF]. Since the cracking speed depends heavily on password complexity, the model is run using different password space sizes. Table 1 shows the size of the password space for different types of passwords.

The rate of successful attempts is proportional to the number of usernames enumerated, so the rate of the brute force activity is multiplied by the marking of the place usernames found. If a username/password pair is found, the VPN is breached. Other transactions (e.g., to setup a VPN tunnel after the breach) require negligible time compared with brute force or username enumeration. As result, after a username/password pair is found, a token is placed in vpn breached.

The other possible mode of operation is the main mode. As mentioned before, in the main mode, the identities are the IP addresses of the peers. The space of 32-bit IP addresses is approximately fourteen times larger than the space of six-character usernames; thus, the find IP activity that randomly searches the IP address space has a base rate that is fourteen times slower than find username. However, upon finding a valid IP address, the attacker can perform subnet-based search, which makes it much faster to find other IP addresses (assuming, of course, that most of the clients are in the same subnet). Note that for the main mode to be enabled, at least one IP address must be found by random search. Upon finding a valid IP address, the attacker exhaustively searches the space of PSKs similar to the aggressive mode, placing a token in vpn breached whenever an IP/PSK pair is found.

The second atomic SAN model captures the behavior of the VPN environment and its operational maintenance (Figure 2). VPNs are vulnerable to malware attacks [START_REF] Dispensa | How to reduce malware-induced security breaches[END_REF]. In particular, malware can modify the configuration of a VPN tunnel in a stealthy manner. Since the VPN tunnel remains operational after the modification, it is difficult for the system administrator to detect such an attack.

We model two environments, one in which malware attacks exist and the other where they do not. Malware can maliciously modify a VPN to send packets in plaintext. Therefore, the installation of malware is synonymous to a VPN breach.

The malware infection rate is hard to quantify in industrial systems. For the sake of argument, however, we choose an infection rate of once a month when malware is present and later show that this rate does not have a significant impact on VPN security. The activity malware arrival models malware infections. Although malware can also retrieve unsecured passwords, we do not consider it to be a part of model because it is implementation specific.

VPN maintenance by the system administrator is a preventive and/or corrective action that can improve security. Maintenance involves changing passwords and checking for bad configurations. If a VPN configuration is modified by malware, a maintenance operation can secure the VPN by correcting the configuration and installing a patch that deals with the malware. Also, regularly changing passwords can mitigate exhaustive search attacks, helping secure the VPN. On the other hand, password changes do not affect username/IP enumeration, so this activity does not flush the usernames found and IPs found places in the model.

Experimental Results

This section presents the results obtained from simulation experiments using the SAN model. The primary goal was to investigate the probability that the VPN is not in the breached state. In SAN terminology, the reward variable (security probability) is defined as the probability that the marking of the place VPN breached is zero. The value of this probability for each configuration was studied for different time periods: one hour, three hours, twelve hours, one day, three days, one week, one month, three months and one year.

VPN security was also studied for different IKE modes (aggressive vs. main mode); password complexity (Table 1); numbers of users/machines (1, 10, 100 and 250); environments (with or without malware); and maintenance rates (once every week, month, three months, one year and no maintenance). Given the number of factors of interest, a large number of experiments are possible, but not all of them are meaningful. Therefore, we only performed experiments in which a few parameters of interest were changed at a time.

The first experiment compared VPN security in the aggressive mode versus the main mode. The main mode is generally more secure because, in order to perform offline password cracking, the attacker has to conduct a man-inthe-middle attack. Even if this attack is successful, the space of 32-bit IP addresses is larger than the space of usernames. The experiment assumed that the attacker can perform a man-in-the-middle attack; otherwise, the main mode is not vulnerable to the attack (i.e., the security probability is one at all times.)

The passwords (or PSKs) for both modes were selected from the space of six alphabetic characters (3.1E+08); the system was assumed to have ten users (usernames or IP addresses); security maintenance was not performed; and malware was not present. The results are shown in Figure 3. The security of a VPN tunnel diminishes over time. However, the security declines faster for the aggressive mode than for the main mode. The aggressive mode is less than 50% secure after six hours whereas the main mode reaches this level after about four days. Note also the short lifetime of a six-character alphabetic password for a VPN tunnel.

The second experiment studied the effect of password complexity on the overall security of a VPN (aggressive mode). To observe the effect of password complexity alone, maintenance and malware were switched off in this experiment. The system had ten different users.

The results are shown in Figure 4. As expected, the overall security of a VPN increases with password complexity. Note that eight-character alphanumeric passwords are secure for a much longer period of time, but even this type of password is less than 65% secure after one year. On the other hand, sixcharacter alphanumeric passwords are less than 60% secure after just one day.

The third experiment studied the effect of maintenance frequency on VPN security. This experiment assumed that IKE was used in the aggressive mode, that the system had ten users and that six-character alphanumeric passwords were used. The results in Figure 5 show that frequent maintenance can mitigate the effect of weak configurations. Note that the security probability reduces until it reaches a minimum before any maintenance starts; after this, the probability increases with frequent maintenance. Since the rate of maintenance is higher than the rate of password cracking in each case, the security probability reaches one at steady state. This does not mean that it is impossible to break the VPN tunnel as time passes; rather, it implies that the portion of time that the VPN tunnel is breached diminishes over longer time periods. Moreover, the declining security trend during the first few days can be repeated after each successful maintenance. The effect is not shown in Figure 5 because the security probability represents the steady state measure of security at any time.

The fourth experiment studied the effect of malware attacks versus weak VPN passwords. Two values of password complexity (six-and eight-character alphanumeric passwords) are plotted in Figure 6 with and without frequent malware attacks (once a month.) In the experiment, IKE used the aggressive mode and no maintenance was performed. A counterintuitive result from this experiment is that malware infections have little impact on the security of a weakly-configured VPN because the dominant effect in this mode is the ability of an attacker to crack a six-character alphanumeric password. On the other hand, in the case of a strong password, frequent malware infections considerably weaken VPN security. Therefore, we conclude that the impact of a malware infection depends on the configuration of the VPN. If the rate of password cracking is higher than the rate of infection, malware has little impact on the system. As a result, priority must be given to secure a VPN configuration. Note that this study only considered the effect of malware on the security of the VPN tunnel. Malware infections have other negative security impacts that were not modeled in the experiment. Next, we studied the effect of the number of users on overall VPN security. As shown in Figure 7, systems with large user populations are much less secure than systems with few users because an attacker has a higher chance of finding valid usernames/passwords (or IPs/PSKs.) This experiment assumed that IKE was used in the aggressive mode, that six-character alphanumeric passwords were used, security maintenance was not performed and malware was not present. The sixth experiment was designed to answer an important question: is it better to choose more secure passwords or to perform maintenance more frequently? The experiment considered two systems, one with six-character alphabetic passwords and once-a-week maintenance and the other one with eight-character alphanumeric passwords and maintenance every three months. The results are shown in Figure 8. Weak passwords with frequent maintenance are less secure in short term, but after a while (one year) complex passwords start to expire and the overall security (of the second system) decreases. Note also that changing passwords every week can be a huge administrative burden. The seventh experiment focused on a single configuration: the most secure configuration with no maintenance, complex (eight-character alphanumeric) passwords, ten system users and no malware. Figure 9 presents the results of the experiment. The importance of regular maintenance is clear -even a relatively secure configuration becomes less than 65% secure after one year without proper maintenance.

Security Recommendations

The simulation results provide valuable insight into securing VPNs, especially in industrial control environments where a tunnel is the only means to establish communications security and the tunnel may, therefore, last for a long period of time.

Based on the experimental results, the following recommendations can be made regarding VPN security:

The aggressive mode for IPSec VPNs provides fast tunnel establishment and less overhead that render the mode an attractive option for industrial environments where timing is critical. However, the mode suffers from serious protocol flaws that can result in security breaches in a relatively short time. This mode should not be used in critical applications. Secure configurations using the main mode and certificate-based authentication provide stronger VPN tunnels at the expense of higher overhead and slower connection establishment.

Long alphanumeric passwords or PSKs should be used to achieve acceptable security.

Even with complex passwords, frequent maintenance must be performed to lower the risk of a successful attack, especially when the adversary has significant computational resources. Note that personal "supercomputers" and botnets can significantly reduce the password cracking time.

A weak configuration can have a dominant effect even when malware infections are frequent. Securely configuring a VPN is the first step to countering attacks.

Less populated VPNs are more secure. When a VPN has a large number of users, other parameters must be stronger (e.g., longer passwords and frequent maintenance). In the case of VPN tunnels for industrial control applications, it is advisable to keep the number of users as low as possible.

Usernames (and IP addresses) used in a VPN must be changed or rotated periodically to reduce the risk of username enumeration attacks.

Related Work

Although probabilistic analysis has been widely used to investigate system reliability, its application to security has not attracted much attention until recently. Wang, et al. [START_REF] Wang | Security analysis of SITAR intrusion tolerance system[END_REF] have proposed the use of probabilistic models for analyzing system security. They have shown that modeling security using Markov chains can be quite informative and can facilitate the design of secure systems. Singh, et al. [START_REF] Singh | Probabilistic validation of an intrusion-tolerant replication system[END_REF] have used probabilistic models to study the security of intrusion-tolerant replication systems.

Many previous efforts and standards recommend that VPNs be used to secure industrial control protocols. IEC 62351 [START_REF]Communication Network and System Security -Profiles including TCP/IP, Technical Specification[END_REF][START_REF]Security for IEC 61850[END_REF][START_REF]International Electrotechnical Commission, Security for IEC 60870-5 and Derivatives[END_REF] recommends the deployment of VPNs for protocols such as DNP3 and 61850. Okabe, et al. [START_REF] Okabe | Security architecture for control networks using IPSec and KINK[END_REF] propose the use of IPSec and KINK to secure non-IP-based control networks. Gungor and Lambert [START_REF] Gungor | A survey on communication networks for electric system automation[END_REF] discuss the use of MPLS and IPSec VPNs to provide security for electrical power system applications. Sempere, et al. [START_REF] Sempere | Analysis of communication alternatives in a heterogeneous network for a supervision and control system[END_REF] demonstrate the performance and benefits of using VPNs over IP (among other technologies) for supervisory control systems. Alsiherov and Kim [START_REF] Alsiherov | Secure SCADA network technology and methods[END_REF] propose the use of IPSec VPNs to ensure integrity, authenticity and confidentiality in SCADA networks; however, they suggest that IPSec be configured in the PSK mode for efficient management. Patel, et al. [START_REF] Patel | Improving the cyber security of SCADA communication networks[END_REF] discuss the use of TLS and IPSec VPNs to wrap SCADA protocols. Alsiherov and Kim [START_REF] Alsiherov | Research trend on secure SCADA network technology and methods[END_REF] suggest using IPSec between SCADA sites to provide security when IEC 62351 is not implemented.

Hills [START_REF] Hills | Common VPN Security Flaws, White Paper[END_REF] has identified several VPN security flaws and has analyzed the presence of secure configurations in VPN deployments. Hamed, et al. [START_REF] Hamed | Modeling and verification of IPSec and VPN security policies[END_REF] have developed a scheme for modeling and verifying IPSec and VPN security policies. Finally, Baukari and Aljane [START_REF] Baukari | Security and auditing of VPN[END_REF] have specified an auditing architecture for monitoring the security of VPNs.

Conclusions

A stochastic model of a VPN and its environment provides a powerful framework for investigating the impact of various configurations and operational modes on VPN security in industrial control environments. Simulations of the model assist in quantifying the security of control protocols and evaluating security trade-offs, thereby providing a basis for the secure deployment of VPNs. The results also provide valuable recommendations for securely configuring VPNs in industrial control environments.

Our future research will study other VPN protocols (e.g., TLS and L2TP) and quantify their security properties. Also, we plan to incorporate detailed models of malware infections and man-in-the-middle attacks to study their impact more meticulously. Our research will also model other industrial control protocols using SANs with the goal of evaluating their benefits and limitations.

Figure 1 .

 1 Figure 1. Probabilistic model of a VPN.

Figure 2 .

 2 Figure 2. VPN malware infection and maintenance models.

Figure 3 .

 3 Figure 3. VPN security in the aggressive mode versus the main mode.

Figure 4 .

 4 Figure 4. Impact of complexity on VPN security.

Figure 5 .

 5 Figure 5. Impact of maintenance frequency on VPN security.

Figure 6 .

 6 Figure 6. Impact of malware on VPN security.

Figure 7 .

 7 Figure 7. Impact of the number of users on VPN security.

Figure 8 .

 8 Figure 8. Password complexity vs. frequent maintenance trade-off.

Figure 9 .

 9 Figure 9. Impact of secure parameters with no maintenance.


Anyi Liu

Jim Chen

Li Yang

Real-Time Detection of Covert Channels in Highly Virtualized Environments

Keywords: Virtualized environments, covert channels, detection INIT

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The widespread deployment of firewalls and other perimeter defenses to protect enterprise information systems has raised the bar for malicious external attackers. However, these defensive mechanisms are ineffective against insiders, who can access sensitive data and send it to external entities using secret communication channels. According to the Computer Security Institute [START_REF] Gordon | CSI/FBI Computer Crime and Security Survey[END_REF], the percentage of the insider attacks rose to 59% in 2007. Insider attacks have overtaken viruses and worms as the most common type of attack [START_REF] Salem | A survey of insider attack detection research[END_REF].

A covert channel is a communication channel that can be exploited by a process to transfer information in a manner that violates system security policies. A successful covert channel leaks information to external entities in a manner that is often difficult to detect. Researchers have proposed a variety of approaches to detect and prevent covert channels. Most covert channel detection approaches [START_REF] Berk | Covert channel detection using process query systems[END_REF][START_REF] Cabuk | Network Covert Channels: Design, Analysis, Detection and Elimination[END_REF][START_REF] Cabuk | IP covert timing channels: Design and detection[END_REF][START_REF] Gianvecchio | Detecting covert timing channels: An entropy-based approach[END_REF][START_REF] Shah | Keyboards and covert channels[END_REF] construct models based on clean traffic and detect covert channels by searching for deviations in actual traffic. Upon detecting a covert channel, a variety of countermeasures [START_REF] Fisk | Eliminating steganography in Internet traffic with active wardens[END_REF][START_REF] Kang | The pump: A decade of covert fun[END_REF][START_REF] Kang | A network version of the pump[END_REF][START_REF] Vutukuru | Efficient and robust TCP stream normalization[END_REF] can be applied to manipulate traffic and prevent information leaks.

While the approaches are effective against most covert channels, they require a sufficient amount of clean traffic. However, in networked virtual environments, such as those encountered in cloud computing, creating suitable models from clean historic traffic is problematic, mainly because the traffic associated with most virtual machine services is highly dynamic in nature. For example, virtual machines may migrate arbitrarily across virtual networks, revert to the snapshot of a saved state, or may run multi-booting systems. In such cases, clean historic traffic is either unavailable or the available traffic does not reflect the characteristics of clean traffic.

To address these challenges, we have designed and implemented the Outbound Service Validator (Observer), a real-time covert channel detection system. Observer leverages a secure virtual machine to mimic the behavior of a vulnerable virtual machine. It redirects all inbound traffic destined to the vulnerable virtual machine to the secure virtual machine, and differentiates between the outbound traffic of the two virtual machines to detect covert channels. Unlike existing approaches, Observer operates in real time and does not require historic traffic for modeling normal behavior. It can be dynamically incorporated in a cloud infrastructure when a vulnerable virtual machine has been identified. Moreover, the implementation is transparent to external attackers, which minimizes the risk that the detection system itself is the target of subversion. Experimental tests demonstrate that Observer can detect covert channels with a high success rate and low overhead. In particular, it induces an average 0.05 ms latency in the inter-packet delay and an average CPU usage increase of about 35% in a virtual network with 100 Mbps throughput.

Related Work

A number of differential analysis approaches have been developed for intrusion detection. Our approach is closely related to that of Netspy [START_REF] Wang | NetSpy: Automatic generation of spyware signatures for NIDS[END_REF], which compares outgoing packets from a clean system with those from an infected system. However, our approach represents an advancement over Netspy's approach. First, Netspy detects spyware that leaks private information as plaintext in HTTP responses; in contrast, our approach detects stealthy attacks, such as covert channels, that involve information leaks using encrypted traffic. Second, in order to generate signatures, Netspy assumes that spyware generates additional network traffic from the infected system; this assumption fails when information is transmitted through a passive covert channel that does not generate extra traffic. Third, Netspy correlates inbound packets with the corresponding outbound packets that are triggered; this approach fails to de-tect sophisticated covert channels that postpone outbound packets to ensure that inbound and outbound packets cannot be correlated.

Privacy Oracle [START_REF] Jung | Privacy Oracle: A system for finding application leaks with black box differential testing[END_REF] employs an approach similar to ours to discover information leaks. It uses perturbed user input to identify the fields of network traces by aligning pairs of network traces. Siren [START_REF] Borders | Siren: Catching evasive malware[END_REF] uses crafted user input along with a description of legitimate user activities to thwart mimicry attacks. However, both Privacy Oracle and Siren are unable to differentiate anomalous output in order to detect covert channels.

The approach of Mesnier, et al. [START_REF] Mesnier | Relative fitness models for storage[END_REF] predicts the performance and resource usage of a device using a mirror device. However, this approach is designed to predict the workload characteristics of I/O devices. Our approach, on the other hand, deals with the more difficult problem of detecting covert channels.

A number of methodologies have been proposed for creating covert channels [START_REF] Cabuk | Network Covert Channels: Design, Analysis, Detection and Elimination[END_REF][START_REF] Gianvecchio | Model-based covert timing channels: Automated modeling and evasion[END_REF][START_REF] Kopf | An information-theoretic model for adaptive sidechannel attacks[END_REF][START_REF] Smith | Predictable design of network-based covert communication systems[END_REF] and for detecting covert channels [START_REF] Agrawal | Trojan detection using IC fingerprinting[END_REF][START_REF] Gianvecchio | Detecting covert timing channels: An entropy-based approach[END_REF][START_REF] Liu | SIDD: A framework for detecting sensitive data exfiltration by an insider attack[END_REF][START_REF] Peng | On the secrecy of timing-based active watermarking trace-back techniques[END_REF]. The accuracy of these techniques depends on the availability of a good model and a substantial quantity of clean historic traffic. Our approach is superior in that it works online and neither requires modeling nor clean historic traffic. Moreover, it can be deployed dynamically or migrated across a networked virtual infrastructure, which renders it an attractive solution for highly virtualized environments.

Several researchers have applied covert channel design schemes to trace suspicious traffic. For example, Wang and Reeves [START_REF] Wang | Robust correlation of encrypted attack traffic through stepping stones by manipulation of interpacket delays[END_REF] employ well-designed interpacket delays to trace suspicious VoIP traffic [START_REF] Wang | Tracking anonymous peer-to-peer VoIP calls on the Internet[END_REF][START_REF] Wang | Network flow watermarking attack on low-latency anonymous communication systems[END_REF]. In contrast, our work only focuses on detecting covert channels, although covert channels design schemes nicely complement our detection methodology.

Research efforts related to cross virtual machine covert/side channels [START_REF] Okamura | Load-based covert channels between Xen virtual machines[END_REF][START_REF] Ristenpart | get off of my cloud: Exploring information leakage in third-party compute clouds[END_REF][START_REF] Wang | Covert and side channels due to processor architecture[END_REF] and their countermeasures [START_REF] Jaeger | Managing the risk of covert information flows in virtual machine systems[END_REF] are relevant to our work. However, they deal with covert channels that leak information between virtual machines that share the same virtual machine monitor or hardware. Our work goes beyond inter-virtual-machine covert/side channels -it focuses on detecting aggressive covert channels between insiders and external entities.

Threat Model

Covert channels can be roughly categorized into two types: covert storage channels that manipulate the contents of storage locations (e.g., disk, memory, packet headers, etc.) and covert timing channels that manipulate the timing or ordering of events (e.g., disk accesses, memory accesses, inter-packet delays, etc.). This paper focuses on the detection of covert storage channels.

Despite the complex nature of networked virtual environments, we desire to handle covert channel threats in as general a manner as possible. First, we assume that a vulnerable virtual machine can be compromised by many exploits. These include exploits that target vulnerable services, zero-day attacks and internal subversion exploits; however, we exclude attacks that change virtual machine behavior via a virtual machine monitor or hypervisor. Second, we assume that, after a virtual machine has been compromised, its user-space applications and kernel-space device drivers can be fully controlled by the at- tacker. Since covert channels leak internal information to external attackers, they can be detected by examining outbound network traffic. Figure 1 illustrates the covert channel threat.

The security foundation is based on two assumptions. First, the virtual machine monitor, which is under the control of the current virtual computing environment, is trusted and cannot be breached. Second, there exist a number of secure virtual machines that are also under the control of the current virtual computing environment. The secure virtual machines may be created along with the vulnerable virtual machine by cloning them from a clean state, or they may be created from a virtual machine prototype such as Amazon's Elastic Compute Cloud (EC2) [START_REF] Amazon | Amazon Elastic Compute Cloud (Amazon EC2), Seattle, Washington (aws[END_REF] or Microsoft Azure Services [START_REF]Microsoft Azure Services Platform[END_REF]. The secure virtual machines are protected by the virtual computing environment and external attackers cannot compromise them. Note that, although this approach requires at least one secure virtual machine to synchronize with a vulnerable virtual machine, the number of secure virtual machines is bounded by the number of vulnerable servers being monitored. Therefore, the Observer system can be applied to monitor as many vulnerable servers as desired when computational and storage resources become available. We do not require the virtual machine monitor of the virtual environment to know the software (i.e., operating system and applications) installed on the virtual machines, although this information is useful to determine the integrity of the virtual machines.

System Architecture

Figure 2 presents the architecture of the Observer system. The system has two main components: the security mediator and the virtual machine repos- itory. The security mediator comprises the: (i) traffic filter, which monitors inbound packets from the Internet and filters traffic of interest; (ii) traffic distributor, which examines the networking protocol information in the intercepted packets, replicates the packets and sends them to the vulnerable virtual machine and secure virtual machine; and (iii) output analyzer, which singles out outbound traffic from the two virtual machines and detects anomalous patterns. The virtual machine repository maintains a set of virtual machines, and activates, deactivates, clones and updates the virtual machine snapshots.

Traffic Filter

To protect services, the traffic filter maintains several rules that determine whether or not packets are to be intercepted. If an incoming packet satisfies a rule, it is subjected to further processing. After a new susceptible service is launched, new rules corresponding to the service are added to the rule list. that TCP packets from an external host (with address 123.123.123.123 and any port number) to an internal HTTP service (with address 129.174.2.123 and port number 80) are to be intercepted. The second rule drops all TCP packets in a reply to an external host, whose packet header field contains a rst flag. Rules can be added and deleted at runtime to ensure that the system cannot be penetrated during rule updates. Note also that the rules are based on a priori knowledge and reported vulnerabilities.

The time taken by the traffic filter is O(N ), where N is the total number of packets (in terms of the number of bytes) that satisfies the rule set provided that the focus is restricted to services that are easily compromised. Since the packet filter does not buffer processed packets, the storage requirement is bounded by the maximum size of a network packet.

Traffic Distributor

The primary task of the traffic distributor is to forward packets destined to the vulnerable virtual machine to the secure virtual machine. Two steps are involved. First, when the traffic distributor receives a packet e from the traffic filter, it constructs a new packet e ′ . The new packet e ′ keeps some of the fields from e (e.g., Src IP and Src P ort), while other fields (e.g., Dst IP , Dst P ort, sequence numbers and checksum) are modified (Dst IP and Dst P ort correspond to the IP address and port number of the secure virtual machine, respectively). The two packets e and e ′ are then dispatched simultaneously. Second, when the traffic distributor receives reply packets from both the virtual machines, it only sends the packet reply corresponding to e; thus, an external attacker has no knowledge of the secure virtual machine.

Figure 4 presents a simplified state machine corresponding to the traffic distributor. M 1 and M 2 represent the vulnerable virtual machine and secure virtual machine, respectively. For example, when the traffic distributor receives a SY N packet, it constructs a new SY N packet, namely SY N ′ , and sends SY N and SY N ′ to M 1 and M 2, respectively. Similarly, when it receives the ACK and ACK ′ packets, it only sends the ACK packet. To synchronize the outputs of M 1 and M 2, the traffic distributor must maintain all the previous communication states in a queue in the event of packet loss or fragmentation.

The overhead involved in constructing a new packet e ′ is essentially constant. The storage requirement is dictated by the total number of packets forwarded from the traffic filter. Although Observer collects live traffic, which increases without bound, the storage requirement is still bounded by 2n, where n is the size of the queue.

Implementation

Observer is implemented on a VMware ESX Server 4.1 [START_REF]VMware ESXi and ESX Info Center[END_REF]. The traffic filter and traffic distributor are implemented as part of a transparent bridge, which uses a customized ipfw application to intercept packets and divert socket to manipulate packets. The security mediator comprises around 1,000 lines of C code.

To minimize the latency after packets leave the security mediator, the vulnerable virtual machine and secure virtual machine are cloned from the same virtual machine image with the same state, and the two virtual machines are configured one hop away from Observer. The vulnerable virtual machine and secure virtual machine must be closely synchronized; the sequence number field of TCP packets is used to synchronize outbound traffic from the two virtual machines. To ensure that Observer maintains accurate time information, each virtual machine is configured to have affinity to one CPU at a time.

The output analyzer uses Ethereal to collect traffic and separate the timing information. The ntop application is used to generate network traffic statistics at runtime. The output analyzer module is written in C, Perl, Dataplot and MATLAB.

Evaluation

This section analyzes the ability of Observer to detect covert channels. It also examines the performance overhead involved in covert channel detection.

Covert Channel Construction and Detection

A scheme similar to that used by Ramsbrock, et al. [START_REF] Ramsbrock | A first step towards live botmaster traceback[END_REF] was used to construct covert channels. Specifically, to encode an i-bit sequence S = s 0 , . . . , s i-1 , we used 2i randomly chosen packet pairs ⟨P ri , P ei ⟩ (i = 0, . . . , L) where r i ≤ e i , and P ri and P ei correspond to reference packets and encoding packets, respectively. A covert bit s k (0 ≤ k ≤ i -1) is encoded into the packet pair ⟨P ri , P ei ⟩ using the equation:

e(L r , L e , L, s k ) = l e + [(0.5 + s k )L -(l e -l r )]mod2L
where L r and L e are the values of the encoded field in P ri and P ei , respectively. The original covert channel design scheme was extended to test the effectiveness of Observer to detect slow covert channels. Specifically, instead of using 2i packets, we used 2ai (a ≥ 1) packets to encode S, where a is a constant or pseudorandom number. P ri and P ei were chosen from the 2a packets. The term a serves as an "amplifier," where a larger value indicates a slower covert channel.

Covert channels were detected using shape tests corresponding to first-order statistics such as means and variances [START_REF] Peng | On the secrecy of timing-based active watermarking trace-back techniques[END_REF]. The shapes of the traffic patterns were tested using a Chi-Square test [START_REF] Corder | Nonparametric Statistics for Non-Statisticians: A Step-by-Step Approach[END_REF] and a two-sample Kolmogorov-Smirnov test (K-S test) [START_REF] Duda | Pattern Classification[END_REF]. The Chi-Square test was used to verify whether or not two discrete sample data come from the same discrete distribution; the K-S test was used to verify whether or not two continuous sample data come from the same continuous distribution. The two tests were chosen because they are distribution free, i.e., they do not depend on the actual cumulative distribution function (CDF) being tested.

Effectiveness

The evaluation focused on the detection of two types of covert channels: IP/TCP packet field channels (PFCs) and botnet traceback watermark channels (BTWCs). A PFC operates by modifying the urgent field of TCP packets to transmit information: a 1 bit is transmitted by increasing the urgent field value by an integer modulo w, while a 0 bit is transmitted by increasing the value by an integer modulo ⌊ w 2 ⌋. A BTWC operates by modifying the length of the encoding packet P ei by padding characters to achieve a specific length that is different from its corresponding reference packet P ri . The padded characters could be visible or invisible (e.g., whitespace), and can be inserted in random locations in the payload.

The latency of Observer was measured using the detection window size, which is the minimum number of packets needed to detect a covert channel since it commenced transmission. A larger window size indicates greater latency and less sensitivity to covert channels in real time. Table 1 shows the detection window size required by Observer to obtain a 100% true positive rate (note that a larger value of a indicates a slower covert channel). The results demonstrate that a slower covert channel requires a larger detection window.

Table 1 shows that that a window size of 160 is required to detect the most aggressive BTWC, which sends one bit per packet. However, a slower BTWC, which transmits one bit every 20 packets, requires a window size of 24,060! The detection window sizes, which are much more sensitive for PFCs, vary from 60 to 730.

! "!! #!! $!! %!! &!!! &"!! &#!! &$!! ! !'
The results can be explained by comparing the cumulative distribution functions (CDFs) corresponding to BTWCs and PFCs for different values of a. Figure 5 shows that the distributions of BTWCs are quite similar for different values of a, but the same is not true for PFCs. Therefore, BTWCs are more difficult to detect than PFCs.

Detection Rate

Live traffic was collected from the vulnerable virtual machine and secure virtual machine in order to determine the false positive rates for Observer. A BTWC and PFC were created with a = 1; the false positive rates for both channels were zero. Tables 2 and3 present the results of the statistical tests for the two channels. As expected, the slower covert channels (with larger values of a) have statistics that are closer to those of legitimate traffic.

A theoretic analysis of false positives was conducted by setting the targeted false positive rate to 1%. To achieve this false positive rate, we used a "cutoff point," which was set at the 99 th percentile of the legitimate samples to determine if samples are benign or malicious.

Figure 6 shows the true positive rates for PFC and BTWC detection for various values of a. The results show that the effectiveness of detection depends on the number of observed packets. For example, in the case of a PFC with a = 10, the true positive rate fluctuates when Observer collects 5,000 packets. A similar situation also occurs for a BTWC. We are currently investigating various approaches to improve the effectiveness of detection.

Performance

Two experiments were conducted to evaluate the performance of Observer. The first experiment evaluated the throughput of Observer under the best and worst case scenarios. In the best case scenario, no packets were intercepted by the traffic filter. In the worst case scenario, the majority of the inbound packets sent to the vulnerable virtual machine were intercepted by the traffic filter because they were assumed to be sent via a covert channel. Packets in both scenarios were collected when an attacker visited the web server of the vulnerable virtual machine for 160 minutes. Table 4 presents the detailed statistics for the two scenarios. Note that the average time to process a packet is almost 56.2 ms even in the worst case. The second experiment measured the average latency introduced by Observer to the inter-packet delay. In the experiment, 1,000,000 packets were collected with and without Observer installed. The average latency added to the inter-packet delay is 5 ms, which is almost unnoticeable compared with the reported average inter-packet delay of 42.67 ms for Northern America [START_REF]IP latency statistics[END_REF]. This latency is the result of the queuing delay that Observer imposes on inbound packets when directing them to both virtual machines at the same time.

Conclusions

Observer detects covert channels in a networked virtual environment by running a secure virtual machine that mimics a vulnerable virtual machine so that differences between the two virtual machines can be identified. Unlike most covert channel detection systems, Observer does not rely on historic data to create models of normal behavior. Experimental tests demonstrate that Observer can detect covert channels with a high success rate and low latency and overhead.

The accuracy of covert channel detection relies on the fact that the virtual computing environment provides at least one secure virtual machine for every vulnerable virtual machine. This limits the scalability of our approach. To address this limitation, our future research will investigate the dynamic allocation and management of secure virtual machines.

Another limitation is that it is necessary to maintain a secure version of a vulnerable virtual machine over its entire lifecycle. Even during the detection phase, it is difficult to ensure that inbound traffic does not contain an exploit that could compromise the secure virtual machine at runtime. Potential solutions that address this limitation will be examined in our future research.

Figure 1 .

 1 Figure 1. Covert channel threat.

Figure 2 .

 2 Figure 2. Observer system architecture.

Figure 3 .

 3 Figure 3. Configuration file of traffic filter.

Figure 3

 3 Figure 3 lists some rules, which are similar to general purpose firewall rules. The rules specify the packet header fields, such as Direction, Protocol, Src IP, Src Port, Dst IP, Dst Port and Packet Header Flags. The first rule specifies

Figure 4 .

 4 Figure 4. State machine for the traffic distributor.

  Urgent field distributions.

Figure 5 .

 5 Figure 5. Cumulative distributions for BTWCs and PFCs for various values of a.

  BTWC true positive rates.

Figure 6 .

 6 Figure 6. True positive rates of channel detection for various values of a.

Table 1 .

 1 Detection window size for various covert channels.

		BTWC PFC
	a = 1	160	60
	a = 5	181	460
	a = 10	7,150	390
	a = 20	24,060	730

Table 2 .

 2 PFC test scores.

		Mean	SD	Chi-Square	Chi-Square	Chi-Square
				Test	(CDF value) (1% cutoff )
	Legitimate 20.143	3.925	0	0	≥ 15.087
	HTTP
	PFC	36.926 16.485	6789.002	1	≥ 11.345
	(a = 1)
	PFC	23.480 10.576	82.136	1	≥ 15.086
	(a = 5)
	PFC	23.343 10.316	75.657	1	≥ 13.277
	(a = 10)
	PFC	20.878	6.137	3.902	0.581	≥ 13.277
	(a = 20)
	PFC	20.478	5.088	0.796	0.061	≥ 13.277
	(a = 50)

Table 3 .

 3 BTWC test scores.

		Mean	SD	K-S	K-S	K-S
				Test (p value) (1% cutoff )
	Legitimate 283.601 453.532	0	1	≥ 0.1923
	HTTP
	BTWC	284.785 452.005 0.248	0	≥ 0.1923
	(a = 1)
	BTWC	283.824 453.215 0.049	2.94e-15	≥ 0.1923
	(a = 5)
	BTWC	283.721 453.357 0.025	2.53e-04	≥ 0.1923
	(a = 10)
	BTWC	283.660 453.441 0.012	0.212	≥ 0.1929
	(a = 20)
	BTWC	283.622 453.503 0.004	0.951	≥ 0.1929
	(a = 50)

Table 4 .

 4 Comparison of throughput.

		Best Scenario Worst Scenario Ratio
	Packets	1,802,176,469	170,712,403	0.094
	Bytes	1,214,518,973,379	128,003,547,066	0.105
	Packets/s	187,727	17,783	0.098
	Bytes/s	126,512,393	13,333,703	0.110
	Duration	160 min	160 min	1.000

, SYN' to M1, M2 Receive SYN/ACK and SYN/ACK' from M1, M2. Send SYN/ACK. Receive ACK. Produce ACK'. Send ACK, ACK' to M1, M2, Respectively Receive PUSH/ACK from M1, M2. Send PUSH/ACK from M1. Receive ACK. Produce ACK'. Send ACK, ACK' to M1, M2, Respectively Receive FIN/ACK and FIN/ACK' from M1, M2. Send FIN/ACK.