Publications

Dissertation

Legal Requirements Metrics for Compliance Analysis
Aaron K. Massey
Ph.D. Thesis, North Carolina State University, 2012.
Abstract URL PDF More Information

Abstract: Laws and regulations safeguard citizens’ security and privacy. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) governs the security and privacy of electronic health records (EHR) systems. The U.S. Department of Health and Human Services (HHS), which is charged with creating, maintaining, and enforcing regulations pursuant to HIPAA, has required systematic changes in institutional privacy practices as a result of nearly 15,000 resolved HIPAA investigations. HIPAA violations can result in serious monetary penalties. HHS recently fined one healthcare provider $4.3 million dollars for violations of the HIPAA Privacy Rule. Ensuring EHR systems are legally compliant is challenging for software engineers because the laws and regulations governing EHR systems are written by lawyers with little to no understanding of the underlying technology.

This dissertation examines how software engineers can evaluate software requirements for compliance with laws and regulations. The main objective of this work is to help software engineers perform a legal compliance analysis for software intended to be deployed in domains goverened by law by developing empirically validated: (a) techniques for determining which requirements are legally implementation ready (LIR); (b) metrics to estimate which requirements are LIR automatically; and (c) a prototype tool that supports identifying LIR requirements using legal requirements metrics.

My empirical studies suggest that the average graduate-level software engineer is ill- prepared to identify legally compliant software requirements with any confidence and that domain experts are an absolute necessity. When working together as a team graduate-level software engineers make extremely conservative legal implementation readiness decisions. Furthermore, we observe that the legal requirements metrics discussed in this dissertation can be used to improve legal implementation readiness decisions. These findings, along with legal and ethical concerns, make the study of legal compliance in software engineering a critical area for continued research.

Book Chapters

Behavioral Advertising Ethics
Aaron K. Massey and Annie I. Antón
Information Assurance and Security Ethics in Complex Systems: Interdisciplinary Perspectives
Dr. Melissa Dark, ed., ISBN: 978-1616922450, pp. 162-182, 2010.
Abstract DOI GT DOI

Abstract: Behavioral advertising is a method for targeting advertisements to individuals based on behavior profiles, which are created by tracking user behavior over a period of time. Individually targeted advertising can significantly improve the effectiveness of advertising. However, behavioral advertising may have serious implications for civil liberties such as privacy. In this chapter, we describe behavioral advertising ethics within the context of technological development, political and legal concerns, and traditional advertising practices. First, we discuss the developmental background of behavioral advertising technologies, focusing on web-based technologies and deep packet inspection. Then, we consider the ethical implications with a primary focus on privacy of behavioral advertising technologies. Next, we overview traditional market research approaches taken to advertising ethics. Following that, we discuss the legal ethics of behavioral advertising. Finally, we summarize these cross-disciplinary concerns and provide some discussion on points of interest for future research.

Interference
Aaron K. Massey and Travis D. Breaux
Introduction to IT Privacy: A Handbook for Technologists
Dr. Travis Breaux, ed., International Association of Privacy Professionals, Portsmouth, NH, ISBN: 978-0-9885525-5-5, 2014.
Abstract IAPP

Introduction: Interference is an act that prevents or obstructs a process from continuing or being carried out properly. For individual privacy, interference can be informed by Warren and Brandeis’ privacy right “to be let alone” and Alan Westin’s notions of solitude and reserve, wherein an individual’s preference not to be bothered includes avoiding outside interference from others. Surveillance and tracking technologies, such as those described in Chapter 5, enable interference because they provide access to the individual’s physical person as well as to information about the individual’s behaviors and preferences. Society’s need to protect itself from nefarious individuals sometimes justifies the use of surveillance and tracking technologies. Similarly, businesses need to create accurate information models about individuals in order to ensure routine and reliable business activities. However, the risk of interference for individuals increases with the amount of information collected and maintained. Example activities include an individual’s ability to use transportation and banking services, the ability to earn a living wage by finding employment or to exercise a vote in a democratic society. These activities rely on establishing a person’s identity and authorization to use services or perform actions, e.g., that a person is licensed to drive or creditworthy, that the person is not a criminal felon. If an error exists in a person’s credit report, or if a person is incorrectly placed on a “no-fly” list, this individual would suffer from interference with their private matters. In this chapter, we begin by introducing interference in the context of current legal views, definitions and privacy harms. Afterwards, we examine interference from different technological perspectives, such as spam, mobile application and other software APIs, behavioral advertising, cyberbullying, social engineering, and finally remote desktop administration. We conclude with lessons learned that the IT professional may use in the context of their professional responsibilities.

Journals

Evaluating Legal Implementation Readiness Decision-making
Aaron K. Massey, Paul N. Otto, and Annie I. Antón
Transactions on Software Engineering
Abstract DOI GT DOI IEEE

Software systems are increasingly regulated. Software engineers therefore must determine which requirements have met or exceeded their legal obligations and which requirements have not. Requirements that have met or exceeded their legal obligations are legally implementation ready, whereas requirements that have not met or exceeded their legal obligations need further refinement. In this paper, we examine how software engineers make these determinations using a multi-case study with three cases. Each case involves assessment of requirements for an electronic health record system that must comply with the U.S. Health Insurance Portability and Accountability Act (HIPAA) and is measured against the evaluations of HIPAA compliance subject matter experts. Our first case examines how individual graduate-level software engineering students assess whether the requirements met or exceeded their HIPAA obligations. Our second case replicates the findings from our first case using a different set of participants. Our third case examines how graduate-level software engineering students assess requirements using the Wideband Delphi approach to deriving consensus in groups. Our findings suggest that the average graduate-level software engineering student is ill-prepared to write legally compliant software with any confidence and that domain experts are an absolute necessity.

Evaluating Existing Security and Privacy Requirements for Legal Compliance
Aaron K. Massey, Paul N. Otto, Lauren J. Hayward, and Annie I. Antón
Requirements Engineering: Volume 15, Issue 1, 2010, pp. 119-137.
Abstract DOI GT DOI Springer

Abstract: Governments enact laws and regulations to safeguard the security and privacy of their citizens. In response, requirements engineers must specify compliant system requirements to satisfy applicable legal security and privacy obligations. Specifying legally compliant requirements is challenging because legal texts are complex and ambiguous by nature. In this paper, we discuss our evaluation of the requirements for iTrust, an open-source Electronic Health Records system, for compliance with legal requirements governing security and privacy in the healthcare domain. We begin with an overview of the method we developed, using existing requirements engineering techniques, and then summarize our experiences in applying our method to the iTrust system. We illustrate some of the challenges that practitioners face when specifying requirements for a system that must comply with law and close with a discussion of needed future research focusing on security and privacy requirements.

Conferences

Identifying and Classifying Ambiguity for Regulatory Requirements
Aaron K. Massey, Richard L. Rutledge, Annie I. Antón, and Peter P. Swire
22nd IEEE International Requirements Engineering Conference
Karlskrona, Sweden, August 25 - 29, 2014.
Acceptance Rate: 31/115 (27.0%)
Abstract DOI GT DOI PDF

Abstract: Software engineers build software systems in increasingly regulated environments, and must therefore ensure that software requirements accurately represent obligations described in laws and regulations. Prior research has shown that graduate-level software engineering students are not able to reliably determine whether software requirements meet or exceed their legal obligations and that professional software engineers are unable to accurately classify cross-references in legal texts. However, no research has determined whether software engineers are able to identify and classify important ambiguities in laws and regulations. Ambiguities in legal texts can make the difference between requirements compliance and non-compliance. Herein, we develop a ambiguity taxonomy based on software engineering, legal, and linguistic understandings of ambiguity. We examine how 17 technologists and policy analysts in a graduate-level course use this taxonomy to identify ambiguity in a legal text. We also examine the types of ambiguities they found and whether they believe those ambiguities should prevent software engineers from implementing software that complies with the legal text. Our research suggests that ambiguity is prevalent in legal texts. In 50 minutes of examination, participants in our case study identified on average 33.47 ambiguities in 104 lines of legal text using our ambiguity taxonomy as a guideline. Our analysis suggests (a) that participants used the taxonomy as intended: as a guide and (b) that the taxonomy provides adequate coverage (97.5\%) of the ambiguities found in the legal text.

Tracking Requirements Evolution by Using Issue Tickets: A Case Study of a Document Management and Approval System
Shinobu Saito, Yukako Iimura, Kenji Takahashi, Aaron Massey, and Annie I. Antón
36th International Conference on Software Engineering (ICSE) SEIP track
Hyderabad, India, May 31 - June 7, 2014.
Acceptance Rate: 25/117 (21.4%)
Abstract DOI GT DOI PDF

