Reasonableness Meets Requirements: Regulating Security and Privacy in Software

Otto, Paul N., Duke Law Journal

ABSTRACT

Software security and privacy issues regularly grab headlines amid fears of identity theft, data breaches, and threats to security. Policymakers have responded with a variety of approaches to combat such risk. Suggested measures include promulgation of strict rules, enactment of open-ended standards, and, at times, abstention in favor of allowing market forces to intervene. This Note lays out the basis for understanding how both policymakers and engineers should proceed in an increasingly software-dependent society. After explaining what distinguishes software-based systems from other objects of regulation, this Note argues that policymakers should pursue standards-based approaches to regulating software security and privacy. Although engineers may be more comfortable dealing with strict rules, this Note explains why both policymakers and engineers benefit from pursuing standards over rules. The nature of software development prevents engineers from ever guaranteeing security and privacy, but with an effective regulatory standards framework complemented by engineers' technical expertise, heightened security, and privacy protections can benefit society.

INTRODUCTION

On October 20, 2008, Anne Pressly, a television anchorwoman in Little Rock, Arkansas, was discovered in her home after having been attacked and severely beaten. (1) Although she spent the next week at a hospital, Ms. Pressly never regained consciousness and ultimately passed away on October 25. (2) The attack quickly gained national media attention, (3) especially because the beating was particularly savage and yet apparently random. (4)

In addition to attracting national media attention, the situation surrounding Ms. Pressly's attack and subsequent hospitalization also inspired curiosity among hospital employees within the St. Vincent Health System. Within a month of Ms. Pressly's death, the hospital announced the firing of several employees for "improperly accessing [her] medical records. (5)

In cases the media follows, there have been many breaches of patients' privacy rights through unauthorized access to medical records. (6) The suspension or termination of hospital employees often follows such breaches, owing to the strict privacy protections put in place by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (7) and its resulting regulations regarding the security and privacy of medical records. (8) As a news article describing the Pressly situation mentions, however, "you still have to wonder ... why is there not more limited access to those [medical] records--especially with a prominent individual when you could really expect an unauthorized person would get overly curious? Why does the hospital allow any employee access to records they do not need to see?" (9)

The problem of unauthorized access to private information is not limited to the healthcare domain, nor is the general problem restricted to unauthorized access. Personally identifiable information (10)--whether financial, medical, or otherwise private--is threatened by identity theft, (11) data breaches, (12) and fraud, (13) among other threats. Misuse of personally identifiable information has increased as more information enters electronic form, thus facilitating both its exchange and exposure on a larger scale. The transition to electronic record systems has necessitated the development of complex software systems (14) to manage the creation, storage, and transmission of electronic information.

Increasingly, laws and regulations specify how software systems must implement data security and privacy measures. Some legal requirements regarding security and privacy emerge in advance of software system development to control the direction of software use. (15) Other security and privacy requirements emerge in response to perceived excesses or threats from existing software systems. (16) In both scenarios, policymakers (17) must make decisions about the means through which they seek to control software design, development, and deployment. (18) In particular, policymakers must decide which approach--rules, standards, or nonintervention--is most appropriate to protect security and privacy within software. (19)

Once laws and regulations take effect, the policymakers' task may appear complete, as auditors and regulators take over the job of overseeing compliance with and enforcement of these security and privacy requirements. The software engineering community, (20) however, has struggled to manage the implementation of these legal requirements within the software development process. (21) The software engineering community has recognized compliance monitoring as a significant problem, (22) but researchers still struggle to develop methodologies for even establishing, much less monitoring, compliance. (23) Extracting security and privacy requirements directly from legal texts has proven too difficult and error-prone to address the need for compliance. (24) Furthermore, the ambiguity inherent in legal texts raises numerous problems for engineers seeking to implement legal requirements directly into software systems. (25) The disconnect between legal requirements and engineering realities raises serious concerns about the efficacy of emerging data security and privacy protections. Both engineers and policymakers recognize compliance as essential to protecting security and privacy, (26) yet the technical means to establish and maintain compliance are lagging behind the legal mandates. (27) The result is a situation in which Ms. Pressly and her family ostensibly have the protection of the law safeguarding Ms. Pressly's medical records, yet the software systems managing her records are ill-equipped to provide the protection without the possibility of unauthorized access.

This Note seeks to explore the relationship between law and software with regard to security and privacy. Specifically, this Note argues that legal requirements governing security and privacy must take the form of broad standards rather than specific rules. (28) Although software engineers may prefer the ease of implementing rules--with their specific technological mandates--to ambiguous and open-ended standards, security and privacy interests are best protected through standards that leave room for evolution. Broad standards allow the law to capture moving targets; by requiring reasonable software security, for example, the law can continue to mandate strong security measures as industry best practices evolve and improve. Similarly, by including broad privacy protections, the law can capture new threats to privacy as understandings evolve regarding what constitutes personal information or whether previously innocuous information is in fact personally identifiable. (29)

Part I of this Note discusses the various aspects of software that make it unique as compared with other regulatory subjects. Part II discusses the spectrum of choices that policymakers face in regulating software. Part III presents the principal argument of this Note: with regard to security and privacy protections, standards are more appropriate than rules for requirements regarding software systems that are made at the original policymaking level. This Note concludes with some thoughts on how policymakers' use of standards in the first instance is most effective when engineers create rules to meet the standards given to them.

I. THE NATURE OF SOFTWARE

There are several characteristics of software systems that make them unique subjects of regulation. These characteristics center around the nature of software design, development, and deployment as compared with non-software-centric systems. To illustrate these unique characteristics, this Part will compare and contrast software with physical buildings at three key stages: design, development, and deployment. (30) Understanding these characteristics is essential to making an informed decision regarding what form of regulation is appropriate for safeguarding security and privacy in software systems.

A. Design

The crucial differentiating factor of software-based systems is that software is virtually unlimited in flexibility and scope. (31) Unlike the construction of a building, in which the laws of physics constrain the possibilities lying before the architect, software can be molded into any shape necessary to perform a desired set of functions. (32) From the perspective of the software engineering community, this flexibility has been described in lofty terms: "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." (33) Software's malleable nature allows it to encompass far greater complexity than physical counterparts can manage. (34) This same flexibility, however, comes at a great cost: the overall software development process (35) is prone to scheduling delays and constant flux, as stakeholders (36) treat flexibility as a license to change requirements at any time. (37)

B. Development

The need to define system functionality (38) is the greatest limitation on the scope of software (that is, the tasks that the software system will perform and the features it will contain). Once decisions on the software's scope and function are made, the "creativity of the programmer, the complexity or sophistication of the software itself, or the environment in which it operates" serve to limit the software's theoretical flexibility. (39) Thus, the narrow selection of permitted inputs and outputs (40) for a specific program necessarily limits the virtually infinite reach of software that exists in theory.

Despite the emergence of significant limits on flexibility and creativity imposed during the development phase, these limits are even more constraining in the development of a physical building. First, there are physical limits to the size and scope of a given building; in software, however, it is relatively easy to add new functionality or address evolving requirements even during development. (41) Second, constructing a physical building proceeds in clearly defined stages, and generally architects and builders try to avoid having to undo any portions that have been situated. In software, however, there is comparatively lower cost in changing many elements of the software, no matter how much has been built. (42)

C. Deployment

After development or construction has concluded, the first major contrast between software systems and physical buildings concerns the ease of replication. Once developed, a software system can be deployed in a virtually unlimited number of locations with minimal additional effort; replication of physical structures can be accomplished through reuse of the original design, but development must begin anew at each new building site. Further, once its deployment is complete, software is "automated" in its function: no further intervention is required for software to make its determinations of allowable and prohibited behaviors. (43) This behavior may not at first glance seem so different from a physical building: once conceived, constructed, and completed, a building is available for full use. The key difference in this regard between software systems and other regulated entities, such as a building, is the degree of interaction that software possesses. Software may take actions without any human oversight. (44) This automated nature can be a great strength: software can just as easily handle one case as it can handle one billion cases, (45) meaning that software systems can manage a larger number of transactions than any human-driven system could hope to address. A significant difference exists in scale of usage as well: whereas most physical buildings have a relatively low occupancy limit, software may simultaneously accommodate many orders of magnitude more users.

Along with its automated nature, software also produces immediate results. Software therefore can bar prohibited behavior without ever allowing a violation to occur in the first place; (46) similarly, software can permit actions to take place immediately, again without requiring human oversight. In contrast, a physical building can take no action to control its usage: once built, the building's structure may have implications for the building's usage, but not enforcement of the developer's intent. Legal requirements implemented in software provide an immediate interpretation of the requirements as they are represented in the software system--even if the result was not fully understood or even contemplated by the original software developers. (47)

The immediate results provided by software systems directly contrast with another characteristic of these systems: the lack of transparency in software's decisionmaking process. Although an individual interacting with a software system will see immediate results from an attempt to engage in a particular action, software does not provide any explanation of its decisions unless an explanation has been included ex ante within the software. Furthermore, unless the software is updated, software is locked into providing the results programmed in during software development. (48) This differs sharply from interactions with a physical building, in which many (if not all) design decisions are exposed directly to the building's occupants. (49)

The final significant difference between software and its physical counterparts is that software is commonly deployed despite the existence of known problems in the software. There is an understanding in the software engineering community that large software systems cannot be constructed perfectly (that is, without a single bug or vulnerability). (50) This tolerance for bugs and system failures contrasts sharply with expectations for physical buildings, in which compliance with building plans and specifications is generally fairly precise and accurate. This difference in expectations leads to a great variance in maintenance costs after deployment: both buildings and software have an expected maintenance phase after deployment, but for software, the cost of testing and maintaining the final product may exceed the costs of design and development. (51)

II. THE INTERSECTION OF SOFTWARE AND REGULATION

With the increased use of computing technologies in modern society, there has been a corresponding--though lagging--increase in laws and regulations targeting actions that software systems can and cannot perform. Although these laws and regulations target various types and aspects of software systems, (52) this Note will focus on laws and regulations concerning data security and privacy protections.

The idea of regulating software through laws has been called a form of legal preemption. (53) The spectrum of choices facing policymakers who regulate the behavior of software systems includes specifying software functionality directly through the promulgation of specific rules, defining broad standards with which software must comply, and enabling software to take the place of explicit regulation. (54) In addition, policymakers may choose to not regulate software systems at all, leaving security and privacy protections to be handled by market forces. (55) Each of these options is discussed in turn.

A. Preemption through Legal Rules

In the strongest form of legal preemption, laws or regulations "directly establish[] formal boundaries or requirements for …

Questia, a part of Gale, Cengage Learning. www.questia.com
Publication information: Article title: Reasonableness Meets Requirements: Regulating Security and Privacy in Software. Contributors: Otto, Paul N. - Author. Journal title: Duke Law Journal. Volume: 59. Issue: 2 Publication date: November 2009. Page number: 309+. © 2009 Duke University, School of Law. COPYRIGHT 2009 Gale Group.

This material is protected by copyright and, with the exception of fair use, may not be further copied, distributed or transmitted in any form or by any means.