Embed Size (px)
Citation preview
Engaging Students in theDevelopment of Cyber SecurityPracticalsPractical Security Exercises for Computer Science Undergraduateshttps://www.cs.york.ac.uk/cyber-practicals/
Howard Chivers
James Brunton
Content
Cyber-Practicals
Practical (Lab) exercises to integrate security teaching intothe Computer Science undergraduate syllabus.
Content:Content:
• The purpose, and products.
• The development process, and lessons learned.
• A student-developer view.
2
Problem
Graduate Computer Scientists do not have the knowledge andskills to avoid basic system & software security errors.
“... systems... typically contain well-known errors...fuelling ...the need to developcybersecurity knowledge and skills ...”
3
How to engage & challenge students in the cyber security?
How to help subject experts embed security aspects in teaching?
Government is responding with help, and also pressure oncourses, including via BCS/IET accreditation.
Help with Specialised Content.
Develop Practical Security Exercises for Undergraduate Teaching.
• Solve one of the difficult and expensive barriers for subject lecturers.
• Supplement existing course material and modules.
• Allow lecturers to maintain distinctive courses and teaching whileadding security elements.
Security Best Practice is embedded, not an (optional) add-on.• Security Best Practice is embedded, not an (optional) add-on.
• Aimed at general computer science (not security specialist) topics inyears 1, 2.
1-year project funded by the Higher Education Academy.
https://www.heacademy.ac.uk/disciplines/stem/cyber-security/learning-and-teaching-cyber-security-2015-2017-projects
4
Practicals Now Available
SQL Injection& prepared queries
Database Inferenceflexibility v privacy
Cross-site Scripting& user input filtering
Exploiting Errorsmanaging exceptions
Exploiting Softwareprotection errors &
compiler protections
Digital Forensics& secure deletion
5
Password Storageresisting offline attacks
Random Numberspitfalls in generator
selection and use
Information Leakagequantifying sidechannels
Cryptography & Integritypoor use of strong primitives
Encryption Modesinformation v data
https://www.cs.york.ac.uk/cyber-practicals/
Delivery Package
• Each practical is hosted in its own virtual machine.
• Provided as a fully automated source-install on a standard basemachine.
• The package includes:
• Webserver: worksheet, answer sheet, tools, papers.
Student Root: e.g. skeleton software solutions.• Student Root: e.g. skeleton software solutions.
• Webshell (run programs), Usermin (e.g. Manage/edit files).
• Standard Worksheet:
• Introduction – including learning outcomes.
• Main Exercises.
• Extension exercise.
• Conclusion – including assessment hooks.
6
Example – SQL Injection
Virtual Machine
Index Page
7
Worksheet
8
Webapp
9
Answers
Conclusion
10
The Project
• Student Engagement Encouraged by HEA.
• Originally focussed on requirements, management and pilot evaluation.
• Some interest in design (and useful suggestions) but much more interestin implementation.
• Resulted in a significant change to how the main phases were staffed.
11
Requirement Design Implement ReviewStudent
Other
Original
Final
Design
• Small but important student input
• The practicals should ‘fix’ security problems as well as expose them.
• Evidently more interest in implementation.
• Worksheet content and delivery package due toindustrial/academic input.industrial/academic input.
• Early sample practical produced as example for studentdevelopers.
• Allowed early samples to be provided to 4 other Universities forcomment, most feedback related to the delivery package.
• Possible list of exercises developed – 29 topics under 7 mainsubject headings.
12
Implementation
• 5 students employed as integrees for 9 weeks in the summer.
• Students selected their own tasks from the 29 suggested titles.
• Students implemented most experiments separately, with group’brainstorming’.
• There were two stages of student review:
• a ‘buddy’ for general peer review and initial evaluation,
• finished product was then reviewed more widely.
• ‘Management’ was enabling rather than direction; regular groupmeetings, plus 1:1 meetings for detailed technical discussion.
• There was a significant learning element, especially regarding best-practice security.
• Typically, each practical took 3 weeks to complete and review.
13
Review
• The finished practicals were instructive and interesting tostudents, but required an independent academic peer review:
• Build process consistency.
• Documentation consistency.
• Timing.
Academic context (learning outcomes, assessment hooks).• Academic context (learning outcomes, assessment hooks).
• Review and update cost was not insignificant – around 3 daysper practical.
14
Conclusion
• Use of student developers proved very effective:
• Added considerable imagination and creativity.
• Provided a significant learning opportunity for students(both security and development).
• Students were not just used as ‘a developer’ the plan wasadapted to provide:adapted to provide:
• Choice of work for students.
• Early exemplar of the final product.
• Continuous internal student review process.
• Academic peer review and update after completion.
15
A STUDENT VIEW
James Brunton
16
1. Choose a subject
2. Research the subject (for a week or so)
3. Break the subject down into layers
4. Brainstorm exercises for each layer
Creating the Practicals
5. Write the documentation and exercises
6. Write a second draft
7. Write a third draft being very conscious of time constraints
• Delete or expand exercises as necessary
8. Peer review and improve as many times as necessary (usually 2 or 3)
Each practical took about 3-4 weeks in total.
17
Removing Pain Points
Make the setup as easy as possible
18
QUESTIONS?
19
