The Challenge of Cyber-Attack Technical Attribution in Computer Networks by Stephan Bren

Course Research Paper Cyber‐attack Attribution

The Challenge of Cyber‐attack Technical Attribution in Computer Networks

Stephan Bren Johns Hopkins University Introduction to Information Assurance August 24, 2012

EXECUTIVE SUMMARY Purpose The primary purpose of this paper is to present an introductory understanding to common sources of information in attributing cyber‐attacks performed over computer networks and the challenges associated with using these sources in performing attribution. The secondary purpose of this paper is develop and collate a body of references useful in performing further research on the topics presented in this paper.

Attack Attribution Security Considerations The challenge of cyber‐attack attribution has significant implications. Adequate attribution: 1) deters future cyber‐attacks; 2) improves defense against future cyber‐attacks; 3) improves response efficiency to active cyber‐attacks in the present; and 4) enables productive response to committed cyber‐attacks of the past. These implications affect diplomacy, commerce, industry, governance, communications, justice, policy, liability, law enforcement, and privacy.

Scope and Limitations Attribution is important to all forms of cyber‐attack, from malware and viruses, to social engineering and penetrative attacks launched over computer networks. This paper focuses on reviewing the general technical challenge of attributing cyber‐attacks launched over computer networks against specific targets, for the purposes of disruption, infiltration, or destruction. It is a brief review of this challenge, without engaging significant ancillary topics such as responding to or defending against such attacks, or discussing attribution techniques. It does not attempt to classify such cyber‐attacks, in so much as these classifications have somewhat different attribution challenges and thus bear upon the focus of this paper. It does not review legal challenges to attribution. Nor does it examine human attribution, where a cyber‐attack is attributed to a person, an organization, or even a government. This paper does not attempt to be exhaustive in this review, but presents an introductory‐level understanding of the types of cyber‐attacks and the attribution challenges associated with these.

Summary of Conclusions Cyber‐attacks launched over a computer network fall into two general categories, distributed denial of service (DDoS) and penetrative. Attacks in either of these general categories may incorporate aspects of the other. DDoS attacks are difficult to attribute in that the purpose of the cyber‐attack is not to communicate with the target computing system but disrupt it; and thus maintaining end‐to‐end communication is unnecessary. Penetrative cyber‐attacks do require maintaining end‐to‐end communication, leaving possible evidence trails, and are thus more amenable to attribution. However, penetrative cyber‐attacks still present significant technical,

iii jurisdictional, and other challenges to attribution, and these challenges are inherent to the TCP/IP protocol and the Internet architecture.

Organization of this Paper It begins by exploring the two general categories of cyber‐attacks, denial of service and penetrative. It then explores common sources of attribution and common challenges associated with employing these attribution sources. It then analyzes these challenges, presenting a conclusion, and offering recommendations for further research. Executive Summary: presents the purpose of this paper, a brief review of security considerations associated with cyber‐attack attribution, the paper’s scope and limitations, a summary of the paper’s conclusions, and the organization of the paper.. 1. Introduction: presents an overview of cyber‐attack attribution, a description of technical attribution, and summaries of the importance of attribution and the challenge of attribution in computer networks. 2. Types of Network Cyber‐Attack: presents a review of the common types of cyber‐attack over a computer network, including DOS and penetrative attack types. 3. Sources of Attribution: presents a review of the common source of attribution, including computer and network device logs, domain name and IP address registries, etc. 4. Attribution Challenges: presents a review of the general challenges associated with the attribution sources discussed in chapter 4. 5. Analysis: presents and analysis of cyber‐attack attribution challenges with respect to the two primary types of attack. 6. Conclusions: presents the conclusions of this paper. 7. Matters for further Research: presents suggested matters for further research. 8. Annotated Glossary: presents an annotated glossary of the technical and other terms used in this paper. 9. References: presents a list of cited references. Also presents lists of additional references reviewed over the course of the development of this paper but not cited. 10. Appendices: presents various tables of data referenced in this paper.

ACKNOWLEDGMENTS The author thanks the Shadowserver Foundation and Cisco Systems Inc. for kindly allowing the reprinting of various chart and graph products. The author acknowledges the use within this paper of images made publically available by: UUNET, Sprint, Microsoft Corporation, CyberSource, Sierra Wireless, Siemens Aktiengesellschaft, Swiss Federal Institute of Technology, Ludovic Ferre, Verizon, Global Crossing, Latin‐Tech Inc., Google, Zoho Corporation, Lizard Labs, Open Systems International, and Fusion PBX. The author acknowledges the use of definitions found in Wikipedia for various terms used in this paper. The author gives particular thanks to Dr. Harold Podell for guiding the development of this work.

CONTENTS 1.

INTRODUCTION ................................................................................................................................ 1 1.1. 1.2. 1.3. 1.4.

OVERVIEW ............................................................................................................................................ 1 TECHNICAL ATTRIBUTION ......................................................................................................................... 1 THE IMPORTANCE OF CYBER‐ATTACK ATTRIBUTION ....................................................................................... 1 THE CHALLENGE OF ATTRIBUTION IN COMPUTER NETWORKS .......................................................................... 2

TYPES OF NETWORK CYBER‐ATTACK.................................................................................................. 5 2.1. OVERVIEW ............................................................................................................................................ 5 2.2. DENIAL OF SERVICE ................................................................................................................................. 5 2.2.1. Overview ................................................................................................................................... 5 2.2.2. Distributed Denial of Service .................................................................................................... 6 2.2.3. Distributed Reflector Denial of Service ..................................................................................... 9 2.2.4. DDoS Cyber‐attacks on Core Internet Infrastructure .............................................................. 10 2.2.5. Summary ................................................................................................................................ 11 2.3. PENETRATIVE ...................................................................................................................................... 12 2.3.1. Overview ................................................................................................................................. 12 2.3.2. Remote Exploits ...................................................................................................................... 13 2.3.3. Local Exploits .......................................................................................................................... 14 2.3.4. Information‐harvesting Attacks .............................................................................................. 16 2.3.5. Penetrative cyber‐attacks for destructive purposes ............................................................... 17 2.3.6. Summary ................................................................................................................................ 18 2.4. CYBER ATTACK ON INDUSTRIAL CONTROL SYSTEMS ..................................................................................... 18 2.4.1. Overview ................................................................................................................................. 18 2.4.2. General Description of ICS ...................................................................................................... 19 2.4.3. Architecture ............................................................................................................................ 22 2.4.4. Vulnerabilities ......................................................................................................................... 26 2.4.5. Summary ................................................................................................................................ 32 2.5. CHAPTER SUMMARY ............................................................................................................................. 33

SOURCES OF ATTRIBUTION ............................................................................................................. 35 3.1. OVERVIEW .......................................................................................................................................... 35 3.2. COMPUTING SYSTEMS ........................................................................................................................... 35 3.2.1. Overview ................................................................................................................................. 35 3.2.2. Windows Systems ................................................................................................................... 36 3.2.3. Linux Systems ......................................................................................................................... 39 3.2.4. Summary ................................................................................................................................ 41 3.3. NETWORK DEVICES ............................................................................................................................... 41 3.3.1. Overview ................................................................................................................................. 41 3.3.2. Firewall ................................................................................................................................... 41 3.3.3. Proxy Server ............................................................................................................................ 42 3.3.4. Network Address Translation Server ...................................................................................... 43 3.3.5. Router ..................................................................................................................................... 43 3.3.6. Web Server ............................................................................................................................. 47

vii 3.3.7. Summary ................................................................................................................................. 49 3.4. TELEPHONE SERVICE PROVIDER CALL DETAIL RECORDS ................................................................................ 49 3.5. ISP POINTS OF PRESENCE LOGS .............................................................................................................. 51 3.6. DOMAIN NAME SERVICE REGISTRIES ........................................................................................................ 51 3.7. REGIONAL INTERNET REGISTRY RECORDS .................................................................................................. 52 3.8. CONTROL SYSTEMS ............................................................................................................................... 52 3.9. CHAPTER SUMMARY ............................................................................................................................. 53 4.

ATTRIBUTION CHALLENGES ............................................................................................................ 55 4.1. OVERVIEW .......................................................................................................................................... 55 4.2. INTERNET ARCHITECTURE ....................................................................................................................... 56 4.3. MACHINE LOGS ................................................................................................................................... 57 4.3.1. Overview ................................................................................................................................. 57 4.3.2. Nonexistence .......................................................................................................................... 57 4.3.3. Inadequate Configuration and Detail ..................................................................................... 58 4.3.4. Malicious Deletion or Editing .................................................................................................. 60 4.3.5. Administrative Deletion Due to Policy .................................................................................... 60 4.3.6. Corruption ............................................................................................................................... 61 4.3.7. Format and Distribution ......................................................................................................... 62 4.3.8. Summary ................................................................................................................................. 63 4.4. PROXY SERVERS ................................................................................................................................... 63 4.5. REGIONAL INTERNET AND DOMAIN NAME REGISTRIES ................................................................................. 64 4.6. JURISDICTIONAL ................................................................................................................................... 64 4.7. CHAPTER SUMMARY ............................................................................................................................. 65

ANALYSIS ....................................................................................................................................... 67 5.1. 5.2. 5.3. 5.4.

OVERVIEW .......................................................................................................................................... 67 ATTRIBUTION IN DDOS ATTACKS ............................................................................................................. 67 ATTRIBUTION IN PENETRATIVE ATTACKS ................................................................................................... 69 CHAPTER SUMMARY ............................................................................................................................. 72

CONCLUSIONS ................................................................................................................................ 73

MATTERS FOR FURTHER RESEARCH ................................................................................................ 75

ANNOTATED GLOSSARY ................................................................................................................. 77

REFERENCES .................................................................................................................................. 111 9.1. CITED ............................................................................................................................................... 111 9.2. ADDITIONAL ...................................................................................................................................... 138 9.2.1. Technical Papers ................................................................................................................... 138 9.2.2. Miscellaneous Articles .......................................................................................................... 140 9.2.3. Treaties and Law................................................................................................................... 140 9.2.4. Whitepapers and Testimony ................................................................................................. 141 9.2.5. General Reference ................................................................................................................ 142 9.2.6. Law Reviews ......................................................................................................................... 142

viii

10. APPENDICES ................................................................................................................................. 149 10.1. 10.2. 10.3. 10.4. 10.5. 10.6. 10.7. 10.8. 10.9. 10.10. 10.11. 10.12. 10.13. 10.14. 10.15.

OVERVIEW ........................................................................................................................................ 149 EXAMPLES OF SIGNIFICANT DDOS CYBER‐ATTACKS .................................................................................. 150 TOP 10 BOTNETS IN 2010 ................................................................................................................... 151 LISTING OF FUNDAMENTAL DOS EXPLOITS .............................................................................................. 152 EXAMPLES OF COMMON BOTNETS ........................................................................................................ 153 LISTING OF OWASP TOP 10 WEB APPLICATION SECURITY RISKS FOR 2010 ................................................. 154 OTHER COMMON WEB SERVER AND WEB SERVER HOST VULNERABILITIES ....................................................... 155 EXAMPLES OF COMMON MALWARE EXPLOIT METHODS ............................................................................ 156 EXAMPLES OF INFORMATION HARVESTING CYBER‐ATTACKS ....................................................................... 157 EXAMPLES OF UNINTENTIONAL PENETRATIVE CYBER‐ATTACKS ...................................................................... 160 EXAMPLES OF INTENTIONAL PENETRATIVE CYBER‐ATTACKS FOR DISRUPTIVE PURPOSES ..................................... 161 EXAMPLES OF WINDOWS FORENSIC DATA SOURCES ................................................................................. 163 EXAMPLE OF LINUX FORENSIC DATA SOURCES ......................................................................................... 168 W3C EXTENDED LOG FILE FORMAT (IIS 6.0) AND THEIR USEFULNESS IN FORENSIC ANALYSIS ........................... 169 NETWORK OPERATOR SUPPORT GROUPS ................................................................................................ 171

LIST OF FIGURES Figure 1.4‐1: Cyber‐Attack Attribution Challenges System Context Diagram ..................................... 3 Figure 2.2‐1: Simplified Denial of Service (DoS) Cyber‐attack ............................................................ 5 Figure 2.2‐2: Simplified Distributed Denial‐of‐Service (DDoS) Cyber‐attack ...................................... 6 Figure 2.2‐3: Two Year DDoS Attack Count. ........................................................................................ 8 Figure 2.2‐4: Two Year Botnet Size. .................................................................................................... 8 Figure 2.2‐5: Two Year Botnet C&C (Zombie) Count. .......................................................................... 9 Figure 2.2‐6: Simplified DRDoS Cyber‐attack Scenario ..................................................................... 10 Figure 2.2‐7: Increasing abstraction in DRDoS attacks. ..................................................................... 12 Figure 2.3‐1: Anatomy of a Remote Exploit ...................................................................................... 13 Figure 2.3‐2: Win32/FakeRean Virus Warning prompt ..................................................................... 14 Figure 2.3‐3: Anatomy of a local exploit ........................................................................................... 15 Figure 2.3‐4: Trends in losses due to online fraud ............................................................................ 17 Figure 2.4‐1: industry applications of control systems ..................................................................... 20 Figure 2.4‐2: Early analog water distribution system control center ................................................ 20 Figure 2.4‐3: Nuclear power plant control center ............................................................................. 21 Figure 2.4‐4: Gas pipeline control point RTU .................................................................................... 21 Figure 2.4‐5: Programmable logic controller .................................................................................... 21 Figure 2.4‐6: PLC‐based manufacturing plant motor control center ................................................ 22 Figure 2.4‐7: Centralized architecture of early distributed control systems .................................... 23 Figure 2.4‐8: networked architecture of modern distributed control systems ................................ 24 Figure 2.4‐9: Centralized architecture of pre‐SCADA (telemetry) systems ....................................... 25 Figure 2.4‐10: Distributed architecture of modern SCADA systems. ................................................ 25 Figure 2.4‐11: Russian technicians performing diagnostics at the Bushehr Nuclear Facility. ........... 26 Figure 2.4‐12: Example applications of wireless IP‐based control networks .................................... 27 Figure 2.4‐13: Example PLC illustrating the availability of standard ports. ...................................... 27 Figure 2.4‐14: Remote terminal unit featuring USB, Flash and Ethernet ports. ............................... 28 Figure 2.4‐15: Examples of critical security points in modern integrated SCADA system ................ 29 Figure 2.4‐16: Siemens Software PLC Simatic WinAC software development environment. ........... 30 Figure 2.4‐17: Sequence of events for a virus targeting process automation controllers. ............... 31 Figure 3.2‐1: result of running "netstat ‐ano" in a Windows command terminal ............................ 37 Figure 3.2‐2: Listing of services running on a 64‐bit Windows 7 host .............................................. 38 Figure 3.2‐3: partial listing of log files on CentOS Linux server host. ................................................ 40 Figure 3.3‐1: Example firewall log showing malicious sequential port scan of internal host ........... 42 Figure 3.3‐2: Example illustration of Tier 1, 2 and 3 ISP connections ............................................... 44 Figure 3.3‐3: Worldwide distribution of internet exchange points. ................................................. 45 Figure 3.3‐4: Illustration of Verizon’s worldwide IXP network. ........................................................ 45 Figure 3.3‐5: Illustration of Global Crossing worldwide IXP network. .............................................. 46 Figure 3.3‐6: view of buffered routing table in a Cisco router. ......................................................... 46 Figure 3.3‐7: Sample Apache HTTPD log entries after scanning attack ............................................ 48 Figure 3.3‐8: Apache HTTPD access Log record of unsuccessful attack by Nimda virus ................... 48

Figure 3.4‐1: Example of a Call Detail Record .................................................................................... 49 Figure 4.1‐1: Technical attribution context diagram. ........................................................................ 55 Figure 4.2‐1: Simple representation of the TCP/IP packet. ............................................................... 56 Figure 4.2‐2: Structure of the TCP/IP packet header section. ........................................................... 56 Figure 4.3‐1: Log Parser Lizard GUI for the Microsoft Log Viewer Engine. ........................................ 62 Figure 5.2‐1: Example illustration of various actor involvements for a typical DRDoS attack. ......... 68 Figure 5.3‐1: Example illustration of actor involvements for typical penetrative attack .................. 70

LIST OF TABLES Table 2.2‐1: Total DDoS Attacks per Year ............................................................................................ 7 Table 2.2‐2: DDoS Cyber‐Attacks on Core Internet Infrastructure ................................................... 11 Table 3.1‐1: Common Sources of Attribution ................................................................................... 35 Table 3.4‐1: Verizon corporate retention policy ............................................................................... 50 Table 3.4‐2: Sprint corporate retention policy .................................................................................. 50 Table 10.2‐1: Examples of Significant DDoS Cyber‐Attacks ............................................................ 150 Table 10.3‐1: Top 10 Botnets in 2010 ............................................................................................. 151 Table 10.4‐1: Listing of Fundamental DoS Exploits ......................................................................... 152 Table 10.5‐1: Examples of Common Botnets .................................................................................. 153 Table 10.6‐1: Listing of OWASP Top 10 Web Application Security Risks for 2010 .......................... 154 Table 10.7‐1: Other common web server and web server host vulnerabilities .............................. 155 Table 10.8‐1: Examples of Common Malware Exploit Methods ..................................................... 156 Table 10.9‐1: Examples of Information‐harvesting cyber‐attacks .................................................. 157 Table 10.10‐1: Examples of unintentional penetrative cyber‐attacks ............................................ 160 Table 10.11‐1: Examples of intentional penetrative cyber‐attacks for disruptive purposes .......... 161 Table 10.12‐1: Examples of Windows Forensic Data Sources ......................................................... 163 Table 10.13‐1: Examples of Linux Forensic Data Sources ............................................................... 168 Table 10.14‐1: W3C Extended Log File Format and their Use in Forensic Analysis ........................ 169 Table 10.15‐1: Network Operator Support Groups......................................................................... 171

Chapter 1: Introduction

1. INTRODUCTION 1.1. Overview There are two main types of attribution associated with network cyber‐attacks: technical and human [1]. Technical attribution involves identifying the network path taken by the attack, the machine or machines used to launch the attack, the owner or owners of those machines, and the computer access accounts used while conducting the attack [2]. Human attribution involves identifying the person or persons who actually used those machines from which the attack was launched and who are ultimately responsible for the attack itself. Human attribution of cyber‐ attacks is outside the scope of this paper. Further discussion on human attribution of cyber‐ attacks can be found in the literature [1]. This paper focuses on technical attribution, its sources, limitations, and challenges.

1.2. Technical Attribution Technical attribution is a multi‐step process of collecting evidence that identifies the network pathway taken by the attacker in order to reach the target machine. It links the computer from which the attack was launched to the target of the attack. This is referred to as traceback and is accomplished by reviewing the system logs of the computing and network equipment and traffic monitoring equipment associated with the attack, and working backwards, router by router, and network by network, to the computer from which the attack was launched. These logs contain the source and destination addresses of the individual messages comprising the network traffic that traverse them and thus also the communications that the attacker had with the target system. Technical attribution may also include other types of evidence derived from forensic computer and network examination, such as registry settings, authentication logs, file properties, installed files, memory, etc. These other sources may not be useful in direct attribution, but they do help build a sense of motivation and ability that can help bound the scope of attribution efforts.

1.3. The Importance of Cyber‐attack Attribution Attribution involves the collection of evidence and associating it with a person or persons or other actor (e.g., organization, nation, etc.). Factual evidence associated with the cyber‐attack is needed for efficient and productive response. Citizens must provide evidence of attacker identity before seeking restitution against the attacker. Network administrators need to know basic information about an attack, such as source address, in order to mount adequate defensive and protective measures. Law enforcement agencies must have objective and significant evidence of the identity of an attacker before they can take active measures against the attacker. Courts must have verifiable, objective, and significant evidence of attacker identity before being able to objectively determine attacker culpability and liability. Private industry must have adequate attribution in order to objectively determine appropriate response and assess risk and liability. Governments must obtain sufficient attribution in order to develop policy to defensively protect its citizens and

The Challenge of Attribution in Computer Networks

craft overt and covert diplomacy that defensively and even offensively attempts to engage the attackers. At every level, factual evidence is needed in order to effectively defend against and respond to a cyber‐attack. Attribution then assigns factual evidence that can attribute a cyber‐ attack to an identity and thus enable action to be taken against that identity, through law and treaty enforcement and other legal and diplomatic measures.

1.4. The Challenge of Attribution in Computer Networks The primary challenge involved with cyber‐attack attribution is that crimes involving computer technology can be committed over significantly greater speeds, distances, multiplicity of targets, and with greater concealment. These characteristics can be readily understood when reviewing the two primary types of cyber‐attack: denial of service and penetrative. Denial of service attacks are typically performed by thousands of individual sources, networked together to form a cohort of attacking sources managed by the attacker, who may also employ various other methods at further hiding or preventing attribution, such as the use multiple layers of control and proxies. Even more sophisticated abstraction can be accomplished by taking advantage of the rapid domain name registration services offered by domain name registries, whereby domain names can be changed within minutes. Where attacks cross jurisdictional boundaries, attribution attempts are complicated further by the need to interact with separate ISPs, IXPs, justice systems, and governments. The very nature of the TCP/IP protocol suite itself, primarily its insecure nature, and the fundamentally one‐way nature of network communications between attacker and target, makes these challenges all but immutable. These and other aspects make it all but impossible to adequately attribute denial of service attacks, and thus present day attention with regard to such attacks is focused on mitigation and prevention, and not on policing and justice. Penetrative attacks present a quite different set of attribution challenges. In this case, communication is two‐way, and often long‐term, as the attacker is seeking to obtain information resources or exploit capabilities, or both, and thus the attacker may leave distinct traces that may be attributed to the attacker. Indeed, attribution in penetrative attacks may take advantage of simplifications that enable the traceback effort to be performed more efficiently. On the other hand, where the paths of the penetrative attack cross jurisdictional boundaries, attribution in these cases encounters the same challenges as for denial of service, as the attribution effort may need to interact with additional ISPs, IXPs, judicial systems, law enforcement offices, and governments. An important and distinctive subset of penetrative attacks is that involving industrial control systems. These systems may be comprised of numerous electronic devices that connect analog hardware devices with a digital network. These electronic devices generally do not feature the authentication, traffic, and other logging capabilities commonly available with standard network equipment, such as computers, servers, routers, and the like. Thus, these electronic devices present distinct attribution challenges. The system of these challenges is presented in Figure 1.4‐1

Chapter 1: Introduction

Figure 1.4‐1: Cyber‐Attack Attribution Challenges System Context Diagram

The Challenge of Attribution in Computer Networks

Chapter 2: Types of Network Cyber‐Attack

2. TYPES OF NETWORK CYBER‐ATTACK 2.1. Overview Cyber‐attacks launched over a computer network fall into two general categories, denial of service (DoS) and penetrative [1], [2], [3] and [4]. DoS attacks involve overwhelming target machines and networks with traffic to such an extent that they can no longer perform their normal functions and thus deny service to normal users. Distributed DoS attacks generally involve a number of intermediary computers in order to obfuscate attribution and to amplify the attack. Penetrative attacks involving gaining control over a target machine or network for benign, malicious, exploitative, and even destructive purposes. Other forms of cyber‐attack also exist. All of these attacks exploit inherent flaws in the TCP/IP protocol suite [5], [6]. Each of these classes is discussed here.

2.2. Denial of Service 2.2.1. Overview A DoS attack involves a large volume of Internet traffic being sent to the target network and computer systems to such an extent that they are overwhelmed by the traffic and are no longer able to adequately function, thus denying service to their normal users. The kinds of traffic sent to the target machine may involve simple requests for the web page hosted by the machine or they may exploit known limitations of TCP/IP architecture. A few of the more common forms are listed in Table 10.4‐1 on page 152, in the Appendix. Figure 2.2‐ 1, at right, shows a simplified DoS attack. Some of the DoS attacks listed in this table have been in use since the late 1990s [18]. Many of these DoS forms of cyber‐attack involved spoofing the source address of the IP packet. The targets of DoS attacks may be computer systems, web servers, routers, and other network and computing equipment connected to a network. Computer worms can consume significant resources over the course of infecting a machine and Figure 2.2‐1: Simplified Denial of Service (DoS) propagating themselves to other Cyber‐attack machines, and that this too can result in DoS.

Denial of Service

These common forms of DoS attack can be greatly amplified through the use of geographically distributed networks of compromised computers [7]. The cyber‐attacks performed from such networks are referred to as distributed denial of service attacks (DDoS).

2.2.2. Distributed Denial of Service Distributed DoS is an evolutionary development of DoS. In DDoS attacks, the attacker employs a network of geographically distributed intermediary computers that in turn perform DoS attacks [17]. This network consists of: 1) server computers, also known as zombies or command and control (C&C) servers, that the attacker has been able to directly hack into and control and 2) client computers, or bots, that the attacker controls through hidden software programs installed to user computers via computer viruses and worms. The attacker controls these bots indirectly through the zombie computers in order to obfuscate traceback, amplify the attack, and simplify administration. The owners of the server and client computers will not be aware that their computers have been compromised. The network of zombies and bots is called a botnet, and the controller of the botnet is termed a herder. A simplified depiction of a DDoS cyber‐attack is shown in Figure 2.2‐2, below. The major uses of botnets are: spam, ID theft, piracy, and of course DDoS [22]. Other uses include: traffic sniffing, online advertisement and game manipulation, etc [23].

Figure 2.2‐2: Simplified Distributed Denial‐of‐Service (DDoS) Cyber‐attack

Chapter 2: Types of Network Cyber‐Attack

Bot software is installed to client computers when unsuspecting users connect to websites or click links in infected or malicious emails that contain hidden software code linked to the software programs [24]. These websites may have been compromised or they have been intentionally created to dispense bots to unsuspecting users. If the user’s web browser has not been configured for security or the user’s computer does not employ security software, the bot will be downloaded by the browser, unbeknownst to the user, and installed on the user’s computer. In some cases, even if the user’s computer has security software loaded, the bot software may be so new that the security software does not recognize it and allows it to be installed. The bot then runs silently in the background. Once installed, the bot contacts its assigned zombie to register its availability for further commands. Bots and zombies are functionally interchangeable, and the assignment of a compromised computer system by the botnet herder as a bot or as a zombie is purely for administrative reasons. Note that a botnet involves some degree of penetration, but of botnet computing systems ‐ not the target computing system. Some examples of significant DDoS cyber‐attack are listed in Table 10.2‐1, on page 150 in the Appendix. The DDoS cyber‐attacks listed there are merely those few that received significant news media attention. The actual number of DDoS cyber‐attacks experienced worldwide is much greater, as shown in Table 2.2‐1, below. Table 2.2‐1: Total DDoS Attacks per Year Year

Total number of attacks

Total number of unique attacks

Average number of attacks per unique target

Total number of unique countries associated with targets

2011

275459

5327

2010

1545208

13757

112

106

2009

7058221

10991

642

110

2008

202678

21312

117

2007

35566

15755

107

2006

50650

25953

133

Source: Shadowserver Foundation [34]. Totals for 2011 are to‐date values as of 5/2011. Note from Table 2.2‐1 that many targets have apparently experienced more than one cyber‐ attack; and that the targets of these attacks were widely geographically distributed. Figure 2.2‐3, Figure 2.2‐4, and Figure 2.2‐5 provide some sense of the variability in the volume of DDoS cyber‐ attacks over time. They also show that the volume of attacks is not necessarily associated with bot volume; and that, conversely, the volume of bots used as zombies (C&C) has remained fairly constant. The top ten botnets used for DDoS are shown in Table 10.3‐1, on page 151 in the appendix. A partial historical listing is available [35].

Denial of Service

Figure 2.2‐3: Two Year DDoS Attack Count. (Source: Shadowserver Foundation, as of 5/2011 [34]. Reprinted with permission)

Figure 2.2‐4: Two Year Botnet Size. (Source: Shadowserver Foundation, as of 5/2011 [34]. Reprinted with permission)

Chapter 2: Types of Network Cyber‐Attack

Figure 2.2‐5: Two Year Botnet C&C (Zombie) Count. (Source: Shadowserver Foundation, as of 5/2011 [34]. Reprinted with permission)

2.2.3. Distributed Reflector Denial of Service A recent variation on DDoS, called Distributed Reflector Denial of Service (DRDoS), employs non‐ compromised computers to further amplify network traffic to the target and to obfuscate attribution. Whereas, in a standard DDoS attack, it is the bots that send traffic directly to the target, in a DRDoS attack, the bots send traffic to the reflectors, which in turn send traffic to the intended target. A simplified depiction of a DDoS attack is shown in Figure 2.2‐6. The traffic sent to the reflectors includes the usual DoS exploits discussed in section 3.2, such as PING and SYN messages having the target IP address as their source IP address. When the reflectors receive these spoofed PING and SYN messages, they respond to them using the source IP address they identified in the spoofed message, which in fact is the target’s IP address. Thus, in a sense, they reflect traffic from the bots to the target. To further obfuscate attribution, botnet operators may employ multiple zombie layers and encrypt their communications with the zombies [10]. Botnets have been used not just for DoS‐type cyber‐attacks, but also for other purposes [35]:

•

Manipulate web‐based advertisement [37].

•

Perform website searches (also known as web crawls) [38].

•

Harvest user or organizational information and generate spam.

•

Perform distributed complex calculations [39].

•

Monitor auction sites and perform bidding [40].

•

Scan computing systems for vulnerabilities (e.g., for exploitation as bots).

Denial of Service

Figure 2.2‐6: Simplified DRDoS Cyber‐attack Scenario Botnets used to generate spam have the largest recorded number of bots employed, as shown in Table 10.5‐1 on page 153 in the Appendix. In 2010, Microsoft estimated total that one out of every 200 PCs were recruited into a botnet [41]. Note that some of these botnets, though primarily focused on generating spam, also have information harvesting and other capabilities. For example, botnets are used to harvest personal identity information (including financial information) that may subsequently be used for fraudulent purposes. The primary application of identity theft is in credit card fraud [42].

2.2.4. DDoS Cyber‐attacks on Core Internet Infrastructure An important subcategory of DDoS cyber‐attack involves attacks on core Internet infrastructure itself, namely Internet routing and domain name services. The fundamental approach of core Internet infrastructure attacks is to send such a large volume of traffic to the devices servicing these critical Internet services that the device consumes all of its available resources processing the traffic and is no longer able to handle normal requests for its services. The primary difference between attacks on core Internet infrastructure and those on other network and computer systems is that attacks on core internet infrastructure have the potential to significantly disrupt or even deny service There have been two such notable instances to date, and these are listed in Table 2.2‐2. Others are likely already on the horizon [60] and [61].

Chapter 2: Types of Network Cyber‐Attack Table 2.2‐2: DDoS Cyber‐Attacks on Core Internet Infrastructure

Date

Description

October 2002

Root Name Server Denial of Service Attack targeting all 13 Internet root servers [62], [63]. All root servers were able to maintain services throughout duration of attack.

February 2007

Root name server attack against 4 of 13 root servers; two were severely affected, causing them to deny service. Involved HTTP attack launched from approximately 4000‐5000 bots located mostly in South Korea, but some also in US, Canada, China, and other countries [64], [65].

In the various forms of denial of service cyber‐attacks discussed thus far, the target was subject to external attack but was not penetrated. Though other intermediary computing systems involved with DDoS cyber‐attacks may have been penetrated, the target system itself was not. In DoS attacks, the intent was to disrupt the target computing system or network itself, not use it for other purposes. A characteristic of all forms of DDoS attack over time is there increasing abstraction. From the initial one‐on‐one attack scenario to the fast‐flux attacks of the present (discussed in chapter 4), cyber‐attacks are becoming more abstract, demonstrated increasing abstraction separating the source of the attack from the target. Some sense of this increasing abstraction is shown in Figure 2.2‐7.

2.2.5. Summary Denial of service attacks take advantage of fundamental vulnerabilities in Internet architecture, specifically the insecurity of the packet network and in the routing protocol used. DoS cyber‐ attacks continue to develop in complexity and sophistication. Beginning with single host attacks, performing fundamental DoS attacks on Internet‐connected machines, these types of attacks have grown to span multiple geographically distributed hosts interconnected in ever more complex ways. Indeed, the constant in DoS development is in increasing abstraction, separating the actual attacker from the target of the attack. The next section examines the second class of cyber‐ attacks, in which the target itself is penetrated.

Penetrative

Figure 2.2‐7: Increasing abstraction in DRDoS attacks.

2.3. Penetrative 2.3.1. Overview A penetrative cyber‐attack generally involves gaining control over the target computer system to such a degree that it can be made to perform tasks and execute commands at the discretion of the attacker. Once the attacker has gained control over the target system, the attacker can use it for benign, exploitative, or even destructive purposes. Penetrative cyber‐attacks may be performed against any computer system, and are generally performed from a source: • •

Remote (external) to the target system and referred to as remote exploits, or Local (internal) to the target system, and referred to as local exploits [66].

Two notable subcategories of penetrative cyber‐attack are exploitative and disruptive/destructive. Penetrative attacks for exploitative purposes, as discussed here, involve primarily information‐ gathering activities. Penetrative cyber‐attacks for destructive purposes are those cyber‐attacks that cause disruption or even destruction of property and services.

Chapter 2: Types of Network Cyber‐Attack

2.3.2. Remote Exploits Remote exploits involve vulnerabilities associated with operating systems and software applications residing on those operating systems. For example, web servers are a convenient target for attack in that they are generally: •

Exposed to discovery; have

•

High bandwidth and availability; are

•

Geographically distributed; are

•

Connected to database servers; and

•

Exhibit numerous vulnerabilities, due to hosting multiple web applications.

Figure 2.3‐1: Anatomy of a Remote Exploit Common vulnerabilities associated with web servers are listed in Table 10.6‐1 and Table 10.7‐1, on pages 154 and 155, respectively. Cyber‐attacks against web servers represent the majority of total cyber‐attacks observed taking place on the Internet [67]. User computers are common targets for remote exploits. Home users, who have broadband Internet connection, offer attackers significant cumulative resources, if they can be harvested, as users with broadband connection often leave

Penetrative

them on and connected, presenting targets that, like web servers, are exposed to discovery and in greater quantity than web servers. Home users are highly attractive targets penetrative attack, as they are generally: • •

Operated by users of widely varying technical ability and Indifferently maintained and secured [17].

While direct attack is one method of penetrating the target system, a simpler method is to have exploitive software inadvertently installed by the user of a target machine that in turn enables the attacker to assume surreptitious control over that machine, commonly referred to as local exploits.

2.3.3. Local Exploits Penetrative cyber‐attacks of user computers through local exploits are usually accomplished through invasive means, that is, using trojans, which are software programs that run in the background, unbeknownst to the user, and that are able to execute any command and perform any task that the user can perform [74], [75]. The Trojan software is also referred to as a bot, which also gives its name to the client computer once it is successfully installed and has taken surreptitious control over the client computer. The bot is initially located as a downloadable file on a malicious or compromised website.

Figure 2.3‐2: Win32/FakeRean Virus Warning prompt

Chapter 2: Types of Network Cyber‐Attack

The attacker causes the user to inadvertently install the bot software through various forms of trickery and subterfuge. There numerous methods for causing users to inadvertently download and install bot software to their computers. A few of the more common methods are listed in Table 10.8‐1 on page 156 in the Appendix. A typical approach involves presenting the user with false claims of virus activity, as shown in Figure 2.3‐2 [76]. These claims are accompanied by urgent recommendations to obtain antivirus protection for a nominal fee. Should users believe the claims and proceed with purchase and download of the false antivirus product, they in fact have purchased a Trojan that is installed to their machines and they have exposed the details of at least one of their credit card accounts to malicious usage. Most of the exploits listed in this table involve Windows operating systems and applications that run on these operating systems. This is primarily due to opportunity associated with the wide‐ spread user‐base of deployed Windows‐based systems. As Apple operating systems experience greater market penetration, they too present more opportunities for cyber‐exploitation [98], [99], and [100].

Figure 2.3‐3: Anatomy of a local exploit

Penetrative

Whatever the means of exploitation, local exploits progress through three main phases: launch, infiltration, and control. Launch occurs when the user inadvertently causes the malware to be executed on the user’s machine. This is followed by infiltration, when the malware installs itself on the user machine and may proceed to download additional malware and gain administrator‐level access to the user’s machine. The last stage, control, involves the malware contacting the attacker to signal its availability and request further direction. Figure 2.3‐3 illustrates these phases. The user doesn’t necessarily need to click on a web page link in order to launch a malware exploit. Some exploits may be launched automatically, as the browser connects to the web page. For example, cross‐site‐scripting (XSS) exploits will run in any browser without requiring user initiation [92], [93], and [94]. XSS vulnerability is easily addressed [95]. Malware can also be embedded in the automatically generated and inserted advertisements that often appear in web pages, prevailing on the trust users typically have for such advertisements [96] and [97].

2.3.4. Information‐harvesting Attacks An important subcategory of penetrative cyber‐attack involves penetrating computing systems in order to harvest information for exploitative purposes. These are referred to as information‐ harvesting attacks. In this category, the primary purpose of the attack is to harvest information. The means by which penetrative cyber‐attack for exploitative purposes are accomplished are those discussed in the previous sections. The attack may involve harvesting: •

Personal information from a user’s home computer;

•

Corporate information from corporate workstations and servers; and

•

Government information from government information systems.

Financial information harvested may be used for personal gain, to fund organized crime, or even to fund terrorist groups [101]. In fact, the harvesting of such financial information has become so routine that a dedicated infrastructure exists supporting the buyers, sellers, intermediaries and service industries involved with such illicitly obtained information; credit card account numbers sell for $1, revision of their account information costs from $42 to $72, and complete identities including bank and credit card numbers, DOB, and government issued identifications sell from $14 to $18 [101], [102]. The finances are extracted from these credit accounts using intermediaries, who are often not aware that they are involved in fraud but are liable nevertheless [103]. Active fraud operations number in the thousands worldwide [104]. Estimates of creditor losses due to online fraud, in 2009, were approximately $95 million in the United Kingdom alone [105]. US creditor losses in 2009, due to online credit fraud, were estimated at $120 million merely for the third quarter of 2009 [106]. A survey of US and Canadian online merchants found that online revenue loss due to fraud was estimated to be approximately $2.7 billion in 2010 [107]. Online credit card fraud is increasingly being used to fund terrorist operations [108], [109], [110], [111], & [112]. Figure 2.3‐4 (below) shows the trends in loss due to online fraud.

Chapter 2: Types of Network Cyber‐Attack

Figure 2.3‐4: Trends in losses due to online fraud US government information is the target of over 140 different intelligence organizations worldwide, due to low resource entry threshold needed for performing such attacks and the ease of obfuscating their attribution [113]. Espionage is significant and increasing [114]. US commerce and industry is also the target of significant information‐harvesting cyber‐attack, with the average loss between $4 – 5 Million [115]. Financial institutions were the top target for phishing efforts in 2010, representing over 50% of all targeted industries; and 3 out of 4 financial phishing attempts targeted banks in North America [89]. Whatever the target of the cyber‐attack, the ultimate objectives of information harvesting attacks are financial gain or compromise of national security (espionage). Table 10.9‐1, in the Appendix, on page 157, lists some examples of these types of attacks. This list is very far from exhaustive and is intended to provide some sense of the breadth and scope of such cyber‐attacks.

2.3.5. Penetrative cyber‐attacks for destructive purposes Penetrative cyber‐attacks for destructive purposes are those cyber‐attacks that cause disruption or even destruction of property and services. The means by which such attacks would be accomplished are those already discussed: malware, trojans, hacking. Once an attacker has penetrated a computer network and gained access to computing resources, such as for cyber‐ exploitation and information gathering purposes, it is relatively trivial to also use that same access to manipulate or even destroy digital assets. The difference between penetrative cyber‐attacks for information‐gathering purposes and those for disruptive or destructive purposes is merely the objective of the attacker: the means remain the same.

Cyber Attack on Industrial Control Systems

Penetration of systems that results in disruptive or destructive outcomes may occur unintentionally or intentionally. Unintentional penetration here may occur through systems becoming infected by computer viruses, which then engage in disruptive activities. Affected systems are generally not the target of such attacks. This is a common occurrence associated with rapid, self‐propagating viruses, also known as “worms,” that affect all systems, opportunity permitting. A few of these are listed in Table 10.10‐1, in the Appendix. A more comprehensive list is also available [194]. In each case, the virus eventually overloaded computer networks, consuming resources, and leading to typical denial of service situations, albeit of critical infrastructure control systems, rather than office and personal computers and web servers. Intentional penetration occurs when a system is specifically targeted for cyber‐attack. In such an attack, the attacker attempts to gain control over a system in order to sabotage or subvert it for other purposes. Table 10.11‐1 on page 161 in the Appendix lists examples of these.

2.3.6. Summary In carrying out intentional penetrative cyber‐attack, the attacker may attempt to gain control over the system using various standard methods: •

Direct hacking of the system through the computer network to which it’s connected;

•

Radio or telephone access points; or

•

Direct physical access.

Such attacks may require social engineering in order to elucidate authentication details, such as usernames and passwords. The attacker may employ Trojan viruses, inadvertently and unknowingly introduced into the system, that subsequently create access portals through which an attacker can operate. Or, in more recent cases, the attacker may employ highly sophisticated, autonomous viruses that target specific devices in order to disrupt their operation or even cause the destruction of the systems and machinery they control [196]. Significant concern, with regard to penetrative cyber‐attacks, is associated with the penetration of industrial control systems.

2.4. Cyber Attack on Industrial Control Systems 2.4.1. Overview Industrial control systems (ICS) are computer‐based systems used extensively in industry to monitor and control sensitive processes and physical functions. Industrial control systems include supervisory control and data acquisition systems, distributed control systems and programmable logic controllers. The electronic architecture of industrial control systems is extremely diverse, being customized to the needs of the industrial application. Early distributed control systems, in the 1970s, through the 1980s, were generally autonomous systems, often mainframe‐based, completely isolated from the environment outside the plant or application and with very limited data‐entry points, and generally highly unique in their architecture and implementation. Communications among system devices were carried over analog and serial bus cables, using a very wide variety of different protocols and methods. Modern industrial control systems employ

Chapter 2: Types of Network Cyber‐Attack

highly‐standardized communications systems, composed of distributed and common off‐the‐shelf components integrated into a single wide area network that is often connected to the corporate network and to the Internet. They also present numerous data entry points, from thumb drives and wireless gateways, to radio, microwave and telephone access points, and to Internet gateways; and with multiple instances of these. Developments in technology standardization have brought enormous simplification, productivity increases, and cost‐savings to industry. They have also introduced new vulnerabilities and risks to industry. The increasing use of standard computers, operating systems, and network protocols, along with the proliferation of access points to industrial control systems introduces to these systems the same vulnerabilities and risks already experienced by standard information technologies. This section briefly describes industry control systems and their architecture, and then summarizes the general vulnerabilities associated with modern industrial control systems.

2.4.2. General Description of ICS Industrial control systems (ICS) are computer‐based systems used extensively in industry to monitor and control sensitive processes and physical functions (Figure 2.4‐1). They are used in such diverse industries as electric power generation and distribution, water distribution, oil and natural gas processing and distribution, waste water treatment, chemical manufacturing, food and beverage manufacturing, mass transportation and control, pharmaceutical manufacturing, pulp and paper manufacturing, and assembly manufacturing (e.g., automotive, durable goods, aerospace). They are used to monitor such parameters as: motion, force, temperature, flow‐rate, and pressure; and they may control valves, relays, switches, motors, doors, lighting, robotic arms, and pumps. They may be found in remote Alaska, monitoring Alaskan pipeline oil flow and pressure valve control; in unmanned town water pumping stations across the US, monitoring and controlling water flow; in remote railway track switches across the US, switching freight and passenger trains in response to central control stations located hundreds of miles distant; in diary product processing plants controlling such sensitive milk parameters as heat, pressure, and flow; and in pharmaceutical plants, precisely control chemical mixing, pill formation, and aggregation. They are found in the countless assembly lines plants manufacturing durable goods of all descriptions, all across the US. They may be used to control such ponderous machinery as the flow valves of the Grand Coulee Dam, in Washington State, to the minute and extremely sensitive direction of molecular beams used in the epitaxial manufacturing of semiconductor devices by Texas Instruments, Inc., facilities in Austin Texas. They may be used to control such mundane processes as the local town water pumping station that may receive only per functionary attention on a monthly basis; and they may be used in the highly regulated and standardized and controlled radiation therapy machines found in hospitals. In short, industrial control systems are pervasive and found in nearly every aspect of human society, wherever automation is employed [200]. The electronic architecture of industrial control systems is extremely diverse, being customized to the needs of the industrial application. However, the common architecture of such systems generally includes three subsystems: command and control, communications, distributed devices.

Cyber Attack on Industrial Control Systems

Figure 2.4‐1: industry applications of control systems The command and control subsystems may be as simple as a one, two or bank of analog meters displaying flow and pressure, such as for a water distribution system, or as complex as computerized visual displays of timelines, locations, and status, integrating the outputs of hundreds of sensors and devices, such as for an automotive assembly plant or a nuclear power generating plant, that comprise an entire control room. They may include the controllers that directly interact with Figure 2.4‐2: Early analog water devices; the integration devices that aggregate signals from distribution system control multiple controllers and feed them to central human machine center interfaces and computerized automation management subsystems; and computerized supervisory control and data acquisition (SCADA) systems that employ historical data archiving, Ethernet backbone communications, and sophisticated data analysis capabilities for monitor and control of geographically distributed assets.

Chapter 2: Types of Network Cyber‐Attack

The communication networks used in ICS are highly unique to each deployment and highly customized to the needs of the deployment. For example, a remote pipeline flow and pressure monitoring station may employ remote telemetry to uplink data to geosynchronous satellite and thence down to leased‐ line systems to the central pipeline control center. An actuator and motor in a beverage manufacturing plant may be connected to its controller over a parallel bus Figure 2.4‐3: Nuclear power plant control center cable bundle, with several intervening amplifiers boosting the analog signals between the actuator and controller; and the controller may in turn be connected to signal integration devices and human machine interfaces over RS‐232 serial buses. No two manufacturing plants are identical, even within similar industries; and thus their communication networks will also be different as well, though they may share similar components. Most of these communication systems are analog‐based, being developed and deployed in the era of analog electronics, and thus there is a large and extent legacy base of analog communications networks in industry. However, standardization and increasingly advantageous cost/benefits of digital communication networks and electronics miniaturization has resulted in new deployments being primarily digitally‐based [201], [202], & [203]. The distributed devices used in ICS may also be highly customized, though typically employing standardized components. They may include: remote terminal units or remote telemetry units (RTU), programmable logic controllers (PLC), and programmable automation controller (PAC), or some combination of these. RTUs are microprocessor‐ controlled devices that function Figure 2.4‐4: Gas pipeline as the primary interface control point RTU between a sensor or physical device and the distributed control system, reformatting signals to enable sensor or device data to be transmitted over a communications network [204]. A Figure 2.4‐5: Programmable PLC is a microprocessor that has been highly dedicated to logic controller automation of specific control machinery and devices, containing embedded control algorithms that enable it to provide specific output in response to specific input conditions. While PLCs themselves are standardized, differences in their application result in wide variation in their input/output interfaces, algorithm design, and internal memory usage. PLCs are typically used in motion control, positioning, and single‐variable status monitoring [205]. A PAC is a more generalized version of a PLC. A PAC functions more like a general computer in that it can be more easily programmed and adapted to the needs of the situation, generally

Cyber Attack on Industrial Control Systems

featuring modular architecture and interfaces and supporting standard programming methods and protocols. PACs are used in many of the same applications as for PLCs, but with important additional capabilities, such as the ability to communicate with other controllers and networked control systems. PACs are typically used in remote equipment monitoring applications [206]. Where distributed devices may be located varies with the needs of the situation. In the production facility or power plant, controllers may be more centralized and connected to sensors and devices over analog cabling. In geographically distributed situations, such as pipeline monitoring and control, or remote power substations, the controllers may be co‐located with the sensors or devices they are monitoring or controlling, respectively. For example, a remote power substation may employ a combination RTU/PAC that enables it to interface directly with Figure 2.4‐6: PLC‐based manufacturing sensors and switches, while also enabling the plant motor control center RTU/PAC device the ability to perform control functions independent of the central command center. Continuing innovations, miniaturization, and engineering developments blur these legacy boundaries even further.

2.4.3. Architecture Industrial control system architecture generally falls into two categories, distributed control systems (DCS) and supervisory control and data acquisition (SCADA) systems. The primary differences between these two are mainly of focus and scale. The DCS communication network had its origins and is typically confined to the industrial plant or factory and is intended for the direct control over machinery. The SCADA communications network had its origins in railroad and power distribution network monitoring and is usually highly distributed over wide geographic regions and is intended for the supervisory control and monitoring of critical infrastructure. Some systems are hybrids of the two. For example, a power plant may use DCS within the plant for control over machinery and processes and SCADA for monitoring and supervisory control over power distribution systems. Similarly, modern SCADA systems are used not only for monitoring, but also for control of distributed systems, such as railroad switches, power substations, etc. Early distributed control systems, in the 1970s through the 1980s, used centralized controllers (Figure 2.4‐7, below). Communications between controllers and sensors and devices were analog, carried over bus cables often requiring intervening signal amplification. Communications between controllers and computing equipment, human machine interfaces and other controllers was carried over serial cables, such as RS‐232, and employing a wide variety of communications protocols. Larger distributed control systems also employed mainframe computers.

Chapter 2: Types of Network Cyber‐Attack

Data entry for such systems occurred at the human machine interface, programming interface, and at the mainframe, through manual key entry or tape drive. No connections to telecommunications systems were extent. The DCS was generally a free‐standing, autonomous system, completely isolated from the environment outside the plant.

Figure 2.4‐7: Centralized architecture of early distributed control systems Modern distributed control systems employ distributed controllers (Figure 2.4‐8). Significant advances in microprocessor capabilities and miniaturization and in the standardization of digital networking enable considerable simplification of the DCS communications system. Where absolute precision and precise control are needed without interruption, dedicated controllers can be brought close to the devices they control; and these controllers are then connected to a plant Ethernet or token ring network for supervisory control and monitoring. This ability to bring controllers close to their devices greatly simplifies plant wiring architecture and power requirements. Where less rigorous control is needed, controllers can be completely moved off direct analog bus connection with their devices. Instead, controllers interact with their devices indirectly, through IO converters that connect both to the device and to the plant TCP/IP network and that convert device analogs signal into a format that can be carried over the network, and vice versa. Modern SCADA systems provide both telemetry and supervisory or even direct control over distributed systems and are comprised of standard TCP/IP‐based wide area networks (WAN) linking distributed RTUs and PLCs much in the same fashion as plant distributed control systems. The RTU itself may in fact be a PLC having telemetry capabilities. These RTUs and PLCs then communicate with Windows and Linux server‐based supervisory applications at the central station

Cyber Attack on Industrial Control Systems

that are monitored and controlled from standard Windows or Linux desktops computers. Modern SCADA systems not only perform their usual data acquisition tasks, but additionally perform supervisory control tasks – hence the name “SCADA” – in that distributed PLCs are controlled from the central station [207].

Figure 2.4‐8: networked architecture of modern distributed control systems Early supervisory control and data acquisition systems were actually telemetry systems that employed geographically distributed RTUs connected to a mainframe computer via dedicated communication methods and using vendor‐supplied protocols, such as Modbus and Profibus (Figure 2.4‐9). Communications types would include: radio, microwave, point‐to‐point radio, and satellite, cable, and telephone lines. Each communication link served to bring the RTU signal to the mainframe through a connection with the mainframe backplane. Communication between the master station and the RTU was one‐way: from the RTU to the mainframe. Thus, these telemetry systems were focused exclusively on data acquisition [207], [208]. Data entry for such systems was limited and occurred only at the human machine interface. Control over distributed machinery and switches was accomplished by direct human access or via completely autonomous control systems implemented at the site of the machinery or switch.

Chapter 2: Types of Network Cyber‐Attack

Figure 2.4‐9: Centralized architecture of pre‐SCADA (telemetry) systems

Figure 2.4‐10: Distributed architecture of modern SCADA systems.

Cyber Attack on Industrial Control Systems

2.4.4. Vulnerabilities Early industrial control systems were generally autonomous systems, having few if any connections available for external access, and where such access was potentially available (e.g., at the MTU‐RTU interface), exploiting such access would have required highly specialized knowledge of non‐standard – even vendor‐specific – communication protocols. Security concerns associated with such systems mainly involved physical access or insider knowledge. The shift to standard communication protocols and hardware architectures and common operating systems and programming methods significantly increases the exposure of such systems to malicious exploitation. Additionally, the connection of such systems to the Internet, and thus worldwide access, greatly increases the exposure of such systems to unauthorized access. Indeed, online databases exist that list Internet‐facing SCADA systems [235], [236]. Moreover, modern Industrial control networks can have multiple points of entry. The plant network may have a connection to the associated corporate network, which in turn is connected to the Internet. The plant network itself may have one or more Internet connections, some of which may not even be known to the plant administrators [193]. The control room may have multiple USB, and other ports to facilitate diagnostics Figure 2.4‐11: Russian technicians performing diagnostics at and maintenance activities, such as the Bushehr Nuclear Facility. evident in Figure 2.4‐11, showing Russian nuclear contractors at the Bushehr Nuclear plant in Iran performing diagnostic work using laptops connected directly to the plant network [237]. The plant or distribution system may also have wireless local area networking (WLAN) implemented, to enable convenient mobile access by technicians and engineers performing diagnostics and other maintenance activities from laptop and handheld computers throughout the plant and its environs. Wireless WAN systems may be used to provide the communications backbone for IP‐based wireless DCS and SCADA systems [238], [239]. Wireless systems are deployed in all industry and commerce sectors. Such wireless systems may use the common 802.11 Wi‐Fi communication standards over 2.4, 3.6, or 5 GHz frequency bands [240]; or the 802.15.4‐2003 (“ZigBee”) standard for over 2.4 GHz, 900 MHz, or 868 MHz frequency bands [241], [242]. SCADA systems may use dialup analog or digital modems for connections to distributed monitoring and control stations over public or private switched telephone networks; dialup modems may also employ public cellular networks, where available, to establish connectivity with distributed stations. These remote stations may employ RTUs that have standard ports for facilitating access for diagnostics and other maintenance purposes from

Chapter 2: Types of Network Cyber‐Attack

laptop and handheld computers. Figure 2.4‐14 shows one remote terminal unit, available from OSI, featuring USB, Flash and Ethernet ports [243]. Note that these ports also present entry points into the overall SCADA system.

Figure 2.4‐12: Example applications of wireless IP‐based control networks In comparison with early industrial control systems, modern ICS present significantly greater opportunities for unintentional and intentional cyber‐attack. USB ports are standard on all computing equipment and even on PLC and RTU equipment (Figure 2.4‐10). USB ports are common points of entry for viruses and trojans to office and Figure 2.4‐13: Example PLC illustrating the availability of standard ports.

Cyber Attack on Industrial Control Systems

home computing equipment. USB ports are commonly available on the rack‐mounted or free‐ standing computing equipment used in plants and factories and power‐generating facilities (Figure 2.4‐13 and Figure 2.4‐14). Thus, industrial control systems are now also vulnerable to cyber‐attack from viruses, worms, and trojans that exploit such common entry points. The non‐standard, vendor‐specific, communication protocols of early industrial control systems continue to be used to interact with PLCs and RTUs in modern systems. However, the use of these communication protocols has been pushed to the periphery of industrial control systems. For example, while in an early assembly line control systems, motors and sensors would communicate with centralized PLCs over long bus cables, in modern assembly line control systems, motors and sensors connect over these same bus lines to co‐located I/O devices that convert their analog signals and package them into a format deliverable over standard TCP/IP networks to PLCs located elsewhere on that network. Or a dedicated PLC may be co‐located at the site of the motor or sensor, and this dedicated PLC then communicates with a master PLC and/or a control room over a TCP/IP‐based network. PLCs and RTUs themselves continue to be highly vendor‐specific in their architecture. However, many of these controller devices employ variants of the Windows operating system, such as Figure 2.4‐14: Remote terminal unit featuring USB, Windows Embedded [245] , Windows Flash and Ethernet ports. CE [244], and even Windows XP [246]. Variants of Linux are also used [247]. Furthermore, the control programs that they host have also undergone standardization. PLC vendors across the market offer their own PLC programming suites that are installed to and run on standard Windows or Linux workstations, with connectivity either direct to the controller or over a network [248] (Figure 2.4‐16). Software for configuring and programming controllers is widely available and offered by all major control hardware vendors [249]. Widely used common programming languages, such as .NET and Java are commonly used to develop the control programs embedded in PLCs and RTUs [250], [251]. The standardization in PLC and RTU programming methods introduces similar vulnerabilities into control systems that other standardizations have introduced. The standardization and foundation of industrial control system backbone communications on TCP/IP exposes distributed control system and SCADA equipment to potential cyber‐attack. The means by which such cyber‐attack would occur are complex. Known exploits, common to office and consumer applications, have the potential to also attack office and consumer equipment when it is deployed to an industrial control system network. However, these known exploits are not able to directly impact PLC, RTU, and other distributed control system and SCADA system equipment, as this equipment presents substantially different hardware and software architectures. While common exploits cannot

Chapter 2: Types of Network Cyber‐Attack

directly impact DCS and SCADA equipment, they do have the potential to adversely impact such equipment indirectly, and this is accomplished through denial of service [252], [253], [254] and man‐in‐the‐middle attacks [199]. Figure 2.4‐15 below illustrates common critical security points in a modern SCADA system [255].

Figure 2.4‐15: Examples of critical security points in modern integrated SCADA system Modern distributed control systems and SCADA systems are networked using standard TCP/IP‐ based networking methods. Distributed components of the DCS communicate with each other, with various applications, and with a control center by using this network. Attached to this plant network may be a variety of standard computing equipment. Also attached will be a variety of sensors, valves, actuators, switches, etc. controlled by PLC by signals carried over a TCP/IP network. Such communications may require a high degree of reliability, fidelity and quality for this communication, in order to maintain continuous, real‐time connectivity. For example, pressure and temperature sensors in a power plant may require constant monitoring. Loss of signal from these sensors could indicate an emergency condition, triggering alarms and automated failsafe responses, and resultant loss of service to its customers. Or consider chemical manufacturing, where process variables must be tightly controlled in order to ensure product quality and safety of the process. Loss of signal for process monitors could significant affect product quality or even lead to unsafe conditions within the plant. Such loss of signal could be triggered by worm infection of a standard workstation that is connected to the plant distributed control system network and that seeks to propagate itself within that network by searching for compatible and vulnerable operating systems. Such attacks might be unintentional, but have significant consequences nevertheless. For example, in January 2003, the SQL Slammer

Cyber Attack on Industrial Control Systems

worm caused DoS impact to a nuclear power plant site network, adversely impacting the plant process computer and its parameter monitoring system [192], [193]. The plant control and protection systems were not affected, but resolving the worm infection required temporary shutdown of the plant. In August 2003, the Blaster worm caused DOS impact on the entire signaling and dispatching network system of a railroad, disrupting and even halting some rail traffic until the infection could be resolved [187], [188]. In August of 2005, the Zotob worm caused DoS impact to some automobile assembly plants by infecting plant control computers hosting Windows 2000 [186]. Thus, as can be seen from these examples, industrial control systems are vulnerable to denial of service attacks.

Figure 2.4‐16: Siemens Software PLC Simatic WinAC software development environment. Man‐in‐the‐middle attacks are also of concern with regard to ICS. In the office and consumer sectors, there is almost monolithic dominance of just a few different types of processing software by specialty. For example, for word processing, Microsoft Word holds has found almost overwhelming market penetration. For database processing, Oracle and Microsoft SQL Server have overwhelming market dominance. And for operating systems, variants of the Windows operating system have 90% market dominance. Thus, malicious code that targets one of these types of processing software will have widespread impact. This is not the case for industrial control software, where PLC programming methods continue to be highly vendor‐ and hardware‐

Chapter 2: Types of Network Cyber‐Attack

specific. While base programming languages used in developing ICS software may involve common programing languages, such as Java, .NET, C, and others, controller algorithm architecture varies considerably by industrial application. For example, the architecture of the software control programs used to control uranium separation centrifuges that refine uranium will be considerably different than the architecture of the software control programs used to control a distillation column that fractionally separates petroleum. Likewise, the control program used to control a robot in an automated assembly plant will have a very different architecture than that presented by the control program used to control a regional power distribution substation. Even the hardware hosting these different kinds of control programs may also be different. Thus a virus targeting one type of PLC control program would be ineffective against another type, much as a virus that targets Adobe PDF would be ineffective against Microsoft Word; or a virus that targets Linux operating systems would be ineffective against Windows operating systems. Furthermore, the virus must be highly sophisticated in that it must be able to interact with multiple types of software and hardware.

Figure 2.4‐17: Sequence of events for a virus targeting process automation controllers.

Cyber Attack on Industrial Control Systems

The virus must first be able to find residence in Windows or Linux workstations, which are most commonly the initial points of entry into industrial control systems: through USB ports, disk drives, or as trojans downloaded from the Internet. Once resident on the workstation, the virus must be able to search its local network environment for particular kinds of SCADA software that can interact with and configure PLCs, such as SIMATIC WinCC, which provides supervisory control and monitoring of Siemens process automation products [256]. Once finding a suitable computer hosting this software, it downloads the appropriate code libraries from its command and control server, and then proceeds to gain control over and use the SCADA application features in order to control its associated PLCs. The basic sequence of events is depicted in Figure 2.4‐17. After gaining control over the SCADA application, it proceeds to build a man‐in‐the‐middle attack: it must hide its malicious interaction with PLCs from human and automated monitoring in order to carry out its activities undetected. Accomplishing these successive infections requires significant technical knowledge in not only standard exploit methods for infecting Windows and Linux workstations, but also in the fundamental architecture of the target SCADA software. Additionally, given the significant diversity in SCADA software architectures and programming methods, and in order for the virus to be efficiently successful in exploiting target system vulnerabilities, the virus must focus on a particular brand or version or type of SCADA software, and this requires highly detailed knowledge of the intended physical target of attack, even so much as knowing exactly what types of hardware and software are in use. Thus, there are a number of significant technical challenges at present to the development of malicious code that would be able to directly attack industrial control systems. Resolving these technical challenges would require significant resources beyond that available to individuals, hacker organizations, or even most criminal organizations, at present. However, these challenges can be resolved and have been in at least one instance to date. In 2009, Stuxnet dramatically demonstrated the ability to cause the disruption of process‐controlled machinery used in Iran’s uranium enrichment plants [195], [196], [197], [198], and [199]. New, significant vulnerabilities industrial control system vulnerabilities continue to be found [257], [258], [261], [262], and [263].

2.4.5. Summary The increasing use of standard computers, operating systems, and network protocols, along with the proliferation of access points to industrial control systems introduces to these systems the same vulnerabilities and risks already experienced by standard information technologies. The introduction of standard hardware and software into industrial control systems has pushed the highly vendor‐specific process automation equipment to the peripheries of such networks and also makes them accessible over a computer network and thus vulnerable to potential cyber‐attack. Thus, industrial control systems are vulnerable to all of the usual cyber‐attack exploits discussed previously. Unique to cyber‐attack of industrial control systems are the potential consequences of such attacks. Whereas, cyber‐attack on information system may result in the theft, damage to or even destruction of information assets, cyber‐attack on industrial control systems may result in the damage to or destruction of physical assets and services. These consequences may occur through

Chapter 2: Types of Network Cyber‐Attack

unintentional cyber‐attack, such as resulting from DOS situations generated through worm infections, or through intentional cyber‐attack, such as through man‐in‐the‐middle exploits.

2.5. Chapter Summary This chapter has reviewed two primary types of cyber‐attack possible over computer networks: denial of service (DOS) and penetrative. DOS occurs where a target computer is forced to consume its resources to a degree that hinders or even prevents its normal operations. On the Internet, this may occur when an Internet‐connected asset, such as a router or web service, experiences traffic volumes beyond its capacity. DOS has been used for malicious purposes for personal reasons, criminal exploitation, and even as a tool of warfare. DOS can also occur within local networks, such as a plant network. DOS in such environments is usually the unintentional result of worm infections and can lead to the temporary loss of physical services, such as power generation or rail access, or product‐generating capacity, such as assembly line output. Penetrative attacks may occur either through direct hacking of exposed entry points, such as web servers, or through the surreptitious insertion of trojans that open a private channel into the target network. Penetrative attacks are used to build DOS capabilities, harvest information illicitly, perform espionage, and even to damage physical assets. In the past, industrial control systems have not presented convenient targets for attack over computer networks, but standardization of computer hardware and software introduces into these system the same vulnerabilities experienced by commercial and consumer users of such equipment. The introduction of these known vulnerabilities raises concerns unique to industrial control systems. Whereas cyber‐attack of commercial and consumer computing systems may damage and destroy digital information assets, cyber‐attack of industrial control systems may damage or even destroy physical assets, and, most importantly, may directly impact human safety. The next chapter reviews the common sources of information available in attempting to attribute cyber‐attacks.

Chapter Summary

Chapter 3: Sources of Attribution

3. SOURCES OF ATTRIBUTION 3.1. Overview This chapter reviews common sources of attribution for network cyber‐attacks typically available. These sources are typically available to local system administrators, and the administrators of internet and telephone service providers. They comprise electronic log files maintained by network and communications devices that contain information regarding the activities they themselves perform and of the traffic passing through them. They include the logs maintained by the computer that is the target of attack. They include the logs of the network devices through which the attacker communicated with the target of attack. They include the telephone or Internet service provider used by the attacker to connect to the Internet. And there are a variety of other sources of critical information here as well. Each of these sources may provide critical information in tracing a cyber‐attack from its target back to its source. Table 3.1‐1 lists the common sources of attribution data that will be discussed in this chapter. Table 3.1‐1: Common Sources of Attribution Source Computing System logs Application logs Network Device logs Router cache tables Telephone service provider call data records Domain Name Service (DNS) Registry records Regional Internet Registry (RIR) records Internet Service Provider (ISP) records PLC and RTU Intrusion Detection System (IDS) logs

3.2. Computing Systems 3.2.1. Overview Computing systems are those devices actually hosting operating systems and applications and which may be the stage for or target of a cyber‐attack. Examination of computing systems for evidence associated with a cyber‐attack involves the field of computer forensics. There are two primary types of operating systems commonly used, as of the time this paper was drafted:

Computing Systems

Windows and Linux. There are a variety of different Windows and Linux versions and types extent. To present the forensic information available by operating system version is beyond the scope of this paper. Additionally, there are a wide variety of different sources of forensic information available even when narrowly focusing on just one version of an operating system, and not all of these artifacts will be useful in attribution. This paper will review only the most common operating system forensic data sources available from Windows and Linux systems, and specifically that information useful in attributing the cyber‐attack.

3.2.2. Windows Systems There are a variety of Windows operating system artifacts available to computer forensic analysis. Table 10.12‐1 provides a broader listing of these artifacts and information on what tools are useful in finding information related to them. Some of these are listed below [264], [265], [266], [267], [268], [269] and [270]: •

Windows Event Logs

•

Logged on users

•

File systems

•

Network connections

•

Running processes

•

Process‐to‐port mappings

•

Network status

•

Registry

Windows Event Logs: Windows systems (as of the time of this writing) maintain two categories of event logs: Windows Logs and Applications and Services Logs [271]. The Windows Logs category includes the three primary logs that have been available in previous Windows versions, including: System, Security, and Application. These logs capture events from legacy applications and those generated by the system. The System log captures system –level events, such as the failure of a driver to load. The events written to this log are entirely determined by the operating system and include application events that have system‐wide impact. The Security Log captures events such as valid and invalid logon attempts, as well as events related to resource usage, such opening and closing files, and other auditable events. The events written to the Security Log can be configured by the administrator, through auditing profile configuration. The Application Log captures events generated by applications and programs. The Applications and Services logs are a new category of logs available beginning with Windows Server 2008 and Windows Vista. These logs focus on events generated by individual applications and components rather than events that have system‐ wide impact.

Chapter 3: Sources of Attribution

All of these logs are generated and maintained by the Windows operating system through the Event Log Service. These are not event logs that are specifically generated by applications themselves. Applications may use the Windows Event log service to log their events, they may write their own logs, and/or they may do both. Of these many event logs types, it is the Windows Security Log that is of primary interest. Depending on how the auditing is configured for the system, the Security log will capture every logon to the system. It will also capture logon failures and access to all system resources. In fact, almost every type of process can be audited. Logons include not only user logons but also system and process account logons. All malware must be run or executed, and, for any process to run, it must have an identity or account to run within. The Trojan running on a compromised system must be running under an assumed account. Correlating that account with unusual activity on the machine, such as: IP scans of the local network; extensive file system searches; unusual processes, etc., will help identify the endpoint identity of the cyber‐ attack over the computer network. The other system artifacts, such as registry, system temp are useful in correlating malicious activity with that identity. A larger listing of Windows forensics data sources is available in Table 10.12‐1, in the appendix.

Figure 3.2‐1: result of running "netstat ‐ano" in a Windows command terminal Logged On Users: This information is volatile, and will change momentarily, but can still be useful in adding context to other information, such as in trying to map logons to processes. Additionally, the cyber‐attacker may have left open a remote logon session, and this can help correlate malicious activity with the Event Log. File System: Trojans, viruses, hacker tools etc. must be on the system in order to be executed by the system. Searches of the file system can reveal these files. Examination of system file time stamps and hash values can help determine if these files were altered as a result of intrusion activity. Hackers may also have left copies of their tools on the target system, and identifying these tools and trojans can be useful in determining the method taken to hack and gain control over the system. Finding the resident malware program behind the cyber‐attack can help attribute

Computing Systems

the attack, when decompiled and forensically examined, as these software programs may contain artifacts left by the software development environment itself, configuration parameters, and even information embedded directly from the machine itself used by the malware developer [273]. Network Connections: Examining network connections is useful in determining: what services are mapped to what ports; what NetBIOS connections were made to local network resources; whether scans are being made of the local network as a part of reconnaissance activities. Running Processes: Every Trojan, virus or worm must be run or executed on a system, and therefore must be associated with a process. Processes provide information on the location of the executable program that is running, the command line that launched the process, the account it is running under, the amount of time that it has been running, and the modules that it depends on. Process‐to‐port mappings: Any process that is connecting to the network uses a port on the network interface to access the network. Suspicious network access can be link to a process, which in turn can be linked to accounts logged in the Event Log and the location of the resident malware. Network Status: when using the machine’s network interface card (NIC) to perform network scans, the NIC must be put into what is called “promiscuous” mode. Unless a machine is dedicated to network scanning, there is no need for the machine’s NIC to be configured this way. Whether or not a NIC is in this mode is not immediately observable, but would be helpful in determining whether the machine has been compromised and for what purpose.

Figure 3.2‐2: Listing of services running on a 64‐bit Windows 7 host

Chapter 3: Sources of Attribution

Registry: the Windows Registry is used to maintain system configuration and that may be useful in computer forensic analysis. For example, it contains the locations and file names of all software applications that re to be automatically started at system boot; and it maintains a history of all programs launched, including the number of times they’ve been run and the last execution time and date [274]. Trojans and other malware would be listed under various AutoRun entries in the Registry. The Protect Storage area contains sensitive information regarding the user. It is also used by attackers to hide the details of malware connections to control servers or intermediate servers and it is also a key area mined by hackers in when harvesting information.

3.2.3. Linux Systems Some sources of forensic information on Linux systems include [276], [277], [278], [279], [280] and [281]: •

Log files

•

File system

•

Shell history

•

Logged on users

•

Network connections

•

Running processes

•

Open file handlers

Log Files: Linux logs are generally all stored in the /var/log subdirectory. Linux has logs that are functionally equivalent to those in Windows. For example, kernel.log and syslog are similar to the Windows system.log, capturing events associated with the operating system; secure is similar to Windows security.log, capturing authentication information, but does not contain other audit data, which is captured in audit.log; and messages.log captures general system alerts; and the messages.log is similar to the Windows application.log, capturing information messages generated by applications and system facilities [282]. Other notable log files include: daemon.log, capturing events generated by background services (i.e., “daemons”); faillog, which is a system‐readable log capturing failed logon attempts and meant to be parsed by the faillog command; and the lastlog, which is a system‐readable log capturing logins and meant to be parsed by the lastlog command. File System: As for Windows systems, the file system is a key area of analysis: unusual (and often hidden) file names and directories; altered system time stamps and hash values and modified binaries; new or recently created files; common malware names (i.e., “signatures”); deleted files (e.g., deleted good system files that were replaced with modified bad system files, or deleted log files); etc. Shell History: command‐line interaction with a Linux system occurs through a shell. These environments maintain a history of the commands entered into them, but do not log responses. Examination of the shell history can reveal contextual information regarding the cyber‐attack. The

Computin ng Systems

e command h history is conffigurable. Any alteration oof this configu uration param meter (in the size of the account’s .profile), for example, it b being set to “0 0”, might be aan indication of an intrudeer ng to hide evidence of the intrusion. attemptin Logged on n users: as for Windows m machines, checking to see w who is curren ntly logged on n can help determine e attribution, or at least th he account th hat is being ussed to engagee in maliciouss activity on the system m. Network connections: examining network connectio ons is useful in n attributing services and the ports they mayy be using to connect with the n network for m malicious reassons. For example, a trojan conttacting its com mmand will be and contrrol server on tthe Internet w contactingg this server tthrough an asssigned port on th he NIC, and th his connection will in turn be asssociated with an IP addre ess located so omewhere on n the Internett. Most connectio ons for normaal network and Internet aaccess employy known portts or port ranges. A Any service lisstening on an unusual port could d be an indicaation of malw ware. Running p processes: he ere the same reasoningg applies as fo or Windows systems. Any malw ware on the taarget machine e must be running if it is to pe erform malicio ous activity, and if it is runn ning, it will haave a process associated witth it. Runningg processess having unusual names orr running states or cconsuming an n unusual amount of system re esources may be indication ns of Figure 3.2‐3: p partial listing of log files o on CentOS Lin nux malware resident on th he system. O Or se erver host. unning under an perhaps aa process is ru unknown identity. Revviewing runniing processess against authhentication an nd audit logs can help build attriibution or at least the assu umed identityy of the attac ker. Likewisee, any processs having an active con nnection to a resource locaated on the In nternet shou ld be revieweed. Open file handles: ope en files are th hose files bein ng edited or eexecuted and are being controlled by a process using them. Processes mayy have one orr more files oppen, and each process is aassociated with an id dentity. Information on op pen file handles is stored inn memory. SSearching thro ough processess and their op pen files can h help bound th he scope of alll files to be eexamined wheen searching for malwaare.

Chapter 3: Sources of Attribution

3.2.4. Summary Windows and Linux computing systems provide a wide variety of forensic data sources useful in attempting to attribute cyber‐attacks. Using a combination of event logs and other operating system artifacts, the forensic computer examiner can establish the identity or identities used to maliciously interact with the target computing system. This information, in combination with network traffic information, can help begin the process of traceback. Host logs, along with firewall logs, are the two crucial initial sources for attribution in network cyber‐attack analysis.

3.3. Network Devices 3.3.1. Overview Network devices include those common systems that are directly attached to a computer network and that provide network‐ or web‐related functionality. Such devices include: •

Firewalls

•

Proxy Servers

•

Routers

•

Web Servers

These devices capture information associated with network traffic passing through or observed by them. Network devices like these and others may be involved with a cyber‐attack and thus can be sources of attribution for the attack.

3.3.2. Firewall A firewall is the primary means of protection from network cyber‐attacks, for most private networks. It is a network device that acts as a gatekeeper between a private network and the Internet. It is usually positioned between the organizational router and the Internet connection. It intercepts each and every packet that passes through it, checking it against a set of rules and determining whether to allow or deny its transmission. A firewall can be configured to log information associated with the packets that it analyzes. It can log almost every aspect of these packets; whether they are inbound or outbound; whether packets were permitted, denied, or rejected; etc. Many firewalls can also audit changes to the firewall itself, such as configuration changes; logons/logoffs; etc. Just how much information is captured depends greatly upon the type of firewall and the configuration of the firewall by the firewall administrator. Given that every transmission must pass through the firewall, firewalls provide a complete and comprehensive source of information on traffic between the Internet and the private network.

Network Devices

Figure 3.3‐1: Example firewall log showing malicious sequential port scan of internal host Firewall logs provide a range of information useful in cyber‐attack attribution. Before hackers install a backdoor Trojan, they attempt to determine which ports are already being used for other services. Thus numerous log entries comprising port scans or scans of ports not commonly used could be an indication of attack. Unusual port scans sourced from a network device within the local network could be an indication of a penetration by a hacker, who is attempting to perform reconnaissance of the local network environment. Repeated unsuccessful attempts to access the firewall and/or other devices on the local network from one IP address or group of IP addresses is an indication of a direct cyber‐attack. Outbound connection attempts by internal devices, such as web servers, could be an indication of a compromised server. Inbound packets having internal IP addresses may be an indication of a spoofing attack, where an attacker is attempting to penetrate the private network by masquerading as an internal user. If the private network employs network address translation, the firewall logs every translation being made – information useful when attempting to traceback possible malicious activity originating within the private network. These are only a few examples of the types of information that firewalls can log. In general, firewall logs are one of the two crucial initial sources for attribution in network cyber‐attack analysis [283], [284] , [285], and [286].

3.3.3. Proxy Server A proxy server functions as an intermediary between a request for service by a client and a network resource that can address that request. It proxys the request on behalf of the client. Such intermediaries are useful in a variety of network applications [287], [288], and [288]. For example, they are used as the Internet facing server that proxys services from within a private network to clients distributed on the Internet. They can function as passive network traffic monitors [289]. They can function as caching servers, caching commonly access pages to an associated web server in order to speed up service. They can be used to provide encryption services to web services sourced from within a private network; in this way, internal devices can be networked without requiring SSL, but still take advantage of encryption once these services are transmitted to Internet‐based clients. They are also used by cyber‐attackers to proxy their attacks on networks in order to abstract attribution of them. Proxy servers can also be used to provide anonymous access to Internet resources: such anonymizing services enable web surfing without attribution, or at least hinder attribution. They are also used to perform network traffic detection and logging.

Chapter 3: Sources of Attribution

Like firewalls, proxy servers can maintain logs of the traffic that they detect or pass through them. The scope of the information captured in a proxy server log is entirely dependent on the proxy software used and administrator configuration. Such logs are particularly important, when attempting to perform a traceback from within a private network that employs proxy services. For example, if an encryption proxy is used, that proxy server’s log would provide critical connection information otherwise hidden. Likewise if an anonymizing proxy server is involved in a traceback attempt, that proxy server’s log would provide useful information on the upstream and downstream hops of the attack pathway. What is particularly useful about proxy logs is that they log all Internet access by a user on the private network. If a user accessed a web page that contained hidden files or links to other resources, the proxy server would log these, and this could be useful information in attempting to identify the source of a trojan [290]. Thus, proxy servers are a useful source of attribution data.

3.3.4. Network Address Translation Server A network address translator (NAT) is a special type of network device that enables one Internet‐ facing IP address to represent a range of internal IP addresses [291], [292]. They enable an organization to lease a single IP address, while still providing access to a group of users having private addresses. NATs were developed in the 1990s to alleviate the declining availability of IPv4 addresses. NATS are typically situated between the private network and its router. NATs in a way act as a firewall between the private network and the Internet, in that they hide the IP address of the internal host from discovery from outside the private network. NATs can have logging capabilities, and these logs would provide critical information in associating an internal IP address with the IP address of the destination host for each session. The depth of the information captured is dependent on the type of NAT employed and administrator configuration [293]. A NAT log can strongly link the identity of each internal user with that user’s Internet traffic. Thus, NATs are another critical source of cyber‐attack attribution.

3.3.5. Router Routers are those network devices that route transmissions between networks of hosts. They are usually situated at the junctures between networks. There are varying router tiers. At the lowest tier are the organizational routers that route transmissions within a private user network. These might be for a home user, company, a government, a college, etc. Large organizations may have a number of different internal routers. These internal networks are then connected to an Internet Service Provider (ISP) router, referred to as Tier 3 routers, in a global tiered structure [294]. ISPs may have their own networks, consisting of a number of routers, linking their customers. ISP networks in turn connect with larger ISPs or to the Internet Exchange Points (IXP) of a national ISP. IXP routers are referred to as Tier 2 routers. These IXPs then connect with each other nationally and internationally, through peering arrangements to form the Internet backbone [295], [296], and [297]. Figure 3.3‐2 presents an example illustration of these connections [295].

Networkk Devices

works; they exxist at the inteerfaces betweeen ISPs and Routers exist within usser networks and ISP netw en IXPs and oother IXPs. There are overr 300 ISPs their IXP; and they exisst at the interrfaces betwee ely 25 IXPs [29 99] within the e USA alone. Worldwide, tthere are tho ousands of [298] and approximate over a hundre ed IXPs. Figure 3.3‐3 illustrrates the worrldwide distrib bution of inteernet ISPs and o exchange points [300].. Figure 3.3‐4 4 and Figure 3 3.3‐5 illustrat e the worldw wide IXP netw works for ossing (note tthat service areas overlap tto a considerrable extent). Routers Verizon and Global Cro d failures; accceptance, can log: syystem errors;; changes to ttheir configurration; login ssuccesses and denial and d rejection off inbound and d outbound IP P packets; andd many otherr kinds of eveents, including IP traffic loggging. All netw work traffic flo ows through routers and tthus can be exxamined. Routers fe eature a rangge of differentt kinds of loggging [302], [3303], [304], an nd [305], • • • •

Console, buffe er, and termin nal logging Syyslog and SNM MP traps IP P traffic loggin ng AAA and ACL vviolation logging

Figure 3.3‐2: Examp ple illustration of Tier 1, 2 and 3 ISP co onnections

Chapter 3: Sources of Attribution

Figure 3.3‐3: Worldwide distribution of internet exchange points.

Figure 3.3‐4: Illustration of Verizon’s worldwide IXP network.

Network Devices

Figure 3.3‐5: Illustration of Global Crossing worldwide IXP network.

Figure 3.3‐6: view of buffered routing table in a Cisco router.

Chapter 3: Sources of Attribution

Console logging data is captured when logged into the router console and recording the console session. Buffer logging, when active, will display: the contents of the router buffer; logging level; hosts logging destination. Terminal logging allows non console sessions to view log messages. Syslog includes all log messages that the router has been configured to generate and write to a log file, which may be located on a different host. SNMP logging captures SNMP events and writes them to a logging server. AAA logging, when active, logs security information, and ACL logging, if available and activated, logs suspect traffic [306]. Of these information sources, Syslog, buffer, and IP traffic log data are the most useful. The buffer contains logging events as they occur and prior to being written to permanent storage in the Syslog. The buffer also caches dynamic tables for: ARP, routing, NAT, ACL violations, protocol statistics, and other dynamic information [307]. Of key value is the routing table, which contains information on how transmissions are being routed and thus helps identify the attribution path for the cyber‐attack. This information is dynamic and is continually being updated in response to changes in the routing environment. It is not written to permanent storage but is in a continuous state of flux. For routers servicing private organizational networks, these routing tables may remain unchanged for long periods of time or may even be statically assigned. However, the routing tables of routers operating at higher tiers, such as those joining ISP networks in peering arrangements, or those joining IXP backbone networks, will be extremely volatile, given the large volumes of internet traffic that they service and thus the large number of sub‐tier routers that are involved with that traffic. Figure 3.3‐6 shows a view of a buffered routing table for a Cisco router [308]. Routing cache tables are of critical important in determining attribution, as they help identify the actual path of the cyber‐attack over the network. The syslog is used by the router to log events. These may be security events associated with specific packet or traffic signatures, such as when packets are accepted, denied, or rejected; they may be events associated with login attempts, such as whether these attempts succeeded or failed; and other event types can also be logged. The syslog is useful in determining whether the router has been tampered with and thus made its data suspect. Lastly, routers can be configured to log all IP traffic [305]. The depth of this information depends on router capability and resources and administrator configuration. When enabled, router IP traffic logging functions essentially as a network sniffer, recording every packet that it senses, in whole or in part. Router IP traffic logs can help establish a definitive pathway for the cyber‐attack and are thus of primary value when they can be obtained.

3.3.6. Web Server Web servers are a common attack targets due to their ready and required availability to Internet access and their connection to internal networks. Web servers, though usually located in a DMZ and partitioned from the organizational network, are nevertheless usually physically connected to the corporate network, in order to enable corporate personnel to manage and maintain the web server. These internal connections provide convenient access to the web server for organizational personnel and they also present potential vulnerabilities that can be exploited. Thus, for cyber‐

Network Devices

attackers, web servers are often the initial doorway into the private network, and therefore web server logs are critically useful in detecting and attributing these attacks [309], [310].

Figure 3.3‐7: Sample Apache HTTPD log entries after scanning attack

Figure 3.3‐8: Apache HTTPD access Log record of unsuccessful attack by Nimda virus Web server logs are maintained by servers hosting web sites (e.g., Microsoft Internet Information Server (IIS), Apache, etc.). They are implemented by default on all web server installations. The logs are usually formatted and contain information according to World Wide Web Consortium (W3C) standards [313]. These logs can contain the history of page requests, over some period of time, along with the IP address of the machine sourcing the request (e.g., a desktop PC), the exact time the request was made, the browser type used, the operating system type and version, and the type of interaction (e.g., an HTTP GET or POST). Two widely‐used web server types are Apache HTTP Server [311] and Microsoft Internet Information Services Server [312]. Both fully support W3C standards. Sample log entries of actual Apache HTTPD server attacks [314].

Chapter 3: Sources of Attribution

3.3.7. Summary This section has reviewed the sources of attribution to be found among common network devices, including firewalls, proxy servers, network address translators and web servers. Such network devices can be configured to generate logs of network traffic that pass through them or that terminate with them. The logs generated by these network devices provide useful information in discovering the IP address from which the attack was launched and the pathway of the attack. Of these network devices firewalls and routers provide the most critical information for attributing cyber‐attacks. The actual physical location of these log files may be at the location of the devices themselves or at a central log server that stores log files from many different network devices for centralized storage, security, and ease of access. For example, the target of a cyber‐attack, most likely a rack‐ mounted server physically located in a server room or in a server farm, will maintain a variety of different log files, as will the applications hosted on this server.

3.4. Telephone Service Provider Call Detail Records Telephone service providers maintain information regarding their customers, the services provided to their customers, and their customer’s usage of these services. These are referred to as Call Detail Records (CDR) [315]. These records are typically digitized and maintained in a database for maintenance and billing purposes by the provider. Figure 3.4‐1 show an example CDR [316].

Figure 3.4‐1: Example of a Call Detail Record

Telephone Service Provider Call Detail Records

Data retention periods vary by service provider and are entirely determined by the service provider. These retention policies do not appear to be made public. For example, a review of some US telephone service provider privacy policies, including those of Cricket [317], T‐Mobile [318], Sprint Nextel [319]. Verizon [320], and AT&T [321], made available at their public corporate internet sites, failed to disclose any enumerated retention policies. However, discussion before the US House of Representatives, Subcommittee on Crime, Terrorism and Homeland Security [329] and panel discussions heard at the Intelligence Support Systems (IIS) World surveillance conference of 2009 [322] indicate that retention policies among telephone service providers varies widely, from no record retention by such carriers at T‐Mobile and Cricket [322] to considerable disclosure by such providers as AT&T and MCI [323]. Some partial information is available for two carriers, Verizon and Sprint, as disclosed in public documents [324] and [325], respectively, and summarized in Table 3.4‐2 and Table 3.4‐1, below. Table 3.4‐1: Verizon corporate retention policy Type of Information

Current Retention

Subscriber – post paid

Typically 3 – 5 years

Call detail records / cell site & sector information

1 rolling year

Text message detail

1 rolling year

Text message content

3 – 5 days

Pictures

Only if on web site (customer may change these at any time)

Bill copies – post paid

1 rolling year

Payment history – post paid

Typically 3 – 5 years

Check copies

6 months rolling

Credit card numbers

6 months rolling

Store surveillance videos

30 days rolling

Service applications

Typically 3 – 5 years

Table 3.4‐2: Sprint corporate retention policy Type of Information

Current Retention

basic customer account information

Life of account, plus 3 years

Location data (family locator service)

Requests are logged 2 years, but contain no location data

Chapter 3: Sources of Attribution

Call detail records are useful in determining attribution where the cyber‐attack may have involved geographically distributed and isolated SCADA devices, or where the cyber‐attacker is thought to have perhaps used a dial‐in connection to an ISP. They should be readily available but require legal process to be released.

3.5. ISP Points of Presence Logs ISPs maintain points of presence (POP) logs of customer access. These logs may include: source and destination IP addresses and ports, and may also include some content information as well [326]. Data retention among ISPs varies widely and is dependent on local, regional, and national government laws and regulations. For example, the US does not have national laws and regulations regarding ISP customer data retention, and thus data retention policies are set by the individual ISPs themselves [327], [328]. Data retention among US ISPs is driven by business needs and policy and not by regulatory direction. ISPs do not generally disclose their data retention policies, but federal legal experience seems to suggest that, in general, such retention is probably six months or less [329]. A new bill passed by the US House of Representatives, House Rule 1981, Protecting Children From Internet Pornographers Act of 2011, if also passed in the US Senate (which as of the time of this writing has not yet occurred), would impose a mandatory 18 month retention period for ISPs [330]. US federal agencies seek a two year retention period [331], [332]. By comparison, ISP data retention among members of the European Union has been established to be between 6 months to two years [333], [334]. For example, in the UK, rules are in affect that mandate ISP data retention for six months and web activity for four days [335], [336]. ISP POP customer access logs are particularly useful in performing attribution of cyber‐attacks over a Internet, as they can help further identify the pathway of the cyber‐attack by simplifying the amount of information that needs to be analyzed. Cyber‐attacks conducted over the Internet may pass through a number of different intermediary IXP and ISP networks. Where ever a path is traced into an intermediary ISP or IXP network, if the path is found to exit the ISP or IXP from another point, this would be sufficient attribution for the ultimate pathway, without needing to definitively identify the actual path through the ISP or IXP network – i.e., the ISP or IXP network is treated as a black box, where the entrance and exit way of the attack path is noted. Lastly, if an attack path is found to emanate from an ISP, but does not enter it, this is a good indication that that ISP is the primary Internet provider for the cyber attacker and thus might have key personal account information associated with the attacker – account information that would include billing information, which would be useful in further attributing the attack. At the very least, this would serve to geographically localize the source of the attack.

3.6. Domain Name Service Registries In some cases, attempting to attribute a cyber‐attack may involve web servers connected to the Internet. For example, a web server may be specifically used for hosting malware or it may be used as a command and control server used in managing botnets. Or the attack path may even be

Regional Internet Registry Records

traced back to a web server. Whatever the case may be, such web servers will likely have domain names, and these domain names will be registered with the registrar of a Top Level Domain (TLD) and contain contact information, referred to as domain name registries [337]. All domain names are ultimately managed by Internet Corporation for Assigned Names and Numbers (ICANN) [338]. Domain name account holders are referred to as registrants. If the TLD is a country, such as “UK”, “US”, etc., that country will be responsible for maintaining such domain names. If the TLD is more general, such as “COM” or “ORG,” the domain name will be maintained by anyone of the many commercial and independent registrars, which are responsible for maintaining domain name account information. This information is readily and freely obtained online by performing a search of the Internet Assigned Numbers Authority. Note however that the quality of this information is not guaranteed by the registrar. Registrants may populate account information however they wish. Moreover, some registrants use proxy services, whereby the proxy service information is inserted into the account information rather than that of the owner [339]. Such proxy services are used to provide a layer of privacy to domain names. The proxy service may be provided by the domain name registrar itself or by a third party.

3.7. Regional Internet Registry Records If, over the course of attribution efforts, a specific IP address is found to be of particular interest – perhaps as the origin IP address of the cyber‐attack, the owner of that IP address can be obtained through a query of a Regional Internet Registry [340]. The Internet Assigned Numbers Authority (IANA) ultimately manages the allocation and registration of Internet number resources. IANA in turn has delegated its authority to various Internet registries that manage the IP address space for world regions. These regional internet registries in turn delegate their authority to national internet registries, responsible for specific countries. IP addresses are not assigned individually to users but are distributed in blocks to government and commercial entities, such as Internet Service Providers and other end‐user organizations, which then manage their assigned address spaces for their customers. Information on the ownership of IP addresses is freely and readily available online through various IP lookup services. Using such a service, the entity responsible for an IP address of interest can be found and, with the cooperation of the responsibly entity, traced to a particular user or organization.

3.8. Control Systems Early deployed control systems and components, such as programmable logic controllers and remote terminal units, generally did not feature any sort of security event logging, and many of these devices may still be deployed [341], [342], and [343]. Modern PLCs and RTUs do feature various logging options, but such logging may be limited to uptimes, alarms (monitoring), and configuration changes. In general, most control systems components, such as RTUs and PLCs, do not feature detailed audit logging capabilities [344]. However, these components are increasingly being deployed on Windows and Linux operating system platforms, which do feature inherent audit logging capabilities, and using more robust memory devices amenable to recording auditable

Chapter 3: Sources of Attribution

logging features. Additionally, plant‐wide control systems may feature security auditing capabilities [345].

3.9. Chapter Summary There are a variety of common sources of information useful in attributing network cyber‐attacks. These sources include the actual targets of a cyber‐attack themselves, including servers, desktops, and PLCs and RTUs; and the network devices attached to the network through which the attack traverses, such as routers, proxy servers web servers, and so on. Also providing information useful towards cyber‐attack attribution are such entities as the internet and telephone service providers, which maintain user access logs; domain name registries, which maintain contact information for the domain names used by websites; and Internet IP address registries, which maintain contact information for Internet IP addresses. These information sources are typically available to the owners and administrators of computer and network devices and/or to the administrative and service entities involved. These sources of information are typically physically located at the site of the devices themselves or in a centralized logging location for a particular network. Obtaining this information can present a number of diverse challenges, both technical and nontechnical. Common examples of these will be reviewed next.

Chapter Summary

Chapter 4: Attribution Challenges

4. ATTRIBUTION CHALLENGES 4.1. Overview This chapter reviews the most common challenges associated with attributing cyber‐attacks. These challenges apply to the common types of cyber‐attacks discussed previously. Attributing a cyber‐attack requires evidence of that attack. Just as for other types of criminal analysis, an evidentiary chain must be built linking the scene of the crime, in this case a computer or network device, with the computer from which the attack was launched. Obtaining that evidence can present significant challenges. These challenges have their basis in the architecture of the Internet and in obtaining adequate or valid attribution data from network devices, ISPs, IXPs, and domain name and IP registration organizations. These challenges are aggravated by jurisdictional challenges, which, though not strictly technical, significantly complicate the common technical challenges that will be discussed here.

Figure 4.1‐1: Technical attribution context diagram.

Internet Architecture

4.2. Internet Architecture There are inherent characteristics of Internet architecture, specifically the TCP/IP protocol suite, that present significant challenges to attribution. These include the structure of a TCP/IP packet itself and the protocols used for routing these packets over the Internet [1]. Communications over the Internet are accomplished via the transmission of packets, which contain among other things a portion of the overall communication data, a source address and a destination address. Figure 4.2‐1 and Figure 4.2‐2 illustrate the TCP/IP packet structure [346].

Figure 4.2‐1: Simple representation of the TCP/IP packet.

Figure 4.2‐2: Structure of the TCP/IP packet header section.

Chapter 4: Attribution Challenges

In the standard packet (non‐SSL) structure, the source and destination address are unencrypted and publically visible. This structure is fundamentally insecure: any part of the packet can be modified outside the awareness of the system it is traversing. Thus, it is possible to send a packet with a source address that is not the actual source address of the packet. Nor are source addresses checked for validity, as they traverse the Internet. ISP and certainly IXP network routers route packets. Nothing more. This vulnerability is in fact exploited in distributed denial of service attacks, making such attacks almost impossible to traceback using standard methods. Routing of these TCP/IP packets on the Internet is dynamic, and thus packet traceability is transient, due to continual changes in routing tables. These routing tables maintain just the previous and next routers for various paths, and thus they do not retain any memory of the entire path that a packet must take. Core Internet routing infrastructure, such as the IXP networks, is focused on efficiency and speed due to traffic volume and not on accounting and attribution. In summary, the insecure nature of the TCP/IP packet structure and the dynamics of Internet routing introduce significant challenges to cyber‐attack attribution, particularly with regard to DDoS cyber‐attacks.

4.3. Machine Logs 4.3.1. Overview Machine logs include the logs available from user workstations, network devices, and control systems [348]. There are a variety of diverse challenges associated with these logs. Typical challenges may include: •

Nonexistence

•

Inadequate configuration and detail

•

Malicious deletion or editing

•

Administrative deletion due to policy

•

Corruption

•

Format and distribution

Each of these will be reviewed next.

4.3.2. Nonexistence Nonexistence of a log is a common challenge. Some devices, such as PLCs and RTUs, may not be capable of generating the types of logs useful in performing cyber‐attack attribution. Other devices, such as routers, proxy servers, and NATs, may not have been setup to generate logs useful in attribution or to generate logs at all. This is often intentional. Router traffic logs useful in cyber‐attack attribution can grow rapidly, quickly exceeding available storage resources. Thus,

Machine Logs

router traffic logging is more often than not simply impractical. This would be particularly the case fore backbone routers, such as those servicing IXPs. In other cases, such as for network address translators, there may be no immediate perceived need identified for capturing such information, and thus may not configured for it. NATs exist behind a firewall, and may thus be viewed as inconsequential. The same is true for hosts, such as servers and workstations. These devices commonly maintained detailed logs used for troubleshooting and performance monitoring and analysis, but not for traffic logging. Or consider web servers. By default, logging is not enabled on Microsoft Internet Information Services (IIS) 6.0 [350] or 7+ [351]. Enabling this requires manual configuration. Default access log mode for Apache deployments varies by implementation. Logs may have been accidentally deleted. For example, log files may be accidentally overwritten, due to inadequate application configuration. This vulnerability is usually addressed by the network administrator by ensuring that only specified individuals have the permissions to be able to access logs and move/edit/delete them. Nevertheless, it does require administrator attention. Of course, the most significant reason for nonexistence is none other than intentional deletion over the course of a penetrative cyber‐attack. The competent hacker penetrating a system will most certainly seek to attempt to remove evidence of the intrusion or at least limit attribution for it as much as possible, and one of the first things done in this regard is to delete the logs on the target server. If the logs are stored locally and then routinely rotated to a central storage location, the intruder may well be able to remove all logged traces of the penetration [1], [352]. The availability of machine logs useful in cyber‐attack attribution is highly dependent on perceived need, availability of resources, administrator judgment and attention, and their secure implementation.

4.3.3. Inadequate Configuration and Detail Where useful machine logs do exist, they may not be adequately configured. By default, many devices do maintain basic logging of various information, but this default configuration may not capture information useful in detecting an attack and in attributing it. For example, a web server may be configured to truncate strings longer than 4KB, when logging them. The web server still processes that portion of the string beyond 4 KB, but doesn’t log it. A cyber‐attacker can perform an attack against a web server, whereby the portion of the query string containing the malicious query is outside of the 4 KB limit. IIS is enabled by default and configured by default to log web traffic according to the World Wide Web Consortium (W3C) extended log file format [354]. Table 10.14‐1, on page 169 in the Appendix, provides a list of these fields. This format captures basic web traffic information, including source IP address and port of the requesting server and a time stamp, among other information. However, a web administrator may have unsuccessfully attempted to implement custom logging, and therefore the web server may not log available information.

Chapter 4: Attribution Challenges

Or the administrator may simply have accepted the default logging fields, during deployment, without further modification. The default IIS configuration may leave out log fields useful in forensic analysis [355]. In some instances, inadequate log file detail may be intentional. High‐ traffic network devices, such as routers and web servers, may rapidly generate large volumes of logging data, quickly consuming available storage resources. For Apache web servers, the default Apache configuration logs only a subset of the HTTP request received by the web server [356]. Additional configuration is necessary in order to obtain the other available fields. Lack of detail may also be the case for web hosting providers, who may manage tens or hundreds of thousands of individual websites, each of which may be configured to generate its own web log. In all of these cases, the administrator must balance available resources against risk. Therefore, the administrator may choose to log only a portion of the available fields – those fields deemed to be of more immediate usefulness. Web server administrators may maintain traffic logs for various reasons and implement rotation policies that may store these records for limited periods. But the need here is driven primarily by performance considerations. Web server administrators seek to ensure and improve their customer service, and therefore performance is constantly monitored and analyzed. The data needed to monitor performance is only a portion of the overall HTTP Request string. Legal and privacy concerns may drive ISPs and web hosting providers to intentionally log minimal data regarding their customer transactions, in order to shield their customers from exposure via legal processes and also to protect themselves from possible liability issues associated with maintain customer data that could potentially be maliciously obtained through hacking [358]. Critical in performing traceback is adequate time synchronization among the devices on a network [348]. This is usually accomplished by configuring devices for the network time protocol (NTP) [359]. This is necessary in order to properly correlate a transmission as it passes through devices and networks. However, in some cases, a device may not be adequately NTP synchronized, hindering transmission correlation. Linux‐based applications can be configured to write logs to a central syslog server. However, there may be inconsistencies in the configured logging formats used by these network devices, hindering effective and rapid analysis of syslog files [360]. Machine logs may be geographically distributed. The various network devices through which or associated with the pathway of a cyber‐attack may be geographically distributed. For example, a targeted server located in a datacenter in St. Louis, OH, may have traversed through routers distributed within the ISP region comprising Ohio, Illinois, Indiana, and Kentucky. The ISP may in turn have connected to an IXP in Illinois. This IXP may then connect to an Asian IXP based in Singapore, which in turn may connect to a regional ISP based in Szechuan province, China. These are some of the more common challenges involving inadequate configuration and detail in machine logs.

Machine Logs

4.3.4. Malicious Deletion or Editing Malicious deletion or editing of machine logs may occur in penetrative attacks, where the attacker seeks to avoid leaving evidence of infiltration or at least hinder it as much as possible. Once a machine has been compromised, and administrative level or root access is obtained, there is little preventing this from occurring and is in fact trivial, in such cases where the machine logs are stored and maintained local to the machine. This may often be the case for web servers and networks maintained by inadequately trained and experienced system administrators or having few resources available. Even if the web server or other network device writes its log file to a centralized server or service, the hijacker may simply reconfigure the device so that it sends filtered or edited logging information. In any event, the log files of any compromised machine must immediately be viewed as suspect, and their validity and usefulness can only be determined after thorough forensic analysis of the entire compromised machine [348]. This is not generally the case for machines subject to DoS attack, where penetration does not generally occur.

4.3.5. Administrative Deletion Due to Policy Data retention policies will vary by: organization, device, market sector, nationality, administrator, type of communication, need, and many other factors. An ISP providing web hosting services and managing a large web server farm will have different web log retention needs than the corporate IT department overseeing a corporate web server that maintains essentially a single customer website. A telephone service provider will have different data retention policy for its customer call detail records than a router administrator for a small ISP network. A corporate network administrator in Germany will implement different data retention policies than a corporate network administrator in the United States. Some of these differences will be driven by billing needs, such as those for telephone service providers. Others will be driven by privacy concerns, such as those discussed in section 3.4 regarding T‐Mobile and Cricket. In many instances, data retention and the availability of data sources useful in attribution will be driven by the careful balancing of available resources against perceived need. For example, ISPs may log some portion of traffic through their routers, or log no traffic all, weighing performance considerations against the need to deploy large and costly storage assets in the event that more significant traffic logging is implemented for uncertain future need. This is certainly the case for the backbone routers, maintained by the IXPs, for which the implementation of traffic logging methods would require significant architectural changes to their existing systems or at least the purchase and deployment of extremely costly storage assets. Web server administrators may maintain traffic logs for limited periods of time, say 12 months, after which they are deleted as they are no longer useful, and maintaining them would require additional storage resources. Beyond this period, traffic logs may likely no longer provide useful operational data for performance review and analysis.

Chapter 4: Attribution Challenges

A number of laws and regulations may drive data retention and deletion policies, and these will vary by country. The requirements imposed by these laws and regulations may also vary by data type. For example, financial information logged in web server and network logs may be governed by different laws and regulations than medical information logged in web server and network logs. On the other hand, ISPs may intentionally delete log data after some minimum period in order to protect customer privacy and their own liability [358]. Further discussion on legal and regulatory matters affecting data retention is provided in the References, section 9.2.3, Treaties and Law.

4.3.6. Corruption Corruption is a constant challenge for log files, as many events can occur that can cause data corruption. These events may be due or hardware or software related reasons. File corruption is not frequent, but may occur and does occur often enough to warrant attention. Some of the more common file corruption causes are discussed next. Abnormal shutdown of the device (server, router, proxy, etc.) is the primary cause of corrupted log files. Abnormal shutdown can be due a malfunctioning power supply, building power loss complemented by a lack of UPS, poor maintenance, intentional power cycling, and unintentional (accidental) power cycling, to name a few common reasons. For example, while a web application was running, it is writing to the log file and keeping it open the entire time. When the application terminates abruptly, the log file that is open at that moment is not closed properly and indeed may even have garbled data written to it. In some cases, only the last write operation is corrupted, but the rest of the file remains useful. In other cases, the entire file is corrupted and may require special tools for recovery. Disk failure is another cause of data corruption. Disk failure may be minor, involving merely a few disk clusters, from which operating systems can usually recover without intervention. More significant disk failures may involve mechanical failure, from which network servers can usually also recover, as network servers are usually deployed with disks in RAID 1 (mirrored) array, for automatic recovery in the event of total disk failure. RAM corruption may lead to subtle log file corruption that is not immediately apparent until the log file is actually opened and read. RAM corruption may cause only individual bits written to disk to be corrupted – errors usually insufficiently significant to trigger operating system alerts. Latency may be a source of data corruption. High traffic volume on storage area network (SAN) assets may lead to I/O errors as multiple data streams compete for access and the SAN is unable to adequately service the access requests. Inadequate disk space can cause log corruption. Log files on network assets can rapidly grow in size, and, if not regularly rotated out of the network device, can soon consume all disk space. Different applications will handle lack of disk space in different ways. It can lead to abrupt application termination as it encounters a situation for which it may not have been adequately programmed. This abrupt termination may lead to log file corruption.

Machine Logs

4.3.7. Format and Distribution Machine logs are typically generated as text files. Some use a proprietary text file format, but most use simple text file formats that are readable on both Windows and Linux machines by simple text editors. Linux and Windows server logs themselves both use simple text file formats. This makes the log files easy to work with, but also a challenging task when attempting to monitor many network devices. For example, each network device and application will generate their log files local to the machine they’re on. Thus, log files providing useful sources of attribution information may be distributed over many machines and over many individual files. The challenges of log file distribution and number can be overcome in part through the use of various parsing tools. For example, Microsoft Log Parser is a free tool for performing queries of distributed text files, either from the command prompt [361], or through commercially available GUIs [362]. Many other log file parsers can be found through simple searches.

Figure 4.3‐1: Log Parser Lizard GUI for the Microsoft Log Viewer Engine. A more specialized case of log file number involves web sites, such as those provided by web hosting providers or those that serve as the front end to organizations. The web servers of web hosting providers may host 500, 1,000, 10,000 or more websites, each of which may be configured to generate its own log. Even the web servers of single organizations, may be architecture to employ multiple sub‐websites, each of which may also generate its own web log. Attempting to review all of these files concurrently would be a severe challenge and resource intensive, and is thus often not performed.

Chapter 4: Attribution Challenges

For IIS (versions 6 and 7), two methods are available: centralized binary logging [363] and W3C centralized logging [364]. Both write log data for all websites hosted on a server to a single text file, the binary method writing much more compact unformatted text that must be read using a log parser, while the other writing in plain text that consumes larger file volumes [365]. Another option is to have the web server write logging events to a relational database server [379]. However, this approach may introduce significant performance constraints and is not recommended for high‐traffic web servers. These options address multiple websites on a single IIS web server. For Apache web servers, there are similar challenges. By default, Apache web servers maintain two logs: one for access and another for errors, both of which are written to the usual Linux log location, var/log [366], [367]. Where an Apache web server is hosting multiple web sites, it can be configured to write web site logs either per website or per server. By default, Apache writes all logging events to single instances of the access and error logs, and thus is configured by default for per‐server log writing. Where there are multiple websites and servers, such as for a web farm, IIS does not support central logging out of the box. To consolidate log files on all of the individual web servers, third party tools, [368], [369], and [370], or custom scripting methods must be used [371], [372]. These logs can then be imported into RDBMS for centralized archiving and retrieval. Apache web servers provide simpler consolidation options. Linux implementations support centralized logging, out of the box, using Syslog [373]. Apache 2.2 (the latest version as of the time of this writing) support Syslog writing of the error log, but not the access log. However, a variety of simple scripting methods and modules are available for also writing access log events to the Syslog server [374], [375], and [376]. And, as for IIS, commercial tools are available for consolidating Apache and other Linux log server and application log files [377]. However, every implementation will deploy such tools uniquely, and not every organization will employ such tools.

4.3.8. Summary There are a variety of challenges associated with obtaining useful attribution information from the devices that are the target of an attack or through which a cyber‐attack traverses. These challenges may be due to the nonexistence of attribution information, corruption, inadequate detail, administrative policy, and variations in format and distribution.

4.4. Proxy Servers Proxy servers are used for a variety of legitimate and illegitimate reasons. The legitimate usages of proxy servers have already been discussed. Their illegitimate usage is often for abstracting or obfuscating the origin of a cyber‐attack. For example, a cyber‐attacker working from his or her own workstation will login to some server connected to the Internet, usually a server having legitimate purposes, such as a web server. From this server, the cyber‐attacker will then login to another internet‐connected web server, and so on, multiple times. Each of these servers most likely is a legitimate server having legitimate usages. The administrators of these machines most

Regional Internet and Domain Name Registries

likely are unaware that their servers have been compromised and are being used for malicious purposes. They are functioning as proxies for the cyber‐attacker. The use of proxy servers greatly challenges the attribution of a cyber‐attack, as establishing the evidentiary chain back from the target of the attack to its source requires that each proxy server be forensically examined for traces of the attackers’ presence and from what host the attacker logged into the server.

4.5. Regional Internet and Domain Name Registries Owners and registrants of domain names and IP addresses increasingly use privacy protection services that hide the actual owner or registrant. In some cases, the registry provides this service. In other cases, the privacy is provided by a proxy service and thus the registry may not know the owner or registrant at all. Additionally, the registry and proxy services may reside in different jurisdictions. Thus, the contact information for a domain name may not be valid or may not be obtainable. IP addresses and domain names can also be temporarily hijacked. For example, when a domain name expires, it is still temporarily attached to an IP address until that IP address is re‐ assigned. ISPs do not attempt to police legitimate domain name and IP address relationships. Thus expired IP addresses having invalid contact information can be used to avoid attribution [380]. Fast switching of domain names to IP addresses can make it all but impossible to trace DDoS attacks to bots. Domain name assignments to IP addresses can be updated in a matter of seconds [381]. This enables the creation of fast‐flux service networks (FFSN), which are a network of compromised computers having constantly changing public DNS records [382], [383]. Further obfuscation may be accomplished by having the DNS records point not to the bots themselves but to proxy servers; and even by changing the name servers used to record the DNS entries and using extremely short time‐to‐live settings for the DNS entries, forcing the requesting host (the target of the attack) to repeatedly obtain the latest DNS record update [382], [383]. Thus, the use of fast flux methods may make it all but impossible to adequately attribute DDoS attacks. However, such methods would not generally be employed for penetrative attacks, which require stable addressing in order to accomplish stable and consistent communications between the attacker and its target.

4.6. Jurisdictional Though not strictly a technical challenge, jurisdictional matters are presented here in that they greatly aggravate the other technical challenges discussed thus far. Cyber‐attacks can be launched from outside of target administrative, jurisdictional and national boundaries. The pathways that a cyber‐attack may traverse can cross multiple national boundaries. Therefore, in addition to the challenges of obtaining adequate attribution data from local and regional sources, added to these are the challenges of obtaining these same kinds of attribution data from countries having differing laws, regulations, business policies, customs, and diplomatic relationships with the

Chapter 4: Attribution Challenges

country in which the target resides. Some, such as the members of the European Union, may have reciprocal arrangements with the United States to share cyber‐attack attribution data. Others, such as China, may not or may choose not to share such information.

4.7. Chapter Summary Attempting to attribute a cyber‐attack begins by gathering evidence for it. As in any criminal analysis, the crime must be associated with a perpetrator. In the case of computer and network forensics, a causal path must be demonstrated from the target computer or network device of the attack to the computer from which the attack was launched – otherwise known as traceback, back tracing, or backtracking. Traceback is accomplished by reviewing the logs and other types of attribution data of each device that the attack involved. Obtaining such information may pose many technical challenges, not the least of which may involve inadequate detail, corruption, or even the inability to actually obtain such information. New methods of hiding attribution, including fast‐flux methods, and that cyber‐attack may occur across one or more jurisdictional boundaries, merely serve to exacerbate these technical challenges.

Chapter Summary

Chapter 5: Analysis

5. ANALYSIS 5.1. Overview In this chapter, the discussions of the previous chapters will be synthesized in order to examine the specific attribution challenges associated with the two primary types of cyber‐attack, DDoS and penetrative, and the different types of attribution challenges associated with each of them. In the former, the attacker is unconcerned with return communication, and thus the packet source address is useless in back tracing. In the latter, return communication is desired, and packet source addresses are valid and useful in back tracing.

5.2. Attribution in DDoS Attacks The cyber‐attacker in a DDoS attack has absolutely no interest in maintaining an end‐to‐end communication link with the target of the attack, but is only interested in one‐way communication. The purpose of such attacks is disruption of services. To accomplish this disruption, the cyber‐attacker causes so much traffic to be sent to the target that it its resources are overloaded in attempting to respond to this traffic. The traffic that is sent to the target involves malicious TCP/IP packets having spoofed or erroneous source addresses. These malicious packets are sent from thousands, tens of thousands, and even hundreds of thousands of hosts geographically distributed worldwide. Attempting to perform a standard analysis of the attack – back tracing it – rapidly encounters severe challenges that all but prevent further productive effort. A sense of these challenges can be gained by reviewing Figure 5.2‐1. This figure presents a greatly simplified depiction of a DRDoS attack network, showing just the paths for single instances of a reflector, bot and zombie associated with a botnet. An actual botnet would feature multiple zombie, bot and reflector instances – zombie instances occurring in the tens or hundreds, and bots and reflectors in the thousands to hundreds of thousands (perhaps even in the millions). As can be seen from this figure, a DRDoS attack may involve multiple ISPs and IXPs and cross multiple national boundaries. Reflectors, bots, and zombies are deployed to not only to scale attack resources but to also hide and prevent attribution for attacks. Performing a productive traceback of a DRDoS attack would require the cooperation of these ISPs and IXPs. Where such cooperation is forthcoming, ISPs and IXPs have the tools and procedures already deployed, as well as the experience, for performing effective back tracing. ISPs and IXPs are in the business of providing internet access; not policing it [384]. However, they do have every interest in looking after their customers’ interests and in working with other ISPs to resolve DRDoS attacks [385]. ISPs and IXPs can perform traceback where a DRDoS attack source is determined to be within their service networks; and recall that, as discussed previously, DRDoS attacks may have numerous sources (i.e., multiple bots). However, where an attack source is determined to be outside the ISP or IXP service networks, traceback efforts, even for ISPs, are not generally operationally feasible [386].

Attribution in DDoS Attacks

Figure 5.2‐1: Example illustration of various actor involvements for a typical DRDoS attack.

Chapter 5: Analysis

Performing a productive traceback also requires rapid response, as the actual DoS attack duration is typically measured in bursts of activity lasting minutes and hours, though the overall attack may last days and weeks [387], [388], and [389]. Thus, ISP and IXP resources must be mobilized almost instantaneously in order to be able to effectively begin traceback efforts – something which, while technically feasible, may be hindered by administrative and communications limitations. There are a number of methods for attempting attribution in denial of service attacks [1], [2], [3], and [4]. All of these meet similar challenges posed previously and are primarily reactive in nature. ISPs have a variety of tools for identifying whether the attack source is from within their networks or without. If from within their network, then they can rapidly and affectively contain the problem through appropriate router controls. If from without the network, ISP options are limited to mitigation or attenuation of the problem [386]. Indeed, attribution of DoS cyber‐attacks is possible though it may require significant expenditure of resources and sustained commitment, as well as the involvement of multiple cooperating parties, among industry and government [390]. DoS attacks exploit inherent vulnerabilities of the TCP/IP protocol suite in IPv4 and the architecture of the Internet itself. While IPv6 will mitigate some of these vulnerabilities, other denial of service vulnerabilities will continue to exist [391] and new ones have been introduced with the advent of IPv6 [392], [393], and [394].

5.3. Attribution in Penetrative Attacks In penetrative cyber‐attacks, the attacker is interested in establishing two‐way communication with the target. The purpose of penetrative cyber‐attacks is to first, gain control over the target, and second, harvest information from the target or exploit target capabilities, such as its access to other potential targets or its control over network devices in turn. To accomplish such penetration, the attacker may attempt to exploit vulnerabilities of the Internet‐connected device, or induce an internal user to inadvertently and unknowingly install a Trojan that provides a backdoor into the target network. The traffic that is sent in a penetrative attack is necessarily two‐ way, and thus the opportunities for obtaining useful attribution data are significantly greater. In this case, performing a traceback of the attack standard considerably greater probability of success, as the attack may leave a number of traces all along the attack pathway, and it may not be necessary to perform segment‐by‐segment back tracing. Some understanding of this attribution effort can be seen from Figure 5.3‐1. This figure presents a simplified illustration of the communication link between an attacker and a compromised workstation or other network device or computer. This illustration assumes that the workstation was compromised through the installation of a Trojan. The Trojan communicates with a zombie server, which in fact is another compromised machine connected to the Internet and that may function both as a source of updates and additional software to the Trojan and as a controller of the trojan. The attacker maintains contact with the Trojan either directly or through a series of proxies (shown) that introduce layers of abstraction that serve to hide attribution or at least make it more difficult. The proxies may also serve as temporary storage locations for stolen information.

Attribution in Penetrative Attacks

Figure 5.3‐1: Example illustration of actor involvements for typical penetrative attack

Chapter 5: Analysis

Performing a back trace on a penetrative attack encounters similar challenges as for denial of service attacks. Sources of attribution may be inadequate or missing due to hardware and software issues, administrative policy, etc. Where the attack path crosses jurisdictional boundaries, the cooperation of one or more ISPs, IXPs, and national governments may be needed. However, these challenges may be more easily surmounted due to the very nature of the communication itself, it being end‐to‐end and in this case, the source addresses of the packets being valid. Granted, proxy services may be employed to anonymize transmissions, but a physical end‐to‐end path must exist if the penetrative attack is to be useful. Therefore, forensic analysis may employ obvious simplifications over the course of the back trace effort. For example, as the source address of any packet received by the target network (and intended for the compromised workstation) must be valid, and from thence backwards to the next proxy or even attacker workstation itself, the attribution effort may hop over intervening networks directly to end points, such as the zombie server acting as the controller for the trojan, intervening proxies, or even the attacker network or workstation itself. One wrinkle in the attribution effort is that if the ultimate destination IP address should be identified, it’s unlikely that this is the actual IP address of the workstation used by the attacker. More than likely, it is simply the IP address of the Internet‐facing modem, router, or NAT of the organization or SOHO network in which the attacker workstation resides. Or it may be the gateway address to a large organization, such as a government agency, or corporate or university office. Still, this represents a significant step in attribution, as it identifies a significant organizational identity or point of accountability associated with the attacker. If the attacker is found to be within the national boundaries of the attacker’s target, law enforcement judicial services and resources can be called upon to address and perhaps even resolve the attack. If the attacker is found to be outside the national boundaries of the attacker’s target, the matter becomes a diplomatic one and possibly subject to whatever agreements may exist between the two countries for law enforcement mutual support. Cyber‐ attacks in the context of industrial control systems pose a distinct challenge to attribution. Modern industrial control systems implement standard computer network methods and approaches, and thus are subject to the same attribution challenges as any other computer network. However, industrial control systems generally feature the widespread usage of specialized hardware, such as PLCs and RTUs, for the control of analog devices. These hardware devices generally do not feature the kind of logging directly useful in attribution efforts, such as traffic and authentication logging. This is due to the architecture of such devices, which is often completely solid state and does not generally feature dynamic storage options for maintaining extensive logging capabilities. Rather, they usually feature data or configuration logging, which are not directly useful in attribution but do provide helpful information (if secured) as to device integrity. In general, attribution in penetrative cyber‐attacks poses fewer challenges than for denial of service, and for penetrative attacks, there is the real possibility that technical attribution can be accomplished; and, if the attacker is located in the same country and the target of the attack,

Chapter Summary

there is also the real possibility that human attribution can be accomplished as well. The sources for attribution in penetrative cyber‐attacks are similar to those in denial of service attacks, as both types of attack use the same network devices and methods of communication. These sources will continue to be available into the future, even with the increasing usage of IPv6. Nor will the implementation of IPv6 hinder the effectiveness of trojans to build backdoors into otherwise secure systems. In fact, IPv6 may serve to significant hinder adequate monitoring of penetration attacks, as the details of such attacks, buried in the transmission IPv6 packet, will be encrypted and thus hidden from traffic monitoring tools. While packet contents may be hidden, source and destination addresses will continue to be available.

5.4. Chapter Summary There are specific attribution challenges associated with the two primary types of cyber‐attack, DDoS and penetrative, each presenting different attribution challenges. In denial of service attacks, the attacker has no interest in return communication from the target of the attack and thus the packets sent to the target do not have valid source addresses, severely hindering attribution from the start. In penetrative attacks, end‐to‐end communication is desired and thus an attribution trail is available from the start. In both types of attack, the attacker may employ various methods to deny or hinder attribution, such as the use of proxy servers to abstract attribution. The attacker may employ these methods and may even perform the attack from outside the jurisdictional boundary of the attack target, introducing further hindrances to attribution. So significant are the challenges to attribution in these cases, and the concomitant resources need to perform attribution, that affected parties generally choose to forgo judicial remedies and instead pursue primarily defensive strategies; and this is particularly the case where the source of the attack is found to lie outside of the national boundaries of the attack. A distinctive subset of penetrative cyber‐attacks is that involving industrial control systems. These generally feature devices that usually have few if any of the logging capabilities usually found standard networking and computing equipment.

Chapter 6: Conclusions

6. CONCLUSIONS Cyber‐attacks launched over a computer network fall into two general categories, DoS and penetrative. A DoS attack involves a large volume of Internet traffic being sent to the target network and computer systems to such an extent that they are overwhelmed by the traffic and are no longer able to adequately function, thus denying service to their normal users. The kinds of traffic sent to the target machine may involve simple requests for the web page hosted by the machine or they may exploit known limitations of TCP/IP architecture. Denial of service attacks take advantage of fundamental vulnerabilities in Internet architecture, specifically the insecurity of the packet network and in the routing protocol used. There are limited source of information for attributing such attacks, and obtaining this information can present significant challenges. These challenges are associated with fundamental vulnerabilities associated with the TCP/IP protocol and the routing and infrastructure of the Internet itself. While IPv6 will mitigate some of these vulnerabilities, other denial of service vulnerabilities will continue to exist and new ones have been introduced with the advent of IPv6. Additionally, there are high cost barriers to performing attribution. Performing attribution for DoS attacks is resource intensive. The high cost barrier to DoS attack attribution can be surmounted, where it seems the cost‐benefit analysis favors this, but, otherwise, affected organizations are likely to take a defensive approach. Lastly, attribution efforts face ever more sophisticated and complex methods used by attackers to hide and prevent attribution. Beginning with single host attacks, which performed fundamental DoS attacks on Internet‐connected machines, such attacks have grown to span multiple geographically distributed hosts interconnected in ever more complex ways in order to abstract attribution. Thus, denial of service attacks will likely continue to exist and present attribution challenges into the future. Penetrative cyber‐attacks generally involve gaining control over the target computer system to such a degree that it can be made to perform tasks and execute commands at the discretion of the attacker. Once the attacker has gained control over the target system, the attacker can use it for benign, exploitative, or even destructive purposes. Penetrative cyber‐attacks may be performed against any computer system. They may be performed internally or externally. Internal penetrative attacks occur through the installation of a trojan, which creates a backdoor so to speak into the target system that can subsequently be exploited by the attacker. External penetrative attacks may involve the exploitation of vulnerabilities existing within Internet‐connected network devices – commonly being web servers – which though usually situated in a separate DMZ network are nevertheless connected to the organizational network via various secured transmission paths for ease of operations and maintenance of the internet connected device. In many cases, the DMZ may not actually reside on a separate physical network at all but share the same physical Ethernet as other organizational network devices, being separated in this case through appropriate domain configuration. Penetrative cyber‐attacks have potentially greater consequences than denial of service attacks, and they may involve the actual disruption or even destruction of critical resources and services or the loss or theft of significant corporate or government information resources with national security impact.

Chapter 7: Matters for Further Research

7. MATTERS FOR FURTHER RESEARCH Industrial control systems pose unique attribution challenges. While modern industrial control systems increasingly employ networking equipment that features the standard logging capabilities useful in performing attribution, they also employ hardware devices that have not historically featured such capabilities. This was due to such considerations as cost, architectural limitations, and perceived need. The recent spectacular penetration of an industrial control system and its resultant consequences, as occurred in the Stuxnet infiltration of the Bushehr nuclear facility in Iran, demonstrates the need to consider methods of attribution for such devices. Such consideration should examine to categories for implementing such attribution: that for legacy devices and that for engineering such devices. At present, there is a large deployed base of industrial control system devices, many, if not most, of which lack attribution capabilities. It would not be practical or operationally feasible to re‐ engineer such deployed devices. Instead, it would be more productive to develop a framework of procedures, administrative steps, configurations, and perhaps even software that can be added as an overlay to an existing industrial control system in order to add to it attribution capabilities for industrial control system devices. A guide published by the US Department of Homeland Security [344] specifically focusing on developing forensic plans for industrial control systems presents a useful framework for industrial control system security. This guide delves in detail into the limitations of industrial control system devices and various strategies, even identifying key metrics that may be common to control devices and that would be useful in forensic analysis. This guide presents useful methods that address control system device security. In particular, this guide notes that field devices used in industrial control may lack effective logging capabilities and presents a few options for implementing such, but without venturing into detail on the means by which such logging capabilities might be added to field devices. Logging and auditing are two of the principle sources of attribution data in computer network forensics. Their absence with regard to field devices may present significant hindrances in developing attribution for autonomous, geographically distributed control devices. Developing a set of low‐cost or even open source tools, methods, and procedures for implementing such would be of great benefit to the owners of such devices and to society at large, depending as it does on such devices for critical infrastructure integrity and service delivery. Therefore, some matters for further research, stemming from the development of this paper, would be research into: 1) The state of the market with regard to delivering attribution capabilities to field autonomous, geographically distributed control devices; 2) Their improvement, where they exist;

3) New methods to accomplish the same; and 4) Proposals for integrating such methods into new field control device development and engineering.

Chapter 8: Annotated Glossary

8. ANNOTATED GLOSSARY Many of the definitions used in this glossary were obtained from Wikipedia. 802.11 This is a set of standards maintained by the Institute for Electrical and Electronics Engineers (IEEE) LAN/MAN Standards Committee (IEEE 802) for implementing wireless local area network (WLAN) computer communication in the 2.4, 3.6 and 5 GHz frequency bands. These standards are those used by all electronics products using the Wi‐Fi brand name. This standard was originally developed by the IEEE in 1997 and provided for a data bit rate of 1‐2 Mega bits per second, using the direct sequence and frequency hopping spread spectrum transmission methods. It had an initial indoor range of approximately 70 ft and outdoor range of approximately 330 feet. This standard has undergone continually improvement and refinement since that time, passing through such variations as 802.11a, 802.11b, 802.11g, etc, to the standard current as of 2011, 802.11n, which has data bit rates of up to 150 Mbits per second, uses the Orthogonal frequency‐division multiplexing transmission method, and has approximate indoor/outdoor ranges of 230/820 feet (802.11n should not be confused with the Bluetooth wireless transmission protocol, which is used for short distance communication among devices. More on the Bluetooth standard can be found elsewhere in this glossary under Bluetooth). Security is maintained for standard 802.11n wireless transmission using the Wi‐Fi Protected Access (WPA) protocol version 2 (WPA2) for SOHO users and WPA2 along with RADIUS authentication for enterprise users. For additional information on the IEEE 802.11 standard, see: 1) Guide to Bluetooth Security, NIST Special Publication 800‐121, September 2008, http://csrc.nist.gov/publications/nistpubs/800‐121/SP800‐121.pdf. 2) DRAFT Guidelines for Securing Wireless Local Area Networks, NIST Special Publication 800‐ 153, September 2011, http://csrc.nist.gov/publications/drafts/800‐153/Draft‐SP800‐153.pdf. 3) 802.11, a Wikipedia article found at: http://en.wikipedia.org/wiki/802.11. 4) IEEE 802.11n‐2009, a Wikipedia article available at: http://en.wikipedia.org/wiki/IEEE_802.11n‐2009. 5) IEEE 802.11, PDF copy of the IEEE standard itself, available here: http://standards.ieee.org/getieee802/download/802.11n‐2009.pdf. 802.15.4‐2003 A standard, developed by the Institute of Electrical and Electronics Engineers (IEEE) 802 Standards Committee, for low rate data transmissions commonly used by small, low‐power digital radios, often run on long‐life batteries. …..Its focus is on the low‐cost, low‐speed communications common between devices, rather than with the end‐user (such as for the Wi‐Fi 802.11 standards). Applications include wireless light switches, electrical meters with in‐home‐displays, and other consumer and industrial equipment that requires short‐range wireless transfer of data at relatively low rates.

It’s also the framework for standards focused on industrial applications, including: ZigBee, WirelessHART, and others. These industrial applications of the standard develop the upper layers of the protocol stack that are not defined in the base 802.15 standard. For additional information on this standard, see: 1) IEEE 802.15.4, a Wikipedia article available at: http://en.wikipedia.org/wiki/IEEE_802.15.4. 2) IEEE 802.15, PDF copy of the standard available here: http://standards.ieee.org/getieee802/download/802.15.4d‐2009.pdf. AAA See Authentication, Authorization, and Accounting. Access control list An access control list (ACL), with regard to computer and network systems, is a list of permissions associated with an object, such as a file, a task, an access screen, etc, and the kinds of operations that these permissions are allowed to perform. The ACL specifies which users or system processes are granted access to these objects and what operations are allowed. There are two fundamental kinds of ACLs: those associated with the file systems on computers and those associated with network connections. On computer systems, everything on the system ultimately resides as a file on some sort of storage medium, typically a disk. Even the control dialogs used to configure various aspects of computer operation are little more than files residing on the file system that contain all of the information necessary for creating the control dialog. To be sure, the control dialog may implement further user access control, but this is handled by the program itself and not the operating system. Access to files is controlled by matching the identity of the user currently attempted to access the file against the ACL, and then allowing access corresponding with that defined in the ACL. Typical permissions include: read, write, and execute. Many others are also defined. Network ACLs operate somewhat differently. A network ACL applies at the juncture of the computer device with the network communications system. A network ACL is applied by the operating system of the device to every new communication that attempts to connect to that device. Every new transmission carries with it an identity token maintained by an authentication system on the network. At the moment when a new transmission arrives at the port of a device, the identity token is authenticated, authorized, and then logged – a process often referred to as AAA security, or Authentication, Authorization, and Accounting. For additional information on ACLs, see 1) Access control list, a Wikipedia article available at. http://en.wikipedia.org/wiki/Access_control_list. 2) Access Control Lists, an MSDN article available at: http://msdn.microsoft.com/en‐ us/library/aa374872(VS.85).aspx. ACL See Access Control List. Address Resolution Protocol This is an IPv4 network protocol used for the resolution of network layer addresses into link layer addresses. A network layer address is the more formal name for what is commonly called

Chapter 8: Annotated Glossary

an IP address. A link‐layer address is the more formal name for what is commonly referred to as a MAC address (media access control address). ARP enables the translation from one to the other. It is a non‐routed protocol and exists only within a network. It is used to locate the Ethernet (or MAC) address associated with a specific IP address. For example, when a computer on a network wants to send a message to another computer located on the same network, it sends an ARP broadcast onto the network to which it is attached. A computer or network device that receives this broadcast and which has the IP address indicated in the broadcast, will respond to the broadcast with its link‐layer (MAC) address, thus identifying the appropriate computer. The computer that initiated the broadcast then receives this response and stores this information in its ARP cache for future transmissions. For additional information on ARP, see: 1) Address Resolution protocol, Wikipedia article available at: http://en.wikipedia.org/wiki/Address_Resolution_Protocol. 2) Guide to IP Layer Network Administration with Linux, available here: http://linux‐ip.net/. ARP See Address Resolution Protocol. Authentication, authorization and accounting With regard to computing system security, authentication, authorization, and accounting refer to the three pillars of computing system security. Authentication refers to the process where an entity’s identity is checked or verified against a previously defined list of entities allowed to have access. This entity, which could be a user, or even a machine process, is associated with some sort of identifier, such as a digital certificate, that enables the process performing the authentication to verify the identity. If the identity is verified, the entity is then allowed access into a system (for example, from a network) or access to an object on the computing system. However, successful authorization doesn’t immediately lead to actual access. For access to be determined, the entity must then be authorized. Authorization is the process of determining what types of interaction an entity may have with a system of object, once it has been authenticated. There are varying types of authorization and these are usually referred to as permissions. For example, one permission might be that the authorized entity can read the object. Another permission might be that the entity is authorized to execute the object (i.e., run a program). And another permission might be that the entity is authorized to edit or delete the object. May other types of permissions may also be defined. Whatever they may be, each permission defines a type of action that may be performed. Thus, there is a one‐to‐one correspondence between a permission and an action. Permissions can be combined in various ways to create hierarchies of access. The top level could be comprised of all of the available permissions, otherwise known as administrative (Windows) or root (Unix) access. The lowest level might comprise merely the read permission. And there may be varying levels in between, each comprising some subset of the available permissions. Accounting refers to the process of auditing or tracking access to an object, and then documenting it to a log for subsequent review – this process keeps an account, as it were of what an entity is doing with respect to an object. Auditing may involve merely logging successful attempts to access an object, logging the identity, date and time of the access, or it

can involve logging not only successful, but also unsuccessful access attempts and even what actions were performed on the object by the entity. Accounting enables such efforts as capacity analysis, trend analysis – both of which are necessary in adequately planning resource support into the future. Accounting also enables security analysis, useful in monitoring authorized usage and in attempting to forensically determine attribution for attempted or actual attacks. For additional information, see: 1) Draft Electronic Authentication Guideline, NIST Special Publication 800‐63 Revision 1, June 2011, http://csrc.nist.gov/publications/PubsDrafts.html. 2) Guide to General Server Security, NIST Special Publication 800‐123, July 2008, http://csrc.nist.gov/publications/nistpubs/800‐123/SP800‐123.pdf. 3) AAA Protocol, a Wikipedia article available here: http://en.wikipedia.org/wiki/AAA_protocol. AutoRun AutoRun is a component of the Microsoft Windows operating system that dictates what actions the system takes when a drive is mounted. It enables media and devices to launch programs by use of commands listed in a file called autorun.inf, stored in the root directory of the medium. It was originally introduced in Windows 95 as a convenience to users to have music automatically begin, once a music CD was installed or have a program automatically install or even be launched, after inserting a CD. This feature was also triggered by the detection of any new drive type, including USB. This feature was enabled on Windows 95 by default. This feature was changed somewhat in Windows XP, which introduced a context menu that appeared when new media was detected. The context menu allowed users to choose what actions they wanted the system take. Windows XP also separated the playing of media, such as movies and music, from the running of programs. Windows XP further introduced media recognition, enabling the operating system to detect what sort of content was resident on the inserted media and then launch the appropriate application to play the media (e.g., AVI files) or display content (e.g., Microsoft Word document). This feature was also enabled on Windows XP by default. Unfortunately, while certainly providing a convenience to many users, AutoRun also provided a convenient opportunity for malware loading and installation. In versions of Windows prior to XP, any file on any media type, even network drives, could be launched without user intervention. In Windows XP and later versions, media continued to be played automatically, by default (AutoPlay), but programs were not (AutoRun). The AutoRun/AutoPlay feature has been further restricted in Windows 7, which enables AutoPlay (media) only for CDROMs. Just how prevalent was the use of the Windows AutoRun feature to install malware is noted in a post of the Microsoft Threat Research and Response Blog. An update was released in the summer of 2011 that substantially restricted AutoRun further by preventing AutoPlay from being enabled automatically, except for CDROMs and DVDs. The update resulted in a 62% reduction in detected malware intrusions for XP SP3, 68% reduction for Vista SP1, and an 82% reduction for Vista SP2. Windows 7 experienced negligible change with this update, as it already included the restrictions. For additional information, see: 1) Guide to General Server Security, NIST Special Publication 800‐123, July 2008,

Chapter 8: Annotated Glossary

http://csrc.nist.gov/publications/nistpubs/800‐123/SP800‐123.pdf. 2) AutoRun, Wikipedia article available here: http://en.wikipedia.org/wiki/AutoRun. 3) Autorun‐abusing malware (Where are they now?), Microsoft Threat and Response Blog, June 14, 2011: http://blogs.technet.com/b/mmpc/archive/2011/06/14/autorun‐abusing‐malware‐ where‐are‐they‐now.aspx. Back tracing See TraceBack Backbone In the context of computer networking, the backbone is that portion of the network infrastructure that interconnects the different subnetworks that comprise the overall network and thus enables the different portions of the overall network to communicate with one another. A network backbone thus acts as a bridge between different parts of a larger network. The Internet backbone performs a similar function. The Internet backbone is that portion of the Internetwork that joins the various geographically distributed subnetworks of the Internet worldwide. In this context, the Internet subnetworks are provided by the various Internet Service Providers, or ISPs. The Internet backbone then is provided by the IXPs, some of which operate nationally only (e.g., Sprint), and connect to ISPs and each other at Internet exchange points; and others that operate internationally (e.g., Verizon) and that also connect ISPs and to each other at Internet exchange points. This whole conglomeration of ISPs and IXPs comprises the overall global network commonly called the Internet. For additional information, see: 1) Internet Backbone, a Wikipedia article available here: http://en.wikipedia.org/wiki/Internet_backbone. Backtracking See Traceback. Bot A bot is a term generally used to refer to a computer that is connected to the Internet and that is able to perform automated tasks and thus acts as a robot. Such bots include the automated assistants one sometimes sees when connecting to a website. They include the spider bots that capture information on websites for use by search engines, such as Google, Yahoo, Bing, and others. Other types of spider bots exist that also capture website information (such as articles) but for re‐use without permission. More sophisticated bots have been used to perform automated trading, such as on eBay; activate ads on commercial websites in order to artificially inflate user activity and thus increase advertisement revenue illegitimately. Still another type of bot is used for performing DoS cyber‐attacks. A computer that has been maliciously compromised and that is used to send DoS attacks against other computers is also referred to as a bot. In this case, the bot is typically a user computer that has resident malware able to perform various kinds of DoS attacks. The bot is usually part of a much larger collection of similar bots referred to as a botnet. The attacker controls these bots indirectly through zombie computers in order to obfuscate traceback, amplify the attack, and simplify administration. The owners of the server and client computers

will not be aware that their computers have been compromised. A user computer is turned into a bot typically through the inadvertent installation of malware, usually a trojan, that enables the attacker to take control over the computer and use it for malicious purposes. Bot‐type malware can be installed through spam email containing malicious links to downloadable software; in the search results; and even embedded in the web pages of both legitimate (but compromised) and malicious web sites. For additional information, see: [17] and [23]in the References section. Botnet A term used to refer to a distributed network of bots, all under the control of one or more human operators. A defining characteristic of a botnet is the use of command and control servers, communicating through Internet Relay Chat (IRC) channels, to oversee and manage the botnet farm. The number of bots in a botnet can vary widely, from one to as many as 30 million, as reported by Krebs on Security. Botnets can massively scale the capabilities of individual bots, thus their attractiveness to various malicious exploits. Botnets also abstract attribution by geographically distributing bot capabilities across jurisdictional boundaries. For additional information, see [23], [24], [25], [34], [35] and [36] in the References section, or see the links below: 1) Bredolab Mastermind Was Key Spamit.com Affiliate, Krebs on Security, October 2010; http://krebsonsecurity.com/2010/10/bredolab‐mastermind‐was‐key‐spamit‐com‐affiliate/. 2) Guidelines on Securing Public Web Servers, NIST Special Publication 800‐44 Version 2, September 2007, http://csrc.nist.gov/publications/nistpubs/800‐44‐ver2/SP800‐44v2.pdf. C&C Server See Command and Control Server Call Detail Record A call detail record (CDR) logs the details of a telephone call placed with a telephone service provider. Call detail records are maintained by telephone service providers for billing purposes, in order to be able to accurately determine charges. The customer billing statement that lists calls made and received is a form of call detail record. The CDRs maintained by the telephone service provider contain much more detail than that typically seen in the customer billing statement. The CDRs maintained by a telephone service provider typically contain the following details of every call: ‐ The telephone number of the calling party ‐ The telephone number of the called party ‐ The date and time that the call was made ‐ The date and time that the call was completed or its duration ‐ The telephone number of the party that was charged for the call ‐ An identification number associated with the telephone service provider that wrote this call detail record ‐ A unique sequence number identifying this call detail record itself ‐ Any additional digits associated with the calling telephone number that were used to help route or charge the call ‐ The result of the initial call attempt (whether it was connected, busy, denied, etc.)

Chapter 8: Annotated Glossary

‐ The route by which the call was entered into the telephone service provider’s exchange ‐ The route by which the call exited the telephone service provider exchange ‐ The type of call (voice, SMS, etc) ‐ And any fault condition that may have occurred. Exactly which fields are included in the CDR is dependent on the particular telephone service provider. For additional detail, see: 1) Call Detail Record, a Wikipedia article available here: http://en.wikipedia.org/wiki/Call_detail_record. CDR See Call Detail Record. Command and Control Server A command and control (C&C) server (also known as a zombie) is a computer connected to the Internet that has been maliciously compromised and that is used to control other maliciously compromised computers. It is typically associated with a botnet, which is a geographically distributed network of compromised computers (see Botnets in this glossary for additional detail). It provides an essential function for the operation and support of a botnet. Fundamentally, it acts as an intermediary between the botmaster, or herder, and the bots themselves. There may be several one or more tiers of C&C servers, each providing controlling some set of C&C servers beneath it. Whether a compromised computer is used as a bot or as a C&C server is entirely arbitrary and dependent on the determination of the botmaster. Two primary configurations for C&C servers have been identified: centralized and P2P. A third configuration, randomized, is theoretically possible but has not yet been developed. The centralized configuration is the most readily understood. It is easily configured, hierarchical, rapidly deployed and thus minimally resource intensive. It can command and control the largest number of bots. It is also the easiest to eliminate, in that it can be more readily identified, given that bot communications traffic will all be directed at static targets that, through various attribution methods, can eventually be traced. Then, given that the bots it supports are configured to communicate with these statically determined C&C servers, the elimination of one or more C&C servers has significant affect on the control of the botnet. The P2P architecture is a distributed one, having no centralized command structure but taking their orders and direction from their peers, as these are learned. The botmaster need send commands to only one of these C&C servers in order to trigger a cascade (often referred to as a storm) of activity. In contrast to the centralized architecture, the P2P architecture is more resilient to having one or more C&C servers eliminated. There is no centralized structure that, if removed, would incapacitate the botnet as a whole or that would have any significant material affect. On the other hand, P2P technology is limited in the number of C&C servers that can be networked in this way, and thus the overall size of the botnet is also limited. C&C servers communicate with each other primarily using the IRC or HTTP protocols. The IRC protocol is designed primarily for one‐to‐many communication, but can also support one‐to‐one communications and is thus ideal for botnet communications. This protocol is usually never enabled on enterprise networks and thus its appearance on an enterprise network is a good indication of an infection. The HTTP protocol is also used. Due to the prevalence of HTTP

protocol in web browsing, the use of this protocol for communications can make such communications much more difficult to identify. In fact, it can allow a bot the communicate through most firewalls, configured as they are to allow transmission through port 80, the default HTTP port. However, HTTP used for communications will feature different header and payload content than the usual browser traffic, and thus deep‐packet inspection methods will uncover such traffic. New communication methods emerging are P2P and the Instant Messaging (IM) protocols already being used for legitimate uses but that are expected to be used for illegitimate uses in the future. For additional information on C&C servers, see [17], [22], [23], [24], [35], [38] and [39] in the References section, or see: 1) Taxonomy of Botnets, Valerie Buitron et al, Northwestern University, undated: http://www.cs.northwestern.edu/~ychen/classes/msit458‐s09/Botnets_defense.ppt. Cross‐site‐scripting Cross site scripting (XSS) refers to a class of web browser vulnerabilities, in which the user's web browser is tricked into executing small bits of script (e.g., JavaScript) that introduce untrusted content and enable the attacker to bypass web browser access controls and gain access to sensitive information, redirect the user's browser to malicious sites, or even to cause the unsuspecting user's browser to perform attacks against another web server. At their peak in 2007 of comprising over 80% of all security vulnerabilities, improved detection techniques and greater risk awareness have since dropped this down to less than 50% in 2010. Cross‐site scripting vulnerabilities are not prevented by anti‐virus software. The AV software may detect and prevent the consequences of an XSS vulnerability being exploited, i.e., malicious software being executed, but it cannot prevent the XSS from occuring. They cannot be prevented by using different browsers. All browser types are susceptible. The Cross site scripting problem revolves around two primary issues: 1) the inherent trust the browser has in content sent to it from the web server, in that the browser assumes it is using HTML and that any characters sent to the browser should be interpreted according to the HTML specification; and 2) the ability of browsers to execute script embedded within the web page content they are sent by the web server. In HTML, the web server notifies the browser of special content by using special characters, such as "<" and ">", which enclose special commands to the browser. Whenever the browser reads these special characters and commands in the content stream sent to it, it trusts their validity. Now, tags can either affect the formatting of the content the browser receives or introduce additional commands or even script (e.g., JavaScript) that the browser is supposed to execute. For example, if the tags create an embedded iFrame pointing to a malicious website, the user's browser will attempt to load that website into the iFrame. The user will not see this, as the iFrame can be configured to not be displayed on the main web page that the user sees. The iFrame then connects to the malicious website, and then executes whatever script is embedded in the website content. These tags may also contain embedded format data, not visible to the user, that can be submitted to other sites ‐ thus the "cross" in cross‐site scripting. This can be exploited in order to bypass security restrictions. For example, a user's browser may be configured to trust

Chapter 8: Annotated Glossary

websites within an organization at a higher level than websites on the Internet. By default, browsers are configured to execute any script embedded in the content stream sent to them from the web server. This script will run at the same security level as the user and will be able to interact with any of the usual objects maintained by the browser, such as cookies, and the web page document object model (DOM). Being able to execute such script enables the attacker to retrieved sensitive and private data and to also make the attack persistent, in that the XSS exploit will leave information on the user's computer that retain a history of the current attack. For additional information on Cross site scripting, see: 1) Cross‐Site‐Scripting in Wikipedia: http://en.wikipedia.org/wiki/Cross‐site_scripting 2) Cross‐site Scripting Overview ‐ the original article on this vulnerability, written by Microsoft engineers David Ross et al: http://ha.ckers.org/cross‐site‐scripting.html 3) XSS Attacks, Jeremiah Grossman, Syngress Publishing, 2007. DCS See Distributed control system. DDoS See Distributed Denial of Service De Militarized Zone A DMZ is a term used by those in computer networking to refer to a special zone of an enterprise network that is configured in such a manner that it is accessible both from within the trusted enterprise network but also from an untrusted network, usually the Internet. The DMZ enables the enterprise to deploy an asset, such as a web server, to the Internet while maintaining communication with that asset for operation and maintenance purposes. Network assets, such as servers hosting web service applications (e.g., IIS or Apache) that in turn host web software (e.g., SharePoint, WebSphere, etc) are placed into the DMZ to provide Internet‐ accessible services, such as retail (Amazon, Sears, eBay, etc) or governmental (libraries, local government services, federal e‐services, etc.), but with which enterprise IT can still maintain convenience communications with for operations and maintenance. This is the common approach for web‐deployed assets by enterprises, worldwide. DMZs are also deployed as a means of securing vulnerable network assets, such as email and domain name system servers, which are often the targets of attack. By placing such assets into a DMZ, and then shielding this DMZ from the rest of the enterprise network through a firewall, the enterprise network is better secured in the event of a breach in email server or DNS server security. In this fashion, a breach in security in one portion of an enterprise network can be more effectively contained from the rest of the enterprise network. A DMZ can be accomplished through physical separation and through appropriate domain configuration. In a physical separation, communications with the assets in the DMZ must pass through a firewall or through a switch or router or through both. If the ZDMZ is deployed through domain configuration, both the authentication system and the assets in the DMZ are configured for different logical domains –though they may actually be connected to the same physical Ethernet. The second approach is much less secure. Web servers are a common attack target for the very reason that they can provide a direct

entry into the enterprise network. Comprising and gaining control over an enterprise web server does not automatically presume entry into the enterprise network, as one or two firewalls must still be traversed. However, once the web server is compromised, the attacker can begin the process of sniffing network traffic and exploiting possible firewall vulnerabilities in order to break through firewall and gain entry into the general enterprise network itself. For additional information, see: 1) DMZ (computing), a Wikipedia article available here: http://en.wikipedia.org/wiki/DMZ_(computing). Denial of service A denial of service situation, in the context of computers and computer networking, occurs whenever a computer or network resource becomes unavailable to its users due to that computer or network resource being forced to consume its resources to such an extent, that it is no longer able to perform its normal duties. In this context, a denial of service (DoS) cyber‐ attack is fundamentally a purposeful attempt to make a computer resource unavailable to its users. There are a variety of ways of forcing a computer to consume its resources. These may involve overloading the target computer with numerous transmissions sent to it over a network. For example, a web server might be sent tens of thousands or even millions of connection attempts. The overwhelming number of connection attempts overloads the operating system of the server hosting the web application software, preventing legitimate users from trying to connect to the web server and viewing its resources. Or the target web server might be sent large numbers of ICMP echo requests. An ICMP echo request, otherwise known as a PING response, require insignificant processor attention. However, the resource usage does become significant when a million such requests are presented to the target server. Other types of attack are also possible. Whatever the actual type of attack, their purpose is the same: force the target resource to use all available resources and thus prevent its adequate response to legitimate users. The targets of such attacks may be web servers connected to the Internet, and these are the typical targets of such attacks that are commonly reported in the media. However, DoS attacks may be performed against a number of other types of targets. For example, intentional DoS attacks may be performed against networks themselves. An ISP may be the target of such an attack. This attack would be performed by overloading one or more of the routers servicing the ISP – perhaps that router that connects the ISP to its IXP providing Internet access. By attacking this router, members of the ISP network would still be able to connect to each other, but they would effectively be denied Internet access. DoS need not only be accomplished through the involvement of numerous hosts sending malicious transmissions. It can also be accomplished through a single malicious software infecting a computer resource and then causing it use all of its resources – perhaps in performing some complex mathematical computation, or performing some other task numerous times. DoS situations may also occur indirectly. For example, self‐propagating viruses may so overload an organization network, or even the Internet itself, that they create DoS situations, even though this was not the intended affect. The Moris, SQL Slammer, and Blaster worms are only a

Chapter 8: Annotated Glossary

very few examples of such DoS situations that were unintentional side effects of other forms of cyber‐attack. For additional information on DoS, see references [7], [8], [10], [12], [13], [15] and [16] in the References section or see the references below: 1) Denial‐of‐service attack, a Wikipedia article available here: http://en.wikipedia.org/wiki/Denial_of_service 2) Guide to Integrating Forensic Techniques into Incident Response, NIST Special Publication 800‐86, August 2006, http://csrc.nist.gov/publications/nistpubs/800‐86/SP800‐86.pdf. Distributed control systems These are a very broad and diverse category of control systems comprising the various control systems found in industrial automation applications, from bottling and canning factories, to refineries, chemical processing, and power generation systems. In general, distributed control systems are found wherever process automation is needed and desired. While very broad and diverse, distributed control systems are usually comprised of a few distinguishing elements: including: ‐ Electric motors ‐ Sensors ‐ Input/output (IO) modules ‐ Electrical buses ‐ Network cable ‐ Analog/digital (AD) converters ‐ Programmable logic controllers ‐ Human‐Machine Interface (HMI) Electric motors in this case comprises all types, from those motors used in actuators and some switches, to those used in valves, and to those used in assembly lines, robotics and many other applications. They may be the micro‐motors used in highly precise measurements, to the very large motors used to control water gates in dams. Electric motors are found wherever physical control and movement are needed. Sensors are those devices able to measure some physical characteristic, such as voltage, movement, acceleration, temperature, acidity, pressure, flow, etc. Sensors may be used in a single control loop, where a pressure is monitored, and a release valve is actuated when and pressure exceeds a certain threshold. Or it may involve multi control loops, for three‐ dimensional control over movement, acceleration, and pressure, such as for a robot used in automobile assembly manufacturing. IO Modules are those devices that convert the analog signals of a device, such as a motor or sensor, to the type of signals used for transmission over the communications system. IO devices provide the interface that enables PLCs to control devices. Electrical buses are the cabling carrying the signals between devices and IP modules, PLCs and HMIs. In early distributed control systems, electrical buses were used for all transmissions, even those to the HMI and PLCs. In most modern distributed control systems, signal transmissions over long distances are usually done over standard Ethernet network, and the electrical bus has been pushed back to mainly the connection between the IO module and the devices that are

being controlled. The IO module is then joined to the network using AD converters. Network cable in distributed control systems may be the standard CAT5 cabling used in Ethernet networks, or it may involve coaxial cable, and even fiber optic cabling for maximum throughput and no electrical interference with other cabling and devices. AD converters are those devices that convert the analog signals generated by controlled devices or IO modules into signals that can be transported over common network cabling. Programmable logic controllers provide the actual control within a distributed control system. PLCs monitor sensors and then provide signals in response in order to control motors and switches. Early PLCs were entirely composed of hardware. Modern PLCs are essentially microprocessors; some are even dedicated PCs streamlined and focused on supporting process control. The typical PLC is comprised of hardware and embedded software – by embedded is meant that the software is actually burned into the memory of the PLC and cannot be erased or edited, as it is non‐volatile. Revising then controller software requires that the entire memory be re‐written, a process performed by attached workstations or workstations sending instructions and data to the PLC. The last significant part of a distributed control system is the human machine interface, otherwise known as the control center. It is at the HMI that people typically oversee the functioning of various controllers distributed in the bottling factory, the automobile manufacturing facility, the power plant, the city water distribution system, the city subway system, the nuclear power plant, etc. The HMI allows for human monitoring of the control system and supervisory control over it. From the HMI, technicians and engineers can monitor operations and take steps to ensure that various operational parameters are maintain within specified limits. For additional information, please see references [200], [201] and [203] in the References section or see: 1) Guide to Industrial Control Systems (ICS) Security, NIST Special Publication 800‐82, June 2011, http://csrc.nist.gov/publications/nistpubs/800‐82/SP800‐82‐final.pdf. Distributed Reflector Denial of Service A distributed reflected denial of service attack (DRDoS) is a type of DDoS attack that employs non‐compromised computers in order to further obfuscate attribution. This is accomplished by sending a spoofed ICMP echo request packet – having as its source IP address the address of the intended DDoS target – to a non‐compromised computer, which can be any Internet‐connected computer or server. The reflector then responds to the echo request in good faith, but actually sending it to the target. The use of reflectors substantially hinders attribution, as it introduces another layer of abstraction into the backtrace process. Back tracing from the target of the attack would quickly identify the reflector, but the reflector would have no audit trail indicating from exactly where it initially received the spoofed packet. Such information would have to be obtained by querying the ISP network hosting the reflector, and obtaining such information might be problematic. One of the earliest such reflector attacks occurred in January 2001 against Register.Com. This attacked employed DNS servers themselves as reflectors. The attack lasted about a week, before back tracing efforts managed to find most of the attacking hosts and stop their activity.

Chapter 8: Annotated Glossary

For additional information on DRDoS, see [7], [8], [10], [12], [13], [15], [16], [17], [22], [23] and [24] in the References section, or see the references below: 1) Denial of Service Attacks, a Wikipedia article available here: http://en.wikipedia.org/wiki/DRDoS 2) Distributed Denial of Service Attacks, Cisco Internet protocol Journal, Volume 7, Number 4, December 2004: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7‐ 4/dos_attacks.html 3) Distributed Reflection Denial of Service, a whitepaper by Steve Gibson of Gibson Research Corporation: http://www.cs.washington.edu/homes/arvind/cs425/doc/drdos.pdf. DMZ See De Militarized Zone. DoS See Denial of Service DRDoS See Distributed Reflector Denial of Service. Ethernet Ethernet is a family of computer networking technologies for local area networks (LANs). It is the common protocol used for computer networking, Standardized in IEEE 802.3. Ethernet is the method by which communications occur at the most basic level ‐ that of the physical signals themselves in transmission media. It is the standard that governs communication on the cable. Ethernet specifies a set of rules for creating frames, and each frame must have explicit minimum and maximum lengths. Ethernet involves the following critical components: ‐ Medium: the medium through which Ethernet signals are sent and to which all devices attach that are part of the Ethernet network ‐ Segment: refers to a single shared medium ‐ Node: a device that attaches to the segment and that may include workstations, printers, etc. ‐ Frame: a discrete portion of the overall information that is to be sent over the Ethernet, being of variable size, having a source and destination addresses that uniquely identify the sender and recipient of the frame Ethernet is a method for local networking, i.e., a single logical network, such as that for a home, or a building, and connecting devices in relatively close proximity. It is not a routable method for networking. The reason being that the addresses employed within an Ethernet network are those of the actual devices themselves – the MAC addresses. While such addresses may be unique – and must be unique – within a network, they may not be unique over several networks or over many networks. The early Ethernet was designed to work over coaxial cabling, a medium that enables devices to be attached to a segment relatively easily, by simply connecting them to the coaxial cable itself. In fact, in this initial implementation, a single coaxial cable can serve as the basis for a complete Ethernet network. However, there are practical physical limits to such a network, and one prominent one is the length of the cable itself. Electrical signals experience attenuation, as they travel through any medium. Thus, the physical distance separating devices is limited to that cable length over which two devices at opposite ends may still communicate. Another

limitation is the number of devices that can be connected to a coaxial network cable. As more devices are connected, the greater the opportunity for collisions, as devices compete to use the cable for transmission. With increasing number of devices, transmission delays increase as well. Modern Ethernet networks avoid the limitations of coaxial cabling by applying device segmentation. . In modern Ethernet implementation, devices are separated from each other through individual segmentation. In this approach, each device has its own cable, usually twisted pair, which connects to what is called an Ethernet switch, or aggregator, which in turn may connect with other switches to form the network. In this fashion, each device only sees Ethernet traffic associated with itself and not with other device. Instead, it is the switches that now manage traffic among their connected devices and then feeding that traffic onto the Ethernet medium between switches. Each Ethernet switch is dedicated to managing its segmented traffic and communication with other switches, making overall communications much more efficient and reliable. Networks in turn are joined by routers, which route frames, enclosed in TCP/IP packets, to their appropriate destination. The first Ethernet network was developed at the XeroxPARC research facility in the early 1970s as a method of joining a computer to a printer. Robert Metcalfe developed the fundamental theory of Ethernet in his PhD dissertation. Metcalf later left XeroxPARC to fond 3Com, still in existence today. Metcalfe then successfully worked with such communications companies as DEC, Intel, and Xerox to promote Ethernet as a standard. The Ethernet standard originally competed with the token ring and token bus standards, in use at the time. The Ethernet standard was able to be adapted more quickly to the much more flexible and less expensive twisted‐pair cabling and thus attained market dominance over the earlier token standards. For additional information, see: 1) Ethernet, a Wikipedia article available here: http://en.wikipedia.org/wiki/Ethernet. 2) How Ethernet Works, available here: http://computer.howstuffworks.com/ethernet.htm . Fast‐flux service networks A fast flux service network (FFSN) is a network of compromised servers having constantly changing DNS records. A DNS record specifies the relationship between a domain name and an IP address. The constantly changing DNS record significantly hinders attribution, as the usual form of traceback, using IP addresses, becomes rapidly impractical within minutes. The primary object of a fast flux service network is to have a valid, fully qualified domain name, such as www.fastflux.com, be associated with hundreds or even thousands of different IP addresses. This is accomplishing by continuously re‐registering domain names to new IP address in a block of IP addresses. The fast domain name registration service offered by most domain name registrars makes this possible. Once setup, the IP address registered for a specific domain name may be changed as often as once every three minutes. The consequence of this is that every time a new user connects to a given domain name in such a network, that user will likely be connecting to a different physical server every time. The FFSN can feature an additional layer of obfuscation through the use of proxies: in this architecture, the FFSN is merely the front end to the network, where content servers behind the FFSN are the actual sources of web

Chapter 8: Annotated Glossary

content. Legitimate websites have employed this technique for some time. It’s now also being employed for illegitimate uses. The challenge to traceback then can also be appreciated. Two kinds of flux networks have been identified: single and double flux. The single‐flux network has already been described above and involves a network of servers, each having a set IP address, but having a domain name that constantly points to a different IP address. Thus, every time a user connects to the domain name, that user will likely be connected to a different server. The double‐flux network adds another wrinkle to this by introducing a single mothership, which sources content, to the existing single‐flux network. In this case, the single‐ flux servers may be little more than compromised home user machines that redirect connection attempts to the mothership. Fast‐flux service networks present principally three characteristics to the criminal entrepreneur. The first one is that the overall architecture is greatly simplified, which reduces deployment and maintenance costs. Rather than needing to deploy (i.e., compromise) multiple servers to feed content, such as for botnets, only one server needs to be employed for this task. The second characteristic is much like that for botnets: disposable assets. The compromised servers that function as proxies or FFSN servers can be disposed of without much loss, aside from the startup cost of initially compromising them. Additionally, this layer of disposable assets performs the usual service of hindering attribution. The third characteristic is life span. As international cooperation in defeating botnets improves, the use of multiple fixed assets to manage content becomes more risky. The FFSN approach limits risk by limiting investment to a single content server, screened by multiple layers of shifting proxies. For additional information, see references [382] and [383]. FFSN See Fast‐Flux Service Networks. File handle A file handle is an abstract indicator for a file. In Linux systems, the term File Descriptor is used. In Microsoft systems, File handle is used, though this properly refers to a different object. In either case, generally, a file handle is essentially an integer that uniquely identifies a file to the operating system. It resides in a what is referred to as a file descriptor table, and each file has its own unique entry in this table. When the operating system receives a request from an application to open a file, it loads that file handle into memory, along with an indicator as to the status of the file (open, closed, etc.) and an indicator of the application using that file and the identity associated with that action. File handles provide important information in forensic computer analysis. By obtaining a memory dump from a running computer, and then reviewing the contents of that memory dump, it is possible to see what files were open at the moment the memory dump was taken, along with what identity was using that file. It’s impractical to know which of the hundreds of thousands of files on a computer are open at any given time. Taking a memory dump and then sifting through that dump for open files accomplishes this task much more readily. Identifying open files may provide evidence of a compromised computer. The reason being that, the application resident on the computer that is maliciously controlling the computer is a file, and such a file will be different than the usual files resident on the machine and are open. By

recursively reviewing and verifying each and every file, validating its legitimacy, malicious software can be found on the machine without having to turn off the machine. This is often desired when performing forensic analysis, as the task may be not only to (eventually) clean the machine, but to also identify the attacker and the means of the attack 1) File descriptor, a Wikipedia article available here: http://en.wikipedia.org/wiki/File_handle 2) File System Forensic Analysis, Brian Carrier, Addison Wesley Professional, 2005 3) Windows Forensic Analysis, Harlan Carvey, Syngress, 2007. 4) UNIX and Linux Forensic Analysis DVD Toolkit, Chris Pogue et al, Syngress, 2008. Herder A term used to refer to the controller of a botnet. For additional information on terminology used in botnet descriptions, please see [7], [8], [10], [12], [13], [22], and [24] in the References section. I/O converter An IO converter is a device that interfaces between two systems that may have different signal requirements. In the context of DCS, an IO converter is a device that interfaces between the analog signals of a motor or sensor and the digital signals expected for a computer network. For additional information on AD converters, please see: 1) Analog‐to‐digital converter, a Wikipedia article available here: http://en.wikipedia.org/wiki/Analog‐to‐digital_converter. IANA See Internet Assigned Numbers Authority. ICANN See Internet Corporation for Assigned Names and Numbers. Industrial control system Industrial control systems are computer‐based systems used extensively in industry to monitor and control sensitive processes and physical functions. Industrial control systems include supervisory control and data acquisition systems (SCADA), distributed control systems (DCS), programmable logic controllers (PLC), programmable automation controller (PAC), and intelligent electronic devices (IED). The electronic architecture of industrial control systems is extremely diverse, being customized to the needs of the industrial application. In general, industrial control systems are used where ever automation is useful. For additional information on industrial control systems, please see: 1) Guide to Industrial Control Systems (ICS) Security, NIST Special Publication 800‐82, June 2011, http://csrc.nist.gov/publications/nistpubs/800‐82/SP800‐82‐final.pdf. 2) Critical Infrastructure Protection II, Maurico Papa and Sujeet Shenoi, Springer, 2008. 3) Investigations involving the Internet and Computer Networks, US Department of Justice, Office of Justice Programs, NIJ Special Report, January 2007. 4) Critical Infrastructure Protection: Challenges and Efforts to Secure Control Systems, US Government Accounting Office, GAO‐04‐354, March 2004. Information‐harvesting attacks Information harvesting attacks is a term defined and used within the context of this paper to refer to a type of penetrative syber‐attack for which the primary purpose is data acquisition

Chapter 8: Annotated Glossary

from the compromised PC or from devices attached to the same network as the compromised PC. Internet Assigned Numbers Authority The Internet Assigned Numbers Authority (IANA) is an organization having a range of management duties with regard to the Internet. These include: ‐ Worldwide IP address allocation: IANA delegates allocations of IP Addresses in blocks to the various Regional Internet Registries located worldwide and defined geographically. Each RIR is responsible then for further allocation of IP addresses in blocks to the ISPs, IXPs and other organizations (such as governments) within its jurisdiction. IANA typically allocates IP addresses in /8 prefix blocks for IPv4 addresses and in /2 blocks for IPv6 addresses. ‐ Autonomous system numbers allocation: autonomous numbers are a set of IP routing prefixes used by network operators to define a common worldwide routing policy. In this system, each ISP, globally, is assigned a unique autonomous system number (ASN) for purposes of BGP routing. This number is a 16‐bit integer and thus provides for 65,536 unique ASN assignments. A few of these are reserved for special purposes. As of 2010, 35,000 of the total available ASNs have been allocated to ISPs distributed worldwide. ‐ Domain name system root zone maintenance: the DNS root zone is the top‐level DNS zone in the worldwide Domain Name System hierarchy. The root zone is not a single zone, but is comprised of all defined root zones, such as .COM, .GOV, .UK, .US, etc. IANA manages these root zones globally, but then delegates management of a root zone to various organizations. For example, management of the .COM root zone is delegated to VeriSign Corporation. Management of the .CY root zone is delegated to the University of Cyprus. Management of the .TR root zone is delegated to the Middle East Technical University Department of Computer Engineering in Turkey. And so on. ‐ Media type definitions: IANA manages a registry of media types and character encodings associated with World Wide Web browsing. This registry is maintained in order to establish a common, global standard for recognizing the various media types and interacting with me appropriately. This media typ registry allows a user in Thailand, reading pages in Thai script to open and view a PDF document developed and made available by a user speaking English in Great Britain. Using the registry, developers and users worldwide can ensure that they can all develop and interact with media using a common set of standards and definitions. ‐ Other Internet Protocol related symbols and number: IANA administers the various Internet Engineering Task Force (IETF) protocol parameters, such as the parameters for the Uniform Resource Identifier (URI) schemes and the various character encodings used on the Internet, such as those that we see in web pages. IANA is operated by the Internet Corporation for Assigned Names and Numbers (ICANN) under contract with the US Department of Commerce. For additional information see: 1) Internet Assigned Numbers Authority, a Wikipedia article available at: http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority. 2) http://www.iana.org/.

Internet Corporation for Assigned Names and Numbers The Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing the Internet Protocol address spaces (IPv4 and IPv6) and assignment of address blocks to regional Internet registries, for maintaining registries of Internet protocol identifiers, and for the management of the top‐level domain name space (DNS root zone), which includes the operation of root nameservers. ICANN was created in 1998 by the National Telecommunications and Information Administration, under the Department of Commerce, in response to the perceived need to privatize the management of Internet names and addresses in way that promoted competition and global participation. ICANN was then formed as an incorporated entity, in the State of California and qualified to engage in commerce in the District of Columbia. It’s offices are located on the campus of the University of Southern California. ICANN is formally organized as a non‐profit organization. It is managed by a board of 14 directors, composed of: representatives of the six operational areas under the purview of ICANN and eight independent members representative of the public interest selected through a nominating committee in which all of the ICANN constituencies are represented. This board then elects the president and CEO. ICANN has three supporting organizations that focus three critical areas of Internet policy including: ‐ Generic Names and Supporting Organization (GNSO): this group focuses on policy with regard to generic top‐level domains (gTLD). ‐ Country Code Names Supporting Organization (CCSO): this group focuses on policy with regard country code top‐level domains (ccTLD). ‐ Address Supporting Organization (ASO): this group focuses on policy making with respect to internet IP addresses ICANN also has various advisory committees that enable input to ICANN policy making from entities and organizations not directly involved with the three supporting organizations mentioned above. These include: ‐ Government Advisory Committee (GAC): composed of national government representatives ‐ At‐Large Advisory Committee (ALAC): composed of representatives of organizations and individual Internet users from around the world. ‐ Root Server System Advisory Committee (RSAC): composed of representatives of the DNS root server operators, this committee provides advice on the operation of the DNS root server system. ‐ Security and Stability Advisory Committee (SSAC): composed of Internet security experts who study issues associated with ICANN’s mandate. ‐ Technical Liaison Group (TLG): composed of representatives of other international organizations that are associated with the Internet. For additional information, see reference [338] or see: 1) ICANN, a Wikipedia Article available at: http://en.wikipedia.org/wiki/Internet_Corporation_for_Assigned_Names_and_Numbers. Internet Exchange Point An Internet exchange point is the physical infrastructure at which internet service providers

Chapter 8: Annotated Glossary

connect with one another. They allow networks to interconnect directly, rather than through third party networks. By interconnecting at these exchange points, overall Internet efficiency is enhanced, as these IXP routers are able to learn more routes. It also lowers costs, as an ISP need not build costly trunk lines to distant networks, but can take advantage of the nearest IXP to connect their subscribers to the overall Internet. Additionally, speed is increased for ISPs, as they can connect more closely to high‐speed trunk lines. A typical IXP consists of one or more network switches, able to handle transfer speeds of 10 GB/s or higher. Traffic between ISPs at these exchanges is governed by mutual peering agreements, which generally allow for the exchange of traffic without compensation. IXP operating costs are typically shared among the participating ISPs, paying a monthly or annual fee, determined by the speed of the port or ports which the ISP is using. Setup fees may also be charged. Internet traffic through an IXP is routed using the Border Gateway Protocol (BGP). In some cases, and ISP may have a connection to an IXP and, in addition, may have peering arrangements with other ISPS, connecting to these other ISPs through private exchanges. For example, a large ISP, having one or more IXP connections, will connect to smaller ISPs that perhaps service local customers. The local ISP then gains Internet access through the larger ISP. In other cases, two ISPs may have private peering arrangements between them and then connect to separate internet exchange points, bringing a degree of redundancy to both in the event of an IXP failure at either end. For additional information, see: 1) Internet Exchange Point, a Wikipedia article available at: http://en.wikipedia.org/wiki/IXP. 2) BGP: Border Gateway Protocol, Advanced Internet Routing Resources: http://www.bgp4.as/internet‐exchanges. Internet Protocol Version 4 Internet protocol Version 4 is the fourth version of the Internet protocol; it is the one currently deployed worldwide and distinguished by the use of the four block IP address, e.g., 192.168.1.23. For additional information on this topic, please see: 1) IPv4, a Wikipedia article available here: http://en.wikipedia.org/wiki/IPV4. Internet Service Provider An Internet Service Provider is a company that provides access to the Internet. An ISP generally has a network of communications media, routers, firewalls, and servers that inter‐ connect its customers. Customers connect to the ISP, from their router, through various media, to the ISP router. This media may include DSL, leased or dialup public telephone lines, wireless, and direct cable connections. Customers may connect to their ISP through these various means. The ISP network in turn may have transit or peer connections to a larger ISP providing indirect connectivity to the Internet, or it may have a peer connection at an IXP providing direct connection to the Internet. Other ISPs may have both direct and indirect peer connections to the Internet, providing the ISP some measure of redundancy. Transit connections are contracts that one ISP has with another one enabling the former ISP to obtain Internet connectivity. The former ISP contracts with the later for this service, paying a monthly fee or based upon traffic volume. Peer arrangements involve ISPs mutually agreeing to allow Internet traffic to pass between them, usually without charge, both benefiting from the increased redundancy such

arrangements enable. ISPs manage the IP addresses that they assign to their customers. An ISP obtains a block of IP addresses from the regional Internet registry in which jurisdiction it resides. The ISP then assigns an IP address from this block to each customer. ISPs may grant a fixed IP address to enterprise customers, such as large businesses and government offices and assign IP addresses dynamically to individual users, such as SOHO users. ISPs may also offer dialup or ISDN connections, which are available to users from any calling location, accessed as they are over the public switched telephone network. There are three general categories of ISPs: Tier 1, 2, and 3. Tier 3 ISPs are generally those that connect customers and that do not provide transit services to other ISPs. Tier 3 ISPs are typically found in local regions servicing customers in a small geographically bounded area. Tier 3 ISPs usually contract with Tier 1 or 2 ISPs to obtain Internet access for their network. Tier 2 ISPs are generally those that provide Tier 3 services and in addition also engage in peer arrangements with other ISPs; they may also provide transit services to Tier 3 ISPs. Tier 2 ISPs still contract with other ISPs to obtain Internet access. Tier 1 ISPs are generally those that may provide all of the Tier 3 and 2 services and in addition peer with other Tier 1 ISPs to provide global interconnectivity. Tier 1 ISPs are sometimes referred to as providing the Internet backbone. For additional information, see references [294], [295], [296], [297], [298], [299] and [300] or see: 1) Tier 1 Network, a Wikipedia article available here: http://en.wikipedia.org/wiki/Tier_1_carrier. IPv4 See Internet Protocol Version 4. ISP See Internet Service Provider. IXP See Internet Exchange Point. Latency In the context of networking, the time it takes for a block of data to move between two portion of the network. For additional information on this topic, please see: 1) Latency (engineering), a Wikipedia article available here: http://en.wikipedia.org/wiki/Network_latency. Local exploit Locate exploit is a term defined and used within the context of this paper to encompass an attack on a computer performed from within, or local to, that computer. Examples include viruses and trojans. Man‐in‐the‐middle attack This is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. For additional information on this topic, please see:

Chapter 8: Annotated Glossary

1) Man‐in‐the‐middle attack, a Wikipedia article available here: http://en.wikipedia.org/wiki/Man‐in‐the‐middle_attack. Microsoft Log Parser The Microsoft Log Parser is a tool that provides universal query access to text‐based data such as log files, XML files and CSV files, as well as data sources on the Windows operating system such as the Event Log, the Registry, the file system, and Active Directory. Its features allow the user to specify what information to query and how the results of the query should be processed. The results of the query can be custom formatted text, or sent to database management systems such as SQL Server Syslog, or even a chart. It can be configured to perform a single task or to perform multiple tasks in succession. Its primary utility is its ability to read log files in almost every format and file type. Log Parser is useful for administrators running Windows and Linux servers, firewalls, and other network devices, such as web servers, network sniffers, routers, and the like. Log parser can read these files across the network, performing consolidation and meta‐analysis. It is completely scriptable, which means that users can craft scripts that then run regularly as tasks, enabling the administrator to generate regular reports as desired. Users program Log Parser using a SQL‐like syntax. Log Parser features a command‐line GUI. All interaction with Log parser is performed at the command prompt. Several vendors have developed visual GUIs that provide a more convenient front‐end to working with Log Parser. One such is Log Parser Lizard. This visual GUI to Log Parser abstracts away from the command‐line, presenting a visual interface that features common tasks and windows for visually charting results. It presents results in tab format, the current standard in Windows office 2010 tools, enabling users to view multiple charts simultaneously. It also provides a repository for saving queries, and a visual editor for actually building queries. For additional information, see references [361] and [362]. Modbus Modbus is a suite of serial communications protocol developed by Modicon in 1979 for enabling PLCs to communicate with other devices, including other PLCs, supervisory computers, HMI stations, etc. in industrial applications. It is a de facto standard that is widely used in industry due to its focus on industrial applications, open architecture, and ease of deployment and maintenance; and it is also royalty free. The protocol is maintained at present by a consortium consisting of Modicon and independent users and suppliers of Modbus compliant devices. The suite includes individual protocols for RTU communications, ASCII communications, TCP/IP communications (also known as Modbus over IP), and a protocol dedicated to process automation communications. In a Modbus network, each device has a unique address and communication is primarily one‐ way: from the master to the device, and so Modbus is essentially a command and control type network. Communications among the devices occur in frames having the following fields: Start: this contains characters that distinguish the start of the command. Address: contains the address of the device for which the command is intended. Function: contains the code associated with the function that the receiving device is supposed

to perform Data: any data that accompanies the function. CRC Check: contains a an error check code to ensure the validity of the frame. End: a set of characters that distinguish the end of the frame. In such a network, only the device defined as the Master can actually send commands. When the master device sends a command, the command transmission also includes the destination address, or recipient address, of the device the command is intended for. Only the intended device will act upon the command, though all other devices on the Modbus network will detect it. The Modbus protocol suite presents some significant limitations at present. The protocol suite was developed in 1979 for communications with and control over the various types of PLCs that were available at that time. The capabilities and features of PLCs have increased significantly since that time. However, the protocol is limited to the range of features that were in existence at the time it was created. More sophisticated PLCs available today are able to identify exceptions, but are not able to communicate these back to the master unit, which must poll devices regularly in order to monitor their condition. This constant polling consumes bandwidth unnecessarily. The protocol is restricted to addressing 247 devices on one segment, which limits the number of devices that can be connected to a master unit. And the protocol does not provide security against unauthorized commands or interception of data. Some of these limitations have been overcome through the Modbus over TCP/IP implementation. For additional information, see: 1) Modbus, a Wikipedia article available here: http://en.wikipedia.org/wiki/Modbus. Network Time Protocol The network time protocol used for synchronizing the clocks of computer systems over packet‐switched, variable‐latency data networks. For additional information on this topic, please see: 1) Network Time Protocol, a Wikipedia article available here: http://en.wikipedia.org/wiki/Network_Time_Protocol. NTP See Network Time Protocol. PAC See Programmable Automation Controller. Packet See TCP/IP Packet. Penetrative cyber‐attack A term defined and used within this paper to encompass that class of cyber‐attacks that involve actual compromise of the target computer and the assumption of some degree of control over it. PING Packet Internet Groper. A TCP/IP utility used to send an ICMP echo request to a target host in order to verify whether that host is connected and reachable. For additional information on

Chapter 8: Annotated Glossary

PING, please see: 1) PING, a Wikipedia article available here: http://en.wikipedia.org/wiki/Ping. PLC See Programmable Logic Controller. Point of presence An access point to the Internet. a physical location that houses servers, routers, ATM switches and digital/analog call aggregators. It may be either part of the facilities of a telecommunications provider that the Internet service provider (ISP) rents or a location separate from the telecommunications provider. ISPs typically have multiple PoPs, sometimes numbering in the thousands. For additional information on this topic, please see: 1) Point of presence, a Wikipedia article available here: http://en.wikipedia.org/wiki/Point_of_presence. POP See Point‐of‐presence. Process A process, in the context of computing, is an instance of a computer program that is being executed. It contains the program code and its current activity. For additional information on this topic, please see: 1) Process (computing), a Wikipedia article available here: http://en.wikipedia.org/wiki/Computer_process. Profibus Profibus is short for Process Field Bus and is a standard for field bus communication in automation technology, including distributed control systems. For additional information on this topic, please see: 1) Profibus, a Wikipedia article available here: http://en.wikipedia.org/wiki/Profibus. Programmable automation controller A programmable logic controller (PLC) is microprocessor computer dedicated to the control of automated processes, such as those found in assembly lines, chemical manufacturing, power generation, building HVAC control, and even in amusement rides. Due to their deployment in a wide range of environments, from indoor to outdoor, from stable to high vibration, PLCs are generally designed for multiple inputs and outputs, able to withstand wide variations in environment conditions, and immunity to electrical noise. Unlike user computers, PLCs do not generally feature disk‐based storage but employ non‐volatile memory, in which both the operating system and the control application are embedded (burned in). PLCs are programmed by first developing the program on a standard workstation using special programming software. Once the program has been completed, it is then uploaded from the workstation to the PLC in a variety of ways, such as through direct serial RS‐232 connection or even over a TCP/IP network. The PLC stores the program and then burns the program into its memory. PLC programming languages are generally conform to International Electrotechnical Comission standard 61131‐3, which addresses graphical and textual programming standards. It defines five programming languages for PLCs, including: functional block diagram, ladder

100

diagram, structured text, instruction list, and sequential function chart. While the fundamentals of PLC programming are common to all of the programming language groups, differences in I/O addressing, memory organization, and instruction set usage cause programs from different vendors to not be interchangeable. Even within the same product line for a specific vendor, the programs for different PLCs may be incompatible. PLCs feature a variety of communication ports, including RS‐232, USB, Ethernet, and Modbus. Other types of ports may include wireless, Profibus, DeviceNet and others. Most modern PLCs are designed to be able to communicate over standard Ethernet‐based TCP/IP, usually featuring a CAT5 port for this. PLCs used in larger configurations comprised of multiple PLCs may even feature peer‐to‐peer communications capabilities, enabling direct PLC to PLC communication. For additional information, see reference [205] or see: 1) Guide to Industrial Control Systems (ICS) Security, NIST Special Publication 800‐82, June 2011, http://csrc.nist.gov/publications/nistpubs/800‐82/SP800‐82‐final.pdf . Programmable logic controller A programmable logic controller is a microprocessor that has been highly dedicated to automation of specific control machinery and devices, containing embedded control algorithms that enable it to provide specific output in response to specific input conditions. Such devices are used where ever machinery is automated. For additional information on PLUs, please see: 1) Guide to Industrial Control Systems (ICS) Security, NIST Special Publication 800‐82, June 2011, http://csrc.nist.gov/publications/nistpubs/800‐82/SP800‐82‐final.pdf. 2) Programmable Logic Controller, a Wikipedia article available here: http://en.wikipedia.org/wiki/Programmable_logic_controller. RAID See Redundant Array of Independent Disks. RDBMS See Relational Database Management System. Redundant Array of Independent Disks A technology that provides increased storage functions and reliability through redundancy. For example, "RAID 1" refers to two physical disks in a mirrored arrangement, whereby data is written simultaneously to both, prividing real‐time backup of data. For additional information, see: 1) RAID, a Wikipedia article available here: http://en.wikipedia.org/wiki/Redundant_Array_of_Independent_Disks. Reflector In the context of a DRDoS attack, a reflector is an uncompromised computer that responds to a spoofed request, having as its source IP address the intended target of the attack. For additional information on this term and other aspects of DRDoS attacks, please see [7], [8], [10], [12], [13], [15], [16], [17], [22], [23] and [24] in the References section. Relational Database Management System A database management system in which data is stored in tables and the relationships among the data are also stored in tables. Common examples of RDBMS include: Oracle, SQL Server, PostgreSQL, MySQL, etc. For additional information on relationship database management

101

Chapter 8: Annotated Glossary

systems, please see: 1) Relational database management system, a Wikipedia article available here: http://en.wikipedia.org/wiki/Relational_database_management_system. Remote exploit Remote exploit is a term defined and used within the context of this paper to encompass an attack on a computer performed from a location external to that computer. Remote telemetry unit A remote telemetry unit is a microprocessor‐controlled electronic device that interfaces objects in the physical world to a distributed control system or SCADA (supervisory control and data acquisition system) by transmitting telemetry data to the system and/or altering the state of connected objects based on control messages received from the system. Also referred to as Remote Terminal Unit. For additional information, please see: 1) Remote Terminal Unit, a Wikipedia article available here: http://en.wikipedia.org/wiki/Remote_Terminal_Unit. Root Access For Linux systems, root is the conventional name of the user who has all rights or permissions (to all files and programs) in all modes (single‐ or multi‐user). Equivalent to administrator access on Windows systems. For additional information on this topic, please see: 1) Superuser, a Wikipedia article available here: http://en.wikipedia.org/wiki/Root_access. RS‐232 The traditional name for a series of standards for serial binary single‐ended data and control signals connecting between a DTE (Data Terminal Equipment) and a DCE (Data Circuit‐ terminating Equipment). It is commonly used in computer serial ports. For additional information on this topic, see: 1) RS‐232, a Wikipedia article available here: http://en.wikipedia.org/wiki/RS‐232. RTU: see Remote Telemetry Unit. SAN See Storage Area Network. SCADA See Supervisory control and data acquisition. Simple network management protocol An Internet‐standard protocol for managing devices on IP networks. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks. is used mostly in network management systems to monitor network‐attached devices for conditions that warrant administrative attention. For additional information on this topic, see: 1) Simple Network Management Protocol, a Wikipedia article available here: http://en.wikipedia.org/wiki/SNMP. Small Office / Home Office This is a phrase commonly used to refer to a small office, or office setup in one's private home, and serviced by a single Internet connection, often a cable modem. For additional information on this topic, please see:

102

1) Small office/home office, a Wikipedia article available here: http://en.wikipedia.org/wiki/Small_office/home_office. SNMP See Simple Network Management Protocol. SOHO See Small Office / Home Office. Spam A term commonly used to refer to unsolicited email messages,l but can also involve instant messaging, newsgroup, blogs, wikis, and even mobile phones. For additional information on this topic, please see: 1) Spam (electronic), a Wikipedia article available here: http://en.wikipedia.org/wiki/Spam_(electronic). Storage Area Network A dedicated network that provides access to consolidated, block level data storage. SANs are primarily used to make storage devices, such as disk arrays, tape libraries, and optical jukeboxes, accessible to servers so that the devices appear like locally attached devices to the operating system. A SAN typically has its own network of storage devices that are generally not accessible through the local area network by other devices. For additional information on this topic, please see: 1) Storage area network, a Wikipedia article available here: http://en.wikipedia.org/wiki/Storage_area_network. Supervisory control and data acquisition system Supervisory control and data acquisition (SCADA) systems generally refer to a system of computer systems that monitor and control industrial infrastructure and industrial and facility processes. Infrastructure includes such things as: water and power distribution systems, oil pipelines, remote oil wells, electrical power and distribution systems, subway systems, and others. In general, includes systems that have geographically distributed subsystems and devices. Industrial processes include such things as: automobile manufacturing plants, and other such systems that run continuously, performing repetitive processes. Facility processes include such things as: building systems, airport control systems, ship and space station systems, oil rig platforms, and the like. As the name implies, SCADA systems 1) provide supervisory control over existing distributed systems – maintaining them so that these distributed systems continue to operate within acceptable parameters; and 2) acquire data from a network of distributed sensors that enable the supervised processes to be adequately monitored. In general SCADA systems are comprised of the following components: 1) Remote terminal (or telemetry) units: these are interfaces that connect sensors with the SCADA communications network. Usually, and RTU converts the electrical signals from the equipment its monitoring into digital format for transmission over the SCADA communication system. Early RTUs were limited primarily to one‐way communication (thus telemetry). Modern RTUs feature many capabilities, including signal conversion, two‐way communication, and the capability of also controlling certain devices. 2) Programmable logic controllers: these are used to control distributed devices; and many PLCs

103

Chapter 8: Annotated Glossary

include the necessary hardware to also connect to the SCADA communications systems. These are the same type of devices as used in factory and plant distributed control systems. PLCs manufactured for outdoor deployment may be ruggedized to adequately operate within extremes of temperature, humidity, and moisture. As discussed for Distributed Control Systems, PLCs are dedicated microprocessor computers, capable of hosting embedded operating systems and software, and focused on controlling specific processes. 3) A supervisory computer system, sometimes called the Master Terminal Unit that gathers all of the data from the distributed sensors, and then sends commands to the appropriate controllers to maintain the overall system within acceptable parameters, when local controllers cannot. 4) A human machine interface: this provides for additional, human monitoring of the overall system, and also provides some degree of master control over the system, in the event that PLCs or the MTU cannot. 5) A communications subsystem: this subsystem connects all of the distributed elements of the overall SCADA system, providing a means of communication between them. This communication system may be based upon radio, microwave, private, public or leased telephone lines, laser, fiber, wireless, and even cell technologies. Radio tends to be used for low‐power, long distance communications, as for microwave. Where available, the public telephone network may be used, such as for geographically dispersed power substations. In more local areas, such as within a city water system, cell communication may be used, leveraging the existing cell telephone system. Wireless Ethernet may be used for oil field monitoring and control, where the distributed devices communicate with a local PLC that in turn communicates with the central MTU located elsewhere. For truly remote locations, where rugged conditions may make private lines not cost effective, communications may be based upon satellite links. Modern SCADA communication systems employ standard TCP/IP networking methods, whether carried over fiber, wireless, cell, or modulated over telephone lines. The earliest SCADA systems, often referred to as Monolithic, were initially primarily data acquisition systems, employing a central mainframe computer and remote units that only sent sensor data over one‐way communication links (thus telemetry). These systems could only monitor operations; no control could be performed. In the event that a distributed process was found to be operating outside of acceptable parameters, a technician would need to be dispatched to the location of the process to perform local maintenance. Later systems, referred to as Distributed, developed in the 1970s and 1980s, employed various proprietary networking protocols to support two‐way communication between the MTU and distributed RTUs and PLCs. The current modern SCADA systems, referred to as Networked, generally employ standard TCP/IP networking methods based upon Ethernet. The SCADA communications system is generally a wide area network, employing one or more communications methods and gateways to link them together. Some systems even connect directly to the Internet, over standard ISP connections, modems at remote sites, leased lines, etc. For additional information on SCADA systems see references [203], [204], [205], [207] and [208], or see:

104

1) Guide to Industrial Control Systems (ICS) Security, NIST Special Publication 800‐82, June 2011, http://csrc.nist.gov/publications/nistpubs/800‐82/SP800‐82‐final.pdf. TCP/IP Packet A formatted unit of data carried by a packet mode computer network, such as that of the Internet. For additional information on this topic, please see Network Packet, a Wikipedia article available here: http://en.wikipedia.org/wiki/Network_packet. TCP/IP Transmission Control Protocol / Internet Protocol Technical attribution Technical attribution is a term defined in the context of this paper to encompass a multi‐step process of collecting evidence that identifies the network pathway taken by the attacker in order to reach the target machine. For additional information on this topic, please see [1], [2] and [3] in the References section, or see: 1) Guide to General Server Security, NIST Special Publication 800‐123, July 2008, http://csrc.nist.gov/publications/nistpubs/800‐123/SP800‐123.pdf. 2) Guide to Computer Security Log Management, NIST Special Publication 800‐92, September 2006, http://csrc.nist.gov/publications/nistpubs/800‐92/SP800‐92.pdf. 3) Guide to Integrating Forensic Techniques into Incident Response, NIST Special Publication 800‐86, August 2006, http://csrc.nist.gov/publications/nistpubs/800‐86/SP800‐86.pdf. TLD See Top Level Domain. Top Level Domain A top‐level domain is one of the domains at the highest level in the hierarchical Domain Name System of the Internet. Examples include .COM, .ORG, .MIL, .US, etc. For additional information on this topic, please see: 1) Top‐level domain, a Wikipedia article available here: http://en.wikipedia.org/wiki/Top‐ level_domain. Traceback The process of sequentially working backwards, step‐by‐step, from the target of the cyber‐ attack, router by router, network by network, to the computer from which the attack was launched. For additional information on this topic, please see [1], [2], [3] and [4] in the References section, or see: 1) Guide to General Server Security, NIST Special Publication 800‐123, July 2008, http://csrc.nist.gov/publications/nistpubs/800‐123/SP800‐123.pdf. 2) Guide to Computer Security Log Management, NIST Special Publication 800‐92, September 2006, http://csrc.nist.gov/publications/nistpubs/800‐92/SP800‐92.pdf. 3) Guide to Integrating Forensic Techniques into Incident Response, NIST Special Publication 800‐86, August 2006, http://csrc.nist.gov/publications/nistpubs/800‐86/SP800‐86.pdf. Trojan A trojan is a malicious software program that, once installed on the target machine, provides a means by which a cyber‐attacker can remotely control that computer. For additional information on trojans, please see [17], [22], [23], [24], [74] and [75] in the References section

105

Chapter 8: Annotated Glossary

or see: 1) Guide to Malware Incident Prevention and Handling, NIST Special Publication 800‐83, November 2005, http://csrc.nist.gov/publications/nistpubs/800‐83/SP800‐83.pdf. W3C See World Wide Web Consortium. Web crawls A search through web pages, usually performed by an automated utility, sometimes referred to as a bot. For additional information on this topic, please see: 1) Web crawler, a Wikipedia article available here: http://en.wikipedia.org/wiki/Web_crawler. Windows CE Windows CE is the legacy name for one member of Microsoft’s family of proprietary operating systems specifically designed for embedded systems. The most recent version, as of the time of this writing, is called Windows Embedded Compact 7.0. This embedded operating system is not a modified version of an existing Microsoft operating system, such as Windows NT, Windows 2000, and Windows 2003. Rather it is a distinct operating system having a kernel independent of those developed for Microsoft’s other operating systems. The other members of the embedded family include Windows Embedded Standard and Windows Embedded Enterprise, each of which is designed to be run from battery‐backed up RAM or non‐volatile memory (e.g., EEPROM). The Windows Embedded family of operating systems is used in a wide variety of applications, from ATM machines, to gaming devices; from medical devices, such as EKG monitors and other medical data gatherers to retail point of sale (POS) machines; and from wholly solid state embedded servers to programmable logic controllers Windows Embedded Compact is componentized real‐time operating system specifically designed for devices having minimal storage capabilities. Windows Embedded Compact occupies at a minimum no more than 500 KB of storage. It is compatible with any of the ARM, MIPS, and x86 type processors; it runs in 32‐bit mode; and a suite of development tools is available. Moreover, significant portions of the Windows Embedded Compact codebase, including many of the various components, have been released in source code form, enabling device vendors to customize these portions as appropriate to their products and applications. Core components, those that do not need adaption to specific hardware environments, remain proprietary and are only available in binary form. Windows Embedded Compact was originally released in 1996, targeting handheld computer systems, such as PDAs. This market then expended with support for the smart phone and automotive markets in 1997 and 1998. Since then, Windows Embedded Compact market has continued to expand, as the number of small devices continues to proliferate. At the time of this writing, Windows Embedded Compact can be found in such products as: •Barcode and RFID Scanners •Personal Navigation GPS devices •Digital Picture Frames •Set‐top boxes, Media Adapters home media servers •e‐readers •Gaming devices

106

•Ruggedized Handheld Terminals •Home and commercial building automation gateways •Industrial Controls •Vending Kiosks •Mobile Point of Service devices •Health Monitoring Devices •Remote metering and monitoring devices •Thin Clients For example, Latin‐Tech, Inc., uses Windows CE as the operating system for their WinPAC‐ 8x46 line of programmable automation controllers used in wastewater processing sites. Using Linux workstations hosting their ISaGRAF application programming studio, engineers program the PAC on the workstation, and then upload it to deployed PACs. Allen Bradley provides a family of different Windows CE development libraries designed to be used with Microsoft Visual Studio. AIS Industrial Innovations manufactures an operator interface touch panel and computer based upon Windows CE. Host Engineering Inc., offers a diskless runtime control platform providing the capabilities of both a PLC and a windows capable PC for process automation control. And the Iran nuclear power plant and uranium enrichment facility employed PLCs and other process automation devices using the Windows CE. In general, Windows CE is widely used in process automation applications as the operating system platform on which to program industrial automation devices. For additional information, see: 1) Windows CE, a Wikipedia article: http://en.wikipedia.org/wiki/Windows_CE. 2) Windows Embedded Compact 7, Microsoft MSDN, 6/22/11: http://msdn.microsoft.com/en‐ US/library/gg154201.aspx. 3) Windows Embedded, Microsoft’s main website for: http://www.microsoft.com/windowsembedded/. 4) The History of Windows CE, by Chris Tulley, HPCFactor: http://www.hpcfactor.com/support/windowsce/. Windows Embedded A family of operating systems from Microsoft designed for use in embedded systems. Windows Embedded operating systems are available to original equipment manufacturers system builders only, who make it available to end users preloaded with the hardware. For additional information on Windows Embedded, please see: 1) Windows Embedded Compact 7, Microsoft MSDN, 6/22/11: http://msdn.microsoft.com/en‐ US/library/gg154201.aspx. 2) Windows Embedded, Microsoft’s main website for: http://www.microsoft.com/windowsembedded/. 3) The History of Windows CE, by Chris Tulley, HPCFactor: http://www.hpcfactor.com/support/windowsce/. World Wide Web Consortium The World Wide Web Consortium (W3C) is the primary international standards organization for the World Wide Web. W3C focuses on developing and maintaining protocols and guidelines

107

Chapter 8: Annotated Glossary

for helping ensure the long term growth of the World Wide Web. These standard and protocol development and maintenance activities focus on the following key areas: Access: it is the W3C that develops accessibility standards for websites to enable people with disabilities to still be able to interact with websites. Through the Web Accessibility Initiative (WAI), the W3C develops standards for ensuring accessibility and metrics for measuring it. Through the Internationalization (I18n) Activity, various W3C working groups and liaises with other organizations, the W3C works to ensure the internationalization of the world wide web, so that web technologies are compatible with different languages, scripts, and cultures. And through the Mobile Web for Social Development (MW4D) Interest Group, the W3C develops standards for and researches how to use new technologies in combination with the WWW to bring minimal services to rural areas and underdeveloped countries. Integration: through its Mobile Web initiative, the W3C is seeking to support and promote the development of web‐enabled devices; through its web TV initiative, it seeks to promote the development of a platform supporting web integration with television; through the W3C Speech Interface Framework initiative, the W3C is developing specifications to integrate web technology with speech interaction; and other integration initiatives are also outstanding. Interactivity: The W3C continues to seek ways in which to enrich the user experience when using the WWW. Therefore, the W3C pursues initiatives in promoting the participation and sharing of knowledge. For example, the W3C supports and develops the fundamental WWW standards, such as for HTML markup, styles (e.g., CSS), scripting methods (e.g., JavaScript), real‐ time interaction (e.g., AJAX), and other design and application tasks, such as developing standards for audio and video streaming (e.g., SMIL). As new applications are discovered and developed for web integration, the W3C will promote these through international standards. Services: A substantial if not major aspect of WWW capabilities has to do with the delivery of services. Users who connect to online retailers are connecting to services and using those services. Now, to the user, their experience is focused on the retailer’s website. However, that website in turn is often connecting to other online services, for data, pricing, availability, etc. Still other websites aggregate the online services available, presenting users with a single point of interaction, even though that user triggers extensive service interaction over the Internet behind the scenes. The delivery of services is scene in VOIP and webTV. It is seen whenever a user tunnels into a corporate site in order to interact with enterprise capabilities – the underlying service being VPN. Corporate intranet sites may bundle a variety of corporate enterprise services into a single point of interaction for their users and/or employees. In fact, portal sites are merely the bundling of services. Numerous intranet applications bundle or employ distributed services to perform complex analysis and transactional processing, such that performed by airline ticketing systems. How these services are recognized, employed and exchanged requires the definition of interfaces – in this case, the interface between a service provider and a service consumer. These interfaces are little more than the standards maintained by the W3C; standards commonly known to developers such as SOAP, XQuery, XML, etc. By establishing standards for such services, the W3C promotes the WWW as a global distribution and delivery medium for services. Security: The W3C is exploring methods for promoting data security, through such specifications

108

as XML Signature, XML Encryption, and XKMS for public key use in XML. It is exploring standards for expressing privacy practices – such as those advertised at websites, and for promoting trust in delivering and consuming services. The W3C is administered through a joint agreement among the Michigan Institute of Technology, the European Research Consortium for Information and Mathematics, and Keio University of Japan. It is organized with a director and CEO and a small management team, who may be distributed internationally. It has an Advisory Committee composed of one representative from each of the W3C members, of which there are 317 at the time of this writing. W3C members may include vendors of technology products, content providers, corporate users, research laboratories, standards organizations, and governments. The Advisory Committee performs various review tasks and elects the members of the Advisory Board and Technical Architecture Group (TAG). The Advisory Board provides guidance to the management team on issues of WWW strategy, management, legal matters, process, and conflict resolution. The TAG primarily focuses on web architecture principles documentation. In addition to these groups there are various charter groups, composed of members of the Advisory Group and invited experts, which produce most of the W3C’s deliverables. The W3C is funded through member dues, research grants and other sources of private and public funding. For additional information on the W3C, see: 1) W3C, organization website: http://www.w3.org/. 2) World Wide Web Consortium, a Wikipedia article: http://en.wikipedia.org/wiki/World_Wide_Web_Consortium. Worm A worm, in the context of computer networking, is a self‐replicating computer program that uses a computer network to infect other computers without human intervention. Fundamentally, a worm is a virus that contains additional code enabling it to not only interact with the computer its infecting, but also search the network that the computer is connected to, in order to scan it for other computers, check whether these other computers have any vulnerabilities it has been programmed to exploit (that enable it to infect them), and then infect those computers if it can. A computer worm also need not install itself fully (as an executable file) onto its host but can merely exist in the volatile memory (i.e., RAM) of its host, while it seeks to infect more computers. Worms generally present an architecture that includes the following core characteristics: a • Distribution mechanism, an • Activation mechanism, and a • Payload In addition to these core architectural characteristics, worms may also evidence an evasion mechanism or strategy that may exist as a separate architectural component or that may comprise special adaptations of one or more of the core architectural characteristics noted above. The distribution mechanism may be self‐carried, embedded, or employing a secondary channel. Self‐carried worms are those that are fully self‐contained and are thus fully

109

Chapter 8: Annotated Glossary

transmitted from host to host. Worms that are embedded rely upon normal communications for transmission, by embedding themselves in these communications, either by appending themselves to them or even replacing them entirely. Worms that employ secondary channels transmit themselves by first infecting the host with a small program, which then downloads the rest of the worm code either from the source of the infection or from some other resource connected to the network. The activation mechanism may be: directly human activated, indirectly human activated, based upon some human activity, activated by a scheduled process, or self‐activated. Directly human activated worms require a person to manually run the worm program, and these are essentially similar to viruses. Once the worm is running, it then seeks out new hosts for infection or attempts to transmit itself through available media (USB drives, disks, etc.). Examples of such worms include the Melissa and Nimda viruses. Indirectly human activated worms require that a person perform some sort of activity with regard to the computer, such as logging, or opening a file, or reading a CDROM or USB thumb drive, before being launched. Worms that are run via scheduled processed are activated when a normal computer process is launched, such as when a computer seeks to update itself – perhaps in this case from an infected update server. The last category of worm activation, self‐activated, are those worms that launch immediately on infecting the host. Such worms generally exploit some type of vulnerability regarding the infected host, such as buffer‐overflow, which is a common infection vector. Examples of self‐activating worms include the Code Red I and II worms. The payload that a worm may carry is associated with what the worm does after it has infected the host. Some worms carry no payloads, and merely seek new avenues of infection. The Morris worm is an example of a worm that did not carry a payload. If the worm does carry a payload, then there is practically no limit to what the worm may feasibly accomplish once it has infected the host – that is within the bounds of the computer itself. The payload may be used to take control over the host; install an application on the host, such as a web server, mail relay, or proxy server; it may install sniffing software, for capturing user keystrokes, monitoring network traffic, etc. The payload may also install applications that are designed to disrupt services or even create denial of service situations. Lastly, worms may employ various evasion strategies and methods that are designed to help the worm avoid detection. These may include: slowing down the scanning of new hosts, so as to avoid noticeable increases in network traffic; altering the worm’s own code, so as to avoid signature detection by intrusion detection systems and antivirus systems; mimicking normal application activity ; and even starting false trails, by attempting to cause intrusion detection systems into focusing on irrelevant signatures. For additional information see: Computer Worms‐ Architectures, Evasion Strategies, and Detection Mechanisms, Smith et al, Journal of Information Assurance and Security 4 (2009) 69‐83; http://www.softcomputing.net/jias/smith.pdf ZigBee See 802.15.4‐2003.

110

zombie A computer that has been maliciously compromised and over which a cyber‐attacker has gained control. For additional information on this topic, see [17], [22], [23] and [24] in the References section.

111

Chapter 9: References

9. REFERENCES 9.1. Cited [1]

A Survey of Challenges in Attribution, W. Earl Boebert, Sandia National Laboratories, Proceedings of a Workshop on Deterring Cyber Attacks: Informing Strategies and Developing Options for U.S. Policy, 2010; http://www.nap.edu/openbook.php?record_id=12997&page=41. See also: Proceedings of a Workshop on Deterring Cyber Attacks: Informing Strategies and Developing Options for U.S. Policy, Committee on Deterring Cyber‐attacks: Informing Strategies and Developing Options; National Research Council, 2010; http://www.nap.edu/catalog.php?record_id=12997. [2] Techniques for Cyber Attack Attribution, David A. Wheeler and Gregory N. Larsen, Institute for Defense Analysis, IDA Paper P‐3792, October 2003; retrieved 5/6/2011; http://www.dtic.mil/cgi‐bin/GetTRDoc?AD=ADA468859. [3] Untangling Attribution: Moving to Accountability in Cyberspace, Robert K. Knake, Council on Foreign Relations, Before the Subcommittee on Technology and Innovation, Committee on Science and Technology United States House of Representatives, July 15, 2010; retrieved 5/6/2011; http://www.cfr.org/united‐states/untangling‐attribution‐ moving‐accountability‐cyberspace/p22630. [4] Roles and Challenges for Sufficient Cyber‐attack Attribution, Jeffrey Hunker et al, Institute for Information Infrastructure Protection (I3P), January 2008; retrieved [5] Security Problems in the TCP/IP Protocol Suite, S.M. Bellovin, Computer Communication Review, Vol. 19, No. 2, pp. 32‐48, April 1989; retrieved 9/10/2011; http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.3609&rep=rep1&type=pd f&rct=j&q=Security%20problems%20in%20TCP%20IP%20Protocol%20suite. [6] A Look Back at “Security Problems in the TCP/IP Protocol Suite”, Steven M. Bellovin, 20th Annual Computer Security Applications Conference (ACSAC), December 2004; retrieved 9/10/2011; https://www.cs.columbia.edu/~smb/papers/ipext.pdf. [7] DDoS: Anatomy of an Attack: A Packet Flow Perspective, Cisco, 2006; retrieved: 5/8/2011: http://www.cisco.com/en/US/prod/collateral/modules/ps2706/prod_presentation0900 aecd805c756c.pdf. [8] SYN Flood, Internet Security Systems; retrieved: 5/8/2011; http://www.iss.net/security_center/advice/Exploits/TCP/SYN_flood/default.htm. [9] The Continuing Denial of Service Threat Posed by DNS Recursion (v2.0), US‐CERT; retrieved 5/6/2011; http://www.us‐cert.gov/reading_room/DNS‐recursion033006.pdf. [10] Distributed Denial of Service Attacks (DDOS): Evolution, Impact, and Solutions; VeriSign Whitepaper; retrieved 5/8/2011; http://www.verisigninc.com/assets/whitepaper‐ ddos_attacks.pdf.

Cited

112

[11] Tracking and Tracing Cyber‐Attacks: Technical Challenges and Global Policy Issues, Howard F. Lipson, CERT® Coordination Center, November 2002; retrieved 5/6/2011; www.cert.org/archive/pdf/02sr009.pdf. [12] CERT® Advisory CA‐1996‐21 TCP SYN Flooding and IP Spoofing Attacks, Software Engineering Institute at Carnegie Mellon; retrieved 5/8/2011; http://www.cert.org/advisories/CA‐1996‐21.html. [13] CERT® Advisory CA‐2000‐21 Denial‐of‐Service Vulnerabilities in TCP/IP Stacks, Software Engineering Institute at Carnegie Mellon; retrieved 5/8/2011; http://www.cert.org/advisories/CA‐2000‐21.html. [14] The NAPTHA DoS vulnerabilities, SecureiTeam; retrieved 5/8/2011; http://www.securiteam.com/securitynews/6B0031F0KA.html. [15] Trends in Denial of Service Attack Technology, Kevin J. Houle and George M. Weaver, CERT® Coordination Center, October 2001; retrieved 5/6/2011; http://www.cert.org/archive/pdf/DoS_trends.pdf. [16] Denial of Service Attacks: An Emerging Vulnerability for the “Connected” Network, Whitepaper, SonicWALL; retrieved 5/8/2011; http://www.sonicwall‐ solutions.com/pdfs/white_papers/denial_of_service_attacks.pdf. [17] Bots &; Botnet: An Overview, Ramneek Puri , SANS Institute InfoSec Reading Room, August 08, 2003; retrieved 5/6/2011; http://www.sans.org/reading_room/whitepapers/malicious/bots‐botnet‐ overview_1299. [18] DDoS attack tool timeline, Dave Dittrich, University of Washington, 7/22/2000; retrieved 5/8/2011; http://staff.washington.edu/dittrich/talks/sec2000/timeline.html. [19] Backtracking Spoofed Packets, Tom Dunigan, Oak Ridge National Laboratory Network Research Group, June 2001; retrieved 5/16/2011; http://www.csm.ornl.gov/~dunigan/oci/bktrk.html. [20] Internet worms and global routing instabilities, James Cowie et al, 2002; retrieved 5/2011; http://www.renesys.com/tech/presentations/pdf/renesys‐spie2002.pdf. [21] Defending against Sequence Number Attacks, Internet Engineering Task Force, RFC 1948; retrieved 5/16/2011; http://www.ietf.org/rfc/rfc1948.txt. [22] Botnet (presentation), Kumar Mukherjee et al, Department of Electrical Engineering & Computer Science, Northwestern University; retrieved 5/20/2011; http://www.cs.northwestern.edu/~ychen/classes/msit458‐ s08/Roadrunners_Botnet.ppt. [23] Uses of botnets, The Honeynet Project, August 10, 2008; retrieved 7/6/2011; http://www.honeynet.org/node/52. [24] Botnets: The New Threat Landscape White Paper, Cisco, 2007; retrieved 5/8/2011; http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns171/ns441/networkin g_solutions_whitepaper0900aecd8072a537.pdf. [25] Virtual Criminology Report 2009, MacAfee, 2009; http://resources.mcafee.com/content/NACriminologyReport2009NF.

113

Chapter 9: References

[26] An Army of Ones and Zeroes–How I became a soldier in the Georgia‐Russia Cyberwar, Evgeny Morozov, Slate, Aug. 14, 2008; http://www.slate.com/id/2197514. [27] Coordinated Russia vs Georgia cyber‐attack in progress, Dancho Danchev, ZDNET, (August 11, 2008), http://www.zdnet.com/blog/security/coordinated‐russia‐vs‐georgia‐ cyber‐attack‐in‐progress/1670. [28] Cyber Attacks Against Georgia: Legal Lessons Identified, Eneken Tikk, et al, NATO CCD COE Legal Task Team1, (November 2008), available here: http://www.carlisle.army.mil/DIME/documents/Georgia%201%200.pdf. [29] U.S. Government Sites among Those Hit by Cyber‐attack, CNN (July 8, 2009); retrieved 5/9/2011; http://www.cnn.com/2009/TECH/07/08/government.hacking/index.html. [30] The Fog of Cyberwar, Danny Bradbury, The Guardian, Feb. 5, 2009; retrieved 5/9/2011; http://www.guardian.co.uk/technology/2009/feb/05/kyrgyzstan‐cyberattack‐internet‐ access. [31] Digital Fears Emerge After Data Siege in Estonia, mark Landler and John Markoff, NY Times, (May 29, 2007), http://www.nytimes.com/2007/05/29/technology/29estonia.html. [32] Refusal to assist investigation proves Russia was behind cyber‐attacks. BBN, August 9, 2007, http://www.balticbusinessnews.com/default.aspx?PublicationId=736e56fd‐1d97‐ 4e65‐8737‐cb5a9212b17b. [33] Denial‐of‐service attack, Wikipedia; retrieved 5/8/2011; http://en.wikipedia.org/wiki/Denial‐of‐service_attack. [34] Shadowserver Foundation; retrieved 5/13/2011; http://www.shadowserver.org. [35] Botnets, Wikipedia; retrieved 5/8/2011; http://en.wikipedia.org/wiki/Botnet. [36] Top 10 Botnet Threat Report – 2010, Damballa; retrieved 5/8/2011; http://www.damballa.com/downloads/r_pubs/Damballa_2010_Top_10_Botnets_Report .pdf. [37] Botnet‐driven click fraud attacks pilfering millions from advertisers, The Last Watchdog blog of Byron Acohido, April 23, 2010; retrieved 5/9/2011; http://lastwatchdog.com/botnet‐driven‐click‐fraud‐steals‐millions‐advertisers/. [38] Web crawler, Wikipedia; retrieved 5/9/2011; http://en.wikipedia.org/wiki/Web_crawler. [39] Search for Extraterrestrial Intelligence (SETI), BOINC; retrieved 5/9/2011; http://boinc.berkeley.edu/. [40] Auction Sniper, www.AuctionSniper.Com. [41] Microsoft: Over 2 million U.S. PCs caught in botnets, Lance Whitney, CNET, October 14, 2010; retrieved May 23, 2011; http://news.cnet.com/8301‐1009_3‐20019602‐83.html. [42] CRS Report 7‐5700 Identity Theft: Trends and Issues, Kristin M. Finklea, Congressional Research Service, August 26, 2009; retrieved 6/1/2011; http://www.fas.org/sgp/crs/misc/R40599.pdf. [43] Top Spam Botnets Exposed, M86 Security Labs, April 8, 2008; retrieved 5/9/2011; http://www.secureworks.com/research/threats/topbotnets/. [44] Mega‐D, M86 Security Labs, March 2009; retrieved 5/9/2011; http://www.m86security.com/labs/spambotitem.asp?article=896.

Cited

114

[45] FBI Busts Alleged Mega D Botnet Mastermind, Mathew J. Schwartz, InformationWeek, December 2, 2010; retrieved 5/9/2011; http://www.informationweek.com/news/security/management/228500163. [46] Secrets of the Ozdok/Mega‐D Botnet, FortiGuard, June 15, 2010; retrieved 5/9/2011; http://www.fortiguard.com/analysis/ozdokanalysis.html. [47] Ozdok/Mega‐D Trojan Analysis, Joe Stewart, Dell SecureWorks, February 11, 2008; Retrieved 5/9/2011; http://www.secureworks.com/research/threats/ozdok. [48] Lethic botnet knocked out by security researchers, John Leyden, The A Register, January 2010; retrieved 5/9/2011; http://www.theregister.co.uk/2010/01/13/lethic_botnet_takedown/. [49] Lethic botnet – The Takedown, M86 Security Labs, January 2010; retrieved 5/9/2011; http://www.m86security.com/labs/i/Lethic‐botnet‐‐The‐Takedown,trace.1216~.asp. [50] Pushdo / Cutwail Botnet A study of the Pushdo / Cutwail Botnet, Trend Micro Report, 22 May 2009; retrieved 5/8/2011; http://us.trendmicro.com/imperia/md/content/us/pdf/threats/securitylibrary/study_of _pushdo.pdf. [51] Botnet targets major Web sites with junk SSL connection, Jeremy Kirk, ComputerWorld, February 1, 2010; retrieved 5/8/2011; http://www.computerworld.com/s/article/9150380/Botnet_targets_major_Web_sites_ with_junk_SSL_connection?source=CTWNLE_nlt_pm_2010‐02‐01. [52] Rustock botnet, Wikipedia; retrieved 7/6/2011; http://en.wikipedia.org/wiki/Rustock#cite_note‐scmagazineus1‐0. [53] Rustock.C aka Ntldrbot – Small Advisory, Windows Sysinternals, May 23, 2008; retrieved 5/2011; http://forum.sysinternals.com/rustockc‐aka‐ntldrbot‐small‐ advisory_topic14844.html. [54] Zeus: King of the Bots, Nicolas Falliere and Eric Chien, Symantec Security Response Whitepaper, 2009; retrieved 5/8/2011; http://www.symantec.com/content/en/us/enterprise/media/security_response/whitep apers/zeus_king_of_bots.pdf. [55] Researchers: Botnet infects thousands of government computers, William Jackson, Federal Computer Week, ◦Apr 22, 2009; retrieved 5/8/2011; http://fcw.com/Articles/2009/04/22/RSA‐botnet.aspx. [56] Mariposa FAQ, Defence Intelligence; retrieved 5/8/2011; http://www.defintel.com/mariposa.shtml. [57] Malicious New Botnet Found in 50 of Fortune 100, Jeremy A. Kaplan, September 28, 2009, Fox News; retrieved 5/8/2011; http://www.foxnews.com/scitech/2009/09/28/malicious‐new‐botnet‐fortune/. [58] The Mumba Botnet Discovered, AVG Technologies, 2009; retrieved 5/8/2011; http://avg.typepad.com/files/revised‐mumba‐botnet‐whitepaper_approved_yi_fv‐2.pdf. [59] AVG uncovers new data‐stealing Mumba botnet, Jeremy Kirk, Network World, August 02, 2010; retrieved 5/8/2011; http://www.networkworld.com/news/2010/080210‐avg‐ uncovers‐new‐data‐stealing‐mumba.html.

115

Chapter 9: References

[60] All your packets are belong to us: Attacking backbone technologies, Daniel Mende & Enno Rey, Black Hat Europe 2009, April 2009; retrieved 5/19/2011; http://www.blackhat.com/presentations/bh‐europe‐09/Rey_Mende/BlackHat‐Europe‐ 2009‐Mende‐Rey‐All‐Your‐Packets‐slides.pdf. [61] Defending TCP Against Spoofing Attacks, Internet Engineering Task Force Network Working Group, July 2007; retrieved 5/18/2011; http://tools.ietf.org/html/rfc4953. [62] 21 Oct 2002 Root Server Denial of Service Attack – Report, Internet Systems Consortium, November 24, 2002; retrieved 5/19/2011; http://www.isc.org/f‐root‐denial‐of‐service‐ 21‐oct‐2002. [63] Backbone DDoS, Internet Traffic Report, 10/22/2002; retrieved 5/19/2011; http://www.internettrafficreport.com/event/2.htm. [64] Factsheet: Root server attack on 6 February 2007, Internet Corporation for Assigned Names and Numbers, March 1, 2007; retrieved 5/19/2011; http://www.icann.org/en/announcements/factsheet‐dns‐attack‐08mar07.pdf. [65] Feb 6/7 2007 DNS Attack Recap, DNS‐Operations Meeting, July 27, 2007; retrieved 5/19/2011; https://www.dns‐oarc.net/files/dnsops‐2007/Kristoff‐Feb07‐attacks.pdf. [66] Exploit (computer security), Wikipedia; retrieved 5/12/2011; http://en.wikipedia.org/wiki/Exploit_(computer_security). [67] The Top Cyber Security Risks, SANS, September 2009; retrieved 5/12/2011; http://www.sans.org/top‐cyber‐security‐risks/. [68] OWASP Top 10 for 2010, Open Web Application Security Project; retrieved 5/10/2011; https://www.owasp.org/index.php/OWASP_Top_Ten_Project. [69] Five common Web application vulnerabilities, Sumit Siddharth, Pratiksha Doshi, Symantec, 27 Apr 2006; retrieved 5/10/2011; http://www.symantec.com/connect/articles/five‐common‐web‐application‐ vulnerabilities. [70] National Vulnerability Database, US‐CERT; retrieved 5/10/2011; http://web.nvd.nist.gov/view/vuln/statistics. [71] Penetration Testing and Network Defense: Detecting Web Attacks, [72] Vulnerability Note VU#247371, US‐CERT, 1/9/2001; retrieved 5/11/2011; http://www.kb.cert.org/vuls/id/247371. [73] Unforgivable Vulnerabilities, Steve Christey, The MITRE Corporation, August 2, 2007; retrieved 5/10/2011; http://cve.mitre.org/docs/docs‐2007/unforgivable.pdf. [74] CERT® Advisory CA‐1999‐02 Trojan Horses, February 5, 1999; retrieved 5/11/2011; http://www.cert.org/advisories/CA‐1999‐02.html. [75] Trojan horse (computing), Wikipedia; retrieved 5/11/2011; http://en.wikipedia.org/wiki/Trojan_horse_(computing). [76] Rogue: Win32/FakeRean, Microsoft Malware Protection Center, February 08, 2011; http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?name=Rog ue%3aWin32%2fFakeRean. [77] Windows Addresses the Changing AutoRun Threat Environment, Microsoft TechNet Blogs: Microsoft Malware Protection Center, 4/28/2009; retrieved 5/16/2011;

Cited

[78]

[79] [80] [81]

[82]

[83] [84]

[85] [86]

[87] [88] [89] [90]

[91] [92]

[93]

116

http://blogs.technet.com/b/mmpc/archive/2009/04/28/windows‐addresses‐the‐ changing‐autorun‐threat‐environment.aspx. Facebook apps found giving access to user accounts to third parties, Help Net Security, May 11, 2011; retrieved 5/16/2011; http://www.net‐ security.org/secworld.php?id=11010. Java Exploits, SANS Internet Storm Center, November 11, 2010; retrieved 5/16/2011; http://isc.sans.edu/diary.html?storyid=9916. Multiplatform Java botnet spotted in the wild, Help Net Security, May 5, 2011; retrieved 5/12/2011; http://www.net‐security.org/malware_news.php?id=1714. Malicious LinkedIn Campaigns Continue, M86 Security Labs, September 30, 2011; retrieved 7/17/2011; http://labs.m86security.com/2010/09/malicious‐linkedin‐ campaigns‐continue/. Fake LinkedIn Messages Install Zeus Malware on Victims' Computers, eWeek, June 7, 2011; retrieved 7/17/2011; http://www.eweek.com/c/a/Security/Fake‐LinkedIn‐ Messages‐Install‐Zeus‐Malware‐on‐Victims‐Computers‐852972/. Computer Worm, Wikipedia; retrieved 5/16/2011; http://en.wikipedia.org/wiki/Computer_worm. Microsoft Security Bulletin MS08‐052 – Critical, Microsoft TechNet, March 10, 2009; retrieved 5/16/2011; http://www.microsoft.com/technet/security/bulletin/ms08‐ 052.mspx. PHP Exploit Code in a GIF, SANS Internet Storm Center Bulletin, June 19, 2007; retrieved 5/16/2011; http://isc.sans.org/diary.html?storyid=2997. Cisco 1Q11 Global Threat Report; Cisco Systems; retrieved 5/10/2011; http://www.cisco.com/en/US/prod/collateral/vpndevc/cisco_global_threat_report_1Q2 011.pdf. McAfee Threats Report: Fourth Quarter 2010, McAfee; retrieved 5/9/2011; http://www.mcafee.com/us/resources/reports/rp‐quarterly‐threat‐q4‐2010.pdf. Microsoft Security intelligence Report, Microsoft Corporation; retrieved 5/16/2011; http://www.microsoft.com/security/sir/. IBM X‐Force 2010 Trend and Risk Report, IBM Security Solutions, March 2011; retrieved 5/14/2011; http://www‐935.ibm.com/services/us/iss/xforce/trendreports/. Annual Report PandaLabs 2010, Panda Security; retrieved 5/12/2011; http://press.pandasecurity.com/wp‐content/uploads/2010/05/PandaLabs‐Annual‐ Report‐2010.pdf. March 2011 Intelligence Report, Symantec,Cloud MessageLabs Intelligence; retrieved 5/8/2011; http://www.messagelabs.com/globalthreats. CERT® Advisory CA‐2000‐02 Malicious HTML Tags Embedded in Client Web Requests, CERT, February 3, 2000; retrieved 7/6/2011; http://www.cert.org/advisories/CA‐2000‐ 02.html. Testing for Reflected Cross site scripting (OWASP‐DV‐001), Open Web Application Security Project; retrieved 7/6/2011;

117

[94]

[95] [96]

[97]

[98]

[99]

[100]

[101]

[102]

[103]

[104] [105] [106]

[107]

Chapter 9: References https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OWASP ‐DV‐001). Advanced Cross‐Site‐Scripting with Real‐time Remote Attacker Control, Mini‐ Whitepaper, Anton Rager, February 9, 2005; retrieved 5/7/2011; http://xss‐ proxy.sourceforge.net/Advanced_XSS_Control.txt. Securing Your Web Browser, CERT, February 14, 2008; retrieved 7/6/2011; http://www.cert.org/tech_tips/securing_browser/. Mass hack plants malware on thousands of webpages, Dan Goodin, The Register, June 9, 2010; retrieved 7/6/2011; http://www.theregister.co.uk/2010/06/09/mass_webpage_attack/. Social engineering in action: how web ads can lead to malware, Ed Bott, ZDNet, July 6, 2011; retrieved 7/7/2011; http://www.zdnet.com/blog/bott/social‐engineering‐in‐ action‐how‐web‐ads‐can‐lead‐to‐malware/3532?tag=nl.e539. Apple’s malware challenge: Usability as its security world changes, Larry Dignan, zdNet, May 26, 2011; retrieved 6/13/2011; http://www.zdnet.com/blog/btl/apples‐malware‐ challenge‐usability‐as‐its‐security‐world‐changes/49378?tag=nl.e539. An AppleCare support rep talks: Mac malware is “getting worse”, Ed Bott’s Microsoft Report, ZDNet, May 18, 2011; retrieved 5/28/2011; http://www.zdnet.com/blog/bott/an‐applecare‐support‐rep‐talks‐mac‐malware‐is‐ getting‐worse/3342?tag=nl.e539. Apple Macs hit by scareware attacks, Joseph Menn, Financial Times, May 26 2011; retrieved May 27, 2011; http://www.ft.com/cms/s/2/a6e6aa7a‐87c0‐11e0‐a6de‐ 00144feabdc0.html. Botnets, Cybercrime, and Cyberterrorism: Vulnerabilities and Policy Issues for Congress, Congressional Research Service Report for Congress, January 29, 2008; retrieved 5/23/2011; http://opencrs.com/document/RL32114/2008‐01‐29/. Cyber Security 2009: Hearings before the Committee on Homeland Security and Governmental Affairs United States Senate, April 28, 2009, Testimony of Alan Paller p90; retrieved 5/22/2011; http://www.gpo.gov/fdsys/pkg/CHRG‐111shrg51019/pdf/CHRG‐ 111shrg51019.pdf. ‘Money Mules’ Help Haul Cyber Criminals’ Loot, Brian Krebs, January 25, 2008; retrieved 7/5/2011; http://www.washingtonpost.com/wp‐ dyn/content/story/2008/01/25/ST2008012501460.html. Money Laundering and Reshipping Fraud, Bobbear, http://www.bobbear.co.uk/. Fraud losses drop on UK cards, cheques and online banking – 31 Mar 2011; retrieved 7/5/2011; http://www.acceptcards.co.uk/news/?id=40. FDIC: Hackers took more than $120M in three months, Robert McMillan, ComputerWorld, March 8, 2010; retrieved 7/5/2011; http://www.computerworld.com/s/article/9167598/FDIC_Hackers_took_more_than_12 0M_in_three_months. 2011 Online Fraud Report – 12th Annual Edition, CyberSource; retrieved 7/5/2011; http://forms.cybersource.com/forms/FraudReport2011NACYBSwww2011.

Cited

118

[108] Brothers guilty in Charlotte terror trial, CNN, June 25, 2002; retrieved 7/5/2011; http://edition.cnn.com/2002/LAW/06/21/hezbollah.trial/index.html. [109] Paying for Terror: How jihadist groups are using organized‐crime tactics–and profits–to finance attacks on targets around the globe, David Kaplan, US News and World Report, November 27, 2005; retrieved 7/5/2011; http://www.usnews.com/usnews/news/articles/051205/5terror_print.htm. [110] The credit card‐terrorism connection: How terrorists use cards for everyday needs and to fund operations, Jeremy M. Simon, CreditCards.Com, May 15, 2008; retrieved 7/5/2011; http://www.creditcards.com/credit‐card‐news/credit‐cards‐terrorism‐ 1282.php. [111] The Fraud‐Terror Link, Frank Perri, Fraud Magazine, July/August 2010; retrieved 7/5/2011; http://www.fraud‐magazine.com/article.aspx?id=4294967888. [112] Stolen Credit Cards Used Extensively by Terrorists, Kount News Room, March 31, 2009; retrieved 7/5/2011; http://www.kount.com/announcements/stolen‐credit‐cards‐used‐ extensively‐by‐terrorists. (Written Statement of Andrew R. Cochran, for the For the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology Hearing U.S. House Committee on Homeland Security, March 31, 2009; retrieved 7/5/2011; http://chsdemocrats.house.gov/SiteDocuments/20090331142105‐01092.pdf) [113] Official: International hackers going after U.S. networks, Jeanne Meserve, October 19, 2007; retrieved 6/1/2011; http://www.cnn.com/2007/US/10/19/cyber.threats/index.html. [114] Capability of the People’s Republic of China to Conduct Cyber Warfare and Computer Network Exploitation, Prepared for, The US‐China Economic and Security Review Commission, Bryan Krekel, Northrop Grumman Corporation, October 9, 2009; retrieved May 22, 2011; http://www.uscc.gov/researchpapers/2009/NorthropGrumman_PRC_Cyber_Paper_FIN AL_Approved%20Report_16Oct2009.pdf. [115] Unsecured Economies: Protecting Vital Information, McAffee Report, 2008, http://resources.mcafee.com/content/NAUnsecuredEconomiesReport. [116] Revealed: Operation Shady RAT, Dmitri Alperovitch, Threat Research, McAfee report 2011; retrieved 8/11/2011; http://blogs.mcafee.com/mcafee‐labs/revealed‐operation‐ shady‐rat. [117] The Truth Behind the Shady RAT, Symantec Official Blog, Symantec, August 4, 2011; retrieved 8/11/2011; http://www.symantec.com/connect/blogs/truth‐behind‐shady‐rat. [118] Oak Ridge National Laboratory Breached by Phishing Email, IE Exploit, Fahmida Y. Rashid, eWeek, April 20, 2011; retrieved 7/7/2011; http://www.eweek.com/c/a/Security/Oak‐Ridge‐National‐Laboratory‐Breached‐by‐ Phishing‐Email‐IE‐Exploit‐361033/. [119] DOE Lab Shuts Down Email, Web Access After Sophisticated Cyber‐Attack, Fahmida Y. Rashid, eWeek, July 6, 2011; retrieved 7/7/2011; http://www.eweek.com/c/a/Security/DOE‐Lab‐Shuts‐Down‐EMail‐Web‐Access‐After‐ Sophisticated‐CyberAttack‐161664/.

119

Chapter 9: References

[120] DOE Networks Under Siege – Labs Report sophisticated Breaches, Rafal Los, HP – Following the White Rabbit – A Realistic Blog on Enterprise Security, July 4, 2011; retrieved 7/7/2011; http://h30499.www3.hp.com/t5/Following‐the‐White‐Rabbit‐ A/DOE‐Networks‐Under‐Siege‐Labs‐Report‐Sophisticated‐Breaches/ba‐p/4811911. [121] Energy Sciences Network; http://www.es.net/. [122] Citigroup data breach affects 360,000 clients, Associated Press, June 16, 2011; retrieved 7/5/2011; http://www.oregonlive.com/business/index.ssf/2011/06/citigroup_data_breach_affects .html. [123] Password Service Warns of Possible Hacking Attack, Riva Richmond, New York Times, May 5, 2011; retrieved 5/23/2011; http://bits.blogs.nytimes.com/2011/05/05/password‐service‐warns‐of‐possible‐hacking‐ attack/. [124] LastPass Security Notification, Last Pass; retrieved 5/23/2011; http://blog.lastpass.com/2011/05/lastpass‐security‐notification.html. [125] HBGary Federal Hacked by Anonymous, Krebs on Security, February 2011; retrieved 5/23/2011; http://krebsonsecurity.com/2011/02/hbgary‐federal‐hacked‐by‐ anonymous/. [126] Anonymous speaks: the inside story of the HBGary hack, Peter Bright, Ars Technica, February 2011; retrieved 5/23/2011; http://arstechnica.com/tech‐ policy/news/2011/02/anonymous‐speaks‐the‐inside‐story‐of‐the‐hbgary‐hack.ars. [127] EMC: RSA was hit with sophisticated attack, SecurID data lifted, Larry Dignan, Zdnet, March 18, 2011; retrieved 5/23/2011; http://www.zdnet.com/blog/btl/emc‐rsa‐was‐hit‐ with‐sophisticated‐attack‐securid‐data‐lifted/46218. [128] Anatomy of an Attack, Uri Rivner, RSA Blogpost, RSA, April 1, 2011; retrieved 5/23/2011; http://blogs.rsa.com/rivner/anatomy‐of‐an‐attack/. [129] Hackers Penetrate Nasdaq Computers, Devlin Barrett, WSJ, February 5, 2011; retrieved 2/5/2011; http://online.wsj.com/article/SB10001424052748704709304576124502351634690.html . [130] Google Hack Attack Was Ultra Sophisticated, Kim Zetter, New Details Show, Wired, (January 14, 2010), http://www.wired.com/threatlevel/2010/01/operation‐aurora/. [131] A new approach to China, The Official Google Blog, January 12, 2010; retrieved 5/22/2011; http://googleblog.blogspot.com/2010/01/new‐approach‐to‐china.html. [132] Operation Aurora: Clues in the Code, Joe Stewart, Dell SecureWorks, January 19, 2010; retrieved 5/20/2011; http://www.secureworks.com/research/blog/research/20913/. [133] FBI investigating online New York school district theft, Jeremy Kirk, ComputerWorld, January 6, 2010; retrieved 5/23/2011; http://www.computerworld.com/s/article/9143144/FBI_investigating_online_New_York _school_district_theft.

Cited

120

[134] FBI disrupts international cyber crime ring, Gautham Nagesh, The Hill, October 1, 2010; retrieved 6/1/2011; http://thehill.com/blogs/hillicon‐valley/technology/122157‐fbi‐ disrupts‐international‐cyber‐crime‐ring. [135] Cyber Banking Fraud: Global Partnerships Lead to Major Arrests, Federal Bureau of Investigation, October 1, 2010; retrieved 6/1/2011; http://www.fbi.gov/news/stories/2010/october/cyber‐banking‐fraud/cyber‐banking‐ fraud. [136] Botnet Operation Disabled: FBI Seizes Servers to Stop Cyber Fraud, Federal Bureau of Investigation, April 14, 2011; retrieved 6/1/2011; http://www.fbi.gov/news/stories/2011/april/botnet_041411/botnet_041411. [137] Vast Spy System Loots Computers in 103 Countries, John Markoff, N.Y. TIMES.COM, Mar. 29, 2009, http://www.nytimes.com/2009/03/29/technology/29spy.html. [138] Tracking Ghostnet: Investigating a Cyber Espionage Network”, in Information Warfare Monitor JR02‐2009, University of Toronto Munk Center for International Studies, 29 Mar 2009; retrieved 5/22/2011; http://www.f‐secure.com/weblog/archives/ghostnet.pdf. [139] The snooping dragon: social‐malware surveillance of the Tibetan movement, Shishir Nagaraja, Ross Anderson, University of Cambridge Computer Laboratory, March 2009; retrieved 5/22/2011; http://www.cl.cam.ac.uk/techreports/UCAM‐CL‐TR‐746.html. [140] Starwood sues Hilton for ‘stealing trade secrets’, Andrew Clark, Guardian, April 17, 2009; retrieved 7/5/2011; http://www.guardian.co.uk/business/2009/apr/17/industrial‐ espionage‐hotel‐industry‐lawsuit. [141] Computer Spies Breach Fighter‐Jet Project, SIOBHAN GORMAN, AUGUST COLE and YOCHI DREAZEN, Wall Street Journal, April 21, 2009; retrieved 5/11/2011; http://online.wsj.com/article/SB124027491029837401.html. [142] UK Cyber Attack Reported, Kevin Coleman, January 20th, 2009; retrieved 5/12/2011; http://defensetech.org/2009/01/20/uk‐cyber‐attack‐reported/. [143] One Hundred Linked to International Computer Hacking Ring Charged by United States and Egypt in Operation Phish Phry, Press Release Federal Bureau of Investigation, October 7, 2010; retrieved 6/1/2011; http://losangeles.fbi.gov/pressrel/2009/la100709.htm. [144] RBS WorldPay breach exposes 1.5 million, John Leyden, The A Register, December 2008; retrieved 5/22/2011; http://www.theregister.co.uk/2008/12/29/rbs_worldpay_breach/. [145] “Cyber Security: Responding to the Threat of Cyber Crime and Terrorism”, (see: Testimony of Jason Weinstein), Senate Judiciary Committee, Subcommittee on Crime and Terrorism, April 12, 2011; retrieved 5/11/2011; http://judiciary.senate.gov/hearings/hearing.cfm?id=5123. [146] 11 charged in TJX identity theft, Jon Swartz, USA Today, August 7, 2008; retrieved 5/23/2011; http://www.usatoday.com/tech/news/computersecurity/infotheft/2008‐08‐ 05‐retailer‐identity‐theft_N.htm. [147] Defending a New Domain, William J. Lynn III, Foreign Affairs, September/October 2010; retrieved 7/7/2011; http://www.foreignaffairs.com/articles/66552/william‐j‐lynn‐ iii/defending‐a‐new‐domain.

121

Chapter 9: References

[148] Insiders Doubt 2008 Pentagon Hack Was Foreign Spy Attack (Updated), Noah Shachtman, Wired Magazine, August 25, 2010; retrieved 7/7/2011; http://www.wired.com/dangerroom/2010/08/insiders‐doubt‐2008‐pentagon‐hack‐was‐ foreign‐spy‐attack/#more‐29819. [149] “Night Dragon” Attacks Threaten Major Energy Firms, Tim Wilson, Dark Reading, (Feb 10th, 2011), http://mobile.darkreading.com/9287/show/6fd87585153824962f5a5c9210409252&t=d 6698507fee3e21613da0969b208c807. [150] Global Energy Industry Hit In “Night Dragon” Attacks, George Kurtz, McAffee, (February 9, 2011), http://blogs.mcafee.com/corporate/cto/global‐energy‐industry‐hit‐in‐night‐ dragon‐attacks [151] What is Night Dragon?, McAfee Corporate Knowledgebase, February 10, 2011; retrieved 5/22/2011; https://kc.mcafee.com/corporate/index?page=content&id=KB71150. [152] Global Energy Cyberattacks: Night Dragon, McAfee White Paper, February 10, 2011; retrieved 5/22/2011; http://www.mcafee.com/us/resources/white‐papers/wp‐global‐ energy‐cyberattacks‐night‐dragon.pdf. [153] Industry Advisory: Night Dragon, NERC Advisory, North American Reliability Corporation, February 18, 2011; retrieved 7/17/2011; http://www.nerc.com/fileUploads/File/Events%20Analysis/A‐2011‐02‐18‐ 01%20Night%20Dragon%20FINAL.pdf. [154] Wolf Reveals House Computers Compromised by Outside Source, press release, Congressman Frank Wolf, US Congress, June 11, 2008; retrieved 5/12/2011; http://wolf.house.gov/index.cfm?sectionid=34&parentid=6&sectiontree=6,34&itemid=1 174. [155] Report: U.S. Fighter Project Infiltrated by Cyberspies, Michael Barkoviak, April 21, 2009; retrieved 5/12/2011; http://www.dailytech.com/Report+US+Fighter+Project+Infiltrated+by+Cyberspies/articl e14918.htm. [156] T.J. Maxx Security Breach Costs Soar To 10 Times Earlier Estimate, Sharon Gaudin, InformationWeek, August 15, 2007; retrieved 6/1/2011; http://www.informationweek.com/news/201800259. [157] T.J. Maxx Data Theft Likely Due To Wireless ‘Wardriving’, Larry Greenemeier InformationWeek, May 09, 2007; retrieved 6/1/2011; http://www.informationweek.com/news/199500385. [158] Payment Processor Breach May Be Largest Ever, Brian Krebs, Washington Post, January 20, 2009; retrieved 6/1/2011; http://voices.washingtonpost.com/securityfix/2009/01/payment_processor_breach_ma y_b.html. [159] Heartland Payment Systems: Lessons Learned from a Data Breach, Federal Reserve Bank of Philadelphia, January 2010; retrieved 6/1/2011; http://www.philadelphiafed.org/payment‐cards‐center/publications/discussion‐ papers/2010/D‐2010‐January‐Heartland‐Payment‐Systems.pdf.

Cited

122

[160] Red storm rising, Dawn S. Onley, Patience Wait, Government Computer News, August 17, 2006; retrieved 7/6/2011; http://gcn.com/articles/2006/08/17/red‐storm‐ rising.aspx. [161] Smash and grab, the hi‐tech way, Peter Warren, The Guardian, January 19, 2006; retrieved 7/6/2011; http://www.guardian.co.uk/politics/2006/jan/19/technology.security. [162] Terrorist Capabilities for Cyberattack: Overview and Policy Issues, US Congressional Research Service, January 22, 2007; retrieved 6/1/2011; http://opencrs.com/document/RL33123/. [163] Computer Hackers Attack State Dept., New York Times, July 12, 2006; retrieved 5/11/2011; http://www.nytimes.com/2006/07/12/washington/12hacker.html?_r=1. [164] State Department Releases Details of Computer System Attacks, Larry Greenemeier, InformationWeek, July 13, 2006; retrieved 5/11/2011; http://www.informationweek.com/news/190303153. [165] Chinese Hackers Hit Commerce Department, Gregg Keizer, InformationWeek, (October 06, 2006), http://www.informationweek.com/news/193105227. [166] Computer System Under Attack, Alan Sipress, Washington Post, October 6, 2006; retrieved 5/11/2011; http://www.washingtonpost.com/wp‐ dyn/content/article/2006/10/05/AR2006100501781.html. [167] As attacks increase, U.S. struggles to recruit computer security experts, Ellen Nakashima and Brian Krebs, Washington Post, December 23, 2009; retrieved 5/22/2011; http://www.washingtonpost.com/wp‐ dyn/content/article/2009/12/22/AR2009122203789.html. [168] 40 Million Credit Card Numbers Hacked, Jonathan Krim and Michael Barbaro, Washington Post, June 18, 2005; retrieved 7/8/2011; http://www.washingtonpost.com/wp‐ dyn/content/article/2005/06/17/AR2005061701031.html. [169] Japan cardholders 'hit' by theft, BBC World News, Tuesday, 21 June, 2005; retrieved 7/8/2011; http://news.bbc.co.uk/2/hi/business/4114252.stm. [170] London couple remanded in Israel’s biggest industrial espionage case, Conal Urquhart, Guardian, May 31, 2005; retrieved 7/5/2011; http://www.guardian.co.uk/world/2005/may/31/israel. [171] Security experts lift lid on Chinese hack attacks, Tom Espiner, ZDNet, November 23, 2005; retrieved 7/6/2011; http://www.zdnet.com/news/security‐experts‐lift‐lid‐on‐ chinese‐hack‐attacks/145763. [172] In Russia, Hackers Appear to Be Untouchable, Andrew Kramer, New York Times, August 24, 2010; retrieved 6/13/2011; http://query.nytimes.com/gst/fullpage.html?res=9803EFDB1439F937A1575BC0A9669D 8B63&pagewanted=1. [173] The Invasion of the Chinese Cyberspies, Nathan Thornburgh, Time, Aug. 29, 2005; http://www.time.com/time/magazine/article/0,9171,1098961,00.html.

123

Chapter 9: References

[174] Inside the Chinese Hack Attack, Nathan Thornburgh, Time Magazine, (Aug. 25, 2005), http://www.time.com/time/nation/article/0,8599,1098371,00.html. [175] Richard Norton‐Taylor, Titan Rain–how Chinese hackers targeted Whitehall, THE GUARDIAN (Sept. 5, 2007 03.06 BST), http://www.guardian.co.uk/technology/2007/sep/04/news.internet. [176] Myfip’s Titan Rain connection, Bill Brenner, SearchSecurity, 31 Aug 2005; retrieved 5/22/2011; http://searchsecurity.techtarget.com/news/1120855/Myfips‐Titan‐Rain‐ connection. [177] Lockheed Martin Network Attack Highlights Dangers of ‘Cyber‐Cold War,’ Wayne Rash, [178] eWeek, June 1, 2011; retrieved 6/8/2011; http://www.eweek.com/c/a/Security/Lockheed‐Martin‐Network‐Attack‐Highlights‐ Dangers‐of‐CyberCold‐War‐190580/?kc=EWKNLGOV06082011STR2. [179] Myfip Intellectual Property Theft Worm Analysis, Joe Stewart, Dell SecureWorks, August 16, 2005; retrieved 5/22/2011; http://www.secureworks.com/research/threats/myfip/. [180] Microsoft computer network hacked; FBI steps in, Paul Festa, CNET News, October 7, 2000; retrieved 5/23/2011; http://news.cnet.com/2100‐1001‐247716.html. [181] Microsoft hacked! Code stolen?, Ted Bridis, October 27, 2000; retrieved 5/23/2011; http://www.zdnet.com/news/microsoft‐hacked‐code‐stolen/111513. [182] Thief Reveals Credit Card Data When Web Extortion Plot Fails, John Markoff, NYT, January 10, 2000; retrieved 7/17/2011; http://www.nytimes.com/2000/01/10/business/thief‐reveals‐credit‐card‐data‐when‐ web‐extortion‐plot‐fails.html. [183] Internet Fraud's New Threat, Linda Punch, Highbeam Business, April 1, 2000; retrieved 7/17/2011; http://business.highbeam.com/137021/article‐1G1‐61873111/internet‐ fraud‐new‐threat. [184] Pentagon hit with ‘Maze’ of hack attacks / Investigators trace case to Russia, Vernon Loeb, Washington Post, May 07, 2001; retrieved 5/9/2011; http://articles.sfgate.com/2001‐05‐07/news/17601343_1_moonlight‐maze‐computer‐ attack‐pentagon‐computers. [185] Under Worm Assault, Military Bans Disks, USB Drives, Noah Shachtman, November 19, 2008; retrieved 8/13/2011; http://www.wired.com/dangerroom/2008/11/army‐bans‐ usb‐d/. [186] Zotob, PnP Worms Slam 13 DaimlerChrysler Plants, Paul F. Roberts, eWeek, August 18, 2005; retrieved 6/3/2011; http://www.eweek.com/c/a/Security/Zotob‐PnP‐Worms‐ Slam‐13‐DaimlerChrysler‐Plants/. [187] Computer Virus Brings Down Train Signals, Marty Niland, Associated Press, August 20, 2003; retrieved 6/3/2011; http://www.informationweek.com/news/13100807. [188] Virus Disrupts Train Signals, CBS News, August 21, 2003; retrieved 6/3/2011; http://www.cbsnews.com/stories/2003/08/21/tech/main569418.shtml. [189] Youth charged in virus attack, Laura Sullivan and Stephen Kiehl, Baltimore Sun, August 30, 2003; retrieved 6/3/2011; http://articles.baltimoresun.com/2003‐08‐ 30/news/0308300036_1_computer‐worm‐blaster‐worm‐blaster‐computer/3.

Cited

124

[190] Welchia, Wikipedia; retrieved 6/3/2011; http://en.wikipedia.org/wiki/Welchia. [191] Strong Attackers, Weak Software, Charles Duhigg, Washington Post, August 21, 2003; retrieved 6/3/2011; http://www.washingtonpost.com/ac2/wp‐dyn/A23036‐2003Aug20. [192] CERT® Advisory CA‐2003‐04 MS‐SQL Server Worm, January 27, 2003; retrieved 6/3/2011; http://www.cert.org/advisories/CA‐2003‐04.html. [193] NRC INFORMATION NOTICE 2003‐14, POTENTIAL VULNERABILITY OF PLANT COMPUTER NETWORK TO WORM INFECTION, UNITED STATES NUCLEAR REGULATORY COMMISSION OFFICE OF NUCLEAR REACTOR REGULATION, August 29, 2003; retrieved 6/3/2011; http://www.nrc.gov/reading‐rm/doc‐collections/gen‐comm/info‐ notices/2003/in200314.pdf. [194] List of computer worms, Wikipedia; retrieved 8/12/2011; http://en.wikipedia.org/wiki/List_of_computer_worms. [195] How to Hijack a Controller: Why Stuxnet Isn’t Just About Siemens’ PLCs, Ralph Langner, ControlGlobal, 01/13/2011; http://www.controlglobal.com/articles/2011/IndustrialControllers1101.html. [196] The Stuxnet Computer Worm: Harbinger of an Emerging Warfare Capability, US Congressional Research Service, December 9, 2010; 124ultisens 6/1/2011; www.fas.org/sgp/crs/natsec/R41524.pdf. [197] W32.Stuxnet Dossier, Symantec, February 2011; retrieved 8/9/2011; http://www.symantec.com/connect/blogs/w32stuxnet‐dossier. [198] Stuxnet Under the Microscope, Revision 1.21, Aleksandr Matrosov et al, undated; retrieved 8/13/2011; http://www.eset.com/us/resources/white‐ papers/Stuxnet_Under_the_Microscope.pdf. [199] Stuxnet ‐Infecting Industrial Control Systems, Liam Murchu, September 2010; retrieved 8/12/2011; www.cert.org/tces/pdf/liam%20o%20murchu.pdf. [200] Guide to Industrial Control Systems (ICS) Security, Special Publication 800‐82, National Institute of Standards and Technology, June 2011; http://csrc.nist.gov/groups/SMA/fisma/ics/documents/oct23‐2009‐workshop/nist‐ ics3_10‐23‐2009.pdf. [201] Distributed control system, Wikipedia; retrieved 7/31/2011; http://en.wikipedia.org/wiki/Distributed_control_system. [202] IEEE 1394 and Industrial Automation: A perfect Blend, Gaurav Sareen, WiPro, unknown date; retrieved 7/30/2011; http://www.automation.com/resources‐tools/articles‐white‐ papers/fieldbus‐serial‐bus‐io‐networks/ieee‐1394‐and‐industrial‐automation‐a‐perfect‐ blend. [203] SCADA, Wikipedia; retrieved 7/30/2011; http://en.wikipedia.org/wiki/SCADA. [204] Remote Terminal Unit, Wikipedia; retrieved 7/30/2011; http://en.wikipedia.org/wiki/Remote_Terminal_Unit. [205] Programmable logic controller, Wikipedia; retrieved 7/30/2011; http://en.wikipedia.org/wiki/Programmable_Logic_Controller. [206] Programmable automation controller, Wikipedia; retrieved 7/30/2011; http://en.wikipedia.org/wiki/Programmable_automation_controller.

125

Chapter 9: References

[207] NCS Bulletin TIB 04‐1 Supervisory Control and Data Acquisition (SCADA) Systems, Office of the Manager, National Communications System, October 2004, http://www.ncs.gov/library/tech_bulletins/2004/tib_04‐1.pdf. [208] SCADA Fundamentals, Functionality & Futures, Michael A. Marullo, GITA CONFERENCE PROCEEDINGS, April 23, 2006; retrieved 8/2/2011; http://www.gita.org/members_only/downloads/ShawW.pdf. [209] US hacker targets hospital’s HVAC system, Gerhard Hope, Construction Week Online, July 7, 2009; retrieved 6/4/2011; http://www.constructionweekonline.com/article‐5752‐ us_hacker_targets_hospitals_hvac_system/. [210] Arlington Security Guard Arrested on Federal Charges for Hacking into Hospital’s Computer System, U.S. Attorney’s Office, Northern District of Texas, June 30, 2009; retrieved 8/13/2011; http://www.fbi.gov/dallas/press‐releases/2009/dl063009.htm. [211] Electricity Grid in U.S. Penetrated By Spies, Siobhan Gorman, Wall Street Journal Online, April 8, 2009; retrieved 6/4/2011; http://online.wsj.com/article/SB123914805204099085.html. [212] Experts hack power grid in no time, Tim Greene, Network World, April 09, 2008; retrieved 6/3/2011; http://www.networkworld.com/news/2008/040908‐rsa‐hack‐ power‐grid.html. [213] Polish teen derails tram after hacking train network, John Leyden, A Register, January 11, 2008; retrieved 6/3/2011; http://www.theregister.co.uk/2008/01/11/tram_hack/. [214] SANS Flash: CIA Confirms Cyber Attack Caused Multi‐City Power Outage, SANS NewsBites, January 18, 2008; retrieved 6/13/2011; http://www.sans.org/newsletters/newsbites/newsbites.php?vol=10&issue=5. [215] Two City Engineers Charged with Allegedly Hacking Into City’s Traffic Computer, Los Angeles County District Attorney’s Office, Press Release, January 5, 2007; retrieved 6/3/2011; http://da.lacounty.gov/mr/archive/2007/010507a.htm. [216] Insider charged with hacking California canal system, Robert McMillan, NetworkWorld, November 29, 2007; retrieved 6/4/2011; http://www.networkworld.com/news/2007/112907‐insider‐charged‐with‐hacking‐ california.html. [217] Operation Aurora, YouTube Video from CNN; retrieved 6/4/2011; http://www.youtube.com/v/fJyWngDco3g. [218] Can Your Generator Be Hacked?, Rich Miller, Data Center Knowledge, September 27th, 2007; http://www.datacenterknowledge.com/archives/2007/09/27/can‐your‐generator‐ be‐hacked/. [219] Mitigating the Aurora Vulnerability With Existing Technology, Doug Salmon, et al, Schweitzer Engineering Laboratories, Inc., September 18, 2009; retrieved 6/4/2011; www.selinc.com/WorkArea/DownloadAsset.aspx?id=6379. [220] Hackers break into water system network, Robert McMillan, Network World, October 31, 2006; retrieved 6/3/2011; http://www.networkworld.com/news/2006/110106‐ hackers‐break‐into‐water‐system.html.

Cited

126

[221] Brit charged with hacking Pentagon, NASA, John Leyden, The A Register, November 13, 2002; retrieved 6/13/2011; http://www.theregister.co.uk/2002/11/13/brit_charged_with_hacking_pentagon/. [222] Gary McKinnon challenges extradition, Staff writers, Guardian, December 10, 2009; retrieved 7/5/2011; http://www.guardian.co.uk/world/2009/dec/10/gary‐mckinnon‐ lodges‐challenge‐extradition?INTCMP=ILCNETTXT3487. [223] Police warn small firms as grudge hacker is jailed, Karl Cushing, September 26, 2002; retrieved 6/13/2011; http://www.computerweekly.com/Articles/2002/09/26/189920/Police‐warn‐small‐ firms‐as‐grudge‐hacker‐is‐jailed.htm. [224] Humans opened the door for Calif. Power hack, ZDnet, June 14, 2001; retrieved 6/3/2011; http://www.zdnet.com/news/humans‐opened‐the‐door‐for‐calif‐power‐ hack/117607. [225] CRITICAL INFRASTRUCTURE PROTECTION: Multiple Efforts to Secure Control Systems Are Under Way, but Challenges Remain, US Government Accountability Office, October 17, 2007; retrieved 6/3/2011; http://www.gao.gov/new.items/d08119t.pdf. [226] Security of Distributed Control Systems: the Concern Increases, IEE Computing and Control Engineering, December/January 2005/06; retrieved 6/3/2011; http://www.au2mation.com/articles/006_Security_conference.pdf. [227] Protecting Critical Infrastructure from Cyber Attacks, presentation by Mark Henderson, Department of Homeland Security, National Cyber Security Division, United States Computer Emergency Readiness Team, June 2007; retrieved 6/3/2011; www.clcert.cl/seminario/US‐CERT_Chile_2007‐FINALv2.ppt. [228] Utility hack led to security overhaul, Michael Crawford, Computer World, February 16, 2006; retrieved 6/3/2011; http://www.computerworld.com/s/article/108735/Utility_hack_led_to_security_overha ul. [229] Juvenile Computer Hacker Cuts Off FAA Tower at Regional Airport, press release, U.S. Department of Justice; retrieved 6/3/2011; http://www.justice.gov/criminal/cybercrime/juvenilepld.htm. [230] Can Hackers Turn Your Lights Off? The Vulnerability of the US Power Grid to Electronic Attack, SANS Institute InfoSec Reading Room, 2001; retrieved 6/2/2011; http://www.sans.org/reading_room/whitepapers/hackers/hackers‐turn‐lights‐off‐ vulnerability‐power‐grid‐electronic‐attack_606. [231] Cyber warfare, Steven A. Hildreth, CRS Report for Congress, June 19, 2001; retrieved 4/18/2011; http://www.au.af.mil/au/awc/awcgate/crs/rl30735.pdf. [232] Supervisory Control and Data Acquisition (SCADA) Introduction, presentation by Jeff Dagle, PE, Grainger Lecture Series for the University of Illinois at Urbana‐Champaign, September 15, 2005; retrieved 6/3/2011; http://www.science.smith.edu/~jcardell/Readings/TRUST%20US/2005_09_15_Jeff_Dagl e.pdf.

127

Chapter 9: References

[233] Cyber terrorism, Dorothy Denning, August 24, 2000; retrieved 6/3/2011; http://www.cs.georgetown.edu/~denning/infosec/cyberterror‐GD.doc. [234] Siberian Pipeline Explosion, Wikipedia; retrieved 6/3/2011; http://en.wikipedia.org/wiki/Siberian_pipeline_sabotage. [235] Hackers tap SCADA vulnerability search engine, Dan Goodin, A Register, November 2, 2010; retrieved 6/4/2011; http://www.theregister.co.uk/2010/11/02/scada_search_engine_warning/. [236] ICS‐ALERT‐10‐301‐01 – CONTROL SYSTEM INTERNET ACCESSIBILITY, Industrial Control Systems Cyber Emergency Response Team, October 28, 2010; retrieved 8/9/2011; http://www.us‐cert.gov/control_systems/pdf/ICS‐Alert‐10‐301‐01.pdf. [237] Iran confirms Stuxnet found at Bushehr nuclear power plant, Paul Woodward, War In Context blog, September 26, 2010; retrieved 7/26/2011; http://warincontext.org/2010/09/26/iran‐confirms‐stuxnet‐found‐at‐bushehr‐nuclear‐ power‐plant/. [238] Sierra Wireless, Industrial and Infrastructure solutions; retrieved 8/10/2011; http://www.sierrawireless.com/Solutions/industrial_infrastructure.aspx. [239] The Virtual Wireless Plant Tour, Emerson Process Management; retrieved 8/12/2011; http://www2.emersonprocess.com/siteadmincenter/PM%20Central%20Web%20Docum ents/WirelessVirtualWebBrochure.pdf. [240] IEEE 802.11, Wikipedia; retrieved 8/10/2011; http://en.wikipedia.org/wiki/IEEE_802.11. [241] IEEE 802.15, Wikipedia; retrieved 8/10/2011; http://en.wikipedia.org/wiki/802.15. [242] ZigBee, Wikipedia; retrieved 8/10/2011; http://en.wikipedia.org/wiki/ZigBee. [243] OSI Remote Information System, Open Systems International; retrieved 8/10/2011; http://www.osii.com/pt/solutions/products/remote‐telemetry.asp. [244] Welcome to Windows CE, Microsoft Development Network; retrieved 8/12/2011; http://msdn.microsoft.com/en‐us/library/ms905511.aspx. [245] Windows Embedded, Wikipedia; retrieved 8/12/2011; http://en.wikipedia.org/wiki/Windows_Embedded#Windows_Embedded_Standard. [246] VISUNET IND, Pepperl and Fuchs; retrieved 8/12/2011; http://files.pepperl‐ fuchs.com/selector_files/navi/productInfo/doct/tdoctb0b2__usa.pdf. [247] Embedded Linux, Wikipedia; retrieved 8/12/2011; http://en.wikipedia.org/wiki/Embedded_Linux. [248] Software Products for Industrial Automation, Automation Direct; retrieved 8/12/2011; http://www.automationdirect.com/adc/Overview/Catalog/Software_Products. [249] SIMATIC Controller Software, Siemens Corporation; retrieved 8/12/2011; http://www.automation.siemens.com/salesmaterial‐as/brochure/en/brochure_simatic‐ industrial‐software_en.pdf. [250] PLC Software and Dashboard Controls for Visual Studio.NET HMI Development, CimQuest INGEAR, LLC; retrieved 8/12/2011; http://www.ingeardrivers.com/. [251] Inductive Automation Corporation; retrieved 8/12/2011; http://www.inductiveautomation.com.

Cited

128

[252] Plant‐Controller Attacks via Cut‐link and Flooding Attacks, Katherine Gabales, Department of Electrical Engineering and Computer Sciences, College of Engineering, University of California at Berkeley, July 30, 2010; retrieved 8/12/2011; http://www.truststc.org/reu/10/Reports/GabalesK_paper.pdf. [253] Architecture for Secure SCADA and Distributed Control System Networks, Juniper White Paper, 2010; retrieved 8/12/2011; http://www.juniper.net/us/en/local/pdf/whitepapers/2000276‐en.pdf. [254] Emerson Wireless Security, Wireless Security Whitepaper, Emerson Process Management, January 2011; retrieved 8/12/2011; http://www2.emersonprocess.com/siteadmincenter/PM%20Central%20Web%20Docum ents/Emerson%20Wireless%20Security.pdf. [255] Viking Project, Automatic Control Laboratory, Swiss Federal Institute of Technology at Zurich, April 15, 2010; retrieved 8/27/2010; http://control.ee.ethz.ch/~viking/. [256] SIMATIC WinCC: Process visualization with Plant Intelligence, Brochure, Siemens Corporation, November 2010; retrieved 8/13/2011; http://www.automation.siemens.com/salesmaterial‐as/brochure/en/brochure_simatic‐ wincc_en.pdf. [257] Homemade cyberweapon worries federal officials, Shaun Waterman, Washington Times, May 24, 2011; retrieved 7/7/2011; http://www.washingtontimes.com/news/2011/may/24/homemade‐cyberweapon‐ worries‐feds/. [258] ICS‐CERT ADVISORY ICSA‐11‐167‐01—HEAP OVERFLOW VULNERABILITIES IN SUNWAY FORCECONTROL AND PNETPOWER, US. Department of Homeland Security Industrial Control Systems Cyber‐Emergency Response Team, June 16, 2011; retrieved 7/7/2011; http://www.us‐cert.gov/control_systems/pdf/ICSA‐11‐167‐01.pdf [259] Role and Challenges for Sufficient Cyber‐Attack Attribution, Jeffrey Hunker, Bob Hutchinson, Jonathan Margulies, Dartmouth College Institute for Information Infrastructure Protection, January, 2008; http://www.thei3p.org/docs/publications/whitepaper‐attribution.pdf. [260] Clark DD, Landau S. The problem isn’t attribution: It’s multi‐stage attacks. ReARCH ‘10: Proceedings of the Re‐Architecting the Internet Workshop 2010; http://conferences.sigcomm.org/co‐next/2010/Workshops/REARCH/ReArch_papers/11‐ Clark.pdf. [261] A Declaration of Cyber‐War, Michael Joseph Gross, Vanity Fair, April 2011; http://www.vanityfair.com/culture/features/2011/04/stuxnet‐201104. [262] Security incidents and trends in SCADA and process industries, Eric Byres, David Leversage and Nate Kube, Industrial Ethernet Book, Issue 39, May 2007; retrieved 6/3/2011; http://www.mtl‐ inst.com/images/uploads/datasheets/IEBook_May_07_SCADA_Security_Trends.pdf. [263] Dozens of exploits released for popular SCADA programs, Dan Goodin, The Register, March 22, 2011; retrieved 8/13/2011; http://www.theregister.co.uk/2011/03/22/scada_exploits_released/.

129

Chapter 9: References

[264] Vista Log Forensics, Rich Murphey, Presentation, DEF CON 15, August 3‐5, 2007; retrieved 8/20/2011; http://www.defcon.org/images/defcon‐15/dc15‐presentations/dc‐ 15‐murphey.pdf. [265] A Practical Approach for Evidence Gathering in Windows Environment, Kaveesh Dashora et al, International Journal of Computer Applications (0975 – 8887), Volume 5– No.10, August 2010; http://www.ijcaonline.org/volume5/number10/pxc3871326.pdf. [266] Digital Forensics and Windows 7: Overview, Troy Larson, Microsoft Network Security Investigations and Forensics, November 17, 201; retrieved 8/21/2011; http://www.slideshare.net/ctin/windows‐7‐forensics‐overviewr3. [267] Digital Forensics and Windows 7: Event Logs, Troy Larson, Microsoft Network Security Investigations and Forensics, undated; retrieved 8/21/2011; http://www.slideshare.net/ctin/windows‐7‐forensics‐event‐logsdtlr3. [268] Forensically interesting spots in the Windows 7, Vista and XP file system and registry, IronGeek, September 24, 2009; retrieved 8/21/2011; http://www.irongeek.com/i.php?page=security/windows‐forensics‐registry‐and‐file‐ system‐spots. [269] Forensics Tools and Processes for Windows XP Clients, Larry Leibrock, October 3, 2002; retrieved 8/20/2011; http://www.blackhat.com/presentations/bh‐asia‐02/bh‐asia‐02‐ leibrock.pdf. [270] Windows Forensic Analysis, Harlan Carvey, Syngress Publishing, 2007. [271] Event Logs, Microsoft TechNet Library: Windows Server / Windows Server 2008 and Windows Server 2008 R2 / Windows Server Content by Category / Windows Server 2008 Content by Category / Installed Help / Troubleshooting / Event Viewer; retrieved 8/20/2011; http://technet.microsoft.com/en‐us/library/cc722404(WS.10).aspx. [272] Windows log files, Jean‐Baptiste Marchand, Hervé Schauer Consultants, 2005; retrieved 8/22/2011; http://www.hsc.fr/ressources/articles/win_log_files/index.html.en. [273] Researcher 'Fingerprints' The Bad Guys Behind The Malware, Kelly Higgins, Dark Reading, June 22, 2010; retrieved 5/15/2011; http://www.darkreading.com/database‐ security/167901020/security/news/225700716/researcher‐fingerprints‐the‐bad‐guys‐ behind‐the‐malware.html. [274] UserAssist uncovers hidden Windows activity logs, Mike Williams, betanews, July 2011; retrieved 8/25/2011; http://betanews.com/2011/07/18/userassist‐uncovers‐hidden‐ windows‐activity‐logs/. [275] Physical Memory Forensics, Mariusz Burdach, Presentation, Black Hat USA 2006; retrieved 8/22/2011; http://www.blackhat.com/presentations/bh‐usa‐06/BH‐US‐06‐ Burdach.pdf. [276] UNIX and Linux Forensic Analysis, Chris Pogue, Syngress Publishing, 2008. [277] Getting Familiar with Linux Logs, Mark Sanborn, May 13, 2009; retrieved 8/20/2011; http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a008009 4831.shtml. [278] The Law Enforcement and Forensic Examiner's Introduction to Linux, Barry Grundy, December 2008; retrieved 8/21/2011; http://linuxleo.com/.

Cited

130

[279] Digital Forensics for UNIX. John Green and Hal Pomeranz, the SANS Institute, undated; retrieved 8/21/2011; http://www.deer‐run.com/~hal/IntroToDigitalForensics.pdf. [280] Forensic Analysis of a Live Linux System, Pt. 1, Mariusz Burdach, Symantec Connect, November 2, 2010; retrieved 8/22/2011; http://www.symantec.com/connect/articles/forensic‐analysis‐live‐linux‐system‐pt‐1. [281] Forensic Analysis of a Live Linux System, Pt. 2 Mariusz Burdach, Symantec Connect, November 2, 2010; retrieved 8/22/2011; http://www.symantec.com/connect/articles/forensic‐analysis‐live‐linux‐system‐pt‐2. [282] Linux Log Files, Ubuntu Documentation; retrieved 8/22/2011; https://help.ubuntu.com/community/LinuxLogFiles. [283] A Firewall Log Analysis Primer, Dell SecureWorks; http://www.secureworks.com/research/articles/firewall‐primer. [284] Identifying Incidents Using Firewall and Cisco IOS Router Syslog Events, Cisco Security Intelligence Operations, Cisco Corporation; retrieved 8/24/2011; http://www.cisco.com/web/about/security/intelligence/identify‐incidents‐via‐ syslog.html. [285] Cisco ASA and PIX Firewall Logging, in Cisco ASA and PIX Firewall Handbook, David Hucaby, Cisco Press, June 7, 2005. [286] Lock IT Down: Best practices for managing firewall logs, Michael Mullins, Tech Republic, May 29, 2002; retrieved 8/24/2011; http://www.techrepublic.com/article/lock‐it‐down‐ best‐practices‐for‐managing‐firewall‐logs/1047958. [287] Proxy server, Wikipedia; retrieved 8/25/2011; http://en.wikipedia.org/wiki/Proxy_server. [288] Proxy server, Forensics Wiki; retrieved 8/25/2011; http://www.forensicswiki.org/wiki/Proxy_server. [289] Passive Network Traffic Analysis: Understanding a Network Through Passive Monitoring, Kevin Timm, Symantec Security Focus, November 2, 2010; retrieved 8/28/2011; http://www.symantec.com/connect/articles/passive‐network‐traffic‐analysis‐ understanding‐network‐through‐passive‐monitoring. [290] Proxy Logs ‐ The Other White Meat, Fravia; march 2002; retrieved 8/25/2011; http://www.searchlores.org/whitemea.htm. [291] Network address translation, Wikipedia; retrieved 8/27/2011; http://en.wikipedia.org/wiki/Network_address_translation. [292] How NAT Works, (Document ID: 6450), Cisco IP Addressing Services, Cisco Corporation, March 29, 2011; Retrieved 8/27/2011; http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a008009 4831.shtml. [293] Obtaining Information about Sessions and Terminating Them, Juniper Networks, Inc., undated; retrieved 8/27/2011; http://www.juniper.net/techpubs/software/junos‐ security/junos‐security10.0/junos‐security‐swconfig‐security/jd0e2466.html#session‐ log‐entry‐detail.

131

Chapter 9: References

[294] Internet Service Providers, Laura Knapp and Thomas Hadley, undated; retrieved 8/30/2011; www.lauraknapp.com/images/isp.pdf. [295] Internet exchange point, Wikipedia; retrieved 8/27/2011; http://en.wikipedia.org/wiki/Internet_exchange_point. [296] How Internet Infrastructure Works, Jeff Tyson, How Stuff Works, undated; retrieved 8/26/2011; http://computer.howstuffworks.com/internet/basics/internet‐ infrastructure1.htm. [297] Telecommunications: A Beginners Guide, Hill Associates, December 2001. [298] List of ISPs, Internet.Com; retrieved 8/27/2011; http://www.thelist.com/misc/usa/. [299] List of Internet exchange points, Wikipedia; retrieved 8/27/2011; http://en.wikipedia.org/wiki/List_of_Internet_exchange_points. [300] Data Center Map: Internet Exchange Points; retrieved 8/27/2011; http://www.datacentermap.com/ixps.html. [301] Telecom Ramblings; retrieved 8/30/2011; http://www.telecomramblings.com/. [302] Router Security Configuration Guide, National Security Agency, December 15, 2005; retrieved 8/27/2011; http://www.nsa.gov/ia/_files/routers/C4‐040R‐02.pdf. [303] Auditing CISCO Routers, 31st Annual Computer Security Conference and Exhibition, Technology Pathways, LLC, 2004; retrieved 8/27/2011; http://www.techpathways.com/uploads/CSI04‐FOR4.pdf. [304] Cisco Guide to Harden Cisco IOS Devices (Document ID: 13608), Cisco IP Addressing Services, Cisco Corporation, last updated: June 7, 2011; retrieved 8/27/2011; http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a008012 0f48.shtml. [305] Router IP Traffic Export Packet Capture Enhancements, Cisco IOS Software Releases 12.4 T, Cisco Corporation, last updated November 17, 2006; retrieved 8/28/2011; http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html. [306] Catalyst 6500 Release 12.2SX Software Configuration Guide: Cisco IOS ACL Support, undated; retrieved 8/27/2011; http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration /guide/acl.html. [307] Cisco Router Forensics, Thomas Akin, BlackHat Briefings USA 2002; retrieved 8/27/2011; http://www.blackhat.com/presentations/bh‐usa‐02/bh‐us‐02‐akin‐cisco/bh‐us‐02‐akin‐ cisco.ppt. [308] AdventNet ManageEngine, ExtraLAN Ltd; retrieved 8/30/2011; http://www.extralan.co.uk/products/diagnostic‐tools/adventnet/oputils.htm. [309] Detecting Attacks on Web Applications from Log Files, Roger Meyer, SANS Institute, January 26, 2008; retrieved 8/27/2011; http://www.sans.org/reading_room/whitepapers/logging/detecting‐attacks‐web‐ applications‐log‐files_2074. [310] Detection and Evasion of Web Application Attacks, KK Mookhey, Blackhat 2004; retrieved 8/28/2011; http://www.blackhat.com/presentations/bh‐usa‐04/bh‐us‐04‐ mookhey/bh‐us‐04‐mookhey‐up.ppt.

Cited

132

[311] Log Files, Apache HTTP Server Version 2.2 Documentation; retrieved 8/22/2011; http://httpd.apache.org/docs/2.2/logs.html#accesslog. [312] Web Server (IIS), Microsoft TechNet; retrieved 8/22/2011; http://technet.microsoft.com/en‐us/library/cc753433(WS.10).aspx. [313] W3C Extended Log File Examples (IIS 6.0), Microsoft TechNet, Windows Server 2003 TechCenter; retrieved 8/22/2011; http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ffdd7 079‐47be‐4277‐921f‐7a3a6e610dcb.mspx?mfr=true. [314] Apache Attack samples, Open Source Host‐based Intrusion Detection System; retrieved 8/22/2011; http://www.ossec.net/wiki/Apache_attack_samples. [315] Call Detail Record, Wikipedia; retrieved 8/28/2011; http://en.wikipedia.org/wiki/Call_detail_record. [316] Fusion PBX; retrieved 9/9/2011; http://www.fusionpbx.com/. [317] Privacy Policy, Cricket Holdings, LLC; retrieved 8/22/2011; http://www.cricketholdings.com/privacy‐policy/. [318] Privacy Policy: Highlights, T‐Mobile USA, Inc.; retrieved 8/22/2011; http://www.t‐ mobile.com/company/website/privacypolicy.aspx. [319] Sprint Nextel Privacy Policy, Sprint Nextel, Inc.; retrieved 8/22/2011; http://www.sprint.com/legal/privacy.html. [320] Privacy Policy, Verizon Corporation; retrieved 8/22/2011; http://www22.verizon.com/about/privacy/policy/. [321] AT&T Privacy Policy, AT&T Corporation; retrieved 8/22/2011; http://www.att.com/gen/privacy‐policy?pid=2506. [322] DOJ's push for data retention & competing on privacy, Christopher Soghoian, January 26, 2011; retrieved 8/22/2011; http://paranoia.dubfire.net/2011/01/dojs‐push‐for‐data‐ retention‐competing.html. [323] A Review of the Federal Bureau of Investigation’s Use of National Security Letters, Office of the Inspector General, U. S. Department of Justice, March 2007; retrieved 8/22/2011; http://www.justice.gov/oig/special/s1001r.pdf. [324] Law Enforcement Resource Team (LERT), Verizon Wireless, undated; retrieved 5/7/2011; http://publicintelligence.info/VerizonLawEnforcementResourceTeam.pdf. [325] Letter from Kent Nakamura, Vice President for Policy and Privacy, Sprint Nextel, to Representatives Edward Markey and Joseph Barton, US House Of Representatives, April 19, 2011; retrieved 8/22/2011; http://markey.house.gov/docs/4‐19‐ 11_sprint_letter.pdf. [326] Testimony and Statement for the Record of Marc Rotenberg, Electronic Privacy Information Center, hearing on House Rule 1981, Protecting Children From Internet Pornographers Act of 2011, US House of Representatives, July 28, 2011; retrieved 8/30/2011; http://epic.org/privacy/testimony/EPIC_Data_Retention_Testimony_FINAL.pdf. [327] ISP Data Retention: Early Results in, Ryan Singel, Wired Magazine, March 21, 2007; retrieved 8/30/2011; http://www.wired.com/threatlevel/2007/03/isp_data_retent/.

133

Chapter 9: References

[328] Which ISPs Are Spying on You?, Ryan Singel , Wired magazine, May 30, 2007; http://www.wired.com/politics/onlinerights/news/2007/05/isp_privacy. [329] Statement of Jason Weinstein Deputy Assistant Attorney General for the Criminal Division Before the House Subcommittee on Crime, Terrorism and Homeland Security, Washington, D.C. ~ Tuesday, January 25, 2011; retrieved 8/22/2011; http://www.justice.gov/criminal/pr/testimony/2011/crm‐testimony‐110125.html. [330] House Rule 1981, Protecting Children From Internet Pornographers Act of 2011, US House of Representatives, July 28, 2011; retrieved 8/30/2011; http://thomas.loc.gov/cgi‐bin/bdquery/z?d112:h.r.1981:. [331] DOJ seeks mandatory data retention requirement for ISPs, Jaikumar Vijayan, ComputerWorld, January 25, 2011; http://www.computerworld.com/s/article/9206379/DOJ_seeks_mandatory_data_retent ion_requirement_for_ISPs. [332] FBI still wants two years of ISP Web logs, Nate Anderson, ars technica, January 2010; http://arstechnica.com/tech‐policy/news/2010/02/fbi‐still‐wants‐two‐years‐of‐isp‐web‐ logs.ars. [333] Telecommunications data retention, Wikipedia; retrieved 8/30/2011; http://en.wikipedia.org/wiki/Telecommunications_data_retention. [334] Examples of Data Retention Rules in Different Countries [4.4.4], International Telecommunications Union; 8/30/2011; http://www.ictregulationtoolkit.org/en/PracticeNote.2117.html. [335] A review by InTechnology of legislation and regulation concerning data storage in the UK and Europe, White Paper, InTechnology Managed Services, April 2004; retrieved 8/30/2011; http://www.intechnology.co.uk/documents/whitepapers/MakingSense_DataLaw.pdf. [336] UK data retention requirements, White Paper, Watson Hall Ltd, 2009; https://www.watsonhall.com/resources/downloads/paper‐uk‐data‐retention‐ requirements.pdf. [337] Domain name registry, Wikipedia; retrieved 8/31/2011; http://en.wikipedia.org/wiki/Domain_name_registry. [338] Internet Corporation for Assigned Names and Numbers; http://www.icann.org/. [339] Domain privacy, Wikipedia; retrieved 8/31/2011; http://en.wikipedia.org/wiki/Domain_privacy. [340] Regional Internet registry, Wikipedia; retrieved 8/31/2011; http://en.wikipedia.org/wiki/Regional_Internet_registry. [341] Roadmap to Secure Control Systems in the Energy Sector, Dale Peterson, Energy Sector Control Systems Working Group, ie Roadmap Workshop, May 28‐39, 2008; retrieved 8/31/2011; http://www.controlsystemsroadmap.net/pdfs/11%20PLC%20Passive%20Security.pdf. [342] SCADA Systems, Motorola Whitepaper, 2007; retrieved 8/31/2011; http://www.motorola.com/web/Business/Products/SCADA%20Products/_Documents/St atic%20Files/SCADA_Sys_Wht_Ppr‐2a_New.pdf.

Cited

134

[343] Security Basics: Control System Forensics, Andrew Ginter, Control System Security blog, January 27, 2011; retrieved 8/31/2011; http://controlsystemsecurity.blogspot.com/2011/01/security‐basics‐control‐ system.html. [344] Recommended Practice: Creating Cyber Forensics Plans for Control Systems, US Department of Homeland security, August 2008; retrieved 8/31/2011; http://www.us‐ cert.gov/control_systems/pdf/Forensics_RP.pdf. [345] SIMATIC WinCC: Process visualization with Plant Intelligence, Siemens AG, November 2010; retrieved 8/31/2011; http://www.automation.siemens.com/salesmaterial‐ as/brochure/en/brochure_simatic‐wincc_en.pdf. [346] IPv4, Wikipedia; retrieved 9/12/2011; http://en.wikipedia.org/wiki/IPv4. [347] Security problems in the TCP/IP protocol suite, S.M. Bellovin, ACM SIGCOMM Computer Communication Review, Volume 19 Issue 2, April 1, 1989; http://www.scribd.com/doc/51338640/Security‐problems‐in‐TCP‐IP‐Protocol‐Suite. [348] Guide to Computer Security Log Management, Karen Kent and Murugiah Souppaya, National Institute of Standards and Technology, Special Publication 800‐92, September 2006; retrieved 9/9/2011; http://csrc.nist.gov/publications/nistpubs/800‐92/SP800‐ 92.pdf. [349] Configuring IIS Logs (IIS 6.0), Microsoft Windows Server 2003 TechCenter, undated; retrieved 9/5/2011; http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/b344f 84e‐bc77‐4019‐859c‐9d483bc85c77.mspx?mfr=true. [350] How to configure Web site logging in Windows Server 2003 (KB 324279), Microsoft Support, December 3, 2007; retrieved 9/5/2011; http://support.microsoft.com/default.aspx?scid=kb;en‐us;324279. [351] Enable or Disable Logging (IIS 7), Microsoft TechNet, undated; retrieved 9/5/2011; http://technet.microsoft.com/en‐us/library/cc754631(WS.10).aspx. [352] Understanding Windows Logging, Ricky M. Magalhaes, Windows Security, May 13, 2004; retrieved 8/19/2011; http://www.windowsecurity.com/articles/understanding_windows_logging.html. [353] International Telecommunication Union, Wikipedia; http://en.wikipedia.org/wiki/International_Telecommunication_Union. [354] W3C Extended Log File Format (IIS 6.0), Microsoft Windows Server 2003 TechCenter, undated; retrieved 9/5/2011; http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/6764 00bc‐8969‐4aa7‐851a‐9319490a9bbb.mspx?mfr=true. [355] Forensic Log Parsing with Microsoft's LogParser, Mark Burnett, Symantec, November 2, 2010; retrieved 9/8/2011; http://www.symantec.com/connect/articles/forensic‐log‐ parsing‐microsofts‐logparser. [356] Apache Log Viewer, iannet.org, January 2011; retrieved 9/8/2011; http://www.apacheviewer.com/logfiles.php.

135

Chapter 9: References

[357] Troubleshooting HTTP 401 errors in IIS, Article ID: 907273, Microsoft Support, Last Reviewed: December 3, 2007; retrieved 9/8/2011; http://support.microsoft.com/kb/907273. [358] Best Practices for Online Service Providers, Whitepaper, June 2008, Electronic Frontier Foundation; retrieved 9/9/2011; http://www.eff.org/wp/osp. [359] Network Time Protocol, Wikipedia; retrieved 9/5/2011; http://en.wikipedia.org/wiki/Network_Time_Protocol. [360] NAT logging basics, David Ford, Oxford University Computing System, July 16, 2009; retrieved 9/5/2011; http://www.oucs.ox.ac.uk/network/security/documents/nattalk.pdf. [361] Log Parser 2.2, Microsoft Tools and Utilities, Microsoft TechNet; undated; retrieved 9/8/2011; http://technet.microsoft.com/en‐us/scriptcenter/dd919274. [362] Log Parser Lizard version 2.0, Lizard Labs (available through CNET Downloads), June 6, 2011; retrieved 9/8/2011; http://download.cnet.com/Log‐Parser‐Lizard/3010‐10248_4‐ 10778651.html?tag=metaData;specsBox. [363] IIS Centralized Binary Logging (IIS 6.0), Microsoft TechNet, undated; retrieved 9/8/2011; http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/13a4c 0b5‐686b‐4766‐8729‐a3402da835f1.mspx?mfr=true. [364] W3C Centralized Logging (IIS 6.0), Microsoft TechNet, undated; retrieved 9/8/2011; http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/6d59 3c76‐94a2‐4360‐b93d‐8ec2bc384f5a.mspx?mfr=true. [365] Professional IIS 7, Kenneth Schaefer et al, March 10, 2008, Wrox. [366] Apache Log Files, Vivek Gete, nixCraft, June 8, 2008; retrieved 9/8/2011; http://www.cyberciti.biz/faq/apache‐logs/. [367] Log Files, Apache HTTPD Server 2.2, undated; retrieved 9/8/2011; http://httpd.apache.org/docs/current/logs.html. [368] EventLog Analyzer, Zoho Corporation Pvt. Ltd.; retrieved 9/8/2011; http://www.manageengine.com/products/eventlog/. [369] Snare Epilog for Windows, InterSect Alliance Pty Ltd; retrieved 9/8/2011; http://www.intersectalliance.com/projects/EpilogWindows/index.html. [370] IIS Monitoring & Management, Hyperic, Inc; retrieved 9/8/2011; http://www.hyperic.com/products/iis‐monitoring. [371] Automatic IIS log housekeeping, 808.dk, last updated November 23, 2009; retrieved 9/8/2011; http://www.808.dk/?code‐iis‐log‐housekeeping. [372] IIS7 logging in Central Location for web farms, Brad Marsh, January 15, 2009; retrieved 9/8/2011; http://bradmarsh.net/index.php/2009/01/15/iis7‐logging‐in‐central‐location‐ for‐web‐farms/. [373] Syslog, Wikipedia; retrieved 9/8/2011; http://en.wikipedia.org/wiki/Syslog. [374] Apache Syslog, Khai’s personal wiki, October 18, 2010; retrieved 9/8/2011; http://khaidoan.wikidot.com/. [375] Sending Apache httpd Logs to Syslog, Rich Bowen, O’Reilly SysAdmin, October 12, 2006; retrieved 9/8/2011; http://oreilly.com/pub/a/sysadmin/2006/10/12/httpd‐syslog.html.

Cited

136

[376] mod_log_spread, Center for Networking and Distributed Systems, Computer Science Department, Johns Hopkins University; retrieved 9/8/2011; http://www.backhand.org/mod_log_spread/. [377] Apache Monitoring & Management, Hyperic, Inc; retrieved 9/8/2011; http://www.hyperic.com/products/apache‐monitoring. [378] Configure Per‐Server Logging Options (IIS 7), Microsoft TechNet, undated; retrieved 9/8/2011; http://technet.microsoft.com/en‐us/library/cc771850(WS.10).aspx. [379] ODBC Logging, Microsoft TechNet, August 22, 2005; retrieved 9/7/2011; http://technet.microsoft.com/en‐us/library/cc739275(WS.10).aspx. [380] Stealing The Internet: An Internet‐Scale Man in the Middle Attack, Alex Pilosov and Tony Kapela, Defcon 16, Las Vegas, NV ‐ August 10, 2008; retrieved 5/19/2011; http://www.defcon.org/images/defcon‐16/dc16‐presentations/defcon‐16‐pilosov‐ kapela.pdf. [381] VeriSign Implements Rapid Updates to Domain Name System Files, Hosting News, September 9, 2004; retrieved 9/5/2011; http://www.thehostingnews.com/news‐ verisign‐implements‐rapid‐updates‐to‐domain‐name‐system‐files‐542.html. [382] Know Your Enemy: Fast‐Flux Service Networks, Jamie Riden, The Honeynet Project, August 16, 2008; retrieved 9/5/2011; http://www.honeynet.org/node/131. [383] FluXOR: detecting and monitoring fast‐flux service networks, Emanuele Passerini et al, Universita degli Studi di Milano, 2008; retrieved 9/5/2011; http://security.dsi.unimi.it/~roberto/pubs/dimva08‐fluxor.pdf. [384] Intrusion Detection FAQ: What are some things that one can do to best elicit cooperation from ISPs in tracking an attacker?, SANS Institute, undated; retrieved 9/12/2011; http://www.sans.org/security‐resources/idfaq/cooperation_from_isps.php. [385] Short Introduction of Telecom‐Information and Analysis Center (ISAC) Japan: Overview, Current Activities, ISAC Japan, March 25, 2008; retrieved 9/12/2011; http://www.nca.gr.jp/jws2008/WS6‐04‐telecom‐isac‐japan.pdf. [386] ISP Security ‐ Real World Techniques, North American Network Operators Group, retrieved 9/12/2011; www.nanog.org/meetings/nanog23/presentations/greene.ppt. [387] Georgia DDoS Attacks – A Quick Summary of Observations, Jose Nazario, Arbor Networks, August 12, 2008; retrieved 9/13/2011; http://asert.arbornetworks.com/2008/08/georgia‐ddos‐attacks‐a‐quick‐summary‐of‐ observations/. [388] Inferring Internet Denial‐of‐Service Activity, David Moore et al, Proceedings of USENIX Security Symposium'2001, Washington D.C., August 2001; retrieved 9/13/2011; http://www.caida.org/publications/papers/2001/BackScatter/usenixsecurity01.pdf. [389] Inferring Internet Denial‐of‐Service Activity, David Moore et al, ACM Transactions on Computer Systems, Vol. 24, No. 2, May 2006; retrieved 9/13/2011; http://cseweb.ucsd.edu/~savage/papers/Tocs06.pdf. [390] Microsoft takes down massive botnet via legal action, Emil Protalinski, TechSpot, march 18, 2011; retrieved 9/13/2011; http://www.techspot.com/news/42885‐microsoft‐takes‐ down‐massive‐botnet‐via‐legal‐action.html.

137

Chapter 9: References

[391] Old IPv4 flaws resurface with IPv6, Iljitsch van Beijnum, ars technical, May 2007; retrieved 9/13/2011; http://arstechnica.com/hardware/news/2007/05/old‐ipv4‐flaws‐ resurface‐with‐ipv6.ars. [392] Navy official says IPv6 could contain hidden denial of service bugs, David Perera, FierceGovernmentIT, August 4, 210; retrieved 9/13/2011; http://www.fiercegovernmentit.com/story/navy‐official‐says‐ipv6‐could‐contain‐hidden‐ denial‐service‐bugs/2010‐08‐04. [393] Multiple systems ICMPv6 flood DoS, Computer Security Vulnerabilities, Marc Heuse, April 13, 2011; retrieved 9/13/2011; http://securityvulns.com/docs26120.html. [394] IPv6‐to‐IPv4 Transition And Security Issues, Information Technology Protective Security Services, February 20, 2008; retrieved 9/13/2011; http://www.brucert.org.bn/files/IPv6‐ to‐IPv4%20Transition%20&%20Security%20Issues.pdf. [395] IPv6 Extension Headers, Bill Cerveny, Arbor Networks, August 2, 2011; retrieved 9/13/2011; http://asert.arbornetworks.com/2011/08/ipv6‐extension‐headers/. [396] Searching & Seizing Computers and Obtaining Electronic Evidence in Criminal Investigations, United States Department of Justice, September 2009; retrieved 9/12/2011; http://www.cybercrime.gov/ssmanual/index.html. [397] IPv6 Obfuscation and Attribution: Some Quick Framing Slides Emerging Trends, Challenges and Strategies Panel, Joe Stauver, NCFTA Canada, Montreal, Quebec, November 17th, 2010; retrieved 9/13/2011; http:// pages.uoregon.edu/joe/ipv6‐for‐ panel/ipv6‐for‐panel.ppt. [398] REPORT ON THE SECURITY IMPLICATIONS OF IMPLEMENTING IPv6, National Institute of Communication Technologies (INTECO), June 2010; retrieved 9/13/2011; http://cert.inteco.es/extfrontinteco/img/File/intecocert/EstudiosInformes/cert_inf_secu rity_implications_ipv6.pdf. [399] A Framework for Assessing and Improving the Security Posture of Industrial Control Systems (ICS) version 1.1, Systems and Network Analysis Center, National Security Agency, August 20, 2010; retrieved 7/30/2011; http://www.nsa.gov/ia/_files/ics/ics_fact_sheet.pdf.

Additional

138

9.2. Additional 9.2.1. Technical Papers [1] [2] [3]

[4]

[5]

[6] [7] [8] [9]

[10]

[11]

[12]

[13] [14]

[15]

Towards an Efficient Implementation of Traceback Mechanisms in Autonomous Systems; K. Boudaoud, F. LeBorgne; Agresti WW. The four forces shaping cybersecurity. Computer 2010;43(2):101‐4. Akritidis P, Anagnostakis K, Markatos EP. Efficient content‐based detection of zero‐day worms. Communications, 2005.ICC 2005.2005 IEEE International Conference on 2005;2(2005):837‐43. Alexander S, DeCleene B, Rogers J, Sholander P. Requirements and architectures for intrinsically assurable mobile ad hoc networks. Military Communications Conference, 2008.MILCOM 2008.IEEE 2008:1‐10. Antoniades D, Trimintzios P, Polychronakis M, Ubik S, Papadogiannakis A, Smotlacha V. LOBSTER: A 138ultisen platform for passive network traffic monitoring. TridentCom ‘08: Proceedings of the 4th International Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities 2008. Bass T. Intrusion detection systems and 138ultisensory data fusion. Commun ACM 2000;43(4). Biryukov A, Lano J, Preneel B. Recent attacks on alleged SecurID and their practical implications. Computers and Security 2005;24(5):364‐70. Bishop M, Gates C, Hunker J. The sisterhood of the traveling packets. NSPW ‘09: Proceedings of the 2009 Workshop on New Security Paradigms Workshop 2009. Boudaoud K, LeBorgne F. Towards an efficient implementation of traceback mechanisms in autonomous systems. Network Operations and Management Symposium, 2008.NOMS 2008.IEEE 2008(2008):1015‐8. Burd SD, Jones DE, Seazzu AF. Bridging differences in digital forensics for law enforcement and national security. System Sciences (HICSS), 2011 44th Hawaii International Conference on 2011:1‐6. Caballero J, Poosankam P, McCamant S, Babić D, Song D. Input generation via decomposition and re‐stitching: Finding bugs in malware. Proceedings of the ACM Conference on Computer and Communications Security 2010:413‐25. Castro R, Barbato P, Taliercio C, Vega J. Securing remote services by integrating SecurID strong authentication technology in EFDA‐federation infrastructure. Fusion Eng Des 2011;ISSU. Champion T, Denz ML. A benchmark evaluation of network intrusion detection systems. Aerospace Conference, 2001, IEEE Proceedings 2001;6:2705‐12. Cohen D, Narayanaswamy K. Attack attribution in non‐cooperative networks. Information Assurance Workshop, 2004.Proceedings from the Fifth Annual IEEE SMC 2004:436‐7. Cohen F. A method for forensic analysis of control. Computers and Security 2010;29(8):891‐902.

139

Chapter 9: References

[16] Denning PJ, Denning DE. Discussing cyber‐attack. Commun ACM 2010;53(9). [17] Erbacher RF. Validation for digital forensics. Information Technology: New Generations (ITNG), 2010 Seventh International Conference on 2010:756‐61. [18] Ericsson GN. Toward a framework for managing information security for an electric power Utility—CIGRÉ experiences. Power Delivery, IEEE Transactions on 2007;22(3):1461‐9. [19] Figueroa J. News briefs. Security & Privacy, IEEE 2010;8(2):8‐10. [20] Giffin J, Srivastava A. Attribution of malicious behavior. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 2010;6503 LNCS:28‐47. [21] Kaushik AK, Pilli ES, Joshi RC. Network forensic system for port scanning attack. Advance Computing Conference (IACC), 2010 IEEE 2nd International 2010(2):310‐5. [22] Kun LG. Homeland security: The possible, probable, and perils of information technology. Engineering in Medicine and Biology Magazine, IEEE 2002;21(5):28‐33. [23] Lambers M, Veenman CJ. Forensic authorship attribution using compression distances to prototypes. Computational Forensics.Proceedings Third International Workshop, IWCF 2009 2009(2009):13‐24. [24] Mohay G. Technical challenges and directions for digital forensics. Systematic Approaches to Digital Forensic Engineering, 2005.First International Workshop on 2005:155‐61. [25] Moore T, Friedman A, Procaccia AD. Would a ‘cyber warrior’ protect us: Exploring trade‐ offs between attack and defense of information systems. NSPW ‘10: Proceedings of the 2010 Workshop on New Security Paradigms 2010. [26] Nance K, Ryan DJ. Legal aspects of digital forensics: A research agenda. System Sciences (HICSS), 2011 44th Hawaii International Conference on 2011:1‐6. [27] Neumann PG. Risks to the public. SIGSOFT Software Engineering Notes 2005;30(3). [28] Pelaez JC, Fernandez EB. VoIP network forensic patterns. Computing in the Global Information Technology, 2009.ICCGI ‘09.Fourth International Multi‐Conference on 2009:175‐80. [29] Roussev V. Hashing and data fingerprinting in digital forensics. Security & Privacy, IEEE 2009;7(2):49‐55. [30] Ryu J, Na J. Security requirement for cyber attack traceback. Networked Computing and Advanced Information Management, 2008.NCM ‘08.Fourth International Conference on 2008;2:653‐8. [31] Sheldon FT, Vishik C. Moving toward trustworthy systems: R&D essentials. Computer 2010;43(9):31‐40. [32] Wolthusen SD. Overcast: Forensic discovery in cloud environments. IT Security Incident Management and IT Forensics, 2009.IMF ‘09.Fifth International Conference on 2009:3‐9. [33] Xin J, Zhang L, Aswegan B, Dickerson J, Daniels T, Guan Y. A testbed for evaluation and analysis of stepping stone attack attribution techniques. Testbeds and Research Infrastructures for the Development of Networks and Communities, 2006.TRIDENTCOM 2006.2nd International Conference on 2006:9.

Additional

140

[34] Yusoff Y, Ismail R, Hassan Z. Adopting hadith verification techniques in to digital evidence authentication. Journal of Computer Science 2010;6(6):613‐8. [35] Cohen FB. Attribution of messages to sources in digital forensics cases. System Sciences (HICSS), 2010 43rd Hawaii International Conference on 2010:1‐10. [36] Tang Y, Daniels TE. A simple framework for distributed forensics. Distributed Computing Systems Workshops, 2005.25th IEEE International Conference on 2005:163‐9. [37] Defending Against BGP Man‐In‐The‐Middle Attacks, Clint Hepner & Earl Zmijewski, February 2009, Renesys Presentation at Black Hat DC 2009; retrieved 7/6/2011; http://www.renesys.com/tech/presentations/pdf/blackhat‐09.pdf.

9.2.2. Miscellaneous Articles [1] [2] [3] [4]

[5] [6] [7] [8] [9] [10]

[11] [12] [13]

Guarding against terrorism and liability; ROLAND L. TROPE, IEEE Spectrum, January 2004. Dixon PD. An overview of computer forensics. Potentials, IEEE 2005;24(5):7‐10. Elliott D. Deterring strategic cyber attack. Security & Privacy, IEEE 2011;PP(99):1‐. Gandhi R, Sharma A, Mahoney W, Sousan W, Zhu Q, Laplante P. Dimensions of cyber‐ attacks: Cultural, social, economic, and political. Technology and Society Magazine, IEEE 2011;30(1):28‐38. Kutler J. This is cyberwar. Institutional Investor 2011:n/a. Lin H. Lifting the veil on cyber offense. Security & Privacy, IEEE 2009;7(4):15‐21. Mulvenon J. Toward a cyberconflict studies research agenda. Security & Privacy, IEEE 2005;3(4):52‐5. Trope RL. Guarding against terrorism and liability. Spectrum, IEEE 2004;41(1):85‐6. Thom Shanker, New Military Command for Cyberspace, N.Y. TIMES (June 23, 2009), http://www.nytimes.com/2009/06/24/technology/24cyber.html. Joe Stewart, Operation Aurora: Clues in the Code, Dell SecureWorks, (January 20, 2010), http://www.secureworks.com/research/blog/index.php/2010/1/20/operation‐aurora‐ clues‐in‐the‐code/. Daniel Pulliam, Agency officials say info security law falls short, Government Executive, (April 20, 2007), http://www.govexec.com/dailyfed/0407/042007p1.htm. Larry Downes, Cybercrime Treaty: What it Means to You, CIO Insight, (2007‐03‐06), http://www.cioinsight.com/c/a/Past‐News/Cybercrime‐Treaty‐What‐it‐Means‐to‐You/. Feds push for tracking cell phones, Declan McCullagh, CNET News, February 11, 2010; http://news.cnet.com/8301‐13578_3‐10451518‐38.html.

9.2.3. Treaties and Law [1] Convention on Cybercrime, Nov. 23, 2001, 2296 U.N.T.S. 167, available at http://conventions.coe.int/Treaty/en/Treaties/Html/185.htm. [2] United Nations General Assembly resolution 3314 (XXIX), Definition of Aggression, available at http://untreaty.un.org/cod/avl/ha/da/da.html. [3] North Atlantic Treaty, available at http://www.nato.int/cps/en/natolive/official_texts_17120.htm.

141 [4]

[5] [6] [7]

[8]

Chapter 9: References Kenneth Geers, Cyberspace and the Changing Nature of Warfare, Keynote Speech for NATO Cooperative Cyber Defence Centre of Excellence (CDCOE) 9 (Oct. 13, 2008), available at http://www.ioc.ee/teated/2009/KennethGeers.pdf. Presidential Decision Directive 63, Critical Infrastructure Protection, (May 22, 1998), available at http://www.fas.org/irp/offdocs/pdd/pdd‐63.htm. National Security Presidential Directive 54, The Comprehensive National Cybersecurity Initiative, (March 2, 2010), available at http://www.fas.org/irp/eprint/cnci.pdf. US Code: Title 18,Chapter 121—Stored Wire and Electronic Communications and Transactional Records Access; http://www.law.cornell.edu/uscode/html/uscode18/usc_sup_01_18_10_I_20_121.html. EU Data Retention Directive 2006/24/EC, http://eur‐ lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:105:0054:0063:EN:PDF.

9.2.4. Whitepapers and Testimony [1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

Michael A. Vatis, CYBER ATTACKS DURING THE WAR ON TERRORISM, INSTITUTE FOR SECURITY TECHNOLOGY STUDIES AT DARTMOUTH COLLEGE, (September 22, 2001), available at: http://www.dtic.mil/cgi‐bin/GetTRDoc?AD=ADA395300. Shishir Nagaraja, Ross Anderson, The snooping dragon: social‐malware surveillance of the Tibetan movement, University of Cambridge Computer Laboratory, (March 2009), http://www.cl.cam.ac.uk/techreports/UCAM‐CL‐TR‐746.html. Planning for the Future of Cyber Attack Attribution, Edward J. Giorgio, Ponte Technologies, Hearing before the US House of Representatives Committee on Science and Technology, Subcommittee on technology and Innovation, July 15, 2010, http://science.house.gov/sites/republicans.science.house.gov/files/documents/hearings /071510_Giorgio.pdf. Attribution and Privacy, John E. Savage, Brown University, Course Lecture: CSCI 1950P Cybersecurity and International Relations, http://www.cs.brown.edu/courses/csci1950‐ p/. Attribution of Cyber Attacks on Process Control Systems, Jeffrey Hunker, Robert Hutchinson and Jonathan Margulies, in Critical Infrastructure Protection II, Edited by Mauricio Papa and Sujeet Shenoi, ISBN: 978‐0‐387‐88522‐3, Springer Verlag, 2008. Confronting the Cyber Threat, Jonathan Masters, Council on Foreign Relations, March 17, 2011; http://www.cfr.org/technology‐and‐foreign‐policy/confronting‐cyber‐ threat/p15577. Cyber Incidents Involving Control Systems, Robert J. Turk, US Department of Energy Idaho National Laboratory, October 2005; http://www.inl.gov/technicalpublications/Documents/3480144.pdf. Microsoft & Data Retention, Whitepaper, Microsoft Corporation, February 2009; retrieved 8/22/2011; http://www.microsoft.com/download/en/details.aspx?id=5309.

Additional

142

9.2.5. General Reference [1] [2]

[3]

[4] [5]

[6] [7]

[8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

Ipv4, Wikipedia; http://en.wikipedia.org/wiki/IPv4. Defending TCP Against Spoofing Attacks, J. Touch, Internet Engineering Taskforce Network Working Group Request for Comments: 4953, July 2007; http://tools.ietf.org/html/rfc4953. Characterizing and Tracing Packet Floods Using Cisco Routers, Document ID: 13609, Cisco Systems; http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080149ad6.sh tml. Critical Infrastructure Protection II, Edited by Mauricio Papa and Sujeet Shenoi, ISBN: 978‐0‐387‐88522‐3, Springer Verlag, 2008. Searching & Seizing Computers and Obtaining Electronic Evidence in Criminal Investigations, 3rd ed, Computer Crime & Intellectual Property Section, United States Department of Justice, September 2009; http://www.cybercrime.gov/ssmanual/index.html. Electronic Communications Privacy Act, Wikipedia; http://en.wikipedia.org/wiki/Electronic_Communications_Privacy_Act. Denial of Service Attacks – DDOS, SMURF, FRAGGLE, TRINOO, InfoSec; http://www.infosyssec.org/infosyssec/security/secdos1.htm. United States Computer Emergency Readiness Team; http://www.us‐cert.gov/. SysAdmin, Audit, Network, Security Institute (SANS); http://www.sans.org/. Denial of Service Attacks, Lecture, Elli Androulaki and Isa Muqattash, Columbia University; retrieved 5/8/2011; https://www.cs.columbia.edu/~smb/classes/f06/l22.pdf. Open Web Application Security Project; https://www.owasp.org/. Trojan list sorted on action, Simovits Consulting AB; http://www.simovits.com/trojans/trojans_action.html. Exploit Database; http://www.exploit‐db.com/. Remote Exploit; http://www.remote‐exploit.org/. Congressional Research Service; http://opencrs.com/. A – Z list of all Threats and Risks, Symantec; http://www.symantec.com/security_response/threatexplorer/azlisting.jsp. SpamCop.Net, service for reporting spam; http://www.spamcop.net/.

9.2.6. Law Reviews [1] TECHNOLOGICAL CHANGE AND THE EVOLUTION OF CRIMINAL LAW: "AT LIGHT SPEED": ATTRIBUTION AND RESPONSE TO CYBERCRIME/TERRORISM/WARFARE, SUSAN W. BRENNER, Journal of Criminal Law & Criminology, 97 J. Crim. L. & Criminology 379, Winter 2007. [2] SOVEREIGNTY IN CYBERSPACE: CAN IT EXIST?, LIEUTENANT COLONEL PATRICK W. FRANZESE, Air Force Law Review, 64 A.F. L. Rev. 1, 2009.

143 [3]

[4] [5]

[6]

[7]

[8]

[9] [10]

[11]

[12] [13]

[14]

[15]

[16] [17]

Chapter 9: References ARMED ATTACK IN CYBERSPACE: DETERRING ASYMMETRIC WARFARE WITH AN ASYMMETRIC DEFINITION, MAJOR GRAHAM H. TODD, Air Force Law Review, 64 A.F. L. Rev. 65, 2009. CYBER WARFARE OPERATIONS: DEVELOPMENT AND USE UNDER INTERNATIONAL LAW, MAJOR ARIE J. SCHAAP, Air Force Law Review, 64 A.F. L. Rev. 121, 2009. A Helpless America? An Examination of the Legal Options Available to the United States in Response to Varying Types of Cyber‐Attacks from China, Daniel M. Creekman, American University International Law Review, 17 Am. U. Int'l L. Rev. 641, 2002. FROM NUCLEAR WAR TO NET WAR: ANALOGIZING CYBER ATTACKS IN INTERNATIONAL LAW, Scott J. Shackelford, Berkeley Journal of International Law, 27 Berkeley J. Int'l L. 192, 2009. CYBERWARFARE AND THE USE OF FORCE GIVING RISE TO THE RIGHT OF SELF‐DEFENSE, MATTHEW HOISINGTON, Boston College International and Comparative Law Review, 32 B.C. Int'l & Comp. L. Rev. 439, Spring 2009. "A CASE OF IDENTITY:” A GAPING HOLE IN THE CHAIN OF EVIDENCE OF CYBER‐CRIME, Joel Michael Schwarz, Boston University Journal of Science and Technology Law, 9 B.U. J. SCI. & TECH. L. 92, Winter 2003. A State's Duty to Prevent and Respond to Cyberterrorist Acts, Christopher E. Lentz, Chicago Journal of International Law, 10 Chi. J. Int'l L. 799, Winter 2010. Cyberwar and Customary International Law: The Potential of a "Bottom‐up" Approach to an International Law of Information Operations, Jon P. Jurich, Chicago Journal of International Law, 9 Chi. J. Int'l L. 275, Summer 2008. Blackbeards of the Twenty‐First Century: Holding Cybercriminals Liable under the Alien Tort Statute, Jennifer J. Rho, Chicago Journal of International Law, 7 Chi. J. Int'l L. 695, Winter 2007. Chasing Bits across Borders, Patricia L. Bellia, University of Chicago Legal Forum, 2001 U Chi Legal F 35, 2001. THE ECONOMIC ESPIONAGE ACT AND THE THREAT OF CHINESE ESPIONAGE IN THE UNITED STATES, Jonathan Eric Lewis, Chicago‐Kent Journal of Intellectual Property; 8 Chi.‐Kent J. Intell. Prop. 189;Spring, 2009. Shoring Up the Weakest Link: What Lawmakers Around the World Need to Consider in Developing Comprehensive Laws to Combat Cybercrime, Richard W. Downing, Columbia Journal of Transnational Law, 43 Colum. J. Transnat'l L. 705, 2005. The Cyber‐Front in the War on Terrorism: Curbing Terrorist Use of the Internet, Todd M. Hinnen, Columbia Science and Technology Law Review, 5 Colum. Sci. & Tech. L. Rev. 5, 2003/2004. Cyber‐Espionage: A Growing Threat to the American Economy, Gerald O'Hara, CommLaw Conspectus, 19 CommLaw Conspectus 241, 2010. Ending the Cyber Jihad: Combating Terrorist Exploitation of the Internet with the Rule of Law and Improved Tools for Cyber Governance, Benjamin R. Davis, CommLaw Conspectus, 15 CommLaw Conspectus 119, Fall 2006.

Additional

144

[18] A Critique of the International Cybercrime Treaty, Ryan M.F. Baron, CommLaw Conspectus; 10 CommLaw Conspectus 263, 2002. [19] Terrorism in the Twenty‐First Century: Threats and Responses, Yonah Alexander, DePaul Business Law Journal, 12 DePaul Bus. L.J. 59, Fall, 1999 / Spring, 2000. [20] Bad Guys and Good Stuff: When and Where Will the Cyber Threats Converge?, Frank J. Cilluffo, Paul Byron Pattak and George Charles Salmoiraghi; DePaul Business Law Journal, 12 DePaul Bus. L.J. 131, Fall, 1999 / Spring, 2000. [21] CONCEPTUALIZING AGGRESSION, Noah Weisbord, Duke Journal of Comparative & International Law, 20 Duke J. Comp. & Int'l L. 1, Fall 2009. [22] SOME OBSERVATIONS ALONG THE ROAD TO "NATIONAL INFORMATION POWER”, William Gravell, Duke Journal of Comparative & International Law, 9 Duke J. Comp. & Int'l L. 401, Spring 1999. [23] THE CRITICAL CHALLENGES FROM INTERNATIONAL HIGH‐TECH AND COMPUTER‐ RELATED CRIME AT THE MILLENNIUM, Michael A. Sussmann, Duke Journal of Comparative & International Law, 9 Duke J. Comp. & Int'l L. 451, Spring 1999. [24] CYBER WARFARE AND THE CRIME OF AGGRESSION: THE NEED FOR INDIVIDUAL ACCOUNTABILITY ON TOMORROW'S BATTLEFIELD, JONATHAN A. OPHARDT, Duke Law & Technology Review, 2010 Duke L. & Tech. Rev. 3, 2010. [25] Carnivore, The FBI's E‐mail Surveillance System: Devouring Criminals, Not Privacy, Griffin S. Dunham, Federal Communications Law Journal, 54 Fed. Comm. L.J. 543, May 2002. [26] Information Warfare and War Powers: Keeping the Constitutional Balance, Kenneth B. Moss, Fletcher Forum of World Affairs, 26 Fletcher F. World Aff. 239, Fall 2002. [27] TRADITIONAL MILITARY ACTIVITIES IN CYBERSPACE: PREPARING FOR "NETWAR”, Paul A. Walker, Florida Journal of International Law, 22 Fla. J. Int'l L. 333, December 2010. [28] The Google‐NSA Alliance: Developing Cybersecurity Policy at Internet Speed, Stephanie A. DeVos; Fordham Intellectual Property, Media & Entertainment Law Journal; 21 Fordham Intell. Prop. Media & Ent. L.J. 173; Fall 2010. [29] OLD CRIMES IN NEW BOTTLES: SANCTIONING CYBERCRIME, Michael Edmund O'Neill, George Mason Law Review, 9 Geo. Mason L. Rev. 237, Winter 2000. [30] A Proposal for an International Convention To Regulate the Use of Information Systems in Armed Conflict, Davis Brown, Harvard International Law Journal, 47 Harv. Int'l L.J. 179, Winter 2006. [31] THE LAW AND ECONOMICS OF SOFTWARE SECURITY, ROBERT W. HAHN AND ANNE LAYNE‐FARRAR, Harvard Journal of Law & Public Policy, 30 Harv. J.L. & Pub. Pol'y 283, Fall 2006. [32] AMENDING THE ECPA TO ENABLE A CULTURE OF CYBERSECURITY RESEARCH, Aaron J. Burstein, Harvard Journal of Law & Technology, 22 Harv. J. Law & Tec 167, Fall 2008. [33] Reasonable Foreseeability in Information Security Law: A Forensic Analysis, Meiring de Villiers, Hastings Communications and Entertainment Law Journal (Comm/Ent), 30 Hastings Comm. & Ent. L.J. 419, Spring 2008.

145

Chapter 9: References

[34] IN DEFENSE OF CYBERTERRORISM: AN ARGUMENT FOR ANTICIPATING CYBER‐ATTACKS, Susan W. Brenner. Marc D. Goodman, University of Illinois Journal of Law, Technology & Policy, 2002 U. Ill. J.L. Tech. & Pol'y 1, Spring 2002. [35] DISTRIBUTED SECURITY: PREVENTING CYBERCRIME, Susan W. Brenner and Leo L. Clarke, John Marshall Journal of Computer & Information Law, 23 J. Marshall J. Computer & Info. L. 659, Summer, 2005. [36] THE "MAGIC LANTERN" REVEALED: A REPORT OF THE FBI'S NEW "KEY LOGGING" TROJAN AND ANALYSIS OF ITS POSSIBLE TREATMENT IN A DYNAMIC LEGAL LANDSCAPE, Neal Hartzog, John Marshall Journal of Computer & Information Law, 20 J. Marshall J. Computer & Info. L. 287, Winter, 2002. [37] INVASION OF THE INFORMATION SNATCHERS: CREATING LIABILITY FOR CORPORATIONS WITH VULNERABLE COMPUTER NETWORKS, Sarah Faulkner, John Marshall Journal of Computer & Information Law, 18 J. Marshall J. Computer & Info. L. 1019, Summer, 2000. [38] JUDICIAL INTERPRETATIONS OF THE ELECTRONIC COMMUNICATIONS PRIVACY ACT RAISE CONCERNS ABOUT WHETHER THE AIRLINE INDUSTRIES' ON‐LINE BUSINESS VENTURES ARE PROTECTED, Christopher T. Blackford, Journal of Air Law and Commerce, 68 J. Air L. & Com. 819, Fall 2003. [39] SYMPOSIUM‐‐PROPERTY RIGHTS ON THE FRONTIER: THE ECONOMICS OF SELF‐HELP AND SELF‐DEFENSE IN CYBERSPACE: Virtual Crime, Virtual Deterrence: A Skeptical View of Self‐Help, Architecture, and Civil Liability, Orin S. Kerr, Journal of Law, Economics and Policy, 1 J.L. Econ. & Pol'y 197, Winter 2005. [40] National Leadership, Individual Responsibility: The Past, Present, and Future of Cybersecurity, Walter Gary Sharp, Sr., Journal of National Security Law & Policy, 4 J. Nat'l Security L. & Pol'y 13, 2010. [41] National Leadership, Individual Responsibility: Offensive Cyber Operations and the Use of Force, Herbert S. Lin, Journal of National Security Law & Policy, 4 J. Nat'l Security L. & Pol'y 63, 2010. [42] National Leadership, Individual Responsibility: Cyber Threats and the Law of War, David E. Graham, Journal of National Security Law & Policy, 4 J. Nat'l Security L. & Pol'y 87, 2010. [43] National Leadership, Individual Responsibility: U.S. International Policy for Cybersecurity: Five Issues That Won't Go Away, Jeffrey Hunker, Journal of National Security Law & Policy, 4 J. Nat'l Security L. & Pol'y 197, 2010. [44] National Leadership, Individual Responsibility: Foundational Questions Regarding the Federal Role in Cybersecurity, Gus P. Coldebella & Brian M. White, Journal of National Security Law & Policy, 4 J. Nat'l Security L. & Pol'y 233, 2010. [45] DIGITAL AGE COMMUNICATIONS LAW REFORM: NATIONAL SECURITY ON THE LINE, Susan Landau, Journal on Telecommunications & High Technology Law, 4 J. on Telecomm. & High Tech. L. 409, Spring 2006. [46] THE COUNCIL OF EUROPE CONVENTION ON CYBERCRIME, Mike Keyser, Journal of Transnational Law & Policy, 12 J. Transnat'l L. & Pol'y 287, Spring 2003.

Additional

146

[47] CRIMES, WAR CRIMES, AND THE WAR ON TERROR: WHY STATES NEED AN INTERNATIONAL LAW FOR INFORMATION OPERATIONS, Duncan B. Hollis, Lewis & Clark Law Review, 11 Lewis & Clark L. Rev. 1023, Winter 2007. [48] THE DEMISE OF ANONYMITY: A CONSTITUTIONAL CHALLENGE TO THE CONVENTION ON CYBERCRIME, Albert I. Aldesco, Loyola of Los Angeles Entertainment Law Review, 23 Loy. L.A. Ent. L. Rev. 81, 2002. [49] TORT LIABILITY FOR VENDORS OF INSECURE SOFTWARE: HAS THE TIME FINALLY COME?, Michael D. Scott, Maryland Law Review, 67 Md. L. Rev. 425, 2008. [50] Hacking into International Humanitarian Law: The Principles of Distinction and Neutrality in the Age of Cyber Warfare, Jeffrey T.G. Kelsey, Michigan Law Review, 106 Mich. L. Rev. 1427, May 2008. [51] THE CRIMINALIZATION OF TRUE ANONYMITY IN CYBERSPACE, George F. du Pont, Michigan Telecommunications and Technology Law Review, 7 Mich. Telecomm. Tech. L. Rev. 191, 2000/2001. [52] RESOLVING TOMORROW'S CONFLICTS TODAY: HOW NEW DEVELOPMENTS WITHIN THE U.N. SECURITY COUNCIL CAN BE USED TO COMBAT CYBERWARFARE, Toby L. Friesen, Naval Law Review, 58 Naval L. Rev. 89, 2009. [53] DEFINING THE PARAMETERS OF CYBERWAR OPERATIONS: LOOKING FOR LAW IN ALL THE WRONG PLACES?, CDR Vida M. Antolin‐Jenkins, JAGC, USN; Naval Law Review, 51 Naval L. Rev. 132, 2005. [54] FREE RADICALS IN CYBERSPACE: COMPLEX LIABILITY ISSUES IN INFORMATION WARFARE, MEIRING de VILLIERS, Northwestern Journal of Technology and Intellectual Property, 4 Nw. J. Tech. & Intell. Prop. 13; Fall 2005. [55] CRIMINAL LAW IN CYBERSPACE, Neal Kumar Katyal, University of Pennsylvania Law Review, 149 U. Pa. L. Rev. 1003, April 2001. [56] Protecting the Most Valuable Corporate Asset: Electronic Data, Identity Theft, Personal Information, and the Role of Data Security in the Information Age; Kenneth M. Siegel; Penn State Law Review; 111 Penn St. L. Rev. 779; Winter 2007. [57] TOWARD A CRIMINAL LAW FOR CYBERSPACE: PRODUCT LIABILITY AND OTHER ISSUES; Susan W. Brenner; University of Pittsburgh Journal of Technology Law & Policy; 5 PGH. J. Tech. L. & Pol'y 1; Fall 2004. [58] Forgery in Cyberspace: The Spoof could be on you!; Stephanie Austria; University of Pittsburgh Journal of Technology Law & Policy; 4 PGH. J. Tech. L. & Pol'y 2; Spring 2004. [59] Gathering Foreign Intelligence in Cyberspace: Does the United States Need Another Secret Court?; Richard P. Terbrusch; Quinnipiac Law Review; 23 Quinnipiac L. Rev. 989; 2004. [60] Trust Not Their Presents, Nor Admit the Horse: Countering the Technically‐Based Espionage Threat; Robert Gray Bracknell; Roger Williams University Law Review; 12 Roger Williams U. L. Rev. 832; Spring 2007. [61] Honeypots: A Sticky Legal Landscape?; IAN WALDEN AND ANNE FLANAGAN; Rutgers Computer and Technology Law Journal; 29 Rutgers Computer & Tech. L.J. 317; 2003.

147

Chapter 9: References

[62] THE NEGLIGENT ENABLEMENT OF TRADE SECRET MISAPPROPRIATION; Michael L. Rustad; Santa Clara Computer and High Technology Law Journal; 22 Santa Clara Computer & High Tech. L.J. 455; March 2006. [63] CYBER‐CRIMES: A PRACTICAL APPROACH TO THE APPLICATION OF FEDERAL COMPUTER CRIME LAWS; Eric J. Sinrod and William P. Reilly; Santa Clara Computer and High Technology Law Journal; 16 Santa Clara Computer & High Tech. L.J. 177; May 2000. [64] PRIVATE ENFORCEMENT OF CYBERCRIME ON THE ELECTRONIC FRONTIER; Michael L. Rustad; Southern California Interdisciplinary Law Journal; 11 S. Cal. Interdis. L.J. 63; Winter 2001. [65] CYBER CRIME 2.0: AN ARGUMENT TO UPDATE THE UNITED STATES CRIMINAL CODE TO REFLECT THE CHANGING NATURE OF CYBER CRIME; Charlotte Decker; Southern California Law Review; 81 S. Cal. L. Rev. 959; July 2008. [66] Computer Attacks on Critical National Infrastructure: A Use of Force Invoking the Right of Self‐Defense; Eric Talbot Jensen; Stanford Journal of International Law; 38 Stan. J Int'l L. 207; Summer 2002. [67] Regulation of Electronic Employee Monitoring: Identifying Fundamental Principles of Employee Privacy through a Comparative Study of Data Privacy Legislation in the European Union, United States and Canada; Gail Lasprogata, Nancy J. King, Sukanya Pillay; Stanford Technology Law Review; 2004 Stan. Tech. L. Rev. 4; 2004. [68] SYMPOSIUM: LAW AT THE INTERSECTION OF NATIONAL SECURITY, PRIVACY, AND TECHNOLOGY: II. CYBERSECURITY AND NETWORK OPERATIONS: ARTICLE: Cyber Warfare and Precautions Against the Effects of Attacks; Eric Talbot Jensen; 88 Tex. L. Rev. 1533; June 2010. [69] SYMPOSIUM: LAW AT THE INTERSECTION OF NATIONAL SECURITY, PRIVACY, AND TECHNOLOGY: II. CYBERSECURITY AND NETWORK OPERATIONS: ARTICLE: Sovereign Discourse on Cyber Conflict Under International Law; Sean Kanuck; Texas Law Review; 88 Tex. L. Rev. 1571; June 2010. [70] Cyber‐Apocalypse Now: Securing the Internet Against Cyberterrorism and Using Universal Jurisdiction as a Deterrent; Kelly A. Gable; Vanderbilt Journal of Transnational Law; 43 Vand. J. Transnat'l L. 57; January 2010. [71] Information Warfare and Neutrality; George K. Walker; Vanderbilt Journal of Transnational Law; 33 Vand. J. Transnat'l L. 1079; November 2000. [72] TOWARD A MORE EQUITABLE PROSECUTION OF CYBERCRIME: CONCERNING HACKERS, CRIMINALS, AND THE NATIONAL SECURITY; Alexander Urbelis; Vermont Law Review; 29 Vt. L. Rev. 975; Summer 2005. [73] Combatant Status and Computer Network Attack; Sean Watts; Virginia Journal of International Law; 50 Va. J. Int'l L. 391; Winter 2010. [74] Carnivore: Is the Regulation of Wireless Technology a Legally Viable Option to Curtail the Growth of Cybercrime?; Stephen W. Tountas; Washington University Journal of Law & Policy; 11 Wash. U. J.L. & Pol'y 351; 2003.

Additional

148

[75] DIGITAL ISSUES IN MERGERS & ACQUISITIONS, E‐DISCOVERY, & INFORMATION TECHNOLOGY SYSTEMS; Daniel B. Garrie and Yoav M. Griver; Widener Law Journal; 19 Widener L.J. 25; 2009. [76] Exploit Derivatives & National Security; MICAH SCHWALB; Yale Journal of Law & Technology; 9 Yale J. L. & Tech. 162; Spring 2006‐7. [77] Sklerov MJ. Solving the dilemma of state responses to cyberattacks: A justification for the use of active defenses against states who neglect their duty to prevent. Mil Law Rev 2009;201:1‐85.

149

Chapter 10: Appendices

10. APPENDICES 10.1. Overview The following lists are provided in this appendix:

•

Examples of Significant DDoS Cyber‐Attacks

•

Top 10 Botnets in 2010

•

Listing of Fundamental DoS Exploits

•

Examples of Common Botnets

•

Listing of OWASP Top 10 Web Application Security Risks for 2010

•

Other common web server and web server host vulnerabilities

•

Examples of Common Malware Exploit Methods

•

Examples of Information Harvesting Cyber‐Attacks

•

Examples of unintentional penetrative cyber‐attacks

•

Examples of intentional penetrative cyber‐attacks for disruptive purposes

•

Examples of Windows Forensic Data Sources

•

Example of Linux Forensic Data Sources

•

W3C Extended Log File Format (IIS 6.0) and their Usefulness in Forensic Analysis

•

Network Operator Support Groups

Examples of Significant DDoS Cyber‐Attacks

150

10.2. Examples of Significant DDoS Cyber‐Attacks Table 10.2‐1: Examples of Significant DDoS Cyber‐Attacks Date

Target

Source

December 2010

Mastercard.com, PayPal, Visa.com and PostFinance.

Anonymous

August 2010

Irish Central Applications Office.

Unknown

July 2009

Major websites in South Korea and the United States [25]

China, North Korea

June 2009

Iranian government websites.

Many

July 2009

Georgian government websites [26], [27], [28].

Russia

July 2009

US government, commercial finance websites [29].

China

February 2009

Kyrgyzstan internet service providers [30].

Russia

May 2007

Estonian government services and business [31] [32].

Russia & individuals

Source: Wikipedia [33].

151

Chapter 10: Appendices

10.3. Top 10 Botnets in 2010 Table 10.3‐1: Top 10 Botnets in 2010 Name TDLBotnetA RogueAVBotnet ZeusBotnetB Monkif Koobface.A Conficker.C Hamweq AdwareTrojanBotnet Sality SpyEyeBotnetA

Source: Damballa [36]

Listing of Fundamental DoS Exploits

152

10.4. Listing of Fundamental DoS Exploits Table 10.4‐1: Listing of Fundamental DoS Exploits Common Name

DoS Type

Exploit

DNS Resource Recursion exhaustion

Misconfigured DNS servers respond to spoofed DN requests [9].

TCP Flood Ill‐formed TCP packet

Stream of TCP packets having various flags are sent to victim computer [15], [16].

Ping of Death

ICMP ping

Sends Ping request specifying an IP packet size greater than 65536 bytes. Exploits weaknesses in packet reassembly. [11], [16],

Ping Flood

ICMP ping

Spoofs source address of ICMP Ping request. Victim IP address used. Flood of ping requests starves victim computer of resources. [11], [15], [16]

Smurf

ICMP ping

ICMP broadcast. Amplified form of Ping flood attack. Victim IP address used. Flood of ping requests starves victim computer of resources. [11], [15], [16], [19]

Teardrop

Ill‐formed TCP packet

IP fragmentation – exploits bugs in operating system network interface drivers [16], [19].

Fraggle, UDP Flood

UDP echo

UDP broadcast. Spoofs source address of request to echo port on victim computer. Second spoof source address of connection request is sent to UDP chargen port on intermediary computer. Intermediary computer responds with data stream to victim computer. Starves victim computer of resources. [10], [15], [16], [17], [19]

SYN Flood

Attacker floods victim computer with requests for connection having spoofed return addresses. Victim computer sends acknowledgements ACKs to spoofed addresses, which never reply. Victim computer connection waits for reply. Victim computer starved of resources while waiting for numerous SYN ACKs. [7], [8], [10], [12], [15], [16], [17], [19]

SYN Flood / Land

SYN Flood

A variant of the common SYN Flood attack. Spoofed address is made the victim computer’s address. Victim computer sends itself acknowledgements, which it must then process, consuming resources. [7], [10], [12], [15], [16], [17], [19]

Naptha

Resource exhaustion

Uses custom program to control attacker computer’s network port. Enables attacker to send only portions of typical TCP/IP connection requests, customized as desired. This in turn enables one computer to send out large volumes of incomplete transactions to target computer, overwhelming target computer resources. [13], [14]

WinNuke

Ill‐formed TCP packet

WinNuke sends illegal packet to any Windows computer port that is listening for data. Causes Windows to crash and reboot [16].

Worm

Resource exhaustion

Target overwhelms its resources over the course of worm replication and propagation; potential global routing instabilities. [15], [20]

153

Chapter 10: Appendices

10.5. Examples of Common Botnets Table 10.5‐1: Examples of Common Botnets Name

Date

Lethic

3/2011 0.2M

Mumba

4/2010 0.055M Uses variations of Zeus botnet [58], [59]. Can sends SPAM, gather information, and perform DDoS. Infected machines mostly in UK and Germany.

Mariposa

5/2009 11M

Designed for information theft and DDoS attack. Possibly used DDoS attack as cover for information theft. Infect primarily businesses, over half of Fortune 500 group [56], [57].

Seneka

4/2009 2M

Employed known vulnerabilities. Infected mainly US government domains [55]. Collected information, launched DDoS attacks, send spam.

Mega‐D

2/2008 0.035M Distributed advertisements [44], [45], [46], [47].

Zeus (Zbot)

7/2007

Malware package containing botnet and web server. Primary purpose is to gather information. Can also generate spam and perform other tasks [54]. Available for purchase to start own botnet.

Grum (Tedroo)

3/2007 0.05M

Distributed pornography advertisements [43].

Pushdo (AKA Pandex, Cutwail)

1/2007 2M

2nd largest spam botnet in existence [50]. Can act as conduit for other malware. Recent variant can generate DDoS attacks using SSL‐ based methods [51].

Rustock

3/2006 2.4 M

Highly sophisticated rootkit bot; many variations

Size

Description Distributed advertisements for unlicensed pharmaceutical products [48], [49].

Listing of OWASP Top 10 Web Application Security Risks for 2010

154

10.6. Listing of OWASP Top 10 Web Application Security Risks for 2010 Table 10.6‐1: Listing of OWASP Top 10 Web Application Security Risks for 2010 Rank

Name

Injection (code and SQL)

Cross‐Site Scripting (XSS)

Broken Authentication and Session Management

Insecure Direct Object References

Cross‐Site Request Forgery (CSRF)

Security Misconfiguration

Insecure Cryptographic Storage

Failure to Restrict URL Access

Insufficient Transport Layer Protection

Un‐validated Redirects and Forwards

Sources: OWASP [68], Symantec [69], US‐CERT [70].

155

Chapter 10: Appendices

10.7. Other common web server and web server host vulnerabilities Table 10.7‐1: Other common web server and web server host vulnerabilities Name Buffer overflows Remote file inclusions Directory traversals World‐writable critical files Direct requests of administrator scripts Authentication bypass Race conditions Privilege escalation Hard‐coded or undocumented accounts and passwords [72].

Source: MITRE [73].

Examples of Common Malware Exploit Methods

156

10.8. Examples of Common Malware Exploit Methods Table 10.8‐1: Examples of Common Malware Exploit Methods Method

Description

Adobe Products

Adobe Acrobat, Reader, and Flash Player exhibit numerous significant remote code execution weaknesses that can enable malware to run on target machines – extent across all operating system platforms.

AutoRun

Exploits the AutoRun feature of Windows operating systems to automatically install software when it appears in removable media. AutoRun is enabled by default on Windows machines.[77]

Facebook

Numerous exploits continuously discovered. LifeJacking: Facebook image overlays that cause Facebook user to “Like” a particular page, which in turn causes this link to appear in user’s friend’s Facebook walls. Iframe Issue: authentication tokens exposed to third parties [78].

Fake Alerts

Web page popups that appear very much like operating system dialogs or otherwise benign‐looking dialogs, but that actually link to malware downloads. Some purport to have found evidence of virus activity. Fake antivirus is widely used and is deployed to Windows and Mac systems.

GIF Injection

The file contains a GIF image but also contains executable code. This is a known exploit [84] [85] and patches have long been available, but continues to be used [86].

Iframe

Malicious HTML inline frames that surreptitiously open pages hosting malicious code in user’s browsers.

Java

A variety of vulnerabilities can be exploited to enable remote code to be downloaded and executed under the currently logged on user privileges [79]. These exploits can also be cross‐platform compatible [80].

Fake LinkedIn messages connect users to malicious websites, leading to trojan download and installation [81], [82].

Microsoft Office

Continually emerging vulnerabilities enabling remote code execution exploits.

Phishing

Generic or targeted email spam containing links to malware.

Search Engine Results Pages

Seemingly relevant links returned by search engines that actually link to malware sites.

Spear Phishing

A form of phishing that that targets one or a few individuals only and involves critical information known to these specific individuals.

Web Browser

Entails a wide range of vulnerabilities, most often associated with Microsoft Internet Explorer, generally enabling remote code to be executed or installed.

Worms

Self‐replicating malware computer programs that can send copies of itself to other computers. Can be designed to install trojan‐type software, enabling the infected machine to be used as a bot. [83]

Sources: Cisco [86], McAfee [87], Microsoft [88], IBM [89], Panda Labs 2010 [90], Symantec. [91].

157

Chapter 10: Appendices

10.9. Examples of Information Harvesting Cyber‐Attacks Table 10.9‐1: Examples of Information‐harvesting cyber‐attacks Year

Target

Comments

2011 Government agencies and contractors worldwide

AKA Operation Shady Rat. Ongoing five‐year advanced persistent threat targeting defense agencies and defense contractors; likely based in China [116], [117].

2011 US Department of Energy

Exploited spear‐phishing and new IE remote code execution vulnerability [118], [119]. Attacks may have been attempting to access classified information on DOE’s Energy Sciences Network [120], [121].

2011 Citibank

Credit card bank. Harvested data associated with approximately 360,000 accounts [122].

2011 LastPass

Web password service. Harvested user account and password data [123], [124]. Linked to organized crime.

2011 HBGary

Malicious attack on cyber‐security company; used common exploit [125], [126]. Launched by the group, “Anonymous.”

2011 RSA

Harvested corporate data possibly linked to RSA’s SecureID [127], [128]. Linked to organized crime.

2011 NASDAQ

Penetrated NASDAQ computer systems; unknown what information, if any, was obtained, or even purpose of penetration [129].

2010 Google, US defense contractors, others

AKA Operation Aurora or Hydraq. Harvested Google business information in China [130]. Objectives: obtaining information on Chinese human rights activists and intellectual property [90], [131]. Clues in codebase linked attack to China [132].

2010 Schools, charities, businesses

Captured account information, from small to medium sized businesses, used to log into bank accounts [133], [134], and [135]. Mostly from eastern Europe. Linked to organized crime.

2009 Individual users

AKA Coreflood. Botnet operation comprising approximately 2 million user PCs, across private, commercial, industry, and government environments. Harvested personal identity and financial information [136]. Linked to organized crime.

2009 Government and private offices worldwide

AKA GhostNet. Worldwide (excluding US) espionage; ongoing; can also involve control over cameras and other monitoring equipment [137], [138], [139]. Linked to China.

2009 Hotel company

Hilton Hotels and Resorts accused of large‐scale computer theft of rival Starwood Hotels & Resorts Worldwide, Inc., company proprietary information [140].

2009 US defense contractors Targeted Joint Strike Fighter (F‐35 Lightning II) project data [141]. Possibly state‐sponsored, China. 2009 UK MoD

Emails sent from multiple Royal Air Force stations were copied to IP addresses traced back to Russia [142]. Linked to Russia.

Year

Examples of Information Harvesting Cyber‐Attacks Target

158

Comments

2009 US Banks

AKA PhishPhry. Used phishing to obtain account numbers and personal information [143].

2008 RBS Worldpay

Obtained customer account data; performed fraudulent withdrawals using customer identity information [144], [145]. Linked to organized crime.

2008 Various retailers

Obtained data on over 40 million user accounts [145], [146].

2008 US military networks

Thumb drive infected with worm was inserted into military laptop at middle eastern installation; worm then spread over both US military classified and unclassified networks [147], [148].

2008 Petroleum and energy companies

AKA. Night Dragon. Combination of attack methods [149], [150], [151], [152] and [153]. Linked to China.

2008 US Congress

Personal PCs of Rep. Frank Wolf. Probed computers to evaluate system’s defenses, and to view and copy information [154]. Linked to China.

2007 US defense contractors Infiltration of F‐35 Lightning II program contractor computer networks [155]. Linked to China. 2007 TJ Maxx, other retailers

Obtained credit information on over 45 million customers [156], [157]. Linked to organized crime.

2007 Heartland Payment Systems

Consumer credit card payment processor. Obtained information on 10s of millions of payment transactions [158], [159]. Linked to organized crime.

2006 US defense NIPRNet system

China‐based sources downloaded 10‐20 TB of non‐classified data [160].

2006 UK parliamentary government offices

Highly targeted spear phishing to specific government personnel; intercepted by IT security; linked to China [161].

2006 US Naval War College

Website hacked, followed by intrusion of unclassified college network [162]. Linked to China.

2006 US State Dept.

Targeted US embassies in East Asia‐Pacific region [163], [164]. Linked to China.

2006 US Commerce Dept.

Targeted Bureau of Industry and Security (BIS) systems [165], [166], [167]. Linked to China.

2006

2005 CardSystems Solutions Inc.

Major security breach of credit card payment transfer service provider; involved approximately 40 million credit card accounts [168], [169].

2005 Israeli Companies

Rival companies infiltrated each other’s computer systems to harvest company proprietary information [170].

2004 US defense agencies

Categorized with ongoing Titan Rain activities. Targeted Army Information Systems Engineering Command, Defense Information Systems Agency, Naval Ocean Systems Center, Space and Strategic Defense all on 11/1/2004 [171].

159 Year

Chapter 10: Appendices Target

Comments

2002 SpeakEasy, PayPal

Hacker Vasily Gorshkov hacked into computer systems, obtaining customer credit account data subsequently used for processing fraudulent charges [172].

2003 US and allied governments

AKA Titan Rain. Ongoing since 2003 [173], [174], [175]. Myfip worm involvement [176], [179]. Such attacks continue to the present [177]. Linked to China.

2000 Microsoft

Industrial espionage; occurred over several week period [180], [181]. Linked to Russia.

2000 CD Universe

Online retailer hacked. Approximately 10,000 customer account details, including credit card account details, maliciously obtained

1998 DOD, NASA, DOE university systems

AKA Moonlight Maze. Occurred over three year period [184]. Linked to Russia.

Examples of unintentional penetrative cyber‐attacks

10.10.

160

Examples of unintentional penetrative cyber‐attacks Table 10.10‐1: Examples of unintentional penetrative cyber‐attacks

Year

Affected System

Comment

2008 US Defense agencies and contractors

Self‐propagating virus, agent.btz, infected US Defense Department networks, by exploiting Windows AutoRun feature. Motivated Defense Department to ban all thumb drives [185].

2005 Automobile plant control system, corporate intranets worldwide

Self‐propagating virus, Zotob, infected plant and corporate networks, adversely impacting performance and even disabling some computers [186].

2003 CSX train signaling system

Self‐propagating virus, Blaster, infected CSX headquarters computer system, temporarily disabling signaling, dispatching and other systems [187], [188].

2003 Maryland Motor Vehicle Administration

Self‐propagating virus, Blaster, infected administration computer systems, forcing office closures [189].

2003 Air Canada Check‐in system, US Navy‐Marine intranet

Self‐propagating virus, Welchia [190], disrupted Air Canada check‐in services and affected US Navy‐Marine intranet service [191]. Also infected many other systems worldwide.

2003 Davis‐Besse nuclear power plant

Self‐propagating virus MS SQL Server 2000 Slammer worm [192]; overloaded plant networks, causing the parameter display system and plant process computer to become unavailable for hours [193].

A more comprehensive list is also available [194].

161

Chapter 10: Appendices

10.11. Examples of intentional penetrative cyber‐attacks for disruptive purposes Table 10.11‐1: Examples of intentional penetrative cyber‐attacks for disruptive purposes Year

Target

Comment

2011 Uranium centrifuge controllers

Highly sophisticated virus that targets specific types of controllers used in uranium enrichment processes. Referred to as Stuxnet. Infected Iranian uranium enrichment plant, centrifuge control systems, causing damage [195], [196], [197], and [198].

2009 US hospitals

Former security guard for Dallas TX hospital hacked into facility HVAC system, in preparation for DOS attack [209], [210]. No damage was reported.

2009 US electrical distribution system control

Foreign hackers based in China and Russia penetrated electrical utility control computer systems across the US, attempting to leave control programs in place; no disruptions were recorded [211].

2008 Power company network

In a single day, consultant hired by a power company to test defenses was able to gain complete control over power production and distribution systems [212].

2008 Tram track control system

Teenage hacker built simple device to control Lodz Poland tram switches, derailing several and causing some injuries [213].

2008 Foreign utility systems

Multiple foreign utility systems have been hacked into and, in some cases, caused intentional power outages; these cyber‐attacks associated with extortion demands [214].

2007 Los Angeles traffic control center

Two city employees hacked into city traffic control center, disrupting control over four intersection signal stations, affecting traffic at these intersections [215]. Attack was associated with labor union negotiations.

2007 California Canal System

Former employee installed unauthorized software to the Tehama Colusa Canal Authority SCADA system [216]. No damage was done.

2007 Generator

US Department of Homeland Security test cyber‐attack, Operation Aurora, successfully hacked into power control system and were able to cause generator to self‐destruct [217], [218], [219].

2006 City water control system

A Trojan inadvertently loaded onto an employee computer subsequently installed spyware to water control system computer; no damage or disruption of services was reported [220].

2002 US military computer systems

Hacker Gary McKinnon penetrated US military and NASA computer systems, seeking information on UFOs, which he believed existed [221]. Gary McKinnon suffers from Asperger's syndrome [222].

2002 Business systems Disgruntled contractor, Stephen Carey, hacked into corporate systems, and then destroyed data [223]. 2001 Power distribution coordinator system

Hackers gained control of development computers and were attempting to compile new code on these machines that would enable them to penetrate more critical systems, before breach was discovered [224]. No disruption to service was experienced.

Year

Examples of intentional penetrative cyber‐attacks for disruptive purposes Target

162

Comment

2000 Sewage treatment plant

Over four month period, hacker used stolen radio transmitter to send control signals and reprogram Australian sewage plant control system. Flooded nearby area with over one million liters of raw sewage [226], [227], and [228].

1999 Gas pipeline control system

Hacker gained control of Russian gas pipeline control system for 24 hours [227].

1997 Airport telephone system

Juvenile hacker disabled Worcester MA airport telephone computer and isolated FAA control tower of airport for six hours, loss of runway lighting [229].

1997 Military and civilian communications systems

Joint exercise among US intelligence and defense communities to test military communications systems in Pacific area and US civilian communications systems. Attack teams were able to conclusively show broad disruptive capabilities across military and civilian communications systems [230], [231].

1994 Roosevelt Dam canal system control system

Hacker gained access to a computer controlling the Salt River Project’s canal system, but the access had insufficient privileges to allow it to control any structures [232]. No disruption was reported.

1992 Emergency Alert System

Disgruntled former Chevron employee disabled gas and chemical emergency alert network for 10 hour period [233]. Poisonous gas release went unreported.

1982 Natural gas pumping station

Gas control system illicitly obtained by Soviet KGB may have been surreptitiously sabotaged, causing control program to issue commands outside of parameters and resulting in spectacular destruction of the station [234].

163 10.12.

Chapter 10: Appendices

Examples of Windows Forensic Data Sources Table 10.12‐1: Examples of Windows Forensic Data Sources

Type

Description

Tool(s)

Event Logs

Event logs capture events occurring within the system. Note that we are referring to those event logs maintained by Windows. Windows XP and Windows Server 2003 maintained three event logs, System, Security, and Application. Windows Server 2008 and newer versions maintain over 140 different kinds of log files. Windows Vista/2008/7 store most log files here: %systemdir%\Windows\System32\winevt\logs. The locations of log files in earlier Windows version were scattered: a partial listing is available [272].

Windows Event Viewer

Logged‐on Users

This information is volatile, and will change momentarily, but can still be useful in adding context to other information, such as in trying to map logons to processes. Additionally, the cyber‐attacker may have left open a remote logon session, and this can help correlate malicious activity with the Event Log.

Task Manager Net Sessions Psloggedon.exe

Open files

Cyber‐attackers connecting remotely may have open files, either being used currently, or that were left open. Open files again provide helpful contextual information in mapping logon activity captured in the Security Event Log with malicious activity.

Net File command Psfile.exe Openfiles.exe

File systems

File System: Trojans, viruses, hacker tools, etc. must be on Windows Search the system in order to be executed by the system. Searches of the file system can reveal these files. Examination of system file time stamps and hash values can help determine if these files were altered as a result of intrusion activity. Hackers may also have left copies of their tools on the target system, and identifying these tools and trojans can be useful in determining the method taken to hack and gain control over the system. Finding the resident malware program behind the cyber‐attack can help attribute the attack, when decompiled and forensically examined, as these software programs may contain artifacts left by the software development environment itself, configuration parameters, and even information embedded directly from the machine itself used by the malware developer.

Examples of Windows Forensic Data Sources

164

Type

Description

Tool(s)

Network connections

Examining network connections is useful in determining: what services are mapped to what ports; what NetBIOS connections were made to local network resources; whether scans are being made of the local network as a part of reconnaissance activities.

Nbtstat netstat

Running processes

Every trojan, virus or worm must be run or executed on a system, and therefore must be associated with a process. Processes provide information on the location of the executable program that is running, the command line that launched the process, the account it is running under, the amount of time that it has been running, and the modules that it depends on.

Task Manager Services Manager Tlist.exe Pslist.exe Listdlls.exe Handle.exe

Process‐to‐ port mappings

Any process that is connecting to the network uses a port Netstat on the network interface to access the network. Fport.exe Suspicious network access can be link to a process, which Openports.exe in turn can be linked to accounts logged in the Event Log and the location of the resident malware. To learn more about netstat execution parameters, enter “netstat –help”

Network Status

When using the machine’s network interface card (NIC) to Ipconfig Promisdetect.exe perform network scans, the NIC must be put into what is Promqry.exe called “promiscuous” mode. Unless a machine is dedicated to network scanning, there is no need for the machine’s NIC to be configured this way. Whether a NIC is in this mode or not is not immediately observable, but would be helpful in determining whether the machine has been compromised and for what purpose. To learn more about ipconfig execution parameters, enter “ipconfig – help”

Clipboard contents

The Windows clipboard is often used to facilitate data transfer among different applications. The clipboard can provide useful clues as to the activities of the cyber‐ attacker if the attacker was logged on locally to the machine.

CTRL+V

165

Chapter 10: Appendices

Type

Description

Browser History (IE)

Windows Explorer Web browsers maintain a history of all URLs that were visited. The depth of this history varies depending on user configuration. Browsers can also maintain a history of resources that were visited locally on the machine. Browser history can provide useful context if the attacker was logged on locally. Location of browser history varies by Windows version. For Windows 7, this would be: %systemdir%\Users\<username>\AppData\Local\Microsof t\Windows\History. On Windows XP, this would be: %systemdir% \ Documents and Settings\%username%\Local Settings\History.

DOS command history

Command history: like the Linux shell, the DOS shell also Doskey /history maintains a history of commands entered into it. Though unlikely to be used, given that penetrative software itself is directly interacting with the system, a quick check of the command history can reveal useful information as to the activities of the hacker on the system.

Registry

The Windows Registry is used to maintain system configuration and that may be useful in computer forensic analysis. For example, it contains the locations and file names of all software applications that re to be automatically started at system boot. Trojans and other malware would be listed under various AutoRun entries in the Registry. The Protect Storage area contains sensitive information regarding the user. It is also used by attackers to hide the details of malware connections to control servers or intermediate servers and it is also a key area mined by hackers in when harvesting information.

System Temp

The system TEMP directory is an interim storage location Windows Explorer for files created by Windows and other applications that have temporary usage for the duration of the process or the user’s interaction with an application. These files are generally duplicates of the source files. For example, the installer of an operating system update may place working files in the TEMP storage area, and these files often remain in the TEMP directory after the installation is completed. %systemdir%\Windows\TEMP

Tool(s)

Regedit.exe Pstoreview.exe Protected Storage Explorer PassView

Examples of Windows Forensic Data Sources

166

Type

Description

Tool(s)

Recent Files history

Whenever a user on a Windows machine opens a file, Windows creates a link to that file in order to be able to track it for purposes of updating the Most Recently Used list. These links are maintained in a subdirectory. The location of this subdirectory varies depending on operating system version. For example, on Windows 7, this would be: %systemdir%\Users\<username>\AppData\Roaming\Micr osoft\Windows. In windows XP, this would be: %systemdir%\Documents and Settings\<username>\My Recent Documents.

Windows Explorer

Cookie Cache

Cookies are text files storing user information associated with the web pages that a user has visited and the user’s interaction or even personal settings associated with them. Cookies may be stored temporarily, or long‐term. On Windows XP, the cookie cache is located: %systemdir%\Documents and Settings\<username>\Cookies On Windows Vista/7, the cookie cache is located: %systemdir%\Users\<username>\AppData\Roaming\Micr osoft\Windows\Cookies

Windows Explorer

Temp Internet files

Temporary Internet files are the components of websites that the user visits and that are downloaded to the user’s machine in order to render them in the web page that the user sees. All parts of any web page that a user views must be downloaded in order to be viewed. Windows stores these web page components in the Temporary Internet Cache. On Windows XP, this cache is located: %systemdir%\Documents and Settings\,username>\Local Settings\Temporary Internet Files. On Windows Vista/2008/7, this cache is located: %systemdir%\Users\<username>\AppData\Local\Microsof t\Windows\Temporary Internet Files\Low\Content.IE5.

Windows Explorer

DAT Files

DAT files are used to maintain a binary record of all of the files within a directory. Every directory has one of these files, and they are generally hidden. These files may contain fragments of the files themselves and are thus useful in discovering whether files have been edited, deleted, or added.

167

Chapter 10: Appendices

Type

Description

Recycle Bin

Windows Explorer The recycle bin is a interim storage area for files that a user deletes from within Windows Explorer. Thus, they are not fully removed from the system but continue to exist until normal recycling policy is implemented or the user flushes the recycle bin manually. Files that are deleted in other ways, for example, from within a terminal session, will not be sent to the Recycle bin.

System memory

System memory, if it can be obtained, is rich in data for attempting to attribute a cyber‐attacker, as it may contain traces providing added context to all of the sources discussed thus far. It contains current and terminated running processes; open TCP/UDP ports and active connections; memory mapped files; deleted files; cache information; hidden data, and more [275].

KNTTools WMFT

Page File

Windows XP and later versions use pagefile.sys as a disk‐ based memory for augmenting RAM. The page file effectively increases the system RAM size. This file contains system memory that is of lower priority, such as for a process running in the background or an application window that has been minimized. The data stored in this file is generally not sequential

Sources: [264] ‐ [275]

Tool(s)

10.13.

Examples of Linux Forensic Data Sources

168

Example of Linux Forensic Data Sources Table 10.13‐1: Examples of Linux Forensic Data Sources

Type Event Logs

File system

Shell History Logged on users Network connections Running processes

Open file handle

System Memory

Description Event logs capture events occurring within the system. Usually located in /var/log directory. May contain evidence for files that were added, deleted, edited. May contain evidence of malicious system changes, identities used in infiltration activities. Absence may indicate tampering. Key area of analysis. Look for unusual (and often hidden) file names and directories; altered system time stamps and hash values and modified binaries; new or recently created files; common malware names (i.e., “signatures”); deleted files (e.g., deleted good system files that were replaced with modified bad system files, or deleted log files); etc. Maintains logs of every user activity. May contain history of commands run by the attacker. For real‐time analysis, e.g., monitoring actively infected Linux machine, useful in identifying possible attacker identities – or those used by attackers. Useful in attributing services and the ports they may be using to connect with the network for malicious reasons. Useful in identifying possible malware running on the machine. Running processes having unusual names or running states or consuming an unusual amount of system resources may be indications of malware resident on the system. Reviewing running processes against authentication and audit logs can help build attribution or at least the assumed identity of the attacker. Likewise, any process having an active connection to a resource located on the Internet should be reviewed Open files are those files being edited or executed and are being controlled by a process using them. Processes may have one or more files open, and each process is associated with an identity. Information on open file handles is stored in memory. Searching through processes and their open files can help bound the scope of all files to be examined when searching for malware. Provides verification of discoveries made through file system analysis. Can help identify memory‐resident malware that does not have a physical disk footprint.

Sources: [275] ‐ [281]

Tool(s) Shell commands

Shell commands, e.g., grep

Shell commands Shell commands Shell commands Shell commands

Shell commands

kcore crashdump IDETECT

169

Chapter 10: Appendices

10.14.

W3C Extended Log File Format (IIS 6.0) and their Usefulness in Forensic Analysis Table 10.14‐1: W3C Extended Log File Format and their Use in Forensic Analysis Default (Y/N)

Usefulness in Forensic Analysis

Field

Appears As

Description

Client IP Address

c‐ip

The IP address of the client or proxy that made the request.

Identify user or proxy server.

Date

date

The date on which the activity occurred.

Event correlation.

HTTP Status

sc‐status

The HTTP status (or result) code sent to the client.

Can identify CGI scans, SQL injection and other intrusions.

Method

cs‐method

The requested action, for example, a GET method.

Can help track down abuse of scripts or executables.

Protocol Substatus

sc‐substatus

The substatus error code.

Can help in identifying hacking attempts

Server IP Address

s‐ip

The IP address of the server on which the log file entry was generated.

Can verify the IP address accessed if the log files are later moved from the system or if the server is moved to a new location.

Server Port

s‐port

The server (TCP) port number that is configured for the service.

To verify the port when correlating with other types of log files.

Time

time

The time, in coordinated universal time (UTC), at which the activity occurred.

Event correlation, determine time zone, identify scanning scripts.

URI Query

cs‐uri‐query

The query, if any, that the client was trying to perform. A Universal Resource Identifier (URI) query is necessary only for dynamic pages.

Can identify injection of malicious data.

URI Stem

cs‐uri‐stem

The target of the action, for example, Default.htm.

Can identify attack vectors.

User Agent

cs(User‐Agent)

The browser type that the client used.

Can help uniquely identify users or attack scripts.

User Name

cs‐username

The name of the authenticated user who accessed your server. Anonymous users are indicated by a hyphen.

Identify compromised user passwords.

Extended Log File Format and their Usefulness in Forensic Analysis

170

Default (Y/N)

Usefulness in Forensic Analysis

The number of bytes that the server received from the client

Can help identify unusual traffic to a single script.

sc‐bytes

The number of bytes that the server sent to the client

Can help identify unusual traffic from a single script.

cs(Cookie)

The content of the cookie sent or received, if any.

Can help uniquely identify users.

Host

cs‐host

The host header name, if any.

Can determine if the user browsed to the site by IP address or host name.

Protocol Version

cs‐version

The protocol version — HTTP or FTP —that the client used.

Can help identify older scripts or browsers.

Referrer

cs(Referrer)

The site that the user last visited. This site provided a link to the current site.

Can help identify the source of an attack or see if an attacker is using search engines to find vulnerable sites.

Server Name

s‐ computername

The name of the server (Windows host name) on which the log file entry was generated.

Can verify the server accessed if the log files are later moved from the system.

Service Name and Instance Number

s‐sitename

The Internet service name and instance number (W3SVC instance number) that was running on the client.

Can verify the site accessed if the log files are later moved from the system.

Time Taken

time‐taken

The length of time that the action took, in milliseconds, to process the request.

Can identify unusual activity from a single script.

Win32 Status

sc‐win32‐status

The Windows (Win32) status code.

Can help identify script abuse.

Field

Appears As

Description

Bytes Received

cs‐bytes

Bytes Sent

Sources: [354], [355], [357]

171

Chapter 10: Appendices

10.15.

Network Operator Support Groups Table 10.15‐1: Network Operator Support Groups

Acronym Description APNIC

Asia Pacific Network Information Centre

APOPS

Asia Pacific Operator’s Forum

APRICOT Asia Pacific Regional Internet Conference on Operational Technologies JANOG

Japanese Network Operators Group

NZNOG

New Zealand Network Operators Group

PACNOG

Pacific Network Operators Group

SANOG

South Asian Network Operators Group

AfNOG

Africa Network Operators Group

EOF

European Operators Forum WG

FrNOG

French Network Operators Group

NordNog Nordic Operator Group

RIPE

Réseaux IP Européens

SwiNOG

Swiss Network Operators Group

ARIN

American Registry for Internet Numbers

NANOG

North American Network Operators Group

ISC

Internet Systems Consortium

ISPCON

Internet Service Providers' Convention

LACNIC

Latin America and Caribbean Network Information Centre

ICANN

Corporation for Assigned Names and Numbers

Network Operator Support Groups

172

173

The Challe T enge of Cyb ber‐Attackk Technicall Attribution A n in Computer Netw works Introduction I n, Challengess and Sourcees for Furtheer Research R The challenge of cybe er‐attack attrib bution has signnificant implicaations. Adequ uate attributio on: 1) f cyber‐aattacks; 2) improves defensse against futture cyber‐atttacks; 3) imprroves deters future response efficiency to active cyber‐aattacks in the ppresent; and 44) enables prod ductive response to ommerce, indu ustry, committted cyber‐attacks of the past. These impliications affect diplomacy, co governaance, communiications, justice e, policy, liabil ity, law enforccement and priivacy. Attribution is important to all forrms of cyber‐‐attack, from malware and d viruses to ssocial uthor engineering and penettrative attackss launched oveer computer neetworks. In this book, the au o an extensive e review of thhe literature fo ocusing on thee general tech hnical presentss the results of challengge of attributin ng cyber‐attackks launched ovver computer n networks again nst specific tarrgets, for the purposes of disruption, d infilltration or desstruction. Thee author begin ns by exploringg the neral categorie es of cyber‐attacks: denial oof service and d penetrative. The author then two gen exploress the commo on sources off attribution and then anaalyzes the co ommon challeenges associatted with employing these attribution soources. The author conclu udes the boo ok by presentiing matters fo or further rese earch. An exttensive annotaated glossary is provided to o aid understaanding of the jjargon used in the field. This boo ok will be of interest to sttudents new tthe field and seeking to gaain a foundattional understaanding of tecchnical attribution, its methhods and challenges. Stud dents will find d the annotated glossary helpful in unde erstanding neew terms and the extensivee reference liisting helpful iin supporting ffurther researcch.

This b book: • • •

Presents an o overview of tecchnical attributtion methods Discusses the e challenges associated with ttechnical attrib bution, in corp porate and industrial nettworks Provides pracctical insights in nto technical aattribution metthods and challenges