Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sensors, threats, responses and challenges - Dr Emil Lupu (Imperial College London)

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Sensors, threats, responses and challenges - Dr Emil Lupu (Imperial College London)

  1. 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
  2. 2. Exposing the physical world to cyber threats
  3. 3. Protection agents or attack vectors?
  4. 4. Less obvious paths to compromise
  5. 5. Policy-Based Systems
  6. 6. How to configure, personalise and automate? Vision Mobile IoT Megatrends 2016
  7. 7. 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
  8. 8. 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
  9. 9. … 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
  10. 10. 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.
  11. 11. 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
  12. 12. 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 )
  13. 13. 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
  14. 14. 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.
  15. 15. Detecting and Diagnosing Malicious Data Injections in WSN
  16. 16. Towards Real-Time Systems
  17. 17. 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?
  18. 18. Consider physiological sensors
  19. 19. Masking attack outcome
  20. 20. • 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. Seismic Vibrations Experiments Elicited Elicited Masked True Event Single Fault
  25. 25. 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?
  26. 26. Dynamic Bayesian Analysis of Attack Graphs
  27. 27. 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
  28. 28. 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.
  29. 29. Results: Exact and approx. inference Static Analysis Dynamic Analysis
  30. 30. 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.
  31. 31. Retrofitting Security
  32. 32. 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
  33. 33. Approaches • Host-based • Message format inference • State machine inference • Fuzzing • Network-based • Message format inference • State machine inferences
  34. 34. 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
  35. 35. • … Thank you ! If you have any questions please contact Emil Lupu: e.c.lupu@imperial.ac.uk

×