Engineering Privacy By Design Seda Grses COSIC, ESAT K.U. Leuven - - PowerPoint PPT Presentation

engineering privacy by design
SMART_READER_LITE
LIVE PREVIEW

Engineering Privacy By Design Seda Grses COSIC, ESAT K.U. Leuven - - PowerPoint PPT Presentation

Engineering Privacy By Design Seda Grses COSIC, ESAT K.U. Leuven Belgium 1 Outline - Introduction and Approach - Privacy Requirements Definition Problem - Privacy Requirements Analysis Problem - Policy and Compliance - Privacy By Design -


slide-1
SLIDE 1

Engineering Privacy By Design

Seda Gürses COSIC, ESAT K.U. Leuven Belgium

1

slide-2
SLIDE 2

Outline

  • Introduction and Approach
  • Privacy Requirements Definition Problem
  • Privacy Requirements Analysis Problem
  • Policy and Compliance
  • Privacy By Design
  • Data Minimization
  • Conclusion

2

2

slide-3
SLIDE 3

privacy?

  • what is privacy?
  • what are privacy requirements?
  • in security engineering: confidentiality

3

3

slide-4
SLIDE 4
  • nline social networks (SNS)

4

4

slide-5
SLIDE 5

5

2004

Facebook

2005 PUBLIC 2006 2007

Canadian Privacy Commissioner

LIVE FEED

protests

1.600.000

Highschools

xss attacks

protests 740.000

newsfeed

Facebook API Mobile BEACON

protests 50.000 in 3 days

bans

2008

cyberbullying unlimited license to user content

user voting

protests

friends lists

2009

facebook

google

CONNECTIONS

chat leak

NOYB FACECLOAK SCRAMBLE

1m 5m 12m 50m 100m

2011

500m

NHS reveals data to Facebook

Discriminatory Behavioral Profiling

User IDs revealed to Third Parties

Homeland Security friends Aliens

User telephone numbers and addresses revealed to Third Parties

1 in 5 divorces due to facebook data

2010

universal “comment” and “send” buttons on 50K sites in addition to “like”

680m 350m

5

slide-6
SLIDE 6
  • all of these are (somehow) about privacy and

the design of the system

  • how do we deal with these issues when

developing systems?

  • specifically: during requirements engineering

6

6

slide-7
SLIDE 7

Zave and Jackson Model of RE

  • domain assumptions describe the behavior of the environment as it is
  • requirements are statements about the desired conditions in an

environment

  • specification is a restricted form of requirement providing enough

information for the engineer to implement the system

7

ENVIRONMENT SYSTEM

7

slide-8
SLIDE 8

requirements

  • functional requirements state the desired

behavior of the environment

  • non-functional requirements either constrain

the behavior of the environment or define certain desired qualities of the environment

8

8

slide-9
SLIDE 9

multilateral privacy requirements engineering

  • reconcile:
  • privacy notions (legal & surveillance studies)
  • privacy solutions (computer science)
  • in a social context
  • multilaterally
  • during requirements engineering

9

9

slide-10
SLIDE 10

10

privacy data protection

10

slide-11
SLIDE 11

10

privacy data protection

non-absolute relational contextual

  • pacity of the individual

10

slide-12
SLIDE 12

10

privacy data protection

non-absolute relational contextual

  • pacity of the individual

procedural safeguards

accountability

transparency personal data

10

slide-13
SLIDE 13

surveillance studies

11

11

slide-14
SLIDE 14

surveillance studies

11

surveillance

11

slide-15
SLIDE 15

surveillance studies

11

surveillance

sousveillance

dataveillance

covaillance

11

slide-16
SLIDE 16

privacy requirements definition

12

lack of universality lack of satisfiability subjectivity legal compliance contrivability environmental factors counter - factuality temporality agonism negotiability

12

slide-17
SLIDE 17

multilateral privacy requirements engineering

  • reconcile:
  • privacy notions (legal & surveillance studies)
  • privacy solutions (computer science)
  • in a social context
  • multilaterally
  • during requirements engineering

13

13

slide-18
SLIDE 18

solutions from privacy research

14

data confidentiality anonymous communications database anonymization IDMS Differential Privacy Privacy Policy Languages Feedback and Awareness Systems anonymous certificates Discrimination aware data mining anonymous certificates

14

slide-19
SLIDE 19

privacy research paradigms

15

privacy as confidentiality the right to be let alone.

Warren & Brandeis (1890) hiding information and identity

15

slide-20
SLIDE 20

privacy research paradigms

16

privacy as confidentiality the right to be let alone.

