overview of the oasis pbd-se and pmrm emerging privacy ... jutla... · overview of the oasis pbd-se...
TRANSCRIPT
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,
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
PbD“Sub-Principles” Documentation
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
PbD“Sub-Principles” Documentation
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)
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
Baseline Information
Use Case Title
A short descriptive title for the use case
ACME Insurance Company Vehicle Data Tracking for Reduced Premiums
Baseline Information
Category of Use Case
e.g. Application categories such as “Online Banking” or Model categories such as “Two Domain”.
Mobile-Vehicular
Baseline Information
Use Case Description
High-level synopsis of the use case.
Applications and Data Subjects
Applications associated with Use Case
Relevant applications and products where personal information is communicated, created, processed, stored or deleted and requiring software development
Applications and Data Subjects
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
Technical, Managerial and Boundary Data
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.
Technical, Managerial and Boundary Data
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
Technical, Managerial and Boundary Data
Domains, Domain Owners, and Roles associated with Use Case
Technical, Managerial and Boundary Data
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
Technical, Managerial and Boundary Data
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
Technical, Managerial and Boundary Data
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
Policies, Controls and Supporting Services/Functions
Services
Inherited Control DM-1:
Minimization of PII
Exported Control AR-3:
Requirements for Contractors
• Define technical functionality and business processes supporting selected services
Policies, Controls and Supporting Services/Functions
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