Engaging Students in theDevelopment of Cyber SecurityPracticalsPractical Security Exercises for Computer Science Undergraduateshttps://www.cs.york.ac.uk/cyber-practicals/

Howard Chivers

hrchivers@theiet.org

admin@cyber-practicals.uk

James Brunton

jrwb502@york.ac.uk

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