Chin-Fu Kuo, Yung-Feng Lu, and Chi-Ying Chen

1. Introduction

Cloud computing is a combination of various computing entities, globally separated, but electronically connected. As the geography of computation is moving towards corporate server rooms, it brings more issues including security, such as the transmission security. There is a survey regarding the use of cloud services made by International Data Corporation highlights that the security is the greatest challenge for the adoption of cloud[1]. Hence,security is a huge concern for cloud users, and it becomes an important issue that provides a secure way to use the cloud. To improve the mutual trust between users and the cloud provider, the cloud security alliance (CSA)[2],[3]has developed a security guide that identifies many areas for concern in cloud computing. The cloud network and perimeter security is one of the most challenging issues.Hence, protecting the information from illegal access has become an inevitable issue for IT product vendors and developers.

In this paper, we are concerned with how to configure the security mechanisms for security gateways in a systematic manner. Network gateways, one of the popular IT products, are designed to bridge network traffic between the Internet and private networks. The major responsibility of the gateways is to protect private networks from being accessed without appropriate permission. Although there do exist numerous security mechanisms, there is no universal standard for configuring security mechanisms on gateways.A gateway that is set up as a network router for an enterprise private network often requires strict security policies. However, a gateway for home usage might not have proper security measures. In addition, the majority of the security mechanisms are computationally intensive.Enforcing unnecessary security mechanisms may compromise the system performance and network throughput. The challenge is how to configure a network gateway so that its security features are met without compromising its performance.

In the current gateway architecture, individual security software components are designed to provide particular security mechanisms. Designing each software component to provide particular security mechanisms has its own merits. However, it leads to additional administration overhead and it may also cause misconfiguration vulnerability.

Instead of proposing new security features, this paper focuses on the providing of a threat-based security configuration architecture for gateways to ease the administration overhead and reduce the chance of misconfiguration vulnerability. Fig. 1 illustrates the threat-based security configuration architecture for the gateways. The novel architecture serves two purposes: 1)reducing the software integration and configuration overhead for product designers during the design phase and 2) providing an intuitive configuration interface for the end-users. From product designers’ perspective, the architecture provides a systematic manner to integrate the software components to overcome the threats and to properly configure the software components. The threat-based configuration architecture shown in the dashed box in Fig. 1 separates the software configuration into four parts: the common criteria document, threat dependency graph, state transition graph, and software configuration.The common criteria document defines the threats that the gateway should overcome.

Given the threats defined by the common criteria document, we propose a threat dependency graph to model the occurrence relation among the threats. The threat dependency graph helps the designers identify the set of threats to be overcome in order to provide certain security features and reduce the chance of misconfiguration vulnerability. We also define the system security states,each of which defines the set of the threats that the system can overcome. The change of the security states during the run-time are modelled by the state transition digraph. Given the common criteria document and security states, the designers can find the software components to overcome the threats with minimal efforts. The four parts of the threat-based security configuration are determined during the design phase and are constructed by domain experts.From end-users’ perspective, the architecture allows the end-users to configure the gateways by selecting the desired security features, as shown on the left-hand side of Fig. 1.After the desired security features are selected, the software components on the gateways are configured according to the flow shown in the dashed box in Fig. 1 to provide the selected features. There is no need for the end-users to configure the individual software components on the gateways. When the new threats are discovered, the designer shall revise the threat dependency graph, state transition diagraph, and software configuration. The end-users shall download the revised threat and state information to reconfigure their own gateways. By this manner, the change of misconfiguration vulnerability can be reduced.

The idea of threat dependency graph is related to the attack tree approach developed by Schneier[4]. The attack tree approach is intended for penetration testing where there is a little background information about the system to be tested. The basic idea is a combination of the work breakdown structure from project management and the familiar tree representation of a logical proposition.However, the occurrence of threats in the gateways may not always have such relation. When a system is vulnerable to eavesdropping, the system is vulnerable to both the unauthorized access to the security configuration data and spoof. We extend the tree structure to a directed acyclic graph to model the occurrence relation among the threats.

To demonstrate the capability of the architecture, we integrate several open source security components on a Linux platform. However, the designed architecture is not limited to the software components used in this paper.Other (open source or commercial) software can also be integrated on such an architecture. A series of experiments are conducted to evaluate the capability of the proposed methodology.

The rest of this paper is organized as follows. Section 2 describes the proposed security gateway based on common criteria. Section 3 describes the design of the gateway and discusses the implementation issues of the security gateway.Section 4 evaluates the performance of the system and demonstrates the effectiveness of the proposed architecture.Our work is summarized and the future work is discussed in Section 5.

2. Security Gateway Based on Common Criteria

Gateways in the paper are referred to the devices defined by RFC1009[5], in which a gateway is an IP-level router to connect two or more networks. In June 1993, the United States, the United Kingdom, Germany, France,Canada, and Netherlands started to develop an evaluation standard for a multi-national marketplace. This standard is known as the “Common Criteria for Information Technology Security Evaluation” (CCITSE), and it is usually referred to as the “Common Criteria” (CC).

In CC, a product which is subjected to evaluation is called a target of evaluation (TOE). As shown in Fig. 2,there is a process for the evaluation of CC. Our TOE is a gateway that is designed to protect the private networks against security threats from the external network. For the sake of presentation, we will use terms “TOE” and“gateway” interchangeably in the paper. The security measures of a TOE are defined by two documents: the protection profile (PP) and security target (ST). PP allows the consumers and developers to compile standardized sets of security requirements to meet their needs. On the other hand, ST specifies the functional requirements and assurance security for the product developers. The evaluators use ST as the basis for evaluation. There are many research have adopted CC to help them verify their security requirements. Details of CC usages are given in[6]-[9].

Fig. 1. Threatbased security configuration architecture.

Fig. 2. Evaluation process of CC.

Fig. 3. Threat dependency graph.

2.1 Security Threats

To define the security threats for a security gateway, we have studied several PPs and STs for the definition of threats for various TOEs. The target products include operating systems (OSs)[10], firewalls[11],[12], and intrusion detection systems[13]. The threats for the security gateway are summarized in Table 1. The threats listed here are not newly discovered but are categorized to aid the design of the threat-based configuration architecture. In the following sections, a symbol “T.threat” represents a threat named“threat”.

The threats are classified into three categories: the threats for the gateway OSs, the threats for the private networks, and the threats for the communication channel.The threats for the gateway OSs may cause abnormal operations in the underlying OSs. Two threats, T.NOAUTH and T.SELPRO, are listed in this category. The threats for the private networks are the ones that may cause disordered operations on the private networks and information leakage.T.AUDIT, T.MEDIATE, and T.RESOURCE are the threats listed in this category. The threats for the communication channels are the ones that may compromise the confidentiality of the communication channels when network packets are not encrypted during transmission.T.EAVESDROP, T.SPOOF, and T.MASQEURADE are the threats in this category.

Although the listed threats could occur individually,their occurrences are not fully independent. For example,T.EAVESDROP might occur when an unauthorized user is able to eavesdrop on the communication media and obtain the authentication data. Hence, the user can bypass the security mechanisms to modify critical configuration data,which causes T.NOAUTH. Note that such a scenario occurs even when the system enforces a flawless authentication mechanism, i.e., no user can log in the system without giving proper identity information. In short, when the threat T.EAVESDROP occurs on the system, it is very likely that threat T.NOAUTH also occurs on the system. We call such a sequence of attacking events of threats as an attacking scenario.

Table 1: Threat description of the gateway[9],[14]

2.2 Threat Dependency Graph

