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
1
Goal and Objectives
Goal: New approaches for computer
security education
Objective 1: To prepare
students to design,
implement, and test
secure software
Student-centered
learning
2
Objective 2: A holistic
platform for constructing
computer security course
projects
Professor-centered
platform
From CSSE Students to
Software Engineers
• To produce reliable,
robust, secure software.
• To work in interdisciplinary
teams.
• To use appropriate design
notations, such as UML.
• To work in multiple
programming languages.
3
Challenges
Student-Centered Learning
Secure
Software
How to provide engaging
computer security projects?
Design
Must we teach students how
to design secure software?
4
Teamwork
What projects can help
students to learn about
teamwork?
Programming
How to teach multiple
programming languages?
Challenges
Professor-Centered Platform
Preparation
Flexibility
How to quickly prepare
engaging computer security
projects?
What projects can be
tailored to students to learn
about teamwork?
Teaching
How to teach computer
security projects?
5
Grading
What is a good way to grade
computer security projects?
Teaching Philosophy
Computer security education should focus on:
• Fundamental security principles
• Security-practice skills.
6
Motivation
College
Principles
Security principles:
• Fundamental
• A wide spectrum.
Industry
Practice
Laboratory exercises:
• Observing
• Evaluating
• Testing
Course projects:
• Analyzing
• Designing
• Programming
7
small-scale, fragmented, and
isolated course projects
Real-World
Systems and Apps
Real-world secure
computing systems:
• Programming
standards
• Large scale
• Work on existing
products
Our Solution:
Application-Oriented Approach
Security Sensitive Applications
User Interface
Security Module 1
Security Module n Non-Security Modules
OS (Windows, Linux, etc.)
8
Security Modules
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
9
A Unified Programming
Environment
Security Sensitive Applications
User Interface
Security Module 1
Security Module n Non-Security Modules
Virtual Machine
(e.g. vmware, virtualBox)
OS (Windows, Linux, etc.)
10
Flexibility
Levels of Difficulty
•
– Beginner
– Intermediate
– Advanced
Objective 1: To prepare
students to design,
implement, and test
secure software
Student-centered
learning
11
Objective 2: A holistic
platform for constructing
computer security course
projects
Professor-centered
platform
Flexibility
How Modules Are Packaged
Beginner
Easy
12
Intermediate
Moderate
Advanced
Hard
Explorative
Basic Understand
Of Concepts
Depth
Understanding Of
Concept
Light Editing
Normal
Implementation
Advanced
Implementation
Types of Course Projects
• Explorative based projects.
• Partial Implementation projects.
• Full Implementations projects.
Beginner
Intermediate
Advanced
• Vulnerability testing, attacking, and fixing.
• Hybrid labs (Exploration & Implementation,
etc.)
13
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.
14
Banking Application
• Toy Application
– A Secure Teller Terminal System
– ATM
• Documentations
– Design
– Test Cases
– Makefile
– Readme
15
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
16
Data Encryption
Module
Integrity
Checking
Access Control List
IPSec
Buffer
overflow
In
Attack Lab
Workflow
A professor’s perspective
Teach Concept
System Setup
Choose Apps &
Difficulty
Design Survey Questions
Generate Project Description
Work On Project
Evaluation/Feedback
17
Design Docs &
Partial Code
Design Document
Example: Data Flow – High Level
18
Put It All Together
An example
A Banking System
User Interface
Access Control
Encryption
IPSec
Non-Security Modules
Virtual Machine
(e.g. vmware, virtualBox)
OS (Windows, Linux, etc.)
19
Class Diagram
A secure teller terminal system
20
Intermediate
Class Diagram
A secure teller terminal system
No security modules in
the design document
(e.g., class diagram)
21
Advanced
An Encrypted Staff File
Beginner
Easy
Explorative
Light Editing
22
Beginner
Beginner
An Unencrypted Staff File
Beginner
Easy
Explorative
Light Editing
23
Encryption Modules
• Transposition - good, low-level encryption
algorithm.
• Substitution - good, low-level encryption
algorithm.
• Put both of them together – A
transposition of a substitution.
24
Access Control
• Role-based system.
• Implemented in a separate module.
• Give students data flow diagram.
25
Access Control
• Students implement Access Control
module.
• Allows them to insert in existing system.
• Better real world experience.
26
Choose a Course to Test Our
Approach
Security Courses
Introduction to
Computer Security
• Introductory-level
• Programming
experiences
• Small-scale projects
work
27
Advanced
Computer Security
• Research projects
• Examples
• Memory attacks
• Parallel Antivirus
• Testing
Other Courses
e.g., Software
Construction
• No design experience
• New programming
language
• Weak programming
skill
• Teach/learn basic
security concepts
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
28
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
29
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
30
Implementation
46%
>21h
Entire Project
40% >30h
Evaluation Results (2)
Survey: The project instructions were clear.
(1) Strongly disagree (2) Disagree (3) Neutral (4) Agree
(5) Strongly agree
31
Teller terminal system
Cryptographic system
69%: agree or strongly agree
58%: agree or strongly agree
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
32
Teller terminal system
Cryptographic system
61%: somewhat difficult or
very difficult
53%: somewhat difficult or
very difficult
Evaluation Results (4)
Survey: What was the level of interest in this project?
(1)
1. Very low
high
(2) Low
(3) Average
(4) High
(5) Very
Teller terminal system
Cryptographic system
58%: Average, High, or very high
85%: Average, High, or very high
33
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
Cryptographic system
44%: Use cases
58%: Testing
34
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
35 17%:
Cryptographic system
strongly disagree or disagree 20%: strongly disagree or disagree
Evaluation Results (7)
Survey: Overall, I have attained the learning objectives
of the project.
Teller terminal system
• 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
36 user-friendly application.
Cryptographic system
• learn two cryptographic
algorithms;
• develop a simple
cryptographic tool;
• perform separate
compilation; and
• to develop a commandline application.
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
37
Teller terminal system
Cryptographic system
52%: strongly agree or agree
65%: strongly agree or agree
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
38
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
39
Xiao Qin: xqin@auburn.edu
40
Demo & Examples
41
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
42