Presentation by Dr Emil Lupu (Imperial College London)at COMIT 2016: Digitally Building Britain, September 2016 More information: http://www.comit.org.uk/liveblog

1. On Sensors, Threats,
Responses and Challenges
Emil Lupu
Deputy-Director Petras IoT Research Hub
Director, Academic-Centre of Excellence in Cyber
Security Research Imperial College London

3. Exposing the physical world to
cyber threats

4. Protection agents or attack
vectors?

5. Less obvious paths to compromise

6. Policy-Based Systems

7. How to configure, personalise and
automate?
Vision Mobile IoT Megatrends 2016

8. Policy-Based Systems
Control
actions
Decisions
Managed
Objects
Monitor
Events
Manager
Agent
Events
Policies
(auth)
New functionality Policies
(oblig/ECAs)
Policy-Based Systems
RBAC
Ponder and Ponder2
http://ponder2.net
CHAPTER 5. APPLICATION OF THE LEARNING FRAM EWORK TO DATA
COLLECTED ON ANDROID
(a) T he Result View (b) T he IntegrityConstraints View
Figure 5.9: The Result and IntegrityConstraints view
5.5.1 A pplicat ion usage
We thought it would be a good idea to keep track of the user’s application usage. While this
sounds like it should be a simple task it, unfortunately, proved to be a little more complicated
than what we had originally thought. As a result, the Android SDK does not provide a way,
through its API, to detect the time at which an application is launched, for obvious security
Policy
Analysis
Policy Refinement
Goal: Protect troop location information from unauthorised disclosure
Who can access location information?
Granularity of the information location provided.
Protection of Information in communications system.
Policies regarding:
Policy Specification
In Natural Language
Subclasses (NLS)
In a Formal Language (FL)
System Side
Algorithms & Tools
User Side
Author NL policies
Convert NL policies to FL policies
Author FL policies
Convert FL policies to NL policies
Abstract Policy Models
Security Ontologies
Policy Transformation
Policy Synchronization
Goals, High Level Policies
In System Context
Concrete Policy Sets
Executable Policies
Information
Control Flow
Policy Ratification
Policy Authoring
Policy Ratification
Databases, XML Stores, Rule Engines, State
Machines, etc
Global Principles and Goals
Large Scale Analyses of NL and
FL Policies
Survey & Coding of Related
Practices
Policy Transformation
Policy Synchronization
Human Factors Based Design & Usability Studies
Policy Presentation
Processing & User Interaction
User Preferences
in a FL
User-Level
Paradigms for
Preferences
Preference Specification Tools
AC & Audit Policies
Data User Risk Choices &
Model Model Model Consent
Policy
Learning
Self-Managed Cells
Data Sharing
Agreement
Refinement
Analysis
Data centric security

9. Techniques for the entire policy
life-cycle
Policy Refinement
Goal: Protect troop location information from unauthorised disclosure
Who can access location information?
Granularity of the information location provided.
Protection of Information in communications system.
Policies regarding:
CHAPTER 5. APPLICATION OF THE LEARNING FRAM EWORK TO DATA
COLLECTED ON ANDROID
(a) T he Result View (b) T he IntegrityConstraints View
Figure 5.9: The Result and IntegrityConstraints view
5.5.1 A pplicat ion usage
We thought it would be a good idea to keep track of the user’s application usage. While this
sounds like it should be a simple task it, unfortunately, proved to be a little more complicated
than what we had originally thought. As a result, the Android SDK does not provide a way,
through its API, to detect the time at which an application is launched, for obvious security
reasons. To overcomethisproblem, wetakea di↵erent approach. TheAndroid Activity Manager
logs every application launch event by its package name. For example, com. andr oi d. camer a
suggests that the user is using a the phone’s camera.
Policy Learning
Policy
Specification
Policy Analysis
Policy Deployment
and Enforcement

10. … and the application areas
Network Management Body Area Networks Security for Sensors
Firewall Analysis and
Rule Generation
Mobile Ad-Hoc
Networks
coyote.c
CHAPTER 5. APPLICATION OF THE LEARNING FRAM EWORK T
COLLECTED ON ANDROID
(a) T he Result View (b) T he IntegrityCon
Figure 5.9: The Result and IntegrityConstraints view
5.5.1 A pplicat ion usage
We thought it would be a good idea to keep track of the user’s applicat
sounds like it should be a simple task it, unfortunately, proved to be a li
than what we had originally thought. As a result, the Android SDK do
through its API, to detect the time at which an application is launched
reasons. To overcomethisproblem, wetakea di↵erent approach. TheAnd
logs every application launch event by its package name. For example,
suggests that the user is using a the phone’s camera.
Therefore, to allow our application to detect application launch events a
use Java’s Runt i me class to execute the command l ogcat Act i vi t yMana
Android’s own console application that allows access to logs at run-time
I nput St r eamReader and continuously filter events as they arrive.
We put some thought into this to avoid duplicate entries. Like we have
Privacy