A threat dependency graph is an acyclic directed graph in which each node represents a threat on the gateway and each directed edge represents an attacking scenario from the source threat to the destination threat. We call a threat T.a a preceding threat of a threat T.b if there exists a path from T.a to T.b. Essentially, an edge in the threat dependency graph represents that failing to overcome the source threat leads to the failure of overcoming the destination threat. In other words, to fully overcome one threat T, the system must overcome all the preceding threats of T.a and T.b.

Fig. 3 shows a simple threat dependency graph with four threats: T.i, T.j, T.k, and T.l, and three directed edges(i.e., attacking scenarios). The edges in Fig. 2 illustrate that T.k may occur when T.i or T.j occurs on the system.Similarly, T.l may occur when T.k has been observed on the system. To protect the system from T.k, the system needs the security mechanisms to prevent all preceding threats of T.k (i.e., T.i and T.j) and T.k rather than T.k only.

To construct the threat dependency graph for the security gateway, we studied the attack scenarios collected by the CERT?coordination Center, Snort rules database[15],and earlier work in the literature (e.g., [16] and [17]). We selected the attacking scenarios in which the threats related to the gateway are involved. Fig. 4 shows the threat dependency graph system from T.EAVSDROP. On the other hand, T.AUDIT is the threat that requires most overhead to overcome. It is because the system has to overcome all eight threats in the graph.

Note that the threat dependency graph shown in Fig. 4 may not cover all possible threats on a security gateway.This is because the graph is compiled based on the observed attacking scenarios. Any attacking scenarios not observed in the literature are not covered by the graph.However, the graph can be revised incrementally when a new threat or an attack scenario has been discovered. The product designer or security service providers can revise the threat dependency graph by analyzing the relationship between the new threat and any of the existing threats. For example, if failing to overcome the new threat T.new could lead to the failure of overcoming one of the existing threat T.old, and a new edge from T.new to T.old will be added to the graph.

3. System Design and Implementation

3.1 System Architecture

We propose a layered software architecture for threat based security gateways. The advantage of this architecture is the following. The security functionalities of each layer are verified without any concern for the software components in the other layers. Its correct functionalities can be used in other above layers. As a result, the system designer can reduce the overhead of selecting and integrating security software components on the gateway.Each layer is designed to overcome the threats listed in one threat category defined in Section 2.2. The software at each layer will be chosen to overcome the threats of the layer. In the proposed architecture, there are three software layers:the secure OS, secure gateway, and service of gateway, as shown in Fig. 5. The bottom layer is the secure operating system layer, which is responsible for providing the basic OS protection to the gateway. The top layer is the gateway service layer, which is on the top of the secure OS layer and is responsible for providing a secure private network. It is responsible for providing secure communication channels.

For the rest of this section, we describe the selected software components in each layer. Rather than implementing new security modules in each layer, existing open source security modules are integrated to demonstrate the effectiveness of our design. However, the gateway is not limited to use the software chosen in this paper. Other commercial or open source software can also be used in this architecture as long as the software overcomes the threats defined in the paper.

·Secure OS layer: The secure OS layer is the minimal requirement for our security gateway. The mechanisms adopted to implement the secure OS layer are pluggable authentication modules (PAM)[18]and security-enhanced Linux (SELinux)[19],[20].

Fig. 4. Threat dependency graph for the security gateway.

Fig. 5. System architecture of the security-enhanced gateway.

PAM provides the authentication mechanism and is used in our gateway to overcome T.NOAUTH. In addition,we choose SELinux as a part of the secure OS layer to overcome T.SELPRO. There are two main types of implementation for access control: the discretionary access control (DAC) and mandatory access control (MAC). The DAC grants the access permission based on the user identity and ownership. Other security-relevant information are ignored. On the other hand, the MAC grants the access permission based on the subjects and objects specified in security policies. With MAC, users can confine user programs and system daemons to the minimum privilege required to complete their tasks. By specifying appropriate security policies, the probability in which the user programs and system daemons might cause harm (e.g., buffer overflow or configuration errors) is minimized. Most OSs,such as FreeBSD[21], implement through DAC.

