Edita Djambazova

Magnus Almgren
email: magnus.almgren@chalmers.se

Kiril Dimitrov

Erland Jonsson
email: erland.jonsson@chalmers.se

Emerging and Future Cyber Threats to Critical Systems

This paper discusses the emerging and future cyber threats to critical systems identified during the EU/FP7 project ICT-FORWARD. Threats were identified after extensive discussions with both domain experts and IT security professionals from academia, industry, and government organizations. The ultimate goal of the work was to identify the areas in which cyber threats could occur and cause serious and undesirable consequences, based on the characteristics of critical systems. A model of a critical system is suggested and used to distill a list of cyber threats specific to such systems. The impact of the identified threats is illustrated by an example scenario in order to stress the risks and consequences that the materialization of such threats could entail. Finally, we discuss possible solutions and security measures that could be developed and implemented to mitigate the situation.

Introduction

Critical systems and networks constitute the critical infrastructure of society. The extensive use of Information and Communication Technologies (ICT) and their proliferation in many new areas, such as process control and critical infrastructures, pose substantial challenges to critical systems' security. Modern technologies are used for industrial process control and may introduce new vulnerabilities and even be the cause for incidents. On the other hand, advanced automation is widely used in critical infrastructures through industrial control systems, something that leads to new security problems. Critical infrastructures (CIs) themselves expand the scale of security threats with their complexity, large connectivity, interdependency, and possible cascading effects. The characteristics of critical systems thus highlight the need for security solutions specific to those systems and we feel that special attention has to be paid to those specific solutions.

In order to find possible solutions, we first have to identify and understand the emerging cyber threats to critical systems. One of the major objectives of the ICT-FORWARD Project 3 was to outline the critical threat areas where research efforts have to be invested and countermeasures have to be devised. After a series of discussions with domain experts from industry, academia, and government organizations, a survey of emerging and future security threats was prepared [START_REF]ICT FORWARD Project: Deliverable D3.1: White book: Emerging ICT threats[END_REF].

This paper summarizes some of the identified security threats to critical systems and discusses the open research problems in applying security mechanisms to such systems and in developing new solutions.

Critical System: Modelling and Specifics

In our work, we used the following definition of a threat:

Definition of a threat: A threat is any indication, circumstance, or event with the potential to cause harm to an ICT infrastructure and the assets that depend on this infrastructure.

Our version is related to a variety of other definitions that exist in the literature, such as the ones provided by ISO/IEC and the EU Green Paper for Critical Infrastructure Protection [START_REF]Commission of the European Communities: Green Paper On a European Programme for Critical Infrastructure Protection[END_REF]. In both these cases, a threat is described as an event, circumstance or incident that has the potential to cause destruction or, more generally, harm to the system or organization that is exposed to the threat. We adapt our definition to explicitly refer to ICT infrastructures and assets, as this is the scope of the FORWARD project. However, we observe that the definition is reasonably general to accommodate a wide range of possible threats and scenarios.

In order to be able to focus our efforts, we further developed a model of a critical system to help distinguish the most interesting and pressing security threats.

Modelling a Critical System

In Fig. 1, a generic ICT system is shown. It is defined as any system that delivers service to a group of users. Such a system is subjected to a number of threats, which may influence the service delivery to the users. We could leave the system box as a black box in the diagram. A ranking of the most important emerging threats can still be performed on such a black-box system. However, by knowing more about the system box, we can better judge what types of emerging threats will be the most severe and therefore important. The paper focuses on the ICT that supports critical infrastructures. Understanding the emerging threats to such systems is important because the consequences can be very dire. In our study, we consider the system from Fig. 1 to be a critical system.

Definition of a critical system: We define a critical system (CS) to be a system that delivers a critical service to a group of users. A critical system consists of a traditional critical infrastructure or a critical application and supporting Information and Communication Technology.

More specific definitions of a critical system can be found elsewhere in the literature. Here, we by purpose refrain from a very specific definition. The criterion of criticality may change over time and each professional group that discusses the issue has their own definition. By presenting a general model with the important salient properties found across many critical infrastructures, we can focus on the issues that will remain relevant in the future in our discussions.

In Fig. 2, we have expanded the system box shown in Fig. 1. Assuming a critical service delivery, we can further detail the structure of the system box based on the model of such critical systems.

Interface Service

Delivery

Threats

Critical System ICT (support) "Security" "Safety" Users Fig. 2. A model of a specific system for critical services.

We would like to emphasize that there are four boundaries in Fig. 2: the outer system boundary, the two inner boundaries to the critical system (the dashed line) and to the supporting ICT system (the flat line), and the boundary (interface) between the critical system and the ICT system. The threats can then be divided into four groups according to the boundaries shown in Fig. 2.

1. Threats targeting the whole CS-ICT. 2. Threats targeting the interface between the CS and ICT. 3. Threats targeting the ICT part. 4. Threats directly targeting the CS.

We do not consider threats that directly target the critical system (4), in that it is a critical infrastructure. Such threats are already discussed and accounted for in other working groups in the EU and elsewhere. The focus here is on cyber threats, often directly targeting the ICT structure by their very nature. Thus, the focus is on problems related to the supporting ICT infrastructure, that is (1) -(3) in the list above. We would like to emphasize (2) in the list, as the particulars of this interface may be prone to many security vulnerabilities.

Specifics of Critical Systems

In order to identify the specific security problems in critical systems we developed the described model of a system for critical services. Based on that model we can outline the security specifics of critical systems and why the threats to critical systems and the respective countermeasures need a different approach compared to that of more traditional systems. Even though the emerging and future cyber threats seem common for all ICT applications, there are specific issues regarding the sub-domain of critical systems. There are many differences compared with a regular ICT system. In a regular system, there is no ICT-CS boundary. A regular ICT system is not normally connected to a system governed by physical laws. This implies that a regular ICT system does not have the same constraints in terms of timely input of data or a similar limitation on the types of interfaces available. No critical service is delivered by a regular system. We divided the system box in Fig. 2 into two parts: one part being the actual critical system (or critical infrastructure) and the second part being the supporting ICT infrastructure. In some cases, the critical system is of an ICT nature; in other cases it is a traditional process control system. Some of the specific characteristics of a critical system as shown in Fig. 2 are described in more detail below. Critical service. A critical system is delivering a critical service to users, which has to be preserved and maintained even in the case of cyber attacks. The disruption of operation of such systems will lead to severe consequences.

Complexity and availability. The complex architecture of critical infrastructures hampers investigation and assessment of the impact of threats. Further complicating the issue is that many of these systems need to run around the clock all days of the year, meaning that a system cannot simply be brought off line for testing or security update.

Many and different interfaces.

There are various types of interfaces to a critical system, since it is the result of combining several independent systems and they differ greatly in many ways. This affects the vulnerability of the system as a whole. Critical systems have specific and diverse relations with ICT systems and between internal systems. Further, the system mixes interactions of human operators (slow response) with computer services (fast response) through a variety of interfaces. Many times these interactions are rather complicated in that the access modes vary and the time frames between the parts are widely different.

Interdependency issues (long chains of dependencies). One of the important issues for critical infrastructures is the interdependencies among the infrastructures. There may be long and complex dependency chains. An attack against any of the services may cascade unpredictably through the system. In [START_REF] Rinaldi | Identifying, understanding, and analyzing critical infrastructure interdependencies[END_REF], the role of ICT in critical infrastructures is defined with the term cyber interdependency. An infrastructure has cyber interdependency if its state depends on information transmitted through the information infrastructure.

Data is important. Almost always, data is important [START_REF] Center | Emerging cyber threats report for[END_REF]. This is especially true for financial services. It is also true for other types of systems, such as air traffic control, where data are underlying even the simplest decisions.

An underlying physical process. Many times, a physical process is underlying the critical system. The system has to observe time constraints which are hard to combine with certain security measures. The critical system may be part of a control loop in the physical system. Thus, critical systems have physical and possibly a very complex interaction with the environment. Security functions integrated into the critical system must not be allowed to compromise the normal functionality of the critical system [START_REF]Draft guide to industrial control systems (ICS) security[END_REF].

Real-time constraints. The connection of a CS to the physical world implies that critical systems are often real-time, as they are determined by physical systems. They may also be considered real-time in that they deliver a critical service that should not be interrupted. Depending on the specific system, the term "real time" may imply very different time scales -from seconds to days. Critical systems are generally time-critical and have to respect some acceptable levels of delay and jitter dictated by the individual installation. Some systems require deterministic responses. This may mean that they have to observe time constraints, which are hard to combine with certain security measures. High throughput is typically not essential to CS. In contrast, ICT systems normally require high throughput, and they can typically withstand some level of delay and jitter [START_REF]Draft guide to industrial control systems (ICS) security[END_REF].