11. Policy Learning Example: Call
screening on Mobile
User Agent
Location
• Example: Under which circumstances
users accept calls on a mobile phone
• Traces of mobile phone usage including
CLID, location, nearby known devices.
CLID
CLID
• Learning: Find H such that B ⋃ H ⊨ E. Where
• B: background knowledge, H: hypotheses, E: positive and negative
examples
• Revision: Given U, find U’ Such that B ⋃ U’ ⊨ E and some minimality
criteria are met.

12. Learning new user behaviour rules…
At home
H H H
07:00
Call from
At location
Day 1 07:30
Context:
in_group(alice, home).
in_group(bob, home).
happens(gps(57,10),07:00).
at_location(home, W, N) ← Conditions,….
Examples:
not do(accept_call(alice), 07:00).
do(accept_call(bob), 07:30).
do(accept_call(bob), 11:00). }
New policy
do(accept_call(Call_Id, From), T ) ← T ≥ 07:30

13. Revising learnt rules incrementally
At home At homeAt Imperial
Near desktop
H C C H F CF H H
07:30
Call from
At location
Near device
Day 2
Context:
………..
do(accept_call(Call_Id, From), T ) ← T ≥ 07:30
Revised policy
do(accept_call(Call_Id, From), T ) ← T ≥ 07:30 ∧ in_group(From, college)
do(accept_call(Call_Id, From), T ) ← T ≥ 07:30 ∧ ¬holdsAt(location(Imperial)), T )

14. An experiment: the reality mining dataset
• modeh(accept(+date, +time, +contact, +volume, +vibrator, +battery_level, +screen_brightness, +headset, +screen_status, +light_level, +battery_charging)).
1
• modeb(=(+contact, #contact), [no_ground_constants, name(c)]). 200
• modeb(=(+volume, #volume), [no_ground_constants, name(vol)]). 20
• modeb(=(+vibrator, #vibrator), [no_ground_constants, name(vib)]). 20
• modeb(=(+battery_level, #battery_level), [no_ground_constants, name(bl)]).200
• modeb(=(+screen_brightness, #screen_brightness), [no_ground_constants, name(scb)]). 20
• modeb(=(+headset, #headset), [no_ground_constants, name(hs)]). 20
• modeb(=(+screen_status, #screen_status), [no_ground_constants, name(ss)]). 20
• modeb(=(+light_level, #light_level), [no_ground_constants, name(ll)]).
• modeb(=(+battery_charging, #battery_charging), [no_ground_constants, name(bc)]). 200
• modeb(weekday(+date)). 2(Positive, Negative)
• modeb(weekend(+date)). 2
• modeb(evening(+time)). 2
• modeb(morning(+time)). 2
• modeb(afternoon(+time)). 2
• modeb(in_call(+date, +time)). 2
• modeb(at(+date, +time, #cell)). 200
• modeb(nearDevice(+date, +time, #device)). 2000
• modeb(neighbourhood(+cell, #cell)). 200
• modeb(user_been_in(+date, +time, +cell)). 2
• modeb(user_is_active(+date, +time)). 2
• modeb(phone_charging(+date, +time)). 2
• modeb(phone_on(+date, +time)). 2
• modeb(user_is_using_app(+date, +time, #app)). 20
• modeb(time_before_h(+time, #hour), [no_ground_constants,name(before)]). 100
• modeb(time_after_h(+time, #hour), [no_ground_constants,name(after)]). 100
Input: Reality mining dataset – single users
Output: Rules able to predict when the user answers phone calls
Battery_level ~ 102
Contacts ~ 101
Devices ~ 103
Cells ~ 102
Date x Time ~ 103
Other options ~ 10
Cell tower
Bluetooth
devices
Activity
Coverage
Abstractions +
Domain
Knowledge
Calls
answer_call(…) IF condition1,1, …,
conditionmax_c,1
Around 5000
choices for
condition

15. Policy Learning
• Using Inductive Logic Programming we are able to reverse
engineer a set of rules from a set of multi-criteria decisions.
• Rules are efficient and can be used to explain decisions made.
• Rules can be manually amended and user familiarity with the
learnt rules can be preserved.
• This allows us to:
• Automate manual decisions.
• Replace legacy implementations with
configurable rule based components.

16. Detecting and Diagnosing Malicious
Data Injections in WSN

17. Towards Real-Time Systems

18. A building full of sensors
• Compromised sensors
can be used to inject
false values
• To elicit fake events
• To mask real ones
• To amplify and reduce
real ones.
• For short term or long
term effects.
• Given some redundancy between the information provided by
sensors can we detect injections?
• Can we distinguish from faults?

19. Consider physiological sensors

20. Masking attack outcome

21. • Wide variety of sensor network
topologies, deployments and signals.
• Different causes for anomalies:
transient failures, common mode
failures, malicious intervention
• Compromised sensors will collude.
• Attacks can vary in sophistication e.g.,
modify existing signals, synthesize
new ones, undermine genuine sensors
• Existing work is mostly:
• Bespoke to a sensor type or deployment
• Evaluated against trivial attacks
The problem is difficult because …
Fire alarms
monitoring
Volcano
monitoring
Medical
Sensors

22. Results
• Physiological sensors: detection and
characterisation (dc) up to 50% of compromised
sensors, maj. voting fails with any percentage
• Fire Alarms: dc up to 47%, maj. voting detects 7%
(0% FP), 13% (13% FP), no detection when >20%
but 27% FP.
• Monitoring Volcano Eruptions: dc up to 88%, maj.
voting up to 25% with (25% FP)
• Now looking at multiple simultaneous events

23. Multiple events: US Seismic Vibrations
Requirements:
• Identification of event-related trends
• Evaluation of overall measurements anomalousness (DETECTION)
• Identification of false trends (given by colluding sensors)
especially with multiple events (CHARACTERISATION)
• Analysis of anomalies root cause (DIAGNOSIS)
GENUINE
MALICIOUS

24. Detection Criterion: Cross Scale
Comparison
Small Genuine
Event
Large Genuine
Event
Low scale coefficients increase with High scale coefficients: measurements
increase/decrease faster in the presence of events

25. Seismic Vibrations Experiments
Elicited Elicited
Masked True Event Single Fault

26. Future Work and Lessons learnt
• Good results obtained on test data. We would like further
validation and extend to multi-mode correlations.
• We are designing new models to compute maximum
tolerance to compromised sensors given redundancy.
• Broad range of sophistication of the attacks possible.
Most research uses very simplistic models.
• How do we systematically test for sophisticated attacks?
• Can adversary poison data from which we learn?
Adversarial anomaly detection?

27. Dynamic Bayesian
Analysis of Attack Graphs

28. Attack Graph Modelling
• Attack Graphs model paths of compromise
from the network topology and
vulnerability analysis.
• Static Measures of Exposure e.g.,
• mean path to compromise of target objective.
• degree of exposure of sub-systems

29. Dynamic Analysis
• A Bayesian representation of the graph allows to represent
the combined effect of vulnerabilities to compromise a node
in the system.
• Dynamic inference enables us to calculate the combined
probability that an attacker can compromise a node
considering the attack graph and symptoms of compromise.
• We can then reason about:
• The possible next steps of an attack based on system vulnerability.
• Likely missing information (zero day) or failures in detection
• The effect of any remedial measure
• In enterprise networks graphs can be huge as often each
host can reach across the network to any other.

30. Results: Exact and approx. inference
Static Analysis Dynamic Analysis

31. Future Work and Lessons Learnt
• Can attack graphs be used to model compromise across
the physical space? Combined physical and digital?
Combined physical, digital and human?
• There are perhaps less problems of scalability in the
physical space (fewer adjacent nodes).
• In such cases inference can be applied at run-time to
analyse risk and determine most appropriate
countermeasures.
• Could also be able to measure time to compromise.

32. Retrofitting Security

33. What would we need to retrofit?
• Many embedded systems e.g.,
ICS have very long lifetimes.
• Protocols: proprietary, vary
from standard specification,
code/knowledge not available.
• Can we model the protocol
from observation? And
sometimes partial knowledge.
• Then insert additional
(protection) functions

34. Approaches
• Host-based
• Message format inference
• State machine inference
• Fuzzing
• Network-based
• Message format inference
• State machine inferences

35. Conclusions
• Rules can be learnt with ILP, allowing to combine the
advantages of rule-based systems, user involvement, and
auditable decisions.
• Compromised sensors can be used in more sophisticated ways
than currently considered. How do we systematically test for
such attacks?
• We need to develop models to jointly analyse and reason
about the physical, human and digital space and their inter-
dependencies. Several CS techniques may be applicable.
• We need to figure out ways in which to learn how legacy
systems operate in order to add security.
• The PETRAS IoT Hub brings together with 9 leading UK
academic institutions and around 60 public and private sector
partners around the general challenges of IoT security

36. • … Thank you !
If you have any questions please contact Emil Lupu:
e.c.lupu@imperial.ac.uk