Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Engineering Software Diversity: a Model-Based Approach to Systematically Diversify Communications

50701825ddf1417b97e8a63e1322d1af?s=47 Brice Morin
October 18, 2018

Engineering Software Diversity: a Model-Based Approach to Systematically Diversify Communications

Automated diversity is a promising mean of increasing the security of software systems. However, current automated diversity techniques operate at the bottom of the software stack (operating system and compiler), yielding a limited amount of diversity. We present a novel Model-Driven Engineering approach to the diversification of communicating systems, building on abstraction, model transformations and code generation. This approach generates significant amounts of diversity with a low overhead, and addresses a large number of communicating systems, including small communicating devices.


Brice Morin

October 18, 2018

More Decks by Brice Morin

Other Decks in Research


  1. Engineering Software Diversity: a Model-Based Approach to Systematically Diversity Communications

    Brice Morin, Jakob Høgenes and Hui Song (SINTEF Digital, Oslo, Norway) Nicolas Harrand and Benoit Baudry (KTH, Stockholm, Sweden)
  2. Diversity… Really?! 2 "Mass-produced" software == Very large monocultures

  3. 3 Microsoft's implementation of SMB Could have been mitigated with

    more diversity: a) different implem of SMB, b) other protocols
  4. 4 Diversity-Stability hypothesis: Increased diversity  increased resilience Red Queen

    hypothesis: Continued adaptation & evolution  sustainability Diversity in space Diversity in time
  5. Diversity in communications 5 • Few different protocols (HTTP/REST, MQTT,

    WS, etc) • Few different programming languages, for which stubs needs to be implemented • Many different serializations (binary, JSON, XML), in theory ∞
  6. A simple non-diversified protocol 6 m1(a, b, c, d, e)

    m2(a, b, c) m3(a) Repeat 100 times:
  7. 7 Non-diversified network traffic m1 m2 m3 m1 m2 m3

    m1 m2 m3 m1 m2 m3m1 m2 m3
  8. Where ThingML helps diversity (though not for communications ) •

    By default, generate code for C/C++, Java, JavaScript, Go  2w-to-2mo to support a new language (1k-10k LoC) • By default, can communicate through MQTT, WS, UDP, etc  2h-to-2d to support a new protocol (100- 1k LoC) Where ThingML support diversity in communications (though very limited by default) • By default, generate 2 (de)serializers (for each supported language) • Binary à la Google Protocol Buffer and JSON 20min-to-2h to write a new (de)serializer (10-1k LoC) • What if you have 1M users and want unique serializations? 40y-to-240y  +10M-1B LoC to be maintained… 8 MDE to Diversify Communications
  9. Approach Overview 9 ThingML Model Core Core Serial Proto Serial

    Proto ThingML Model Diversified
  10. 10

  11. Shuffle parameters 11 payload[2] payload[3] payload[1]

  12. Shuffle message definition 12

  13. Duplicate messages 13

  14. Split messages 14

  15. All at once? 15

  16. 16

  17. Measuring diversity in space 17

  18. Measuring diversity in time 18

  19. What's the overhead? 19

  20. Conclusion • Systematic diversification • A perfect use case for

    MDE! • We applied MDE to the diversification of communications • Significant diversity can be introduced automatically • No overhead at design-time: just specify your API, we take care of the rest • Runtime Overhead is compatible with "mass-produced" software/firmware 20
  21. Question? 21 https://github.com/SINTEF-9012/thingml-diversifier https://github.com/modelsconf2018/artifact-evaluation/tree/master/morin See https://github.com/TelluIoT/ThingML @bm0rin brice-morin

  22. Teknologi for et bedre samfunn

  23. Is that diversity useful? • Note: based on further experiments,

    not to be found in the paper 24
  24. 25

  25. 26