Warren & Brandeis (1890) hiding information and identity

privacy as control

separation of identities, data protection principles right of the individual to decide what information about himself should be communicated to

  • thers and under what
  • circumstances. (Westin 1970)

16

slide-21
SLIDE 21

privacy research paradigms

17

privacy as confidentiality the right to be let alone.

Warren & Brandeis (1890) hiding information and identity

privacy as control

separation of identities, data protection principles right of the individual to decide what information about himself should be communicated to

  • thers and under what
  • circumstances. (Westin 1970)

privacy as practice

the freedom from unreasonable constraints on the construction of

  • ne’s own identity (Agre, 1999)

transparency and feedback

17

slide-22
SLIDE 22

privacy research paradigms

18

privacy as confidentiality

hiding information and identity

privacy as control

separation of identities, data protection principles

privacy as practice

transparency and feedback

18

slide-23
SLIDE 23

SECURITY ENGINEERING

security engineering & paradigms

19

privacy as control privacy as practice privacy as confidentiality

19

slide-24
SLIDE 24

multilateral privacy requirements engineering

  • reconcile:
  • privacy notions (legal & surveillance studies)
  • privacy solutions (computer science)
  • in a social context
  • multilaterally
  • during requirements engineering

20

20

slide-25
SLIDE 25

privacy and the Zave & Jackson Model

  • Zave and Jackson model is limited:
  • does not account for requirements that are

not absolutely satisfiable

  • does not facilitate subjective articulations
  • f domain assumptions, requirements or

specifications

  • does not express stakeholder attitudes and

emotions (only beliefs, desires and intentions)

21

21

slide-26
SLIDE 26

Zave and Jackson Model of RE

  • domain assumptions describe the behavior of the environment as it is
  • requirements are statements about the desired conditions in an

environment

  • specification is a restricted form of requirement providing enough

information for the engineer to implement the system

22

ENVIRONMENT SYSTEM

22

slide-27
SLIDE 27

requirements

  • functional requirements state the desired

behavior of the environment

  • non-functional requirements either constrain

the behavior of the environment or define certain desired qualities of the environment

23

23

slide-28
SLIDE 28

privacy requirements ontology

24

quality privacy constraint Q privacy concern Σ quality space

well-defined structured ill-defined subjective

24

slide-29
SLIDE 29

privacy requirements ontology

25

quality privacy constraint Q privacy concern Σ quality space

well-defined structured ill-defined subjective color: red munsell color notation: 10 red hue 7 chroma 8

25

slide-30
SLIDE 30

26

quality privacy constraint Q privacy concern Σ quality space

well-defined structured ill-defined subjective justified approximation

evaluation

26

slide-31
SLIDE 31

privacy requirements ontology

27

stakeholder arbitration surveillance information privacy concerns

due to experiences or expectations of harms due to informational constraints on info. self-determination due to significance of information

functionality

27

slide-32
SLIDE 32

privacy requirements ontology

27

stakeholder arbitration surveillance information privacy concerns

due to experiences or expectations of harms due to informational constraints on info. self-determination due to significance of information

functionality functionality

27

slide-33
SLIDE 33

SECURITY ENGINEERING

privacy requirements ontology

28

stakeholder arbitration surveillance information privacy concerns privacy goals confidentiality practice control

justified designation

functionality

28

slide-34
SLIDE 34

privacy requirements ontology

29

stakeholder arbitration surveillance information privacy concerns privacy goals

justified designation

privacy constraints

justified approximation

functionality

29

slide-35
SLIDE 35

privacy requirements ontology

30

stakeholder arbitration surveillance information privacy concerns privacy goals

justified designation

privacy constraints

justified approximation

communication analysis confidentiality strength of anonymity

functionality

30

slide-36
SLIDE 36

SECURITY ENGINEERING

role of security engineering

31

privacy as control privacy as practice privacy as confidentiality

31

slide-37
SLIDE 37

32

adversary threats

privacy concerns

functionality usability information

justified designation

privacy goals

justified approximation

trust assumptions stakeholder data protection

privacy constraints

32

slide-38
SLIDE 38

privacy engineering

  • requires learning skills (craft)
  • complicated practice
  • market incentives
  • assume functionality vs. privacy
  • policy and regulation

33

33

slide-39
SLIDE 39

Policy and Privacy By Design

34

communication of the ec

data protection compliance throughout the entire life cycle of technologies and procedures

data security, reasonable collection limits, sound retention practices, data accuracy

FTC report

34

slide-40
SLIDE 40

Policy and Privacy By Design

35

define the purpose generally to collect any data

