An Application-Oriented Approach for Computer Security Education

1. An Application-Oriented Approach for Computer Security Education Xiao Qin Department of Computer Science and Software Engineering Auburn University Email: xqin@auburn.edu URL: http://www.eng.auburn.edu/~xqin

2. Objective 1:To prepare students to design, implement, and test secure software Objective 2:A holistic platform for constructing computer security course projects Professor-centered platform Student-centered learning Goal and Objectives Goal: New approaches for computer security education

3. From CSSE Students toSoftware Engineers • To produce reliable, robust, secure software. • To work in interdisciplinary teams. • To use appropriate design notations, such as UML. • To work in multipleprogramming languages.

4. Challenges Student-Centered Learning Secure Software Teamwork What projects can help students to learn about teamwork? How to provide engaging computer security projects? Design Programming How to teach multiple programming languages? Must we teach students how to design secure software?

5. Challenges Professor-Centered Platform Flexibility Preparation What projects can be tailored to students to learn about teamwork? How to quickly prepare engaging computer security projects? Grading Teaching What is a good way to grade computer security projects? How to teach computer security projects?

6. Teaching Philosophy • Computer security education should focus on: • Fundamental security principles • Security-practice skills.

7. Motivation College Industry Real-World Systems and Apps Principles Practice • Security principles: • Fundamental • A wide spectrum. • Laboratory exercises: • Observing • Evaluating • Testing • Real-world secure • computing systems: • Programming • standards • Large scale • Work on existing • products • Course projects: • Analyzing • Designing • Programming small-scale, fragmented, and isolated course projects

8. Our Solution:Application-Oriented Approach Security Sensitive Applications User Interface Non-Security Modules Security Module 1 Security Module n OS (Windows, Linux, etc.) Security Modules

9. Considerations • Security modules: related to fundamental security principles. • Applications: represent real world scenario(s) • Each application: contains all possible security modules. • Flexibility: difficulty levels are configurable. • Programming environment: easy setup • Hints for students: data structures and algorithms

10. A Unified Programming Environment Security Sensitive Applications User Interface Non-Security Modules Security Module n Security Module 1 Virtual Machine (e.g. vmware, virtualBox) OS (Windows, Linux, etc.)

11. Flexibility Professor-centered platform Student-centered learning Objective 1:To prepare students to design, implement, and test secure software Objective 2:A holistic platform for constructing computer security course projects • Levels of Difficulty • Beginner • Intermediate • Advanced

12. FlexibilityHow Modules Are Packaged Beginner Easy Intermediate Moderate Advanced Hard Explorative Basic Understand Of Concepts Depth Understanding Of Concept Light Editing Normal Implementation Advanced Implementation

13. Types of Course Projects Beginner • Explorative based projects. • Partial Implementation projects. • Full Implementations projects. • Vulnerability testing, attacking, and fixing. • Hybrid labs (Exploration & Implementation, etc.) Intermediate Advanced

14. Choose the First Application • Real World Scenarios • Banking System: Implemented • P2P File-Sharing: future work • Three RAs worked on this project • Strategy 1: each RA design and implement a security sensitive application • Strategy 2: three RAs collaborate on a single application.

15. Banking Application • Toy Application • A Secure Teller Terminal System • ATM • Documentations • Design • Test Cases • Makefile • Readme

16. Implementation Projects Banking Application Existing Components Students’ Tasks • Properties of these projects: • Focused on targeted principles • Focused on a single application • Each project takes 2-6 weeks • Difficulties can be adjusted Data Encryption Module Integrity Checking Buffer overflow Access Control List IPSec In Attack Lab

17. WorkflowA professor’s perspective System Setup Teach Concept Choose Apps & Difficulty Design Docs & Partial Code Design Survey Questions Generate Project Description Work On Project Evaluation/Feedback

18. Design DocumentExample: Data Flow – High Level

19. Put It All Together An example A Banking System User Interface Non-Security Modules Access Control Encryption IPSec Virtual Machine (e.g. vmware, virtualBox) OS (Windows, Linux, etc.)

20. Class Diagram A secure teller terminal system Intermediate

21. Class Diagram A secure teller terminal system Advanced No security modules in the design document (e.g., class diagram)

22. An Encrypted Staff File Beginner Easy Explorative Light Editing Beginner

23. An Unencrypted Staff File Beginner Easy Explorative Light Editing Beginner

