Abstract
Attempting to educate practitioners of computer security can be difficult if for no other reason than the breadth of knowledge required today. The security profession includes widely diverse subfields including cryptography, network architectures, programming, programming languages, design, coding practices, software testing, pattern recognition, economic analysis, and even human psychology. While an individual may choose to specialize in one of these more narrow elements, there is a pressing need for practitioners that have a solid understanding of the unifying principles of the whole. We created the Playground network simulation tool and used it in the instruction of a network security course to graduate students. This tool was created for three specific purposes. First, it provides simulation sufficiently powerful to permit rigorous study of desired principles while simultaneously reducing or eliminating unnecessary and distracting complexities. Second, it permitted the students to rapidly prototype a suite of security protocols and mechanisms. Finally, with equal rapidity, the students were able to develop attacks against the protocols that they themselves had created. Based on our own observations and student reviews, we believe that these three features combine to create a powerful pedagogical tool that provides students with a significant amount of breadth and intense emotional connection to computer security in a single semester.
Keywords:
Acknowledgements
Thanks to Katie Chang for her help with the literature search and to the various Network Security classes for their willingness to be guinea pigs.
Notes
No potential conflict of interest was reported by the author.
1 Permitting students to send each other this kind of code is obviously dangerous. As stated in the related work section, we run these Playground experiments in virtual machines.
2 The message definition mechanism shown here was not exactly the same in the initial release of Playground. Although similar, it was slightly more complicated and less intuitive. This much better version was implemented for the Fall 2016 course.
3 The data types shown in the examples, e.g. STRING, UINT2, and so forth, are defined by the framework. They are not Python types.
4 Finally in fall 2016, our students actually proposed their transport layer with cryptographically enforced, mutual authentication.