1. Privacy-­‐by-­‐Design Framework
for
Assessing
Internet
of
Things
Applications
and
Platforms
Charith
Perera,
Ciaran
McCormick,
Arosha
K.
Bandara,
Blaine
Price,
Bashar
Nuseibeh
The
6th
International
Conference
on
the
Internet
of
Things
(IoT
2016)
November
7–9,
2016
in
Stuttgart,
Germany.

2. Internet
of
Things
• The
Internet
of
Things
(IoT)
is
“…the
network
of
physical
objects—
devices,
vehicles,
buildings
and
other
items—embedded
with
electronics,
software,
sensors,
and
network
connectivity
that
enables
these
objects
to
collect
and
exchange
data…”#
• By
2020,
there
will
be
50
to
100
billion
devices
(i.e.
things,
sensors,
smart
objects)
connected
to
the
Internet*
#
International
Telecommunication
Union,
Internet
of
Things
Global
Standards
Initiative,
2015,
http://www.itu.int/en/ITU-­‐T/gsi/iot/Pages/default.aspx
*
International
Data
Corporation
(IDC)
Corporate
USA,
“Worldwide
smart
connected
device
shipments,”
March
2012,
http://www.idc.com/getdoc.jsp?containerId=prUS23398412

3. Application
Development
Desktop
Application
Mobile
Application
Web
Application
Application
• Processing
happens
locally
• UI
sits
locally
• Processing
happens
locally
complemented
by
cloud
resources
• UI
sits
locally
• Processing
happens
remotely
• UI
sits
locally

4. Internet
of
Things
Application
Development
BeagleBone
Waspmote
Raspberry PiArdunio
Gadgeteer
Dragonboard 410C
• NO Operating System
• Less Powerful
• OS Driven
• More Powerful
Cloud Computing
• Unlimited Computational
Resources*

5. Todays
IoT
Development
Market
Hardware Software

6. Privacy-­‐by-­‐Design
• IoT
applications
are
complex
by
nature
as
they
involve
both
software
and
hardware
as
well
as
many
different
types
of
computational
devices
(e.g.,
sensors,
gateways,
cloud)
• Privacy
is
a
significant
problem
in
IoT
applications
because
they
handle
data
that
can
be
used
to
derive
very
sensitive
personal
information

7. Why
hasn’t
privacy
been
a
priority?
• IoT
systems
(applications,
service,
platforms)
are
still
new;
Not
mature
enough
• Most
IoT
platforms
follow
the
philosophy
“You
feed
your
data
to
our
platform,
we
do
the
processing
and
give
you
back
the
results”
• Current
IoT
platform
providers
assume,
anyone
who
uses
their
platform
has
the
full
ownership
of
the
data
they
feed.
(In
reality
this
is
not
the
case
always)
• Therefore,
privacy
is
not
a
major
concern
for
IoT
platform
providers.

8. Our
Motivation
and
Proposed
solution
• There
isn’t
any
process/methodology/framework
to
help
software
architects
in
assessing
and
designing
IoT
applications
• Existing
frameworks
are
not
prescriptive
enough
to
follow
by
an
engineer
(We
discuss
them
few
slides
later)
• Recent
Security
and
Privacy
Violations:
HACKING
IoT:
A
Case
Study
on
Baby
Monitor
Exposures
and
Vulnerabilities#
• Therefore,
we
wanted
to
build
a
Privacy-­‐by-­‐design
framework
that
can
guide
software
architects
in
assessing
IoT
application.
#
https://www.rapid7.com/docs/Hacking-­‐IoT-­‐A-­‐Case-­‐Study-­‐on-­‐Baby-­‐Monitor-­‐Exposures-­‐and-­‐Vulnerabilities.pdf

9. BUT
IT
IS
NOT
….
• Guidelines
SHOULD
NOT
be
used
to
compare
different
IoT
application
or
platforms.
• The
primary
reason
is
that
each
IoT
application
or
platforms
is
designed
to
serve
a
specific
purpose
or
category
of
application.
Focus:
Enterprise
middleware
platform
for
Smart
Cities
and
Businesses
Focus:
Smart
Home
Automation

10. What
is
out
there
?
(Literature)
Privacy
by
Design
Foundational
Principles
-­‐ 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
life-­‐cycle
protection
6) Visibility
and
transparency-­‐ keep
it
open
7) Respect
for
user
privacy,
keep
it
user-­‐centric
*A.
Cavoukian,
“Resolution
on
privacy
by
design,”
in
32nd
International
Conference
of
Data
Protection
and
Privacy
Commissioners,
2010.

11. What
is
out
there
?
(Literature)
LINDDUN
– Deng
et
al.*
*M.
Deng,
K.
Wuyts,
R.
Scandariato,
B.
Preneel,
and
W.
Joosen,
“A
privacy
threat
analysis
framework:
supporting
the
elicitation
and
fulfillment of
privacy
requirements,”
Requirements
Engineering,
vol.
16,
no.
1,
pp.
3–32,
2011.
This
is
a
privacy
threat
analysis
framework
that
uses
data
flow
diagrams
(DFD)
to
identify
privacy
threats.
1) Define
the
DFD
2) Map
privacy
threats
to
DFD
elements
3) Identify
threat
scenarios
4) Prioritize
threats
5) Elicit
mitigation
strategies
6) Select
corresponding
PETS

12. What
is
out
there
?
(Literature)
*J.-­‐H.
Hoepman,
"Privacy
Design
Strategies,"
in
ICT
Systems
Security
and
Privacy
Protection,
vol.
428,
N.
Cuppens-­‐Boulahia,
F.
Cuppens,
S.
Jajodia,
A.
Abou El
Kalam and
T.
Sans,
Eds.,
Springer
Berlin
Heidelberg,
2014,
pp.
446-­‐459.
Privacy
Design
Strategies
–Hoepman*
1) Minimize
2) Hide
3) Separate
4) Aggregate
5) Inform
6) Control
7) Enforce
8) Demonstrate
• We
determined
that
Hoepman’s
is
the
most
appropriate
starting
point
for
developing
a
more
detailed
privacy-­‐by-­‐design
• Primarily
because
this
framework
already
focuses
on
the
architectural
aspects
of
privacy
design

13. IoT
Data
Flow
View
CDA
DPP
DPADS
DD
CDA
DPP
DPADS
DD
CDA
DPP
DPADS
DD
CDA
DPP
DPA
DS
DD
Consent
and
Data
Acquisition
Data
Pre-­‐Processing
Data
Processing
and
Analysis
Data
Storage
Data
Dissemination

14. Privacy
By
Design
Guidelines
1) Minimise data acquisition
2) Minimise number of data sources
3) Minimise raw data intake
4) Minimize knowledge discovery
5) Minimize data storage
6) Minimize data retention period
7) Hidden data routing
8) Data anonymization
9) Encrypted data communication
10) Encrypted data processing
11) Encrypted data storage
12) Reduce data granularity
13) Query answering
14) Repeated query blocking
15) Distributed data processing
16) Distributed data storage
17) Knowledge discovery based aggregation
18) Geography based aggregation
19) Chain aggregation
20) Time-Period based aggregation
21) Category based aggregation
22) Information Disclosure
23) Control
24) Logging
25) Auditing
26) Open Source
27) Data Flow Diagrams (DFD)
28) Certification
29) Standardization
30) Compliance with Policy, Law, Regulations
MINIMISEHIDESEPARATE
AGGREGATIONDEMONSTRATE
INFORM
CONTROL
/
ENFORCE

15. Evaluation
of
Privacy
Capabilities:
Methodology
• Step
1:
Identify
how
data
flows
in
the
existing
application
or
platform
• Step
2:
Build
a
table
for
each
node
where
columns
represent
data
life
cycle
phases
and
rows
represent
each
privacy-­‐by-­‐design
guideline.
• Step
3:
Depending
on
the
level
of
detail
which
software
architects
wish
to
explore,
they
can
either
use
(1)
a
summarised
colour
coding
base
scheme
(2)
a
notes
based
scheme

16. Evaluation
of
Privacy
Capabilities:
Methodology

17. Platforms
We
Assessed
http://www.eclipse.org/smarthome/ https://github.com/OpenIotOrg/openiot
• Focus:
Enterprise
middleware
platform
for
Smart
Cities
and
Businesses
• Middleware
infrastructure
supports
flexible
configuration
and
deployment
of
algorithms
for
collecting,
and
filtering
information
streams
stemming
from
internet
connected
objects
• Focus:
Smart
Home
Automation
• Platform
for
integrating
different
home
automation
systems
and
technologies
into
one
single
solution
that
allows
over-­‐
arching
automation
rules
and
uniform
user
interfaces

18. Results

19. Research
Directions
• Can
1)
Novice
2)
Experience
Software
architects
assess
a
given
platform
using
the
proposed
guidelines
consistently?
If
there
are
variation,
why?
• Given
a
case
study,
can
privacy
guidelines
guide
1)
Novice
2)
Experience
Towards
a better privacy-­‐aware
IoT
applications
Evaluation
Future
work
• Privacy
Tactics
-­‐ Tactics
are
design
decisions
that
improve
individual
quality
attribute
(e.g.
Privacy)
concerns.
[Basic
building
blocks]
• Privacy
Patterns
-­‐ Patterns describe
the
high-­‐level
structure
and
behaviour
of
software
systems
as
the
solution
to
multiple
system
requirements
[Complex
Compositions]

20. Thank
You