The recent denial-of-service attacks in Estonia reprise a running theme in this column space: the prevalence of inherent weaknesses regarding security, survivability, and resilience of our computer-communication infrastructures. These attacks provide another warning of things to come. They also suggest further reasons why renewed energy should be expended on improving the trustworthiness of our infrastructures and on somehow reducing our critical dependencies on systems, networks, and people that are not trustworthy.
In the July column, Charles Perrow suggested reducing the surface of exploitable vulnerabilities and providing greater diversity. In the August column, David Parnas pointed out some remaining difficulties, noting that there is still much more to be done—including insisting on precise specifications and applicable standards, and transcending simplistic approaches. He might have added the urgent need for pervasive use of the good software engineering practices that he himself has been pioneering since the early 1970s.
The Estonian attacks began at the end of April 2007, and demonstrated quite profoundly how widely distributed and loosely coordinated denial-of-service attacks could affect an entire nation. (Estonia popularly refers to itself as E-stonia, because almost everyone there has Internet access.) Initially, only Estonian governmental computer systems were attacked, which later spread via the Internet throughout the country—to newspapers, TV stations, schools, and banks. The attacks intensified on May 3 (which coincided with protests in Moscow against the Estonian removal of a Soviet-era war monument) and again on May 89 (when Europe commemorated the end of World War II). Although some Russian government server systems were involved, many other systems participated in the attacks (presumably unsuspectingly, as compromised zombie systems). The Estonian government suspected Russian complicity. A Kremlin spokesman denied any Russian governmental involvement. Analysis is apparently still ongoing.
Many opportunities exist for creating major service denials, often requiring no direct access to system resources. Much more serious potential damage can result from the implantation of Trojan horses and other forms of malware (worms, viruses, and so on)—some of which could have effects that were largely undetectable (such as surreptitious surveillance), others that could trigger outages and situations from which recovery would be exceedingly difficult. Corruption of software delivery pipelines could add further risks. In some cases, the consequences could be irreversible.
The Internet is of course a worldwide medium, and risks are not confined by national boundaries. However, the Estonian case apparently represents the first case in which a specific country was the target nationwide. As such, it illustrates only the tip of an iceberg with respect to the enormous potential for disruption—whether widespread or specifically targeted. (In contrast, the 1988 Internet worm targeted only BSD Unix systems, although performance degradation and unsubstantiated fear affected other systems as well.)
The technological expertise and nontechnological incentives required to carry out much more damaging attacks are already widely available to nation-states, organizations, and even individuals. The Estonian case serves to remind us once again of the need for more coherent serious measures to reduce the risks.
What can you do to help? First, study and act upon Toward a Safer and More Secure Cyberspace, National Academies Press, 2007, a new report from the National Research Council Computer Science and Telecommunications Board that assesses the overall situation—coming to some old conclusions that are still valid, as well as new ones. Second, make your concerns known to your elected government officials, at all levels. Third, partake in research and development that can help overcome the underlying problems. Above all, if you are developing systems or teaching how to do it, apply security principles and wisdom to network routers, secure name services, operating systems, application software, critical national and global infrastructures, and consider how such endeavors depend on one another. Today, all of these have serious associated risks. Assume that weaknesses will exist, and try to compensate for them.
The feeling that "we have not yet had the electronic tsunami or Chernobyl, so why should we worry?" tends to undermine attempts at constructive remediation. It is time to recognize that computer-related disasters can happen anywhere or everywhere, irrespective of geographical borders.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment