Standing Your Ground: Current and Future Challenges in Cyber Defense

Standing Your Ground: Current and Future Challenges in Cyber Defense

Barry V. W. Irwin (Rhodes University, South Africa)
Copyright: © 2014 |Pages: 9
DOI: 10.4018/978-1-4666-6158-5.ch006
OnDemand PDF Download:
List Price: $37.50


This chapter explores the challenges facing those involved in cyber defense at a national, organizational, and individual level. As the global economy grows more dependent on the Internet and connected infrastructure, the risk and impact of attack grows. A long-standing response to attacks of various kinds conducted on the Internet has been to filter traffic but not to respond. In some cases, reactive action is taken, but even where attribution is possible, prosecution is rare. In recent months, several countries have stated their policy of military response where they feel that their national infrastructure is threatened. The risk to organizations, civilian populations, and individuals is discussed in the case of such militant response or retaliation. The chapter further considers aspects such as reputation, neutrality, and the concept of Internet “kill switches.”
Chapter Preview

Evolution Of Security

The Internet has transitioned from its largely academic roots, where the principles of openness and data sharing were paramount to a global network, vital to global commerce and communication. Possibly as a factor of the rapid growth, legal systems globally have failed to keep up, and the ease with which actions may be performed on or against system located in areas geographically distant to the instigator, have made the enforcement of traditional laws difficult. The question of legal jurisdiction in such cross border incidents greatly complicates the resolution from a law enforcement perspective. The long standing principle employed by many network administrators has been to protect the border and implement appropriate technologies to manage the communications of what has become an increasingly hostile, exterior network to those hosts within their organization. This thin veil of security, aptly described by Bill Cheswick as a “sort of crunchy shell around a soft, chewy center” (Cheswick, 1990), has probably never been more apt. The initial approach taken with the widespread adoption of firewall systems was to block the known bad (blacklisting), which has transitioned to largely block everything except what we need (whitelisting). In both approaches, the majority of organizations still focus their defensive efforts outwards. The act of blocking itself takes many forms. Considering the case of the traditional IP Firewall, a block is often differentiated between two states: Deny: in which IP datagrams matching the rule are discarded, and Block: in which prior to the discard a protocol relevant error message is sent indicating this has occurred.

In the case of blocking, the RFC specifications for the ICMP protocol provide for fairly specific signaling as to why a packet may have been dropped (IANA, 2008) (which may not have been only due to security reasons). A similar approach is taken when dealing with email, where spam is either discarded (preferably pre-acceptance) or a notification of the message having been quarantined or tagged is sent.

In recent years many organizations have started to consider the implications of focusing defensive resources inwards on their networks. While in many ways this has been primarily driven by technologies such as DLP (Data Loss/Leak Prevention), a secondary driver has been seen to be the mitigation of risk and liability. Considering the scenario of an administrator detecting repeated port scanning activity from a source, the response has usually consisted of a number of distinct phases.

Attribution: The source(s) are identified, initially as an IP address, and then resolved using various methods to a source organization. This organization may be an endpoint, or in the case of consumer Internet access, an Internet service provider.

Action: The identified sources are blocked, usually at the firewall or routing infrastructure at the point where the administrator has control.

Complaint: A notification of the malicious activity is sent to the responsible organization, usually as an email directed to the abuse@ email address, which is required to exist as per RFC 2142 (Crocker, 1997). This is not always successful, as the addresses often do not exist or no response is received. An escalation path is typically followed with the provider of network access to that organization.

Complete Chapter List

Search this Book: