Menu
Home
Log in / Register
 
Home arrow Computer Science arrow The Privacy Engineer’s Manifesto
< Prev   CONTENTS   Next >

Develop Privacy Requirement Use Cases

Use cases reflect the requirements of business processes, and business processes are supported by information systems and automated business processes. Figure 5-2 shows a simple set of privacy use cases that could be used to develop a privacy engineering program.

Figure 5-2. Privacy requirements use cases

These use cases may contain explanatory elements that may be developed into use cases themselves, for instance, to:

• Determine and maintain privacy policies and procedures:

• Develop privacy policy

• Develop privacy procedures, standards, and guidelines

• Design privacy notice

• Develop archiving rules

• Determine security requirements:

• Develop authentication rules related to privacy

• Develop authorization rules related to privacy

• Determine data requirements:

• Determine proportional PI and related data collection and maintenance requirements

• Determine privacy processing requirements

• Developed backup strategy

• Develop third-party transfer rules

• Develop and build class and data models:

• Include privacy indicators in the model metadata

• Include encryption indicator in the model metadata

• Develop privacy component specifications, including:

• Enter privacy rules

• Test for authorization rules

• Present privacy notice

• Enter opt-in/opt-out rules

• Allow user to opt in or opt out depending on rules

• Test for privacy indicator in database metadata

• Test for encryption indicator in database metadata

• Test for privacy rules

• Test or third-party transfer rules

Use cases will usually be used to gather requirements as part of a project system's engineering development lifecycle. The information gathered as a part of use-case development should be entered into use-case metadata.

By virginia lee, senior Attorney, Privacy and security legal, intel Corporation

Engineers and lawyers may be speaking the same language, but you wouldn't know it when it comes to communicating about privacy. imperfect communication leads to enmity between the two groups. it is as if they were living on opposing alien planets. successful communication can be achieved between these seemingly disparate factions. it's not rocket science, but it may feel as difficult. it comes down to peeling back the jargon and teasing out the essence of what is being communicated.

What are the issues that crop up when engineers and lawyers try to communicate over privacy issues? The first critical impediment to good communication between the two are the perceptions held by each. Engineers have the perception that lawyers only say no. lawyers believe that engineers don't really care about privacy. These perceptions are rooted in some truths. There are relentless calls from

legislators and regulators about the need for more restrictions around the collection and use of consumers' data. All of us are bombarded by news articles about how some app developer surreptitiously collected a user's personal information without any concern as to whether the user would approve. so it is no wonder that there is a disconnect between the two groups.

Another roadblock to a mutual understanding are the concepts used by each. Engineers are accustomed to working in a deterministic environment. most things are black or white for an engineer. on the other hand, lawyers tend to deal in the gray spaces. The issues they deal in are much more “squishy,” lacking clear definitive answers. Additionally, both sets of concepts tend to be very complicated to outside parties.

There is hope for developing a middle ground where engineers and lawyers can meet and dialogue. To do this, both lawyers and engineers should more frequently use plain spoken language. A tool in the engineer's toolkit can accomplish this task. use cases can provide a bridge for reaching this plain spoken middle ground without using technical or legal jargon.

Engineers are adept at creating use cases for defining the features and functionality in a product release. These same use cases can be drafted to describe to a lawyer what the flow of events is for a user. use cases can also be used in defining how privacy legal concepts or rules can be applied to the functionality of a product or service. lawyers need to understand how the user's information will be collected, used, and shared. The user flow described in a use case is a great tool for providing this information.

one major benefit of use cases is that they make difficult concepts more concrete and comprehensible. scenarios can be created that define privacy issues in a manner that is understandable by both parties. With these more simple descriptions comes a clearer view of the user interaction that lawyers can more easily grasp.

Another advantage is that use cases help create a shared glossary. Engineers and lawyers should develop a shared privacy glossary that aligns with the company's privacy policies and principles. This glossary needs to be based on the company's own business practices. A shared glossary will provide the necessary definitions that can bridge the language gap. For example, what does the company mean by the term “personal information”? There are numerous definitions of this term used in rules and regulations, as well as by companies in their privacy policies. A company's definition of “personal information” will impact the way information is collected from users. Engineers and lawyers should work together to develop an appropriate definition through use cases and provide guidelines that are used throughout the company's development cycle.

use cases move teams to speak a shared language. lawyers need to limit the legalese and try to distill the legal concepts into more understandable concepts.

Engineers need to limit the techno jargon to more simple concepts. so often the legal rules or regulations are written so obtuse that it can drive an engineer crazy. Working with the lawyer, this “legalese” can be deciphered into something more palatable. As an example, the phrase “data only used for the purposes for which it was collected” crops into rules surrounding the appropriate collection of personal information from users. Translated this means only using the information collected from the user for the reason you told the user you were collecting it. As an illustration, an app developer collects a piece of data to provide recommendations to a user but then decides to use the information for serving targeted ads, without letting the user know beforehand. lawyers can provide these types of real-world examples through use cases to better describe confusing legal concepts.

ultimately, use cases help to develop rapport and understanding between the two factions. The best way to develop affinity with an opposing side is to find ways to interact using less formal methods. in order to work in harmony, engineers and lawyers need to develop rapport with each other. We all tend to face similar challenges and can find solidarity.

A successful privacy engineering engagement between an engineer and a lawyer is possible. Engineers and lawyers will always look at privacy issues differently due to how they frame the issues. However, by developing use cases to define concepts, these differences can be lessened. Both sides need to be cognizant of the other's point of view and approach any engagements with a jargon-free approach. Engineers and lawyers working in unity to mitigate the privacy issues will make for a successful and privacy-enhanced product.

Use Case Metadata

Metadata is business information that information technology needs to design and develop databases and the systems that satisfy business objectives and requirements. Whereas, mathematics is the language of science, metadata is the language of data, business, application, and technology architecture. Metadata is the who, how, where, when, and why of things we manage and the activities performed in managing them. Metadata is crucial to quality solution design and to maintain data quality and consistency in the operational environment.

The following are pieces of information (metadata)[1] gathered during use-case development:

• For each use case:

– Use-case name

– Use-case description

– PI involved in use case:

• Intended uses

• Related use cases

– Expected use-case results

– Measures of success

– Primary actor performing the use case

– Support actor(s) performing the use case

– Location of the use case

– Frequency of the use case

– Related use case(s)

– Ideal course of action:

• Event name and description (iterated for all events):

• Decision 1 name and description

• Business rule 1 description (If . . . Then . . . Else)

• Business rule data entities/attributes required

• . . . (iteration)

• Business rule and description (If . . . Then . . . Else)

• Decision and name and description

• Business rule 1 description (If . . . Then . . . Else)

• . . . (iteration)

• Business rule and description (If . . . Then . . . Else)

• Business processes triggered by event

• Process data entities/attributes required

– Alternative courses of action (extension use case)

For privacy engineering, use cases are key to understanding which events or behaviors have privacy impacts. By including privacy indicators and related privacy rules in the use-case metadata, the privacy engineer can easily index issues and understand where to focus attention.

The answer is “when it's not.”

metadata can be defined as business information that information technology needs to design and develop databases and the systems that satisfy business objectives and requirements. others give an even more terse definition: metadata is data about data. Both definitions define metadata as something that is descriptive of other data.

But when data initially identified or initially collected and processed as metadata are used not to describe other data but as data itself, such data may be considered content and not metadata, that is, either proprietary as in trade secret or other confidential data or personal data where it identifies an individual human. The fact that such collections of metadata may not name an individual by his or her legal surname is not determinative for legal and process based consideration.

For example, the us national security Agency (nsA) collects telephone call and e-m ail envelope metadata so it can more easily access large databases to determine end points where possible terrorists may be calling within the united states. This would be a correct use of the word “metadata.” Where such data are used to create analytics and patterns to show anomalies or help predict known threatening behavior, they may also be used to build a case of probable cause for further individual inspection. Due process principles and protections apply under existing law to prevent further message content inspection without such process. Where this process is not followed or where overcollection of metadata capable of individual identification takes place, an inevitable political and social backlash is unleashed.

But what if this so-called metadata is analyzed as data itself to gain an understanding of calling patterns or some purpose other than that described to a court or other reviewing body that allowed the correction of the data? Then the metadata itself may be considered content (and is not metadata) and thus is separately subject to data protection and other cyber security rules and regulations. in other words, the expectation of privacy in the united states and in other countries may be broader than initially considered by law enforcement agencies and international policing

requirements. metadata, like all other forms of raw data, is subject to the reengineering and new protection requirements implied by the jargon “big data.”

Use Case Metadata Model

Figure 5-3 presents a metadata model showing the metadata that needs to be collected for any use case being developed (see also Appendix A).

Figure 5-3. Use-case metadata model

As discussed previously and later in Chapters 6, 7, 8, and 9, it is helpful to understand the various elements that need to be covered in each use case:

• An event (the when) may require one or more decisions to be made.

• Each decision event pairing may have a decision event actor

(the who) who is involved in making the decision.

• A decision event may be governed by one or more decision event rules, including one or more privacy rules, which are a type of a business rule, as discussed later.

• Each decision event rule will require one or more data attributes (the what) needed to determine the decision criteria. For example, if the decision event rule is IF role name = Guest THEN invoke Guest Privacy Rule processing, “role name” is a data attribute used as part of the rule.

• Once the decision event rules have been processed, a decision event action (the how) may be taken by the system.

• This decision event action may impact a decision event action actor.

• The decision event action may be motivated by a goal or objective (the why) form of motivation.

• A decision event action will take place in a location (the where).

All this information that has been gathered within the use cases would then be put into a metadata repository based on this metadata model.

  • [1] The use case metadata collected is the same for both business and system use cases. The differences are in the level of detail and the language used considering the audience.
 
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
 
Subjects
Accounting
Business & Finance
Communication
Computer Science
Economics
Education
Engineering
Environment
Geography
Health
History
Language & Literature
Law
Management
Marketing
Philosophy
Political science
Psychology
Religion
Sociology
Travel