further legitimize collection through consent and “technical control”

vulnerabilities

  • f PbyD

as compliance

limit the scope of “personal data”

35

slide-41
SLIDE 41

36

PbyD as compliance leaves out security engineering

centralized databases “trust us, we do not do evil” engineer introduces symbolic mimicry

  • f bureaucracy

increase consumer confidence

36

slide-42
SLIDE 42

the Cavoukian PbyD principles

37

privacy by design is

privacy embedded into design

37

slide-43
SLIDE 43

the Cavoukian PbyD principles

37

privacy by design is

privacy embedded into design

privacy by design is embedded into the design and architecture of it systems...it is not

bolted on as an add on, after the fact. The result is that privacy becomes

an essential component of the core functionality being delivered.

37

slide-44
SLIDE 44

privacy by design and DM

38

Cavoukian states privacy by design includes from the principles of data protection you can infer

DATA MINIMIZATION

38

slide-45
SLIDE 45

39

SYSTEM

DATA

DATA

39

slide-46
SLIDE 46

functional requirements

40

SYSTEM

functionality: charge customers based on driving

fees location data

service providers customers

ID

40

slide-47
SLIDE 47

functional requirements

41

SYSTEM

functionality: charge customers based on driving

fees location data

service providers customers

ID

excluded functionality: law enforcement LBS

41

slide-48
SLIDE 48

data minimization

42

SYSTEM

fees location data

service providers customers

ID

functionality: charge customers based on driving

42

slide-49
SLIDE 49

data minimization

43

SYSTEM

fees location data

service providers customers

ID

functionality: charge customers

43

slide-50
SLIDE 50

modelling attackers/threats

44

SYSTEM

fees location data

service providers customers

ID

threat 1: SP profiles customers threat 1I: attacker compromises SP DB threat III: attacker compromises OBU

functionality: charge customers

44

slide-51
SLIDE 51

multilateral security analysis

45

SYSTEM

fees location data

service providers customers

ID

security req

  • f SP:

fees are correct

functionality: charge customers

45

slide-52
SLIDE 52

implementation/testing

46

SYSTEM

fees location data

service providers customers

ID

  • nly data

revealed that is known to SP

no additional vulnerabilities through implementation

functionality: charge customers

46

slide-53
SLIDE 53

47

SYSTEM

DATA

DATA

47

slide-54
SLIDE 54

48

SYSTEM

minimize centralization

keep data in user controlled domain

minimize observation, storage, and disclosure

minimize identifiable data

minimize trust minimize risk

48

slide-55
SLIDE 55

before

49

SYSTEM

fees location data

service providers customers

ID

functionality: charging customers, LBS

location data

threat 1: SP profiles customers threat 1I: attacker compromises SP DB threat III: attacker compromises OBU threat IV: SP profiles customers threat V: law enforcement abuses DB

49

slide-56
SLIDE 56

after

50

SYSTEM

fees location data

service providers customers

ID

  • nly data

revealed that is known to SP

no additional vulnerabilities through implementation

functionality: charge customers

minimize trust

50

slide-57
SLIDE 57

after

51

SYSTEM

fees location data

service providers customers

ID

  • nly data

revealed that is known to SP

no additional vulnerabilities through implementation

functionality: charge customers

minimize risk

51

slide-58
SLIDE 58

after

52

SYSTEM

fees location data

service providers customers

ID

  • nly data

revealed that is known to SP

no additional vulnerabilities through implementation

functionality: charge customers

minimize centralization

52

slide-59
SLIDE 59

after

53

SYSTEM

fees location data

service providers customers

ID

  • nly data

revealed that is known to SP

no additional vulnerabilities through implementation

functionality: charge customers

data in user controlled domain

53

slide-60
SLIDE 60

after

54

SYSTEM

fees location data

service providers customers

ID

  • nly data

revealed that is known to SP

no additional vulnerabilities through implementation

functionality: charge customers

minimize observation, storage, disclosure

54

slide-61
SLIDE 61

after

55

SYSTEM

fees location data

service providers customers

ID

  • nly data

revealed that is known to SP

no additional vulnerabilities through implementation

functionality: charge customers

minimize identifiable data

55

slide-62
SLIDE 62

conclusion

  • PbyD requires an engineering practice
  • privacy engineering is a complex practice
  • security engineering at its root
  • data protection and compliance provides additional measures
  • proportionality
  • access control on collected data
  • transparency and oversight
  • unacceptable use
  • DP/Compliance cannot replace privacy engineering

56

56

slide-63
SLIDE 63

Thank you!

  • sguerses@esat.kuleuven.be

57

57