Many owners, policies, and domains. Often, a critical system has many owners and this fact is emphasized through the deregulatory nature of policy decisions taken lately. The mixed ownership affects the system as a whole, in that there are artificial interfaces between the parts and each part may be governed by its own security/safety policy. For example, data is often sent over both propriety networks and the Internet.

Trade-off between safety and security. Based on the tradition of safetycritical systems, safety is and has been emphasized over security. For example, passwords are sometimes avoided by intent; it is reasoned that sometimes it is very important to immediately be able to control a process (to stop it from reaching a critical point), and a password would only slow down the operators. Thus, no regards to integrity or access control exists in such a system and such features cannot easily be added later, or added to one part of the system if another part lacks such support.

Mismatch of practices between CS and ICT systems. Operating systems and applications in critical systems may not tolerate typical IT security practices. Legacy systems are especially vulnerable to resource unavailability and timing disruptions. Control networks are often more complex and require a different level of expertise (e.g., control networks are typically managed by control engineers, not IT personnel). Software and hardware are more difficult to upgrade in an operational control system network. Many systems may not have desired features including encryption capabilities, error logging, and password protection [START_REF]Draft guide to industrial control systems (ICS) security[END_REF].

The human factor plays a pivotal role for proper operation. The human being is considered to be the weakest point in a critical system. The roles include operators in control rooms, engineers taking technical decisions, managers and decision-makers for future strategy development. On the other hand, insiders with experience of and knowledge about the critical system could be a serious threat as seen, for example, in [START_REF] Noonan | The National Infrastructure Advisory Council's final report and recommendations on the insider threat to critical infrastructures[END_REF].

Example Scenario

We illustrate with an example scenario how the specific characteristics of critical systems described above influence information security of these systems. Although the example scenario is completely fictional, it was considered by domain experts as being realistic in that it shows some real or emerging threats for which no ready solutions are available.

The example scenario takes place on an oil platform. That domain, i.e. the oil platform, is specifically chosen because it embodies many of the problems related to critical systems' security highlighted by domain experts, such as the trend to increase efficiency through greater automation and more remote operations. The organizational structures are becoming more complex and there is an increased reliance on computer systems that are vulnerable to malfunctions and malicious attacks. The introduction of ICT opens up the previously isolated critical infrastructures to the information infrastructure and exposes them to threats.

The antagonist in the scenario is a single person with strong environmental ties who wants to make a "statement" about the dangers of the current oil dependency by shutting down an offshore drilling platform. Using his skills and some internal knowledge about the system, he manages to reach the main functionality of the platform. However, instead of stopping the production of oil on the platform, his attack causes a large oil spill with a severe environmental impact. Below, we give a brief overview of the attack, which is further elaborated in [START_REF]ICT FORWARD Project: Deliverable D3.1: White book: Emerging ICT threats[END_REF].

The Attack and Its Consequences

In order to reduce costs and increase effectiveness, oil platforms are connected in a bigger infrastructure involving remote control centers and a number of expert nodes in case problems occur. The antagonist in the example scenario takes advantage of such a trusted expert node by installing malicious software that does not spread actively, but propagates only when the victim host initiates its own connection to this server, thus working in much the same way as current malware in the web domain. The malicious server software is tailored towards the victim environment. The antagonist has an insider's view (from his previous work on the oil platform) and knows its weak points, i.e., vulnerable routers that can be corrupted, as well as the means to grant himself sufficient authorization for his goal of shutting down the oil production of the platform (known passwords). He manages to reach the control network and connects to a critical console. At that point, the safety systems on the platform fail and thousands of tons of oil flow into the ocean.

Related Threats

In Sect. 4, we go through the threats against critical systems in detail. Here, we highlight the threats particularly important to the execution of the attack described in the scenario. Issues related to the use of commercial-off-the-shelf components 4 and retrofitting security to legacy systems are fundamental to this scenario. Some of the systems are simply vulnerable to "normal" malicious code, and the antagonist uses this fact to download his code onto the offshore platform. The antagonist then uses his detailed knowledge of the system (the insider threat) for his next step in the attack. As safety takes priority over security in many industrial domains, we emphasize the non-existing password policies at the offshore platform. The domain is complex and issues such as unforeseen cascading effects and other problems due to scale also work in favor of the antagonist. Even though not explicitly mentioned, the human factor probably played a role in this scenario, and better designed user interfaces might have alerted the operators in time to the failure of the safety system. Finally, we would like to point out that in this story the antagonist was never brought to justice; legacy systems, where security has not permeated the design, seldom have the necessary sophistication for allowing advanced forensic analysis.

Discussion

Some of the discussed related threats are common to all ICT systems and there are countermeasures developed to overcome them. The problem with critical systems is that the security techniques cannot always be implemented directly. In most cases, they need to be modified according to the timing and performance requirements of the critical system. Even if tailored to the system's constraints, security mechanisms may still not work properly, since it is almost impossible to test them before implementation, because critical systems' operation should not be interrupted.

More interesting for our study, however, are those security threats that are specific to critical systems. Some of them are known to the professional community and there are solutions proposed and implemented. Other threats are just beginning to appear with the introduction of modern technologies in critical systems and the new, not studied or poorly understood, interactions of the CS and the ICT. We will focus our discussion in the next section on these specific security threats.

Emerging and Future Threats to Critical Systems

Based on the characteristics of critical systems discussed in Sect. 2.2, we have identified areas where security threats might grow in the future and where new solutions should be sought for. The identified threats to critical systems summarize the views of many experts both from the domain of information security and industrial automation/critical infrastructure protection, and reflect the general vision that critical systems can become an attractive target for cyber attacks and that the cross area of ICT and CS is an open field for security research. Fortunately, there are not yet many (publicly known and documented) examples of successful attacks to critical systems, but the present experience shows the clear need for effective and specific countermeasures in this domain.

In the following subsections, we describe the identified cyber threats to critical systems and discuss some of the possible solutions. We focus on the ones relevant to the described scenario, but also include other important threats to critical systems. The full list of identified threats can be found in [START_REF]ICT FORWARD Project: Deliverable D3.1: White book: Emerging ICT threats[END_REF].

Use of Commercial-Off-The-Shelf Components

Threat. The use of Commercial-Off-The-Shelf (COTS) components and systems can make any system, but especially a system connected to a critical infrastructure, vulnerable to a variety of attacks. There are two problems with COTS components. The first problem is related to hidden functionality and outsourcing, as described in Sect. 4.9. The designer has no real control over the product he is introducing into his system. The COTS product is designed (and manufactured) elsewhere and the documentation can be incomplete or even faulty. There is no guarantee that there is no hidden functionality. Nor can its absence be verified, as discussed in Sect. 4.9. The second problem is related to the generality of the COTS systems versus the sometimes very specific requirements of the environments where they are used. It is this second problem we describe below.

To reduce cost and time for design, the use of COTS systems and components in critical applications seems attractive and will thus continue. COTS systems are often used in industrial automation process-control systems because they are cheaper to deploy and may include more functionality than a custom-built system. However, there is a gap between the priorities (safety versus cheap COTS components) and this gap leads to new challenges to security and reliability. For example, COTS systems are prone to "normal" virus infections and attacks, so attackers do not need to specifically tailor their malicious code to these systems. There will be remote access through connections to the Internet, leading to new threats. Response management is needed, coping with incidents -recovery, isolation, and restoring the system to a working state. Forensics should also be applied to determine the responsibilities.

There are some projects (e.g., DEAR-COTS [START_REF]DEAR-COTS project homepage[END_REF]) where COTS components are applied to design distributed computer-controlled systems. They are organized using redundancy and design diversity to make the system dependable and secure. Some of the issues addressed in DEAR-COTS are the use of emerging information technologies to cope with heterogeneity issues while providing a dependable user-friendly man-machine interface.

Possible solutions. No good solution exists, but various work-arounds, such as using COTS systems with some fault-tolerant approaches (replication, diversity approach); applying COTS components in non-critical areas only; introduce and manage heterogeneity; or use of a compact and trusted application base.

Another possible approach is to introduce semantic technologies, i.e., to take a holistic approach to security with semantic technology (e.g., service-oriented architecture). Physical components should be classified, as they have to be defined from the basis. We have to identify and decide what and how to protect, i.e., an assessment of the assets to be protected has to be done.

Retrofitting Security to Legacy Systems