·Secure gateway layer: Three security modules are selected for the secure gateway layer: iptables[22], Snort[15],and iproute2[23]. Iptables is part of the netfilter framework in the Linux kernel. We use iptables to implement the network address translation (NAT1) protocol and build a packet filtering firewall at the packet level. Iptables is used in our gateway to overcome T.MEDIAT. Iptables is also one of the minimal requirements for our security gateway.

The Snort[15]is an intrusion detection system (IDS) that could inspect the traffic flow passing through the gateway to protect the private networks. By logging the packets or only the packet header, the administrator can trace or analyze the attacks later. Hence, T.AUDIT is overcome. In addition, when certain attacks occur, Snort signals can alarm to the system.

Iproute2[23]consists of traffic control mechanisms for classifying, prioritizing, sharing, and limiting traffic of either direction. Iproute2 allows the end users to control the traffic such that the bandwidth is not over-consumed by certain hosts. Iproute2 also allows the end users to assign the priority to each host. Therefore, T.RESOURCE. is overcome by iproute2.

·Service of gateway layer: The widely used IPv4 has no authentication and encryption mechanisms on the header and content of IP (Internet protocol) datagrams. Therefore,the datagrams could be read, modified, or forged during transmission. This defect may cause threats T.EAVESDROP, T.SPOOF, and T.MASQUERADE.IPSec is one of many mechanisms to resolve this defect.There are two major protocols in IPSec: the IP authentication header (AH)[24]and IP encapsulated security payload (ESP) protocol[25]. AH authenticates IP datagrams to provide data integrity and source authentication; ESP encrypts IP datagrams to prevent eavesdropping. Therefore,all communication channels of different applications operated over the IP protocol could be protected.

3.2 Security State and State Transition

The security state of a gateway is a set of threats that the gateway can overcome. For each threat in the threat set,its preceding threats must also be included in the set.Otherwise, the gateway is not able to be fully protected against the threats and the threat set is not a valid security state. Consider the threat dependency graph in Fig. 6. The threat set {T.i, T.j, T.k} is a valid security state because all preceding threats of threats T.i, T.j, and T.k are included in the set. However, the threat set {T.i, T.k} is not a valid security state because T.j is a preceding threat of threat T.k but not included in the threat set.

There are eight security states in our security gateway.Table 2 shows the states, the threats that the system can overcome, and the corresponding security software configuration for each state. State S0is the initial state of the system and activates no security software. State S1has the minimal security level which overcomes threats T.MEDIATE, T.EAVESDROP, and T.SPOOF. When the system is in state S1, the system activates iptables and IPSec with data encryption standard (DES) to overcome the threats. State S7has the maximal security level which overcomes all eight threats of the gateway. But note that the index of the security state does not imply the security level of the gateway. A greater index does not imply a higher security level. For example, it is difficult to compare the security level of states S2and S3because they could overcome different threats and attacking scenarios.

Table 2: State configuration

Fig. 6. State transition digraph.

The state transition digraph of the gateway is shown in Fig. 6. Each node represents a security state and each edge represents the state transition from the source state to the destination state. The initial system state is state S0. The annotation on each edge represents the changing of the threat set. The system may overcome or ignore certain threats. For example, when the gateway is in state S5, its security state could be changed to S6by changing the software configuration to ignore another threat,T.RESOURCE.

The state transition digraph aids the end users to reduce the runtime administration overhead. With the state transition digraph, the end users only focus on determining the security features that the system should overcome. The security mechanisms on the system are automatically configured based on the software configuration shown in Table 2. For instance, when the system starts, the system is in the initial state S0. If the end user decides that the system should be protected from the T.NOAUTH attacks, the end user can request the system to migrate to state S3. And the software on the system is, then, configured according to Table 2. (The system can also be protected from threat T.NOAUTH by migrating to state S4, S5, S6, or S7. However,it will over consume more resources and compromise the system performance. The performance of the system at different states will be studied in Section 4.)