24. Encryption Modules Transposition - good, low-level encryption algorithm. Substitution - good, low-level encryption algorithm. Put both of them together – A transposition of a substitution.

25. Access Control • Role-based system. • Implemented in a separate module. • Give students data flow diagram.

26. Access Control Students implement Access Control module. Allows them to insert in existing system. Better real world experience.

27. e.g., Software Construction Advanced Computer Security • No design experience • New programming • language • Weak programming • skill • Teach/learn basic • security concepts • Research projects • Examples • Memory attacks • Parallel Antivirus • Testing Choose a Course to Test Our Approach Security Courses Other Courses Introduction to Computer Security • Introductory-level • Programming • experiences • Small-scale projects • work

28. Comp 2710 Software Construction • Two projects • A secure teller terminal system: access control • A cryptographic system: two algorithms • 57 students (CSSE and ECE) • Computer Science • Software Engineering • Electrical Engineering • Wireless Engineering

29. Preliminary Studies • Survey Questionnaires • The quality of project design • Students’ evaluation on projects: • How interested they are • Programming background • Whether the labs spark their interests in security • How many hours they spent on the projects • Participants: • 48 students for project 1 • 53 students for project 2

30. Evaluation Results (1) Survey: Approximately, how many hours did you spend on the project? (1) ≤ 5 hours (2) 6-10 hours (3) 11-20 hours (4) 21-30 hours (5) > 30 hours Design 81% <10h Implementation 46% >21h Entire Project 40% >30h

31. Evaluation Results (2) Survey: The project instructions were clear. (1) Strongly disagree (2) Disagree (3) Neutral (4) Agree (5) Strongly agree Teller terminal system 69%: agree or strongly agree Cryptographic system 58%: agree or strongly agree

32. Evaluation Results (3) Survey: What was the level of difficulty of this project? (1) Very easy (2) Somewhat easy (3) Average (4) Somewhat difficult (5) Very difficult Teller terminal system 61%: somewhat difficult or very difficult Cryptographic system 53%: somewhat difficult or very difficult

33. Evaluation Results (4) Survey: What was the level of interest in this project? 1.  (1) Very low (2) Low (3) Average (4) High (5) Very high Teller terminal system 58%: Average, High, or very high Cryptographic system 85%: Average, High, or very high

34. Evaluation Results (5) Survey: What was the most time consuming part of in the design portion of the project? (1) Use Cases (2) Class Diagram (3) System Sequence Diagram (4) Testing Teller terminal system 44%: Use cases Cryptographic system 58%: Testing

35. Evaluation Results (6) Survey: As a result of the lab, I am more interested in computer security. (1) Strongly disagree (2) Disagree (3) Neutral (4) Agree (5) Strongly agree Teller terminal system 17%: strongly disagree or disagree Cryptographic system 20%: strongly disagree or disagree

36. develop a non-trivial application using classes, constructors, vectors, and operator overloading; learn a security issue – authentication; perform object-oriented analysis, design, and testing; and develop a reasonably user-friendly application. learn two cryptographic algorithms; develop a simple cryptographic tool; perform separate compilation; and to develop a command-line application. Evaluation Results (7) Survey: Overall, I have attained the learning objectives of the project. Teller terminal system Cryptographic system

37. Evaluation Results (7 cont.) Survey: Overall, I have attained the learning objectives of the project. (1) Strongly disagree (2) Disagree (3) Neutral (4) Agree (5) Strongly agree Teller terminal system 52%: strongly agree or agree Cryptographic system 65%: strongly agree or agree

38. About the QoSec Project • Funded by the NSF CCLI Program • Phase I ($150K) was funded in 2009 • 1 PI and 4 Research Assistants • Alfred Nelson • Andrew Pitchford • John Barton • Web pages of the project will be available soon: • http://www.eng.auburn.edu/~xqin

39. Plan and Collaborations • Prepare for an NSF TUES Phase II Project • Four to six universities involved • 10 Pis • More tool applications • More preliminary results • Evidence for collaborations • Contact me if you are interested in • this NSF CCLI Phase I project or • our future NSF TUES Phase II project Xiao Qin: xqin@auburn.edu

41. Demo & Examples

42. Questions? • If you are interested in information regarding this project, add your name to our newsletter list after this discussion. http://www.eng.auburn.edu/~xqin • Slides are available at http://www.slideshare.net/xqin74