Threat. Security can seldom be retrofitted to an existing system, but due to economical constraints this is sometimes considered necessary. Most critical systems are created to provide a certain functionality. Safety and control characteristics are the natural focus of such systems. Thus, applying security measures afterward instead of incorporating them in the original design could constitute a problem. For example, the in-vehicle network has historically been a closed environment responsible for the control and maneuverability and safety of vehicles. The in-vehicle network has been designed to provide this functionality and security has not been part of the design. In the connected car of the future, external communication is allowed to interact with the previously isolated in-vehicle network. Thus, the in-vehicle network is opened up to potential attacks. Designing security solutions for the existing in-vehicle network creates difficulties as realtime constraints, protocol and hardware limitations need to be considered. In addition, security solutions must not interfere with the functionality provided, e.g., by imposing delays as this could have serious consequences from a safety perspective. Due to economical constraints it may not be possible to redesign the entire system with security in mind. Either the best possible security solutions considering the existing system are developed and applied and as a result possibly degrading the system's performance, or good enough solutions are applied to ensure that the existing system's functionality is left unaffected.

Possible solutions. The short-term solution could be a better understanding of how to best adapt security to such systems. Experts recommend [15] to study all connection points in the network, understand what traffic has to flow from the old networks into the business network. The information should be flowed through a more modern server, which can be better protected and analyze the traffic in real time. In general, analyzing the current architecture in detail and cataloging all software running on the control networks help discovering the weaknesses of the network and strengthening its security.

New architectures can be developed where security permeates all parts of the design for the long term. Migrating to new technologies, however, takes time, while security is needed at the present moment and this reality could influence the process of introducing new and more secure technologies.

The Insider Threat

Threat. A definition of the "insider threat" is given in [START_REF] Noonan | The National Infrastructure Advisory Council's final report and recommendations on the insider threat to critical infrastructures[END_REF]. This threat lies in the risk that a trusted employee betrays his employer by conducting some kind of malicious activity. Insider betrayals comprise a broad range of actions, from theft or subtle forms of sabotage to more aggressive and overt forms of vengeance, sabotage, and even work place violence. Insider activities cause financial losses to organizations, have negative impacts on their business operations, and damage their reputation.

In [START_REF] Noonan | The National Infrastructure Advisory Council's final report and recommendations on the insider threat to critical infrastructures[END_REF], it is argued that the nature and seriousness of the threat requires a combined view of physical and IT security systems and policies. Although physical and cyber threats from insiders manifest differently, the concepts are quickly converging as many potential attacks bear characteristics of both physical and IT sabotage, fraud, or theft.

Some interesting results from a study on the insider threat [START_REF] Keeney | Insider threat study: Computer system sabotage in critical infrastructure sectors[END_REF] show that a negative work-related event is most likely the trigger to most insiders' attacks. Furthermore, the majority of insiders planned their activities in advance. An observation is that the majority of insiders were granted privileged access when they started work, although less than half of the insiders had authorized access at the time of the incident. An interesting point is that both unsophisticated and relatively sophisticated methods for exploiting a system's vulnerabilities were used. Remote access was used to carry out the majority of the attacks. Many times, the insider attacks were only detected when there was a noticeable irregularity in the information system or when a system became unavailable.

Possible solutions. Effective strategies for discovering an "insider" is an open research question. The recommendations from [START_REF] Noonan | The National Infrastructure Advisory Council's final report and recommendations on the insider threat to critical infrastructures[END_REF] include low-cost, easily implemented policy solutions for near-term effect: education and awareness, employee screening, technology policy, information sharing. In the long-term aspect, further guidance, findings, samples, and tools are needed. Some solutions for IT systems/cyber security could be the following: to use integrated IT and physical security system tools to identify rule violation patterns for potential insider threat behavior; to use dual protection access technologies (e.g., biometric, key card or encryption key verification); to use dual control access mechanisms to protect high-value systems and processes; to manage access, integrity and availability of computer systems (e.g., identity management system). Control over creation and termination of user and administrator accounts and maintaining security/access rights should be done by segregation of duties. Using data loss prevention tools could help stopping the leakage of information outside the network and can be a measure to detect an insider activity.

Safety Takes Priority over Security

Threat. In the domain of critical systems, both safety and security are important but in certain scenarios, safety takes priority. Based on the tradition of safety-critical systems, safety is and has been emphasized over security. Giving priority to safety, however, is not just a traditional vision. It is justified by the potential losses after a safety incident. Safety of critical systems is important because of critical system's interaction with the physical world and the possible risks of that interaction. Security is usually considered being of less importance compared to the major safety issues of the actual CS. With the extensive use of ICT in critical systems, however, security should be considered more seriously, since security and safety are very interrelated. Problems with security can lead to safety issues. Thus, a security attack can lead to a safety problem and endanger lives.

Complicating the issue is the fact that control system professionals are often not aware of security risks, since these are not considered part of the normal system operation. The emphasis in control systems is on safety and availability aspects. On the other hand, IT security specialists use known techniques from a normal ICT system to introduce security, but may be missing important safety and control characteristics of the specific CS, as discussed in Sect. 2.2 and Sect. 4.2. This lack of mutual understanding between the control and security communities makes the overlooking of security a problem. Control specialists and even the management personnel of organizations are security-unaware and tend to neglect security measures and tools. Sometimes people with little experience or with different primary tasks operate the supporting IT system and they are more prone to do mistakes or ignore security alerts.

Possible solutions. As we stated previously, the understanding that safety and security are interrelated is of very high importance and will lead to improvement in overall security and safety policy. A better understanding of the domain for the IT security experts is necessary. On the other hand, the control community should be aware of the important role of security measures to safety. Work should be done on changing the mindset. Some simple technical measures could be to document changes done to the system in order to facilitate the implementation of security tools where they are most needed; keep the control traffic off the business network; document all the software installed on the network, etc.

Unforeseen Cascading Effects

Threat. Interconnected systems and networks are difficult to model properly and interdependencies between them can lead to cascading effects that are hard to foresee. This is due to the inherent complexity of the connected systems. It is claimed that nobody really understands a network such as the Internet anymore, nor even many smaller interconnected, heterogeneous networks that have been deployed over the past decades. Further, testing is virtually impossible due to the complexity and scale. In particular, testing is often impossible when the system is connected to a critical infrastructure with real-time requirements.

An important class of cascading effects occurs when, e.g., some section of the Internet is attacked or overloaded to the point of service denial and another (perhaps critical) system depends on that section. Even though the attack was not directed against the critical system per se, it is affected indirectly.

It is clear that dependencies are responsible for unforeseen cascading effects. Unfortunately, dependencies in large networks and systems are very difficult to understand due to their complexity. Even though system complexity is an issue in many areas, some factors related to critical systems make the issue of the complexity extra severe in such environments. First, due to the deregulation of markets, critical infrastructures are often run by different organizations that need to cooperate. These organizations are seldom a single unit, but they are comprised by many smaller units as virtual organizations. A complicating issue is then that part of the system may be governed by proprietary protocols while others use open standards. Different system owners may not trust each other, and different parts of the system may be governed by their own safety/security policies.

Possible solutions. What we need are new, more appropriate modelling tools and an overall better, probably structured and hierarchical, architecture with a security baseline. Removing the human from the loop and introducing automation may help. On the other hand, the seemingly intuitive action scripted in automated systems might be completely wrong in certain systems and lead to large problems. For essential services, it is important that dependencies should be tracked from the design phase onwards.

User Interface

Threat. The human plays various roles in control systems at all levels of their operation. For example, in a real critical system, it has been estimated that in some situations, human reliability can fall from 10 -4 to 10 -3 , whereas a system's reliability is maintained at 10 -9 . Incorrect interactions with the system, handling other operator errors, and complex interdependencies as described above make it difficult to correctly work with the system. For these reasons, the human being is a serious factor when considering overall system security.

It is imperative to wrap new solutions to upcoming and even existing threats in understandable and discreet user interfaces to make sure they are properly used. The user information overload is a constant problem that is very likely to persist for a long time and hinder solutions for security problems to catch, even if they already exist.

Possible solutions. The education and training of personnel working in critical systems is a constant task that can help maintain an up-to-date knowledge on systems and networks. The awareness of security risks should be raised. There are many bad practices (e.g., running un-patched versions of software, using default configurations and passwords, etc.) that could easily be removed by making people understand the role of security measures. A sound and evolving security policy in the organization is needed to mitigate security risks. There are approaches to model the user (cognitive modelling) and user-interactive properties that could be used to improve the interaction of the users with the systems.

Another approach is to model and design the systems in such a way that they are more easily comprehended and understood. This would include, e.g., structural design, encapsulation, intuitive interaction interfaces, etc.

Sensor Networks