The state transition digraph also aids the end users to eliminate the misconfiguration vulnerability. When the system is in state S4and the end user decides to ignore T.NOAUTH attacks but overcome T.SELPRO attacks, the system state should be migrated to state S5. Without the state transition digraph, the end user may decide to deactivate PAM and activate SELinux. However, without activating PAM, the system is not able to overcome threat T.SELPRO. This is because T.NOAUTH has a path to T.SELPRO in the threat dependency graph and must be overcome.

3.3 Implementation Challenges

In this section, we present the alternatives for implementing the proposed architecture and discuss the implementation decisions we made. We also present the challenges for integrating several existing security mechanisms, and how we handle those challenges. The alternatives for the implementation of IDS and the communication channel protection are discussed as follows.

·IDS: There are two main types of IDS. One is the network-based IDS and the other is the host-based IDS. A network-based IDS installed on the edge of the networks scans all of the incoming/outgoing traffic of the private networks for suspicious attacks; the host-based IDS installed on a host machine scans security vulnerabilities only on the host machine. IDS is used on our gateway to protect the private network rather than one host machine.Therefore, a network-based IDS such as Snort is more suitable for our gateway. One benefit of Snort is that its online signature database is updated constantly by the user/security community. The database contains signatures for various attacks. By updating the new signatures, Snort could respond to new attacks quickly.

·Communication channel protection: There are two ways to protect the communication channels. One way is to provide authentication and encryption mechanisms on the application layer. For example, the secure socket layer protocol (SSL)[26]has been proposed to protect a communication channel between a web browser and a web server. However, the disadvantage of this approach is that each application must be tailored to support secure communication channels. The other way is to adopt IPSec on the network layer. The IPSec serves as a transparent mechanism to authenticate and encrypt IP datagrams flowing through the secure gateway, so that all hosts in the private network could benefit from it without any modification.

Several challenges occur during our system integration:

·Integrating the IPSec and firewall: There are several challenges when IPSec has to work with firewalls. One challenge is that the firewall should allow the IPSec traffic to pass through the firewall. The firewall has to be configured to allow traffic using ports 50 and 500. Because the port 50 is used by ESP and the port 500 is used for the key exchange. The other challenge is about NAT. IPSec authenticates IP datagrams to ensure that they are not modified during transmission, but NAT rewrites the header of the datagrams when they go pass through the gateway.As a result, IPsec authentication fails since IP datagrams are modified. A resolution to this problem is that the sending gateway passes the IPSec datagrams without doing NAT, and the receiving gateway also passes the IPSec datagrams without doing NAT. The process is shown in Fig. 7.

·Integrating the IDS and firewall: An important consideration in the installation of IDS is the time to analyze the packets. If the IDS analyzes the packets before they are processed by the firewall, the IDS analyzes all packets directed to the gateway. On the other hand, an IDS behind the firewall will only analyze packets that pass through the firewall. We choose the former setting. The reason is that the system will get more information for the state of the environment, avoiding a false sense of safety.This approach introduces additional performance overhead to the system. Unfortunately, it is extremely difficult to quantify the increased overhead. This is because the amount of increased overhead highly depends on the number and type of rules set in the firewall. In addition,although more firewall rules may filter more packets to reduce the run-time overhead on the IDS, it also introduces additional overhead on the firewall.

Fig. 7. System configuration with both NAT and IPSec.

Table 3: Software versions for the experimental environment

4. Performance Evaluation

In this section, we evaluate the effectiveness and performance of the proposed threat-based security gateway.

4.1 Workload Generation and Performance Metrics

To evaluate the performance of a threat-based security gateway, we set up an experimental environment which was isolated from the Internet to avoid interference, as shown in Fig. 8. The security gateway was installed on an x86-based machine which has an Intel Pentium III 700 MHz CPU and 512 MB RAM (random access memory).Two security gateways were connected via a wire-speed layer-3 switch. Each security gateway was connected to a private network which has one or more hosts. The software installed on the gateways is listed in Table 3.

