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.

Transcript

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
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
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