Threat. The convergence of control with communication and computation will make sensor networks the new dominant "computing class." This class will provide the ability for large numbers of interconnected sensors, actuators, and computational units to interact with the physical environment. This computational shift is going to bring a big shift also on computer security issues.

One problem is that small sensors require a means to communicate. This is typically a wireless connection. However, in addition to the security concerns of wireless networks in general (discussed in Sect. 4.8), wireless sensor networks have a number of additional issues. For example, the nodes in sensor networks are in general very limited in terms of battery, storage, and computational power. Therefore, strong cryptography and other general security tools are of limited use, if at all available. An attacker can have much more powerful hardware than the nodes being attacked. Sensor networks also typically reside in unattended environments where an attacker can physically destroy nodes, add malicious nodes or in other ways tamper with the hardware of the network. It is usually hard to distinguish the natural failures of the nodes in a sensor network from a malicious attack where nodes are deliberately destroyed.

There are many venues of attacking sensor networks [START_REF] Chan | Security and privacy in sensor networks[END_REF][START_REF] Perrig | Security in wireless sensor networks[END_REF], including the following: snooping information, inserting false or misleading information, jamming radio channels, making nodes run out of battery by never letting them sleep, giving the impression of phantom nodes that do not exist, giving the impression of connectivity that does not exist, making messages go through an attacking node that can selectively drop messages from the system.

Possible solutions. In summary, we consider the following three approaches worth further pursuit in the context of sensor devices.

-Autonomic solutions where the system will continuously evolve and control its security. -Solutions that will mask subsystem takeover.

-Combining sensor information with physical information for verifying certain operations.

Wireless Communications in Industrial Environments

Threat. Wireless communications offer many convenient advantages compared to traditional wired communications within the industrial domain, such as: operator mobility, safety by enabling remote access to noxious environments, access security for visualization and optimization, and the immediate benefits of their deployment [START_REF] Berra | Emerson first to offer WirelessHART automation products[END_REF]. Today, wireless communications are not yet widely used in practice in industrial environments. Most plants are only considering them for information gathering in the form of measurements, but not for closed-loop control [START_REF] Kagan | Interview about wireless devices adoption in the industry and the future trends[END_REF]. Based on their advantages, however, a greater adoption of wireless communications in industrial control can be expected, thus with an overall growth in their market share. Experts from WINA and ISA [START_REF] Hoske | Industrial wireless implementation guide[END_REF] predict that within 10 years, even critical control communications will be wireless.

Recently, following the WirelessHART and ZigBee Alliance announcements and after approving the SP100 standard for industrial wireless communications by ISA, there is already use of wireless communications in industrial and even critical applications. Despite this, the single industrial wireless standard ISA-SP100.11 does not give enough guarantees for dependability and security to critical systems and applications.

One main security aspect of the wireless communications in general follows from the unbounded nature of radio frequency propagation. The perimeter of a wireless network cannot be limited and controlled as can be done with a wired network. There are reflected signals, which find their way out of buildings. These dispersed signals could be detected by motivated attackers that could then attempt to interfere with them if they are in physical proximity of the facility. Thus, traffic can be passively captured and an attempt to penetrate the network could be made with the aim to reach other connected enterprise networks.

Possible solutions. The first and main consideration when addressing security of industrial wireless communications is the conformity to the ISA-SP100 Usage Classes. Many useful and detailed recommendations for securing wireless networks are given in [START_REF] Masica | Recommended practices guide for securing ZigBee wireless networks in process control system environments[END_REF].

The IEEE 802. 15.4 standard [12] gives some recommendations how to use guaranteed transmission mode and secure mode. It is shown that cryptographic randomization, agility, and diversification, in a game-theoretic context can provide the tools for building resilient wireless networks against both external and internal attacks. Such techniques can even allow the identification of internal attackers.

Hidden Functionality

Threat. One threat of paramount importance is that of hidden functionality in systems, and in particular, in software. Hidden functionality may comprise almost any functionality, but common examples are back doors, i.e., secret and undocumented entries to a system, and Trojan horses. Such functionality can be introduced into the system by accident, but the most common reason is that somebody, for example, the designer or maintenance engineer, enters this functionality for his own, in many cases malicious, purposes. In other cases, it is introduced for commercial reasons. Regardless of its purpose, the idea is that this extra hidden functionality is not known by the authorized user and the rightful owner of the system.

It is evident that such functionality presents an enormous threat. Not only is it unknown, but it is also put into the system in such a way that it is very hard to discover. Furthermore, this functionality is uncontrolled and can lead to a large range of very detrimental impacts on the system. As an example, in the U.S., the possibility of malicious hardware used for espionage, or even for terrorist activities is considered an emerging threat. Most hardware fabrication is nowadays outsourced. Circuits can be added on chips at the fabrication plant to offer a back door to potential attackers, or perform some other action. It is technically very hard for vendors to detect whether the produced hardware follows their design to the letter.

Possible solutions. It is very difficult to find solutions to this problem. Any type of remedy would imply the ability to prove, or at least make plausible, that no such functionality exists. Unfortunately, there are significant theoretical obstacles in proving the absence of something. It is certainly possible to find and remove such functionality, but to verify that there is none left after removal is extremely hard. Still, the only possible solution would be to develop better validation and verification methods and tools. A methodology for measuring security could be one of them as well as runtime detection of any unknown (malicious) functionality. In the short term, potential solutions to this problem might involve the use of secure and trusted fabs for critical hardware, such as the one used for aviation and military equipment.

Next Generation Networks

Threat. Recently, there is a general trend for carrying multimedia in the field of electronic communications. Under the pressure of the Internet, on the one hand, and because of the increased service requirements of end users, on the other, some telecommunication companies are migrating to the so-called Next Generation Networking (NGN).

NGN is a broad term describing some key architectural modifications in the telecommunication core and access networks that have been deployed in the last five years. The main goal of NGN is that one network transports all information and services (voice, data, and multimedia) by encapsulating them into packets. NGNs are commonly built around the Internet Protocol and therefore the term all-IP is also sometimes used to describe the transformation towards NGN [START_REF]Wikipedia: Next generation networking (NGN all-IP)[END_REF].

The openness and easy access and usage of NGN lead to an increased number of vulnerabilities and extreme attention to security measures must be paid. Recently, many security experts bring up the attention to the specific vulnerabilities of the NGNs. The most exploited among them are [START_REF] Fonash | Cybersecurity & Communications (CS&C) overview, Technology trends, & challenges[END_REF][START_REF] Kim | An efficient IP traceback mechanism for the NGN based on IPv6 Protocol[END_REF]:

-Knowledgeable end users can gain access to the control plane of "all-IP" networks like NGNs. -Large number of external connectivity points (and from any other point/site of the Internet) -Shared core network among several NGN operators (the possibility of occurrence and the variety of vulnerabilities is higher) -Malicious users can manipulate the traffic more easily as no physical access is required.

More than 32 fundamental vulnerabilities in NGNs are described as a result of the systematic assessment of NGN vulnerabilities [START_REF]NSTAC: Next Generation Networks Task Force[END_REF].

Possible solutions. Security mechanisms on open packet networks will be very different from those of legacy telecommunication services in many aspects. In legacy networks, being circuit-oriented vertical networks, much policy management was "built into" the integrated service, comprising all aspects of the network. Security will need to be addressed differently in the NGN. The design and implementation of NGN need to meet complex requirements, which complicates its security architecture. As a consequence, it is difficult to use a single standard to define it [START_REF] Zhimeng | Security technologies for NGN[END_REF]. As a present security solution it was recommended in [START_REF] Yuxi | IP Bearer Network for NGN[END_REF] to use multiprotocol label switching (MPLS) virtual private networks to construct an NGN virtual private bearer network, and thus logically separate NGN services from traditional data services. As telecommunications companies already deploy NGNs in different forms (e.g., Vivacom in Bulgaria, KPN in the Netherlands, Ireland [START_REF]Wikipedia: Next generation networking (NGN all-IP)[END_REF], British Telecom's 21CN), this is an important problem.

Conclusion

Although information security, as a fast developing research direction, offers new solutions to counter cyber threats, there are domains where the existing security techniques cannot be applied directly. In some areas, the necessity to protect systems from cyber attacks is just beginning to be realized. Even though there is a rising interest and concern of the lack of cyber security of critical systems, the research in this area is still scattered and somewhat isolated to particular domains. A more thorough understanding of the risks and the need for new security solutions that focus on the emerging threat areas and the specific characteristics of critical systems is necessary. The paper demonstrates some of the problems in implementing security in critical systems. The identified and described threats to these systems indicate the research areas where new security solutions are needed. Current practice shows that known IT security measures should be implemented considering the specifics of critical systems. Those measures should respect time constraints, continuous operation mode of these systems, their requirements for availability and safety, their heterogeneity, complexity, and interdependence, etc. New, possibly holistic, solutions should be developed, e.g. building in security at design level, applying service-oriented architecture, organizing systems according to the "defense-in-depth" strategy, resilience approach to their design and operation.

We have to note that critical systems encounter many different security problems that are a mixture of technological, psychological, and social issues. This calls for interdisciplinary approaches to be adopted to address the diverse threats to critical systems.

Fig. 1 .

 1 Fig. 1. A model of a generic ICT system.

The threat names are printed in italics.

This work was supported by the EU FP7 ICT-FORWARD Project under Grant agreement no. 216331/14.09.2007 3 http://www.ict-forward.eu


Ludovico Cavedon
email: cavedon@cs.ucsb.edu

Christopher Kruegel

Giovanni Vigna
email: vigna@cs.ucsb.edu

Are BGP Routers Open To Attack? An Experiment

The BGP protocol is at the core of the routing infrastructure of the Internet. Across years, BGP has proved to be very stable for its purpose. However, there have been some catastrophic incidents in the past, due to relatively simple router misconfigurations. In addition, unused network addresses are being silently stolen for spamming purposes. A relevant corpus of literature investigated threats in which a trusted BGP router injects malicious or wrong routes and some security improvement to the BGP protocol have also being proposed to make these attacks more difficult to perform. In this work, we perform a large-scale study to explore the validity of the hypothesis that it is possible to mount attacks against the BGP infrastructure without already having the control of a "trusted" BGP router. Even though we found no real immediate threat, we observed a large number of BGP routers that are available to engage in BGP communication, exposing themselves to potential Denial-of-Service attacks.

Introduction

The Border Gateway Protocol (BGP, [START_REF] Rekhter | A Border Gateway Protocol 4 (BGP-4)[END_REF]) is the routing protocol at the core of the Internet. BGP is employed to perform routing decision between Autonomous Systems (ASes), which are separate administrative domains. Directly connected Autonomous Systems establish peering relationships. A peering relationship implies full trust: one router will accept and use for routing any network prefix advertised by its peer routers (unless administratively forbidden).

This full trust between peers is one of the weaknesses of the protocol. In fact, unconditional acceptance and propagation of routing information coming from other peers might render the whole Internet routing stability vulnerable to malicious, compromised, or just misconfigured BGP routers. According to Mahajan et al. [START_REF] Mahajan | Understanding BGP misconfiguration[END_REF], BGP misconfiguration is quite common (up to 1% of the global BGP table entries), although only 4% of these misconfigured announcements result in disrupted connectivity. Nevertheless, wrongly advertised prefixes sometimes gave place to well-known catastrophic routing incidents. For example, Pakistan Telecom disrupted worldwide routing to YouTube's web site in an attempt to prevent access to that web site in Pakistan [START_REF]RIPE NCC: YouTube Hijacking: A RIPE NCC RIS case study[END_REF]. Another example is the AS7007 incident [START_REF] Bono | Explanation and Apology[END_REF], where the wrong propagation of routes caused an Internet-wide blackout. In addition, an AS might generate malicious BGP prefix advertisements in order to hijack some IP addresses and use them as not-yet-blacklisted sources of spam, as reported by Ramachandran and Feamster [START_REF] Ramachandran | Understanding the network-level behavior of spammers[END_REF] and analyzed by McArthur and Guirguis [START_REF] Mcarthur | Stealthy IP Prefix Hijacking: Dont Bite Off More Than You Can Chew[END_REF].

Previous literature has been investigating possible areas of attack against the BGP protocol (see, for example, [START_REF] Nordström | Beware of BGP attacks[END_REF] and [START_REF] Butler | A survey of BGP security issues and solutions[END_REF]). Pilosov and Kapela [START_REF] Pilosov | Stealing The Internet[END_REF] also gave a live demonstration about the feasibility of an unnoticed Man-In-The-Middle (MITM) attack performed by means of BGP prefix hijacking.

Much work has focused on finding solutions to the above-mentioned attacks. For example S-BGP ( [START_REF] Kent | Design and analysis of the secure border gateway protocol (S-BGP)[END_REF]), soBGP ( [START_REF] James | Extensions to BGP to support secure origin BGP (sobgp)[END_REF]), and IRV ( [START_REF] Goodell | Working around BGP: An incremental approach to improving security and accuracy of interdomain routing[END_REF]) are BGP extensions aimed at authenticating prefix origins and updates. However, most of the proposed solutions imply a heavier load on the CPU and memory of routers in order to perform cryptographic operations. Moreover, changes to the protocol need to be backward compatible, as it not possible to replace all the routers software at once. For these reasons, adoption of the defense techniques proposed so far has been extremely slow.

Almost all of the successful attacks against BGP considered in the literature require the attacker to have control of a BGP router. This condition, however, is not easy to achieve and maintain, while having a malicious behavior. In fact, the attacker has to demonstrate the need to become an AS (i.e., at least being a multi-homed network), or must be supported by the complicity of an ISP (which is willing to accept the risk of damaging its own reputation), or needs to compromise an existing BGP speaker (but router exploits are rather rare), or requires to hijack an existing TCP connection between two BGP routers (which is very hard to carry out).

However, there is an unanswered question: Is it possible to mount attacks in order to disrupt inter-domain routing without already having the control of a "legitimate" BGP router? In this work, we perform a large-scale study to explore the validity of this hypothesis.

First, we tried to identify how many BGP speakers were reachable on the Internet, by performing a SYN scan for TCP port 179 over a very large part of the Internet address space (about 73%). The scan was performed between December 2008 and January 2009. 2.2 million hosts (0.8‰) answered to our SYN packets, identifying an equal number of processes listening on that TCP port. Clearly, there is no implication that those hosts were BGP speaker. Restricted to this subset of IP addresses, two additional scans (performed in February 2009 and February 2010) went further in the connection negotiation, aiming at detecting whether the counterpart was willing to continue after a 3-way handshake and even establish a BGP session.

In the rest of this paper, we present our findings and we describe the issues we encountered with such a large-scale scanning experiment.

The Border Gateway Protocol (BGP) is specified in RFC 4271 [START_REF] Rekhter | A Border Gateway Protocol 4 (BGP-4)[END_REF]. BGP is a path-vector routing protocol used across Autonomous Systems (ASes) on the Internet. BGP routers exchange information about reachable destinations (under the form of CIDR IP prefixes) with an associated path to traverse in order to reach them. The information collected by the BGP process is employed to perform routing decisions between ASes. In most setups, the BGP routers of an AS exchange prefix vectors only with the BGP routers of neighbouring ASes (i.e., directly connected ASes). In such cases, the two BGP routers are said to be in a peering relationship. Peering relationships between routers of two different AS are also called eBGP (external BGP) peerings, in order to differentiate them from connections between BGP routers within the same AS, called iBGP (internal BGP) peerings. A peering relationship implies full trust: one router will accept and use for routing any network prefix advertised by the other router (unless administratively forbidden).

Peering relationships are carried out using a TCP connection on port 179. Upon establishment of such connection, the two BGP routers exchange an OPEN message, which contains identification parameters like the AS number and the BGP identifier (usually the IP address assigned to one of the network interfaces) of the sender.

In case a BGP speaker accepts the peering request (on the basis of the remote IP address of the TCP connections and the information contained in the OPEN message), it sends to the remote party a series of UPDATE messages, containing the description of the prefixes that the router is configured to advertise. At the same time, the router listens for route updates form the other peer, and stores them in its Routing Information Base (RIB) according to the configured policy.

The lifetime of the peering relationship is bound by the TCP connection: if such connection is closed or lost, all the routing information learned via that connection is removed from the RIB. The connection is checked for liveliness with periodic KEEPALIVE messages.

Any error condition, for example during the OPEN negotiation or in UP-DATE messages, is notified by sending a NOTIFICATION message, and the TCP connection is subsequently closed. Instability of a BGP connection might cause a potentially big set of routes to be cyclically added and removed from the RIB. This would have the effect of increasing the load on the router and on the network (as route UPDATE s would be consequently propagated). In order to overcome this problem, Route Flap Dampening (RFD, [START_REF] Villamizar | BGP Route Flap Damping[END_REF]) has been defined, which temporarily suppresses unstable routes. As it will be discussed in the next section, an attacker can exploit this functionality in order to disrupt connectivity.

In some cases, it may be required to establish an eBGP peering between two routers that are not directly connected, creating so called multi-hop BGP sessions. This may be the case, for example, when the two peers communicate via a device that does not support BGP or via links for which static routes have been set.

The main authentication mechanism for BGP is via the remote IP address, the router identifier and the AS number. Clearly this information is not enough to defend against spoofing attacks. BGP also provides an Authentication option in the OPEN message, which would allow for remote peer authentication, but would not defend against TCP-level attacks. Moreover, this option has never found widespread usage. In fact, in the latest BGP specifications the Authentication options has been deprecated in favor of TCP MD5 signatures [START_REF] Heffernan | Protection of BGP Sessions via the TCP MD5 Signature Option[END_REF]. When two peers are communicating using TCP MD5 signatures, every TCP packet they exchange must carry a specific TCP option containing an MD5 hash of the packet concatenated with a shared secret. The value of the shared secret must be manually specified in the configuration of both routers. In this way, an attacker who does not know the secret cannot establish a spoofed peering session or hijack/reset an existing TCP connection, as non-signed packets are discarded.

Attacks against BGP

The biggest weakness of BGP is the trust that a router has toward its peers (see Fig. 1). Any route that is advertised by a neighboring BGP speaker is merged in the routing database and is propagated to all the other BGP peers. Configuration mechanisms for filtering incoming and outgoing prefix advertisements are available, but clearly having a system administrator manually specify acceptable prefixes mostly defeats the purpose of having a routing protocol like BGP. Moreover, the number of prefixes a BGP router is handling might be extremely large: the current the size of the Forwarding Information Base (FIB) of a BGP router is above 300,000 entries 1 .

Attacks from a trusted peer

Exploiting a trust relationship, a malicious or misconfigured router can claim ownership or reachability of network prefixes it is not entitled to.

Such advertised prefixes will then be spread potentially to all BGP routers and used to build routing tables, having the effect of directing IP packets towards the misbehaving router rather than the legitimate AS.

Hijacking traffic can be performed for multiple reasons. For example, an entity or malicious AS may want to make a subnet unreachable from other Internet hosts, or "blackhole" it. In this case, such AS can start advertising the prefix for the target network and then discard all the traffic it receives that is intended for that network. This is what happened in February 2008 in Pakistan [START_REF]RIPE NCC: YouTube Hijacking: A RIPE NCC RIS case study[END_REF], where the government decided to block access to the YouTube website, by having the main Pakistani telecom provider hijack YouTube network prefixes. However, a BGP misconfiguration caused the hijacked prefixes announcements to be propagated outside Pakistan boundaries, therefore blackholing YouTube's website across the whole Internet. Attacks to the BGP infrastructure can be more sophisticated than blackholing. The ability of diverting traffic toward one's own AS allows for mounting Man-In-The-Middle (MITM) attacks, where traffic is sniffed or even modified. Pilosov and Kapela [START_REF] Pilosov | Stealing The Internet[END_REF], in fact, gave a live demonstration about the feasibility of attracting most of the traffic destined to a target AS and than route it back to the intended AS, without users noticing it, and hiding the presence of the attacker from the output generated by routing analysis tools, such as Traceroute.

Probably, the most common reason for willingly stealing a network IP prefix is for spam purposes. Ramachandran and Feamster [START_REF] Ramachandran | Understanding the network-level behavior of spammers[END_REF] observed that a percentage of spam emails (growing up to 10% from time to time) are sent from IP addresses belonging to short-lived prefixes (i.e., prefixes that are withdrawn within a day after being firstly advertised). In this way, spammers can obtain non-blacklisted new IP address to use; moreover keeping the duration of the prefix hijacking short does not allow the affected ASes to perform effective countermeasures.

Effectively stealing prefixes If two ASes advertise the same prefix, the ASes across the Internet will be likely to be partitioned into two groups: ASes which are closer to the legitimate one and ASes which are closer to the malicious or misconfigured one. Therefore, not all the traffic will be diverted to the misbehaving router.

In order to increase the effectiveness of an IP prefix hijacking attack, a commonly used technique is to advertise subnets with a longer netmask than the original netmask of the prefix to be hijacked. As BGP will build forwarding rules using the longest-prefix matching criteria, the newly advertised rules will override the original one.

On the other side, the longer prefix matching functionality can also be exploited by advertising shorter prefixes: in this way the advertiser will steal unused subnets without disrupting the routing of actively-used prefixes.

Attack which do not need control of a trusted BGP router

If an attacker does not control a trusted peer, some other attacks are possible at the TCP level. First of all, a malicious node able to sniff traffic between two BGP peers could be able to hijack the TCP connection and inject its own UPDATE messages. Achieving favorable conditions for this attack, however, is difficult to achieve, given that usually eBGP routers are connected via dedicated point-to-point links.

BGP is also very sensitive to Denial-of-Service (DoS) attacks, much more than other TCP-based protocols. This is due to the fact that, by specification, all the routes learned from a peering session are withdrawn as soon as the associated TCP connection is lost. Therefore, the ability for an attacker to reset a TCP connection or overload/reboot a router can have a significant effect. Moreover, if the connection is being reset multiple times, the Route Flap Dampening (RFD) protection mechanism of BGP will suppress the flapping routes for a prolonged length of time after the end of the attack.

A TCP Reset attack consists in sending a TCP packet with the RST flag set to one of the connection endpoints. Successfully performing this attack requires guessing the source port number of the TCP connection (which is generally nonrandomly chosen), but does not require an exact guess of the sequence number. In fact, as shown by Watson [START_REF] Watson | Slipping in the Window: TCP Reset attacks[END_REF], with an outgoing bandwidth of 1.4 Mbps it is possible to perform a successful TCP connection reset in about 10 seconds against a target with a 63 KB TCP window size.

TCP MD5 signatures [START_REF] Heffernan | Protection of BGP Sessions via the TCP MD5 Signature Option[END_REF] were introduced to protect against TCP hijacks and resets, and started being adopted by some ASes in the years 2003-2004. Still, as discovered by Convery and Franz [START_REF] Convery | BGP Vulnerability Testing: Separating Fact from FUD[END_REF], some implementations were performing the MD5 signature validation before checking for the correctness of other TCP fields (e.g., sequence number and source IP address), therefore significantly affecting the CPU usage in case of TCP DoS flooding attack. Moreover, in the same study, they showed that an attacker with the ability to sniff MD5 signed TCP packets could recover a 6 character password in 3.5 hours.

Finally, the last two more generic channels for attack should be considered: if the router accepts BGP connections (even if it later declines the peering request), DoS by resource exhaustion could be an option for an attacker. Alternatively, malformed packets could be used to attempt to crash the router or even exploit it to gain some kind of control over it. Nevertheless, these types of vulnerabilities are rare, and they are very hard to exploit.

Scanning the Internet for BGP routers

The goal of our experiment was to scan the whole Internet for open BGP ports (179) and gather information about how many BGP routers are reachable and how they react to our probes. Our question was: "Is it possible for an attacker who does not already have control over a legitimate, trusted BGP router to affect the BGP infrastructure?" Scanning the whole Internet address space is an activity that poses some challenges by itself. The number of IP addresses to probe is about 3.7 billions, which means that in order to complete the scan in 2 weeks, with maximum 1 retry per IP address, we need a constant outgoing packet rate of 6,000 SYN packets per second.

Such activity is very noisy, both from the side of the scanner's ISP and the side of the ASes receiving the scan probes. In particular, the port 179 is notoriously a very low traffic port, and, independently from how slowly the scan is performed, a whole network sweep on that port is going to be easily detected. Moreover, scanning activity is usually identified as malicious, and sometimes finds a hostile response from network administrators.

We took a number of precautions in order to reduce the impact of our scanning activity on remote networks, and we tried to address in advance potential complaints about our scanning. First of all, we setup a web page served by an HTTP server reachable at the IP address originating the scan. This web page was explaining who we were, what we were doing, and making it clear that no malicious activity was to be performed by means of our scan.

Moreover, we offered the scanned party the opportunity to contact us and request to be excluded from the rest of our scans.

Second, we minimized the incoming packet rate seen from target networks by spreading the scan of the whole network across the whole duration of the experiment. In other words, we cycled over the IP address space by incrementing the most significant bytes (network-bytes) first.

During our scanning activity we received complaints from 10 different institutions, asking to be excluded from further scans. Only one other institution (AT&T) contacted us letting us know that they were aware of our activity (see Fig. 2) and that they were interested in hearing about the details of our experiment.

One problem we incurred in was that, because of the restructuring of our lab network, we needed to change the source IP address used during the experiment. Such change was perceived by some network administrators as an evasion attempt. These administrators had actually noticed our activity and silently added a firewall rule to block our original IP address. This issue caused our IT department to request the termination of the scanning activity. The data we collected up to that point was about 73% of the whole address space, from X.X.0.0 to X.X.186.249.

Given the noisiness of such an experiment and the perceived blurred boundary between benign and malicious scanning, such a large-scale scanning constitutes a one-shot experiment: it is not viable to repeat it, at least in the near future. Fig. 2. Numeber of TCP flows per hour as detected by AT&T on their network (/8 prefix). The picture clearly marks two phases of our scanning activity at two different outgoing packet rates. It it noteworthy how scanning on port 179 is extremely more noisy that normal activity on that port.

Scanning tools

We first looked at the Scapy [START_REF] Biondi | Scapy[END_REF] tool, which allows great flexibility for manipulating network packets. However, such tool does not allow handling an outgoing packet rate as high as we needed (6,000 packets per second), because of its excessively slow data handling.

We therefore decided to use Nmap [START_REF] Lyon | Nmap -Free Security Scanner For Network Exploration & Security Audits[END_REF] for the Internet-wide scan of hosts. Nmap was able to handle the required rate on a quad-core Intel Xeon X3220 2.4 GHz with 4GB of RAM and 1 Gbps connection to the Internet. With Nmap, we generated a report of which hosts had the TCP port 179 open.

Even though we did not have major issues, with some hindsight, we now think that implementing an ad hoc tool for large-scale SYN scanning would have provided us with more accurate results. Nmap has an adaptive mechanism to adjust scanning parameters, which tries to learn network delays and congestion from previous probes. While sweeping a broad range of networks, however, adaptive learning does not work well, causing unexpected (and incorrect) timing estimation (such as network RTT and optimal inter-packet sending time).

In addition, the parallel scanning of hosts performed by Nmap was not optimal. The ideal technique would have been sending out SYN packets at a chosen rate while recording possible answers. Allowing a timeout of maximum 1.5 seconds, with at most 1 retry requires one to keep in memory the state for up to 9,000 IP addresses at the same time. Unfortunately Nmap did not allow keeping a sliding window running over all the range of IPs, and, instead, it required scanning the hosts in batches. Therefore, we set to the batch size to 15,000 IP addresses, therefore alternating peaks of high scanning rate and moment of limited outgoing traffic.

Once we collected the list of IP addresses answering to our SYN packets, we tried to engage in a BGP exchange with them. Given the much smaller number of hosts to contact (about 2.2 millions), it was possible to write a Python tool for that purpose. We based out tool on the Announcer application by Colitti [START_REF] Colitti | Active BGP Probing[END_REF].

Announcer is an implementation of a basic BGP speaker written in Python, without any actual routing feature. We borrowed the code for generating and parsing BGP messages, while we wrote our own BGP state machine.

We took an approach that was as passive as possible. In more details, we did the following:

1. opened a TCP connection toward port 179; 2. waited for the remote peer to send any data (5 seconds timeout); 3. in case of no data received or OPEN request received, we sent a BGP OPEN request, using the UCSB AS number (AS131) and our IP address as BGP identifier; 4. waited for the remote peer to send any data (i.e., OPEN message, if not already sent, or UPDATE messages); 5. sent a KEEPALIVE message and waited for reply; 6. terminated the peering session.

At all times, we monitored and recorded any event that would cause an unexpected session termination:

timeout, either during connection establishment or waiting for data from the remote peer (the timeout was set to 5 seconds); -TCP RST packet, indicating a connection refusal or abrupt connection termination; -TCP FIN packet, indicating the intention of the peer to close the connection; -ICMP error, indicating unreachability of the remote host or port; -BGP NOTIFICATION message, indicating an error during the establishment of the peering session; non-BGP data read from the socket, indicating the presence of a non-BGP speaker on that port.

Results

During our initial TCP SYN scan (carried on between December 2008 and January 2009) about 2.2 million hosts where reported to have the TCP port 179 open (i.e., 0.8‰ of the scanned IP addresses). This pool of potential BGP routers was than probed with our Python BGP speaker in February 2009. Quite unexpectedly, 35% of these hosts no longer responded to our BGP connection requests. A reason for this behavior can be inferred by looking at the distribution of the IP addresses that were leading to timeout in the second scan: 90% of such IP addresses were belonging to less than 1% of /16 networks in the scanned address space. In fact, we found a surprisingly large number of subnets that contained a large number of hosts accepting TCP connection on port 179. The initial Nmap scan was hitting these networks at a relatively low rate, as the whole Internet address space was being covered breadth-first. When we later processed the IP addresses with the open port, these peculiar networks started receiving a much higher rate of incoming SYN packets (up to 50 packets per second). The likely explanation for the increased number of observed timeouts is the triggering of rate-limiting mechanisms in the target networks. Such networks are probably honeypots, employed to monitor malicious activity on the Internet.

The same BGP probes on the same list of IP addresses was also repeated one year later, in February 2010. As could be expected, the number of hosts timing out at our connection attempts increased by 34%. Among the IP address that resulted in a timeout in February 2009, 85% were also present in the latest scan.

Similarly to the variation in number of hosts timing out, we also observed a doubling of the hosts no longer reachable or refusing the TCP connection between the two BGP scans. Among the hosts concluding the 3-way handshake, though, the distribution of observed behaviors remained pretty much the same. Therefore, we will concentrate the results of the second scanning experiment (Table 1).

Of the host that completed the TCP 3-way handshake, 45% closed or reset the connection right away. This behavior is probably determined by the interaction between a user space process and the router kernel for the management of the TCP connection. In fact, if the BGP speaker code is running as a user process, the 3-way handshake is managed by the kernel, which is not aware of the IP addresses of the configured peers (unless some ad-hoc firewall rules have been setup). The actual decision on whether the host requesting a TCP connection has the right to do so is made in the user-space process, which is notified of the connection after the 3-way handshake. Only at this point the BGP process can decide to terminate the connection. About 1% of the hosts immediately requested us to close the BGP connection with a BGP CEASE NOTIFICATION, while 0.5% started communicating with our tool sending non-BGP data. Interesting enough, about 4900 hosts answered with the signature of a popular Instant Messaging (IM) protocol. Similarly to the network behavior of honeypots, such IM servers where listening on all IP addresses belonging to multiple /16 subnets on all TCP ports. Other popular non-BGP speakers we found were SSH server or telnet-like services. 0.4% (7,904) of the hosts concluding the 3-way handshake parsed our OPEN message, but declined the BGP peering session with a NOTIFICATION OPEN Error message. Almost all these BGP speakers also sent us an OPEN message, therefore identifying themselves. They turned out to be actually only 1258 distinct routers (i.e., distinct BGP identifiers), belonging to 318 different ASes. Among them, 3497 routers declared themselves to be in AS numbers reserved for private use, lowering to 192 the number of public ASes for which BGP routers were discovered. 1. Results of February 2010 scan. The first column indicates the last packet we sent during our probe, the second column indicates the last packet received from the remote host (or the firing of a timeout in case no data was received). The fourth column indicates the percentage over total probed IP addresses, while in the last column the percentage is computed over the hosts that completed the TCP 3-way handshake.

In addition, we found 5 routers (all of them from the same AS) who accepted our BGP peering request and started sending us UPDATE messages with BGP prefixes. At this point, theoretically, we should have been able to send prefix UPDATE s back to the BGP router. If malicious and accepted by the remote peer, such injected route information could be used to disrupt local connectivity or backhole a subnet, potentially world-wide (i.e., advertising a subnet with a non-routable address as NEXT HOP ). We decided not to attempt to send such an update, as that would have been an excessively aggressive experiment. We instead contacted the administrators of such routers, in order to report the potential security threat and to try to gather some information about those BGP speakers. It turned out that we were not actually dealing with some BGP routers, rather than with a BGPDNS [START_REF] Oppermann | BGPDNS, Using BGP topology information for DNS RR sorting a scalable way of multi-homing[END_REF] infrastructure. While those hosts were not propagating incoming BGP prefixes to other BGP routers, they were storing them in a database. The owner of those BGP speakers confirmed that their security had to be improved and sending them updates could have been a way to overload their database server.

For the sake of completeness, in our scan in February 2009, we found about other 400 peers that were apparently willing to initiate a BGP peering session with us. After some investigation, these hosts appeared to be all from the same network and were not actually BGP speakers. Rather, they were behaving as reflectors. More in detail, they were sending us back whatever data we were writing on the TCP connection. Similarly to honeypots, reflectors are used to capture and observe malicious behavior on the Internet.

Filtering potential honeypot networks

As mentioned in the previous section, we found a surprisingly relevant number of networks with a high number of IP addresses answering to our SYN packets on port 179. Such behavior is an indication that most probably such TCP endpoints are not actually BGP speakers, rather they are likely honeypot networks, whose purpose is to monitor network activity on the Internet.

Based on this rationale, we tried to identify all the networks that had more than 32 hosts answering with SYN+ACK on port 179. 2.6% of all the networks2 satisfied our criterion, covering 81% of all the probed IP addresses. We then excluded such IP addresses from the statistics on the scan of February 2010 and compared the results.

As we expected, the percentage of IP addresses being unreachable or leading to a timeout reduced to approximately half, while the percentage of hosts closing the connection right after the 3-way handshake almost tripled (59% of all nonfiltered IP-addresses). These numbers seem to confirm the hypothesis we did at the beginning of the previous section about our BGP probes hitting some rate-limiting firewalls of these honeypot networks.

Areas of attack

From the results of the experiments we described, we can identify some areas that can be the target of attacks from a malicious user who does not have control of a trusted BGP router. First, the router that engages in a BGP peering session with an arbitrary BGP speaker is the most exposed, possibly to route injection, but also to mishandling of malformed packets. In fact, Convery and Franz [START_REF] Convery | BGP Vulnerability Testing: Separating Fact from FUD[END_REF] were able to find 4 flaws on 3 different router vendors that allowed a BGP speaker peering with a target router to force a reset of the target router.

From a more general point of view, whenever unnecessary input is parsed or resources are allocated, there is some ground for attack. For example, all routers waiting and replying to OPEN messages might be vulnerable to some kind of malformed OPEN message, or to resource exhaustion attacks.

Areas of defense

BGP is not a public service. Every network administrator knows which ASes their routers will be talking to, and the configuration of such peers is done manually. For this reason, protection against unwanted peers is quite simple. Denial of TCP connections should be performed as early as possible, during the 3-way handshake, with cooperation between the BGP process and the kernel and/or firewall.

Moreover, the standard mechanisms for BGP protection at the TCP level should be employed, i.e., TCP MD5 signatures [START_REF] Heffernan | Protection of BGP Sessions via the TCP MD5 Signature Option[END_REF] and the TTL Security Mechanism [START_REF] Gill | The Generalized TTL Security Mechanism (GTSM)[END_REF]. These features should be a requirement for BGP peers rather than an option.

Related work

The security of BGP and Internet routing has been addressed by multiple researchers in previous literature.

A survey of possible attacks against BGP has been made in 2004 by Nordström and Dovrolis [START_REF] Nordström | Beware of BGP attacks[END_REF], in order to raise awareness of potential security risks, and to observe how existing and proposed countermeasures would have not been actually deployable or would have not been effective enough.

In 2008, Butler et al. [START_REF] Butler | A survey of BGP security issues and solutions[END_REF] provided an updated and extensive snapshot of BGP security issues and possible solutions. They observed how BGP has been so far successful in providing a good stability of Internet routing. Nevertheless, they underlined some areas where BGP is still believed to be in need of security improvements.

Most of the literature has focused in proposing solution to the attacks where the malicious user owned a trusted BGP router. One of these proposals is S-BGP ( [START_REF] Kent | Design and analysis of the secure border gateway protocol (S-BGP)[END_REF]), which adds multiple layers of security to the current BGP specifications. S-BGP allows a BGP router to validate the authenticity and integrity of each path received from a peer. S-BGP, in fact, requires BGP speakers to sign every UPDATE message. The ownership of a prefix by an AS, instead, is signed by the address assignment authorities. TCP/IP level security is guaranteed by requiring the use of IPSec. Adoption of S-BGP does not appear to be feasible, as it does not allow for incremental deployment over exiting BGP, and requires many other infrastructure modifications, like the introduction of a Public-Key Infrastructure (PKI) and IPSec support.

Another mechanism for route validation has been proposed by Goodell et al. [START_REF] Goodell | Working around BGP: An incremental approach to improving security and accuracy of interdomain routing[END_REF] under the name of Interdomain Route Validation (IRV). This proposal, rather than a modification of BGP, is an external service that allows a BGP speaker to query other ASes and the address assignment authorities in order to validate the received paths. This approach requires a much lighter deployment effort than S-BGP, but poses some concerns of scalability and vulnerability to DoS attacks.

James ([10], soBGP ) proposed to increase the security of BGP by adding an additional SECURITY BGP message which carries signed information about prefixes ownership and ASes connectivity, allowing for the creation of a distributed database which routers can use to establish validity of paths. Even though soBGP allows for incremental deployment, it is not being adopted because of the necessary changes in the router software and the increased requirements in terms of router memory and CPU time.

Chan et al. [START_REF] Chan | Modeling adoptability of secure BGP protocol[END_REF] developed an interesting study about the adoptability of secure BGP enhancements.

In their study about behavior of spammers with respect to network resources usage, Ramachandran and Feamster [START_REF] Ramachandran | Understanding the network-level behavior of spammers[END_REF] observed how some spammers make use of BGP prefix stealing in order to acquire control of not-yet-blacklisted IP addresses. Unused IP addresses are stolen for a short amount of time (often less than 24 hours), in order to prevent the execution of effective countermeasures. Further analysis on prefix hijacking has been carried by McArthur and Guirguis [START_REF] Mcarthur | Stealthy IP Prefix Hijacking: Dont Bite Off More Than You Can Chew[END_REF].

As already described, the main concerns for BGP from the DoS attack point of view, are the consequences of BGP peering session teardown. Sriram et al. [START_REF] Sriram | Study of BGP Peering Session Attacks and Their Impacts on Routing Performance[END_REF] conducted a simulation study on the impact of such attacks on routing performance. They showed how the BGP routing infrastructure is non-negligibly affected by this kind of attacks, even while having a relatively low success ratio for BGP peering session attacks.

A very interesting study on BGP security has been performed by Convery and Franz [START_REF] Convery | BGP Vulnerability Testing: Separating Fact from FUD[END_REF]. Their work started from an analysis and categorization of all possible vectors of attack against the BGP protocol. As the second step, they tried to discover potential vulnerability in routers by means of protocol fuzzing and resource exhaustion attacks. In the end, they performed a scanning study very similar to the one we performed. They ran a traceroute towards each prefix advertised in the Internet routing tables in order to gather IP addresses of potential BGP routers. Afterwards, they tried to connect to all of these hosts on port 179, and they sent an OPEN message and listened for data. Our approach for collecting IP addresses of routers was performed on a much larger scale. In fact, we were able to conclude the 3-way handshake with 2.2 million hosts on port 179 (vs. 4,602). Clearly our number is inflated by the fact that we hit not only routers, but also some honeypot/reflector networks. However we were able to reach a broader number of BGP speakers, not only those we could encounter on a path from our network towards all ASes on the Internet. In fact, in February 2009, about 16,000 hosts answered our OPEN request (vs. 1,750), and we found that 7 of them were willing to establish a BGP peering relationship with us.

Conclusions

With our experiment we took a snapshot of a very large subset of the Internet, looking at how BGP routers answer to a casual inquirer.

We described the challenges we faced for performing such large-scale scanning experiment, and what we learned. Such activity revealed itself to be very noisy and perceived as extremely hostile. Therefore, one performing a large-scale scan must be able to handle complaints, no-scan requests, and be aware that she may not be able to repeat the experiment.

Based on how the BGP protocol works and on related work on the subject, we identified some possible areas of attack to the BGP infrastructure. We then tried to match them to the results of our scan.

We could not find any real immediate threat. Nevertheless, we found a large number of BGP speakers that would establish a connection with us and possibly accept some input from us. Such routers were not required to engage in such communication, and, in doing so, they exposed themselves to a potential menace, as BGP is extremely sensitive to Denial-of-Service attacks. Moreover, given the amount of trust given to the other peers, a compromised router could seriously affect the whole Internet routing infrastructure. For this reason, it is very important that some equivalent of the principle of least privilege is applied also to the acceptance of BGP connections, shielding the routers as much as possible from potentially malicious traffic.

Fig. 1 .

 1 Fig. 1. Example of BGP prefix advertisement propagation. Two prefix advertisement messages sent from the router of Autonomous System AS50 are represented in the picture. AS50 is claiming to be able to reach the network 10.3.0.0/16 by being directly connected to AS90. AS60 and the other ASes on the Internet need to trust this piece of information from AS50.

We used the "network" separation as provided by the IP2Location (http://www. ip2location.com) database. The actual number of networks (4510) satisfying our creterion is not relevant as an absolute number, as single big networks are sometimes split into smaller ones.

Acknowledgments This work has been partially supported by the National Science Foundation through grants 0905537 and 0716095, and by the Office of Naval Research through grant ONR N000140911042. We would also like to thank AT&T for their feedback on our scanning activity.