overview of the oasis pbd-se and pmrm emerging privacy ... jutla... · overview of the oasis pbd-se...

Overview of the OASIS PbD-SE and PMRM emerging privacy standards

Dawn N. Jutla, PhD, Board Member, OASIS, Advisory Board Member, PRIPARE

co-Chair OASIS PbD-SE, co-editor OASIS PMRM

[email protected] @DNJutla

Cyber Security an Privacy Forum 2014

May 21-22

*PMRM-related slides in deck (Slide 11 onwards) from: John Sabo - Chair PMRM TC), Gershon Janssen,

[email protected], [email protected]

mailto:[email protected]



EMERGING Standards to make

Privacy-by-Design Instinctual on the Internet

FOR EVERY ORGANIZATION AND SOFTWARE ENGINEER –

ON PURPOSE, IN A MANAGED WAY

THE 7 FOUNDATIONAL PRINCIPLES

– DR. ANN CAVOUKIAN

1. Proactive not Reactive; Preventative not Remedial

2. Privacy as the Default Setting

3. Privacy Embedded into Design

4. Full Functionality – Positive-Sum, not Zero-Sum

5. End-to-End Security – Full Lifecycle Protection

6. Visibility and Transparency – Keep it Open

7. Respect for User Privacy – Keep it User-Centric

Scope of the OASIS PbD-SE and OASIS PMRM Standard-Track Work Products

Privacy-by-Design Principles

& FIPPs & GAPPs

Privacy Laws and Policies

Privacy Control

Statements

Detailed Privacy

Requirements

Multiple Points of

View

Stakeholder Connectivity and Contexts

Privacy Components and Services

Privacy Software

Architecture

Privacy-enriched Software Apps and Systems

OASIS PbD-SE crosses the entire 4-stage spectrum from principles to implementation

DEFINING Principles, Legal, and Policy Requirements

DEFINING detailed privacy requirements across contexts & privacy services

DESIGNING Architecture for Privacy Software

BUILDING Privacy-Integrated Software Implementations

Organizations

Citizens (Employees and Consumers)

App Provider (e.gAcross Air, WikiTude, iOnRoad, Skype, TagWhat, etc.)

Carrier (e.g. network carriers: AT&T, Bell, DoCoMo, Rogers, Sprint, Telus)

Device and OS (e.g. iPhone, IPad, iOS, Blackberry, Android, Windows)

Advertisers

User-provided personal data (each platform and merchant

may get different data attributes) in a single service

User profiles sent to advertiser networks, aggregators, and to merchants

Ads, offers, deals etc.

Marketing Aggregator (e.g. Flurry, MobClix, Traffic MarketPlace)

Government

x

x

x

x

Separate Cloud Instance

© Dawn N. Jutla Personal data flows between platforms.

PbD“Sub-Principles” Documentation

1.ProactivenotReactive;PreventativenotRemedial

1.1–Demonstrable Leadership: A clear

commitment, at the highest levels, to prescribe and enforce high standards of privacy protection, generally higher than

prevailing legal requirements.

1.2–Defined Community of Practice: Demonstrable privacy commitment shared by organization members, user

communities and stakeholders.

1.3–Proactive and iterative: Continuous processes to identify privacy and data protection risks arising from poor designs,

practices and outcomes, and to mitigate unintended or negative impacts in proactive

and systematic ways

MUST normatively reference the PbD-SE specification

MUST reference assignment of responsibility and accountability for privacy in the organization, and privacy training program.

MUST include assignment of privacy resources to the software project, recording who are responsible,

accountable, consulted, or informed for various privacy-related tasks MUST reference all external sources of privacy

requirements, including policies, principles, and regulations. MUST include privacy requirements specific to the

service/product being engineered, and anticipated deployment environments MUST include privacy risk/threat model(s) including

analysis and risk identification, risk prioritization, and controls clearly mapped to risks


2.PrivacybyDefault

2.1–Purpose Specificity: Purposes must be

specific and limited, and be amenable to

engineering controls

2.2–Adherence to Purposes: methods must be in

place to ensure that personal data is collected,

used and disclosed:

in conformity with specific, limited purposes;

in agreement with data subject consent; and

in compliance with applicable laws and

regulations

2.3–Engineering Controls: Strict limits should

be placed on each phase of data processing

lifecycle engaged by the software under

development, including:

Limiting Collection;

Collecting by Fair and Lawful Means;

Collecting from Third Parties;

Limiting Uses and Disclosures;

Limiting Retention;

Disposal, Destruction; and Redaction

The OASIS PMRM Privacy Use Case Template is RECOMMENDED as a tool to use for iterating and identifying and documenting privacy requirements and

assessment.

SHOULD list all [categories of] data subjects as a stakeholder

MUST document expressive traceable models of detailed data flows,

processes, behaviors, and the privacy properties to be satisfied for

the use cases or user stories associated with internal software project

and all data/process interaction with external platforms, systems,

APIs, and/or imported code. (Examples of expressive models are

roughly equivalent to UML models)

MUST describe selection of privacy controls and privacy

services/APIs and where they apply to privacy functional

requirements and risks.

MUST include software retirement plan from a privacy viewpoint


5. End-to-End Lifecycle Protection

5.1–Protect Continuously: Personal data must

be continuously protected across the entire

domain and throughout the data life-cycle from

creation to destruction

5.2–Control Access: Access to personal data

should be commensurate with its degree of

sensitivity, and be consistent with recognized

standards and criteria

5.3–Use Security and Privacy Metrics: Applied

security standards must assure the confidentiality,

integrity and availability of personal data and be

amenable to verification

Applied privacy standards must assure user/data

subject comprehension, choice, consent,

consciousness, consistency, confinement (setting

limits to collection, use, disclosure, retention,

purpose), and context(s) around personal data at a

functional level, traceability of data flows, and

minimized identifiability, linkability, and

observability at a systems level, and be amenable

to verification

MUST be produced for all stages of the software development

lifecycle from referencing applicable principles, policies, and

regulations to defining privacy requirements, to design,

implementation, maintenance, and retirement.

MUST reference requirements, risk analyses, architectures, design,

implementation mechanisms, retirement plan, and sign-offs with

respect to privacy and security.

MUST reference security AND privacy properties and metrics

designed and/or deployed by the software, or monitoring software, or

otherwise in the organization and across partnering software systems

or organizations.

Comprehension(UserunderstandingofhowPIIishandled)

Usersshouldunderstandhowpersonalidentifiableinformation(PII)ishandled,who’scollectingitandforwhatpurpose,andwhowillprocessthe

PIIandforwhatpurposeacrosssoftwareplatforms.Usersareentitledtovisibility-toknowallpartiesthatcanaccesstheirPII,howtoaccess/correcttheirowndata,thelimitstoprocessingtransparency,whythePIIdataisbeingrequested,whenthedatawillexpire(eitherfromacollectionordatabase),andwhathappenstoitafterthat.Thiscategoryalsoincludes

legalrightsaroundPII,andtheimplicationsofacontractwhenoneisformed.

Consciousness(Userawarenessofwhatishappeningandwhen)

Usersshouldbeawareofwhendatacollectionoccurs,whenacontractisbeingformedbetweenauserandadatacollector,whentheirPIIissettoexpire,who’scollectingthedata,withwhomthedatawillbeshared,howtosubsequentlyaccessthePII,andthepurposesforwhichthedataisbeingcollected.

Choice

(Toopt-inorout,divulgeorrefusetosharePII)

Usersshouldhavechoicesregardingdatacollectionactivitiesintermsofoptinginorout,whetherornottoprovidedata,andhowtocorrecttheirdata.

Consent

(Informed,explicit,unambiguous)

Usersmustfirstconsent(meaninginformed,explicit,unambiguousagreement)todatacollection,use,andstorageproposalsforanyPII.Privacy

consentmechanismsshouldexplicitlyincorporatemechanismsofcomprehension,consciousness,limitations,andchoice.

Context(Useradjustingpreferences

asconditionsrequire)

Usersshould/mustbeabletochangeprivacypreferencesaccordingtocontext.Situationalorphysicalcontext—suchascrowdedsituations(for

example,whenataservicedeskwhereseveralpeoplecanlisteninonyourexchangewhenyouprovideaphonenumber,orwhenyouareinthesubwaywithcamerasandaudioonwearablesaroundyou)—isdifferentfromwhenyouperformabuytransactionwithAmazon.comorprovideinformationtoan

appregisteredwithanaggregatorthatsellstoadvertisers.Dataalsohascontext(suchasthesensitivityofdata,forexample,financialandhealthdata)coulddictatedifferentactionsonthesamePIIindifferentcontexts.

Confinement

(Dataminimization,proportionality,anduser-controlledre-useofdata)

Usersmust/shouldbeabletoset/requestlimitsonwhomayaccesstheirPII,forwhatpurposes,andwhereandpossiblywhen/howlongitmaybestored.

Settinglimitscouldprovidesomegoodopportunitiesforfuturenegotiationbetweenvendorsandusers.

Consistency

(Userpredictabilityofoutcomeoftransactions)

UsersshouldanticipatewithreasonablecertaintywhatwilloccurifanyactioninvolvingtheirPIIistaken.Thatis,certainactionsshouldbepredictableonuseraccessofPIIorgivingoutofPII.

A-TOILING the 7Cs: Satisfying Privacy Properties

Adapted from: Dawn N. Jutla, Peter Bodorik, "Sociotechnical Architecture for Online Privacy," IEEE Security and Privacy, vol. 3, no. 2, pp. 29-39, March-April 2005, doi:10.1109/MSP.2005.50. http://bit.ly/1qePUpn

A – Auditability A - Accountability T – Traceability 0 - Observability I – Identifiability Linkability – measure of the degree that a real identity can be linked to data (BIRO, 2009)

http://bit.ly/1qePUpn

http://bit.ly/1qePUpn

RACIChartforSoftwareEngineers

PbD-SEMethodologyStep

Documentstobereferenced/produced

SoftwareEngineer

PrivacyResource

ProjectMgmt.

Mgmt. ThirdParty

User

3.1ReferenceOrganization-alReadiness

PrivacyPolicyDocument

CI

RA CI

CI

A CI

I

CI

PrivacyRoles/TrainingPrograminOrganization

I

RA CI

CI

A I

I

I

3.2ScopePrivacyRequirements

&ReferenceArchitecture

FunctionalPrivacyRequirements&hookstoReference

Architecture

RA

RA CI

ACI

A I

RA I

CI

3.3ConductRiskAnalysisonUseCases

BusinessModelwithPersonalDataFlows

CI

RA CI

CI

A C

CI

-

RiskanalysisControlsidentification

CI RA CI CI A CI CI -

3.4IdentifyPrivacyResourceAllocation

PrivacyresourceallocationtoSEteam

I RACI RI A I I -

3.5CreateRACIforProducing

Artifacts

RACIassignmenttoartifactproduction

RCI CI RA CI A I - -

3.6CustomizePrivacyArchitecture

PrivacyArchitecture(incl.servicesidentification)

RA

A CI

A CI

A I

I

-

3.7ConductPeriodicReview

ReviewofArtifactsthroughoutthePDLC

RA CI RA CI A I - -

3.8ExecuteCodeTesting&PrivacyEvaluation

Testingandevaluationforsatisfyingprivacyproperties

RA RCI RA CI A I - C

3.9CreateRetirementPlan

Planforretirementofsoftwaresolution

CI RA CI RA CI A CI I I

3.10Sign-off Signoffwithchecklist

RA CI RA CI RA CI A C - -

PMRM’s Privacy Use Case Template as Tool Supporting Privacy by Design

• Provides all stakeholders associated with the specified software

development project within an organization a common picture and a clearer understanding of all relevant privacy components of the project

• Can expose gaps where PbD analysis has not been carried out or where implementation has not been initiated or completed

• A tool to map privacy policies, requirements and control objectives to

technical functionality

• Facilitates the re-use of knowledge for new applications and the extension of Privacy by Design principles more broadly throughout an organization

• Where code must bridge to external systems and applications, a

standardized template will help ensure that Privacy by Design principles extend to the transfer of personal information across system and organizational boundaries.

• A standards-based use case template can reduce the time and cost of

operationalizing PbD and improve the quality and reusability of documentation

PMRM v1.0 Methodology – Consistent Analysis of Complex Use Cases

PMRM-Based Template Benefits

• Provides an inventory of Privacy Use Case components and the responsible parties that directly affect software development for the Use Case

• Consistently segments Privacy Use Case components in a manner generally consistent with the OASIS PMRM v1.0 Committee Specification

• Enables understanding of the relationship of the privacy responsibilities of Privacy Use Case stakeholders

• Enables traceability – as you move through the different stages of the privacy lifecycle and across interconnected applications

• Agnostic - Does not specify an implementer’s SDLC methodology, development practices or in-house data collection, data analysis or modeling tools

• Valuable as a tool to increase opportunities to achieve Privacy by Design in applications by extracting and making visible required privacy properties

• Enables Capability Maturity Model analysis for an organization

Privacy Use Case Template

PMRM Template Privacy Management Analysis (PMA)

Use Case Title

Use Case Categorization

Use case Description

Applications associated with

Use Case

Data Subjects

PI/PII

Legal/Reg

Domains and Owners

Data Flows and Touch Points

Systems

Controls

Services

Functions

Baseline Information

Applications and Data Subjects

Technical, Managerial and Boundary Data

Policies, Controls

and Supporting Services/Fu

nctions


Use Case Title

A short descriptive title for the use case

ACME Insurance Company Vehicle Data Tracking for Reduced Premiums


Category of Use Case

e.g. Application categories such as “Online Banking” or Model categories such as “Two Domain”.

Mobile-Vehicular


Use Case Description

High-level synopsis of the use case.


Applications associated with Use Case

Relevant applications and products where personal information is communicated, created, processed, stored or deleted and requiring software development


Data subject(s) associated with Use Case

Include any data subjects associated with any of the applications in the use case.

• The registered Insured person associated with the vehicle VIN • Other drivers designated by the vehicle owner

The PI and PII collected, created, communicated, processed, stored or deleted within privacy domains or systems, applications or products. • per domain, system, application or product

depending on level of use case development • including incoming, internally generated and

outgoing PI


PI and PII covered by the Use Case

• Registered driver name, Account Number, VIN • Registered driver contact information • Linked vehicle operational data • Linked vehicle time and location data • Linked evaluation assessment and summary information

The policies and regulatory requirements governing privacy conformance within use case domains or systems and links to their sources.


Legal, regulatory and/or business policies governing PI and PII in the Use Case

• Government(s) regulations • Vehicle Manufacturer privacy policies • Telecom Carrier privacy policies • Insurance Company privacy policies • Data Subject Consent preferences • Specific policies governing apps (e.g., “Data Communications to

Manufacturer” • Links to policies ….

• http://acmeinsurancegroupinc.biz/vehicle privacy/ • http://HudsonCarCompany.biz/privacy_vehicle….

• Domains - both physical areas (such as a customer site or home) and

logical areas (such as a wide-area network or cloud computing environment) that are subject to the control of a particular domain owner

• Domain Owners - the stakeholders responsible for ensuring that privacy

controls and functional services are defined or managed in business processes and technical systems within a given domain

Note: Identifying stakeholders is essential for clarifying the intersection of privacy requirements and software development.

• Roles - the roles and responsibilities assigned to specific stakeholders and

their relationship to systems within a specific privacy domain


Domains, Domain Owners, and Roles associated with Use Case


Domains, Domain Owners, and Roles associated with Use Case

Domain 1: Hudson Motor Company’s Vehicle Communications Data Center, Vehicle Owner’s Web Portal and Backend Data Collection Application Domain 1 Owner: VP, Vehicle Manufacturer’s Vehicle Communication and Data Division Role: Application design, development, content, testing, integration testing with external systems, and adherence to corporate security and privacy policies, management of raw datasets of vehicle information.

• Touch points - the points of intersection of data flows with privacy

domains or systems within privacy domains

• Data flows – data exchanges carrying PI and privacy policies among domains in the use case


Data Flows and Touch Points Linking Domains or Systems

Hudson Motors

Communications Division

Vehicle Backend

Data Operations

Vehicle Web

Portal

Vehicle Communications

System Acme

Insurance Customer

Vehicle Programs

Customer Profile Dept.

Analytics Domain

Customer Portal

Software Development

Group

Data Communications

Local Agent portal


Systems supporting the Use Case applications

• Control - a process designed to provide reasonable assurance regarding

the achievement of stated objectives • per specific domain, system, or applications as required by internal

governance policies and regulations • including inherited, internal and exported privacy controls

Policies, Controls and Supporting Services/Functions

Privacy controls required for developer implementation

Acme Insurance Customer

Vehicle Programs

Customer Profile Dept.

Analytics Domain

Customer Portal

Software Development

Group

Data Communications

Local Agent portal

Incoming PI (Driving patterns and assessed risk

linked to VIN)

Inherited Control DM-1:

Minimization of PII

Outgoing PI (Name, account number, driving

pattern and assessment summaries)

Exported Control AR-3:

Requirements for Contractors

• Service - a collection of related functions and mechanisms that operate for a specified purpose

• Identify Services satisfying privacy controls


Services

Inherited Control DM-1:

Minimization of PII

Exported Control AR-3:

Requirements for Contractors

• Define technical functionality and business processes supporting selected services


Functions

• Inherited Control DM-1: Minimization of PII • Usage service

• Automated interfaces to maintain separation of data using identifier with relatively inaccessible auxiliary info

• Security service • Role-based access control

• Exported Control AR-3: Requirements for Contractors

• Agreement service • Chain-of-trust contract clause

Works in Process

• PbD-SE TC and the PMRM TC working in partnership

to develop practical privacy standards and

standards-derived tools

• Output/input to/from PRIPARE and broader

participation from business, policy and technical

experts

• Contact [email protected] and/or

[email protected] or email: join@oasis-

open.org