Abstract:Requirements evolve throughout the software lifecycle. When requirements change, requirements engineers must determine what software artifacts could be affected. The history of and rationale for requirements evolution provides engineers some information about artifact dependencies for impact analysis. In this paper, we discuss a case study of requirements evolution for a large-scale system governed by Japanese laws and regulations. We track requirements evolution using issue tickets created in response to stakeholder requests. We provide rules to identify requirements evolution events (e.g. refine, decompose, and replace) from combinations of operations (e.g. add, change, and delete) specified in the issue tickets. We propose a Requirements Evolution Chart (REC) to visually represent requirements evolution as a series of events over time, and implement tool support to generate a REC from a series of issue tickets using our rules to identify requirements evolution events. We found that the REC supports impact analysis and compliance efforts.

Proposing Regulatory-Driven Automated Test Suites
Patrick Morrison, Casper Holmgreen, Aaron Massey, and Laurie Williams
Agile2013 Best Paper Award
Nashville, Tennessee, August 2013.
Abstract DOI GT DOI PDF

Abstract: In regulated domains such as finance and health care, failure to comply with regulation can lead to financial, civil and criminal penalties. While systems vary from organization to organization, the same regulations apply for all systems. As a result, efficiencies could be gained if the commonalities between systems could be captured in public, shared, test suites for regulations. We propose the use of Behavior-Driven-Development (BDD) technology to create these test suites. With BDD, desired system behavior with respect to regulatory requirements can be captured as constrained natural language ‘scenarios’. The scenarios can then be automated through system-specific test drivers. The goal of this research is to enable organizations to compare their systems to regulation in a repeatable and traceable way through the use of BDD. To evaluate our approach, we developed seven scenarios based on the HITECH Act Meaningful Use (MU) regulations for healthcare. We then created system-specific code for three open-source electronic health record systems. We found that it was possible to create scenarios and system-specific code supporting scenario execution on three systems, that iTrust can be shown to be non- compliant, and that emergency access procedures are not defined clearly enough by the regulation to determine compliance or non-compliance.

Automated Text Mining for Requirements Analysis of Policy Documents
Aaron K. Massey, Jacob Eisenstein, Annie I. Antón, and Peter P. Swire
21st IEEE International Requirements Engineering Conference
Rio de Janeiro, Brazil, July 2013.
Acceptance Rate: 21/114 (18.4%)
Abstract PDF

Abstract: Businesses and organizations in jurisdictions around the world are required by law to provide their customers and users with information about their business practices in the form of policy documents. Requirements engineers analyze these documents as sources of requirements, but this analysis is a time-consuming and mostly manual process. Moreover, policy documents contain legalese and present readability challenges to requirements engineers seeking to analyze them. In this paper, we perform a large-scale analysis of 2,061 policy documents, including policy documents from the Google Top 1000 most visited websites and the Fortune 500 companies, for three purposes: (1) to assess the readability of these policy documents for requirements engineers; (2) to determine if automated text mining can indicate whether a policy document contains require- ments expressed as either privacy protections or vulnerabilities; and (3) to establish the generalizability of prior work in the identification of privacy protections and vulnerabilities from privacy policies to other policy documents. Our results suggest that this requirements analysis technique, developed on a small set of policy documents in two domains, may generalize to other domains

Assessing the Accuracy of Legal Implementation Readiness Decisions
Aaron K. Massey, Ben Smith, Paul N. Otto, and Annie I. Antón
19th IEEE International Requirements Engineering Conference
Trento, Italy, September 2011.
Abstract DOI GT DOI PDF

Abstract:Software engineers regularly build systems that are required to comply with laws and regulations. To this end, software engineers must determine which requirements have met or exceeded their legal obligations and which requirements have not. Requirements that have met or exceeded their legal obligations are legally implementation ready, whereas requirements that have not met or exceeded their legal obligations need further refinement. Research is needed to better understand how to support software engineers in making these determinations. In this paper, we describe a case study in which we asked graduate-level software engineering students to assess whether a set of software requirements for an electronic health record system met or exceeded their corresponding legal obligations as expressed in regulations created pursuant to the U.S. Health Insurance Portability and Accountability Act (HIPAA). We compare the assessment made by graduate students with an assessment made by HIPAA compliance subject matter experts. Additionally, we contrast these results with those generated by a legal requirements triage algorithm. Our findings suggest that the average graduate-level software engineering student is ill-prepared to write legally compliant software with any confidence and that domain experts are an absolute necessity. Our findings also indicate the potential utility of legal requirements metrics in aiding software engineers as they make legal compliance decisions.

