TRU/e

Software Security, Autumn 2019

This course is taught by Erik Poll. It is part of the TRU/e Master specialisation in Cyber Security. More background on goals, prerequisites, etc. at the bottom of this web page.

Make sure you are registered in Osiris, which will then also register you in Brightspace. Beware that there is a 6EC version (ISOFSE) and a . (IMC051) of this course. Only register for the 5 EC version if you are doing the TRU/e Cyber Security specialisation.

If you somehow cannot register for the course (yet), send me an email, so that I can make sure email announcements via Brightspace reach you!

Lectures & obligatory reading material

Lectures: Fridays 10:30-12:15 in lecture room 00.28 in Mercator I.

NB the description below will be updated as we go along, with slides and pointers to papers. The obligatory reading material and exam material for the course includes the slides, some academic research papers listed below, and the following textbook material:

day slides Mandatory reading
Sept 6
Sept 13
Sept 20
1st assignment (individual or in pairs): PREfast. Deadline: Oct 3 Generic feedback on typical problems
Sept 27
Group fuzzing project. Deadline: Dec 1
Oct 4
Oct 11
  • Guest Lecture on pen-testing & red-teaming by Geert Smelt of Secura
Oct 18 To read:
Oct 25 & Nov 1 : no lectures (midterm break/exam period)
Nov 8
Nov 15
Nov 22
Nov 29
2nd individual/pair project (6EC version only). Deadline: December 12 Generic feedback on typical problems

Dec 6
Dec 13
Dec 20
Jan 24 Exam - 12:45-15:45 in LIN 4 - lecture room 4 in the Linneaus building, or HG00.108 for students with extra time; but always double-check this on rooster.ru.nl The exam is closed book, and covers the material treated in class (and in the slides), the course lecture notes, the papers listed above, and the projects.
Mock exam

Prerequisites

Basic programming skills, incl. familiarity with C and Java. In more detail:

Topics

Software is the root cause behind most IT security problems. This course addresses two questions: Common security problems include memory corruption, integer overflows, various injection attacks (command injection, SQL injection, XSS, deserialisation attacks ...), race conditions... The LangSec paradigm explains some of these underlying root causes, namely buggy or unintended parsing of many input languages, which are often too complex, too expressive, or ill-specified.

Techniques to prevent or detect problems include threat modeling, checklists and coding standards, code reviews, "safe" programming languages, LangSec (language-theoretic security), fuzzing and other forms of security testing, static analysis tools and source code analyzers, information flow analysis (incl. tainting), program verification, and proof-carrying code.

The focus of this course is not on pen-testing or hacking to find vulnerabilities, as in the RU bachelor courses 'Hacking in C' and 'Web Security', but more on (addressing) the underlying causes and general techniques to improve the security of software.

Grading

The course will be graded based on a written exam and project work: two smaller individual projects (C++ code analysis with PREfast, and program verification with ESC/Java) and a bigger group projects looking at fuzzing and static analysis for web applications.

You MUST seriously participate in the project work to take the exam, and do all individual exercises. Final grade will be based on the exam (50%) and results on the projects (where project grades are weighed: 10% individual project(s), 40% group project), but you MUST pass the exam to pass the course.

The exam will cover the material presented in the lectures, the obligatory literature listed below, and the project work. The exam is closed book, ie. you cannot bring copies of slides, papers etc to the exam. You're not expected to be able to reproduce technical details from the papers, but you should be able to explain the core ideas. I will only ask about technical details from the papers that have been discussed in the lectures (and are covered by the slides). You are expected to be able to spot simple buffer overflow problems given some hints, but are not expected to spot tricky ones even with hints.

Optional background reading

For additional background info I can recommend: