I wish reality were as simple as Bob Toxen made it out to be in his article "The NSA and Snowden: Securing the All-Seeing Eye" (May 2014) where he said, "A simple one-minute scan on the way out by a handheld metal detector—’wanding,’ as used by the Transportation Security Administration and at courthouses—would have found any flash memory device." However, flash devices have shrunk to minuscule size, even as their capacity has increased dramatically. Consider the micro-SD flash storage device in a typical smartphone; it can store more than 32GB and be small enough to be hidden practically anywhere. Moreover, its small mass makes detection especially difficult for a typical handheld metal detector. A spy could even attach one with chewing gum to a tooth, defeating practically any routine check.
So the real problem in the case of Edward J. Snowden is not that Snowden carried a flash memory device in and out of National Security Agency facilities but that he was able to transfer sensitive data to the device in the first place.
In most secure environments, it is extremely difficult, if not impossible, to attach an external device to a secure system. If it could be done, the system would no longer be secure, as the device would be able to transfer malware to, as well as steal data from, the secure system.
In 2008, an infected USB flash drive was famously connected to a military laptop. The malicious code uploaded itself to a secure network under the control of U.S. Central Command. This incident should have alerted the NSA to the dangers inherent in the use of removable memory devices. Moreover, the Stuxnet affair, two years later, demonstrated that U.S. security services were clearly aware that removable memory devices are potential attack vectors. The NSA should have anticipated these risks and taken necessary measures well in advance of Snowden’s leaks.
The reason for the apparent indifference to such risks is that insider attacks are particularly difficult to address. The esprit-de-corps culture prevalent in the NSA made it essentially unthinkable that one in their midst could betray the organization, and is why Snowden was able, apparently, to convince coworkers to grant him additional access.
Security is an overhead; by controlling access, security makes it inherently difficult for people to carry out their work, so a compromise between utility and security must be established. In the Snowden case, though the compromise went too far toward utility, it would be a mistake to go to the other extreme by imposing security procedures that impede the NSA’s useful work.
Vassilis Prevelakis, Braunschweig, Germany
Author’s Response
Wanding would have caught a USB memory stick due to the metal in its plug. No security ring is perfect. Defeating the rings involving encryption, physical access to systems, and software limiting the number of documents one may access would be extremely difficult. I demonstrated that stopping even system administrator insider attacks can be done reasonably easily. The reason Prevelakis claimed for NSA "indifference" is unsubstantiated. Aldrich Ames, Robert Hanssen, and other convicted American traitors should have convinced the NSA (and the CIA) to avoid unlimited trust. (I do not consider Snowden a traitor, as he was alerting Americans to the apparently unconstitutional and illegal actions of the government.)
Bob Toxen, Duluth, GA
The esprit-de-corps culture prevalent in the NSA made it essentially unthinkable that one in their midst could betray the organization.
I was disturbed by the cover headline—"The NSA and Snowden: How better security measures could have stopped the leak"—publicizing Bob Toxen’s article (May 2014) for implying that Snowden simply produced "leaks" that should have been "stopped." Moreover, I found it odd that the article focused on how the NSA’s poor security allowed these leaks to take place. It would have been more appropriate to acknowledge the alternative interpretation, that Snowden’s revelations brought to light abhorrent violations of privacy on the part of the U.S. and U.K. governments. After all, the constitutionality of the NSA’s spying was critiqued in the article’s sidebar. Why not follow through to address the apparent contradiction between "good security practices" and the supposed "transparency" of agencies with the power to tap all our communications (including this one)?
William Gaver, London U.K.
Objects Are Patterns, Not Language
To those who care about the writing of software, should object-oriented language constructs recede in today’s shattered-object world? Back in the early days of design patterns, the question arose as to why languages do not support pattern-oriented constructs. The answer came back from the Gang of Four of design-patterns fame that languages should not be pattern-oriented, since modern languages provide tools to create patterns effectively without pattern-specific features.
Maybe objects are more for our heads than for our languages when it comes to modern systems.
Instead of this purist point of view, modern languages do provide features that support common patterns, with iterators as an important example. So pattern support exists, at least partially, but there is no reason to think any language will have a goal of being pattern-oriented, as it is largely true that the other constructs of modern languages express the nature of patterns well without additional notation. So patterns live comfortably in the minds of software developers largely without specific notation to support them.
Not so with objects, for which most popular modern languages devote a vast amount of notation and through which many modern APIs are structured. Moreover, what programmer, when introduced to object-oriented design, does not enjoy a simple taxonomy of an animal farm as a clear approach to structuring problems in a step toward solving them? But our modern animal farm is more George Orwell than Old MacDonald, as once-comfortable objects fight to escape the boundaries being placed on them.
Object-oriented design was born in a world of one place and one time; the cow lived on a farm, the farm lived on a server, and the cow was alive for the duration of the time we had tasks to ask of her: be born, give milk and calves, and then provide steaks and burgers during systematic deconstruction. The cow lived in our minds and in our code as a structured entity with which we could converse.
But objects got big and devices got small and the world moved on. Servers today live on the farm and the cows (objects) no longer live at all, certainly not like they did; but just as shards of the cow—a little on a phone here as JavaScript to render a moo, a little on a server there as SQL to keep track of her progeny. A nice object-oriented library is likely available to manage talking to the database or updating the user interface to render a comforting sound. But this is the story of the blind men and the elephant now told in code; "the object" is described only as a collection of amalgamated ideas in disparate languages on systems at different times. A single object-oriented language has no purpose to serve here, because the unified description of these objects is bigger than the purpose of programming languages.
For small objects, object-oriented programming can still be useful, but our problems have outgrown our systems, and object-oriented languages want objects to be inside the systems instead of the systems being inside our objects. We no longer have cows, at least in terms of whole cows in one place at one time. So, are cow parts best described as objects or are these object shards too disconnected and independently represented to be viewed as objects?
REpresentational State Transfer, or REST, is not object-oriented but does allow interaction with the conceptual objects defined by interacting systems. Maybe objects are more for our heads than for our languages when it comes to modern systems. For a related perspective on objects, see Mordechai Ben-Ari’s Viewpoint "Objects Never? Well, Hardly Ever!" (Sept. 2010), and for more on REST and related technologies, see Ian Foster et al.’s article "How Do I Model State?: Let Me Count the Ways" (Sept. 2008).
Warren MacEvoy, Grand Junction, CO
Join the Discussion (0)
Become a Member or Sign In to Post a Comment