We adopted Iperf[27]to generate network traffic and measure network performance. In our setting, there were an Iperf client and an Iperf server. The Iperf client sent(transmission control protocol (TCP) or user datagram protocol (UDP)) packets to the Iperf server. The TCP traffic was used to measure the throughput of the connection.

The experiments also verified the effectiveness and performance tradeoff of state transition. Attacking packets were generated by using hping[28]. We used hping to forge malicious packets by stuffing the payloads with the signatures specified in the Snort database. Packets were sent by hping at the rate of 100 packets per second to trigger attacking alerts of Snort. When Snort detected attack events, it sent alert messages to the end-user. So, the end-user can modify the desired security features of the gateway, and then the state of the gateway could be automatically adjusted.

The performance metrics are the average network throughput and average CPU workload. The average network throughput is the amount of transferred data in mega bits per second (Mb/sec) on the network connection between the Iperf client and Iperf server in average; the average CPU workload is the ratio of the time when the CPU is busy. We measured performance for different security states.

4.2 Results and Analysis

We present the results that show the tradeoff between the security states and performance. In the evaluation results, the 95% confidence interval of each data point in our results is no greater than 2.4% of its data values.

·Average throughput: The average network throughput for different security states are shown in Fig. 9.The average network throughputs were no more than 25 Mb/sec. This was caused by the overhead imposed by IPSec. The overhead of authentication and IP datagrams encryption backlogged the network packets and reduced the average network throughput.

In Fig. 9, the average throughput increases when the system state migrates from S1to S2and from S3to S4(i.e.,the system is able to overcome more threats). This is because that AES used in S2and S4is more efficient than DES used in S1and S3. Although AES provides more functionalities and has better performance than DES does,we chose AES and DES for different states for the purpose of demonstration. In practice, the system designer can use AES for both states to reduce the overhead. Moreover, the difference of the average network throughput between S1and S3(or S2and S4) was small because PAM introduced negligible overhead when there was a new secure shell(SSH) session generated. In order to overcome additional threats from S4to S7, additional security software components were activated and the average network throughput was decreased gradually.

Fig. 8. Experimental environment for performance evaluation.

Fig. 9. Average throughput for different state configurations.

Table 4: Average CPU workload

·Average CPU workload: The average CPU workload for different security states are shown in Table 4. The average CPU workloads of states S1and S3(or S2and S4)are similar. It shows that overcoming T.NOAUTH needed little overhead. Moreover, it is clear that enabling AES in states S2and S4could reduce the CPU workload. The reason is that AES is more efficient than DES. Overcoming T.SELPRO increased the CPU workload from S4to S5. The average CPU workloads of states S5and S6are similar. It shows that overcoming T.RESOURCE imposed ignorable effect on the CPU workload. When the system was in state S7, the CPU workload was 100%. This was because the Snort was activated in S7. Incoming packets were analyzed by the Snort to check for suspicious activities. The checking process involved pattern-matching with thousands of build-in attacking signatures. This process was computationally intensive.

·Threat detection and state transition: The throughput variation of the security gateway as the system state changes is shown in Fig. 10. The upper part shows the change of network throughput over time; the bottom part shows the attacks generated by hping over time. In order to demonstrate the state transition, the default state of the gateway was set as S1and the Snort was turned on. In the figure, Si+Snort represents the software configuration when the system was in the state Siand the Snort was activated.Afterward, the Snort detected attack events. If attack events were detected, alarm messages were sent to the end-user.Then, the state of the security gateway was changed automatically based on the security features of the end-user.

When no attack occurred, the throughput was about 16 Mb/sec. At time 5, a T.MASQUERADE attack was issued and detected by the Snort. The state of the security gateway was manually changed from S1to S4to overcome T.MASQUERADE. It is clear that the throughput was increased to around 20 Mb/sec because AES was enabled.(Note that AES is a more efficient algorithm.) At time 13, a T.RESOURCE attack was added in and detected by the Snort. The state of the gateway was manually changed from S4to S7to overcome T.RESOURCE. We used iproute2 to restrict the total traffic of the private network to be 10 Mb/sec. The throughput was further maintained around 10 Mb/sec. At time 19, when there was no attack of T.MASQUERADE, the state of the gateway was still S7. At time 25, when there was no attack belonging to T.RESOURCE and T.MASQUERADE, the state of the gateway was changed from S7to S1+Snort, which was the default state. The throughput was back to around 16 Mb/sec again. The results demonstrate how the threat-based security gateway can react to the change of system security features. When the system is in safe states, unnecessary security mechanisms are turned off to improve the system performance. However, when the system is under threats,necessary security mechanisms are turned on to protect the system. The tradeoff is the system performance.

The average number of packets analyzed by the Snort and received UDP packets. Fig. 11 shows the traffic flow in the gateway when the Snort is active. The Snort copies the incoming packets to its own buffer space and performs the inspection. When the gateway is overloaded, the Snort may have to drop/ignore packets. However, when the Snort drops a packet, the original packet still arrives on the gateway.

The average number of packets analyzed by the Snort and the received UDP packets are shown in Fig. 12. When the system was in state S5, the number of the received UDP packets increased steadily until the UDP sending rate was 35 Mbits/sec. When the sending rate was greater than 35 Mbits/sec, the number of the received UDP packets began to decrease. The reason is as follows. Before the peak, the interrupt service routine had enough CPU resources to handle the incoming packets. However, when the UDP sending rate reached 35 Mb/sec, the system was fully loaded by the incoming packets. After the peak, the number of the received UDP packets began to decrease. The reason is that the buffer of the network interface card was corked and the incoming packets were dropped. The same result could be observed when the state of the system was in state S6. The difference was that the peak appeared earlier,because the IPSec was turned on in the state S6. This phenomenon also affected the number of packets analyzed by the Snort. There was also a peak point for the number of packets analyzed by the Snort. Either in state S2or S6, the number of analyzed packets increased until the peak was reached, and began to decrease after the peak. This is because the priority of interrupt service routine is higher than that of the Snort. Therefore, when the system is overloaded, the resource is mostly consumed by the interrupt service routine and forces the Snort to drop packets without analyzing. This is the reason why the peak of the number of analyzed packets by the Snort appeared earlier than that of the number of received UDP packets.

Fig. 10. Throughput with manual state changing.

Fig. 11. Flow of packets in the gateway.

Fig. 12. Average number of analyzed packets by Snort and the received UDP packets.

5. Conclusions

This paper explores the design and implementation of a security gateway based on CC, and proposes a threat-based software-configuration architecture. The architecture serves two purposes: 1) reducing the integration and configuration overhead for the product designers and administrators and 2)providing a user-friendly manner for the end-users to configure the gateway. We identify potential threats for security gateways, derive the relationship among the threats,define the system security states, and integrate several open source security software components to demonstrate our design. The performance evaluation shows that when the system security state changes, the network throughput significantly changes. In addition, when the Snort is turned off, 60% of the CPU workload can be released. If it is not required to overcome T.AUDIT, the released CPU time can be used to increase the throughput or execute other critical operations.

[1] F. Gens. New IDC IT cloud services survey: Top benefits and challenges. [Online]. Available: http://blogs.idc.com/ie/?p=730

[2] Security Guidance for Critical Areas of Focus in Cloud Computing, Cloud Security Alliance, 2012.

[3] M. Pan, P. Li, Y. Song, Y. Fang, and P. Lin, “Spectrum clouds: a session based spectrum trading system for multi-hop cognitive radio networks,” in Prof. of Int. Conf.Computer Communications, Orlando, 2012, pp. 1557-1565.

[4] B. Schneier, “Attack trees,” Dr Dobb’s Journal, vol. 24, no.12, pp. 21-19, Dec. 1999.

[5] R. Braden and J. Postel, RFC 1009 (Requirements for Internet gateways), 1987.

[6] Y. Wu, Y. Suhendra, and H. Guo, “A gateway-based access control scheme for collaborative clouds,” in Prof. of the 7th Int. Conf. on Internet Monitoring and Protection, Stuttgart,2012, pp. 54-60.

[7] Common criteria for information technology security evaluation. [Online]. Available: http://www.commoncriteriaportal.org/cc/

[8] K. V. Dolan, P. A. Wright, and R. R. Montequin. U.S.Department Defense application-level firewall protection profile for medium robustness environments, version 1.0.Technical Report. [Online]. Available:http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA395046

[9] K. V. Dolan, P. A. Wright, and R. R. Montequin, B. Mayer,L. Gilmore, and C. Hall. U.S. government traffic-filter firewall protection profile for medium robustness environments. Technical Report. Available:http://www.dtic.mil/dtic/tr/fulltext/u2/a395046.pdf

[10] National Security Agency. Protection profile for single-level operating systems in environments requiring medium robustness, version 1.22. Technical Report. [Online].Available: http://www.niap-ccevs.org/pp/pp_os_sl_mr_v1.22.pdf

[11] T. Alexander, R. Hawkins, and T. Kelly. Security assurance cases: motivation and the state of the art. [Online]. Available:http://www-users.cs.york.ac.uk/~rda/York%20CESG%20sec urity%20case%20report%20i1_1.pdf

[12] T. Kaneko, S. Yamamoto, and H. Tanaka, “Proposal on countermeasure decision method using assurance case and common criteria,” in Proc. of the 6th Int. Conf. on Project Management, Honolulu, 2012, pp. 331-336.

[13] A network infrastructure security product for attack detection, analysis and response, version 2.11. Technical Report. [Online]. Available: http://www.commoncriteriaportal.org/files/epfiles/st_vid2013-st.pdf

[14] Common criteria for information technology security evaluation, version 2.1. Technical Report. [Online].Available: http://www.niap-ccevs.org/Documents_and_Guidance/ cc_docs/cc_users_guide.pdf

[15] M. Roesch, “Snort-lightweight intrusion detection for networks,” in Proc. of the 13th USENIX conference on System administration, Berkeley, 1999, pp. 229-238.

[16] B. Hatch and J. Lee, Hacking Linux Exposed, New York:McGraw Hill, 2003.

[17] W. Stallings, Network Security Essentials, Upper Saddle River: Prentice Hall, 2002.

[18] Pluggable authentication modules. [Online]. Available:http://www.kernel.org/pub/linux/libs/pam

[19] S. Smalley, C. Vance, and W. Salamon. Implementing selinux as a linux security module. Technical Report.[Online]. Available: http://www.nsa.gov/research/_files/publications/implementing_selinux.pdf

[20] SELinux Project. [Online]. Available: http://selinuxproject.org/page/Main_Page

[21] FreeBSD. [Online]. Available: http://www.openbsd.org/

[22] H. Welte, J. Kadlecsik, M. Josefsson, and P. McHardy.Iptables. [Online]. Available: http://www.netfilter.org

[23] Iproute2. [Online]. Available: http://snafu.freedom.org/linux2.2/iproute

[24] S. Kent and R. Atkinson, RFC 2402 (IP Authentication Header), 1998.

[25] S. Kent and R. Atkinson, RFC 2406 (IP Encapsulating Security Payload), 1998.

[26] Secure sockets layer. [Online]. Available: http://www.openssl.org/

[27] C. H. Hsu and U. Kremer, “Iperf: a framework for automatic construction of performance prediction models,” in Proc. of Workshop on Profile and Feedback-Directed Compilation,Paris, 1998, doi: 10.1.1.40.2777.

[28] Hping: Netwrok packet analyzer and reassembler. [Online].Available: http://www.hping.org/