Workshops

Proposing Regulatory-Driven Automated Test Suites for Electronic Health Record Systems
Patrick Morrison, Laurie Williams, Casper Holmgreen, and Aaron Massey
Fifth International Workshop on Software Engineering in Health Care
San Francisco, California, May, 2013.
Abstract DOI GT DOI PDF

Abstract: In regulated domains such as finance and health care, failure to comply with regulation can lead to financial, civil and criminal penalties. While systems vary from organization to organization, regulations apply across organizations. We propose the use of Behavior-Driven- Development (BDD) scenarios as the basis of an automated compliance test suite for standards such as regulation and interoperability. Such test suites could become a shared asset for use by all systems subject to these regulations and standards. Each system, then, need only create their own system-specific test driver code to automate their compliance checks. The goal of this research is to enable organizations to compare their systems to regulation in a repeatable and traceable way through the use of BDD. To evaluate our proposal, we developed an abbreviated HIPAA test suite and applied it to three open-source electronic health record systems. The scenarios covered all security behavior defined by the selected regulation. The system-specific test driver code covered all security behavior defined in the scenarios, and identified where the tested system lacked such behavior.

Prioritizing Legal Requirements
Aaron K. Massey, Paul N. Otto, and Annie I. Antón
Second International Workshop on Requirements Engineering and Law
Atlanta, Georgia, September 2009.
Abstract DOI GT DOI PDF

Abstract: Requirements prioritization is used in the early phases of software development to determine the order in which requirements should be implemented. Requirements are not all equally important to the final software system because time constraints, expense, and design can each raise the urgency of implementing some requirements before others. Laws and regulations can make requirements prioritization particularly challenging due to the high costs of noncompliance and the substantial amount of domain knowledge needed to make prioritization decisions. In the context of legal requirements, implementation order ideally should be influenced by the laws and regulations governing a given software system. In this paper, we present a prioritization technique for legal requirements. We apply our technique on a set of 63 functional requirements for an open-source electronic health records system that must comply with the U.S. Health Insurance Portability and Accountability Act.

A Requirements-based Comparison of Privacy Taxonomies
Aaron K. Massey and Annie I. Antón
First International Workshop on Requirements Engineering and Law
Barcelona, Spain, September 2008.
Abstract DOI GT DOI PDF

Abstract: Understanding the nature of privacy regulation is a challenge that requirements engineers face when building software systems in financial, healthcare, government, or other sensitive industries. Requirements engineers have begun to model privacy requirements based on taxonomic classifications of privacy. Independently, legal research has modeled privacy harms in a taxonomic fashion. In this paper, we compare a requirements engineering taxonomy of privacy protections and vulnerabilities to a legal taxonomy of privacy harms. We seek to determine the extent to which the concepts and terminology are consistent between the two taxonomies. A consistent, standard vocabulary for privacy concepts for both requirements engineers and lawyers will improve the common understanding of privacy concepts, legal traceability and compliance auditing. We conclude that the taxonomies we analyzed are reasonably compatible. We believe this compatibility indicates that a taxonomic understanding of privacy is a promising area of research for requirements engineers.

Posters

Aligning Requirements with HIPAA in the iTrust System
Aaron K. Massey, Paul N. Otto, and Annie I. Antón
16th IEEE International Requirements Engineering Conference
Barcelona, Spain, September 2008.
Abstract DOI GT DOI PDF

Abstract: We describe a case study in which we evaluated an open-source Electronic Health Record (EHR) system’s requirements for compliance with the U.S. Health Insurance Portability and Accountability Act (HIPAA). Our findings suggest that legal compliance must be requirements-driven, while establishing due diligence under the law must be test-driven.

Copyright Notice:

Papers published by the Institute of Electrical and Electronics Engineers, Inc. (IEEE) are Copyright © 2008-2017 by IEEE. Personal use of this material is permitted. However, permission to reprint or republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

Papers published by the Association for Computing Machinery, Inc. (ACM) are Copyright © 2008-2017 by ACM. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee.