Software Security

Riccardo Scandariato
Institute of Software Security, TUHH, Germany
scanda***to @ tuhh.de

Master Course “Software Security”

Winter Semester 22/23
Course Objectives
“Teaching future developers to avoid critical security
vulnerabilities”

• Help you avoid unforgivable vulnerabilities in the code

you write
https://cwe.mitre.org/documents/unforgivable_vulns/unforgivable.pdf

• Examine major causes for software vulnerabilities

• Examine the techniques to identify software
vulnerabilities
• Examine current practices for addressing these
problems (avoid and/or fix)

2
3
About me
Call me Riccardo (no prof needed)

Head of the Institute of Software Security

Italian, 47, in HH since 2020

4
More MSc courses in SoSe (with me!)
• Secure Software Engineering
“Training future software project managers to set
up a sound security program”

• Cybersecurity Data Science

“Use the potential of machine learning to address
complex cybersecurity challenges”

5
Share your opinion
Go to menti.com – XXXX YYYY

• My program
– CS
– IIW
– ICS
– Other

6
Share your opinion
Go to menti.com – XXXX YYYY

• My prior courses in security

– 0
– 1
– 2 or more

7
Security and privacy objectives
Learning objectives
• Recap some some basic security concepts

9
Security & Reliability
• Reliability deals with accidental failures
– Failures are assumed to occur according to some given
probability distribution
• The probabilities for failures is given first, then the
protection mechanisms are constructed
• To make software more reliable, it is tested against
typical usage patterns:
– “It does not matter how many bugs there are, it matters
how often they are triggered”

10
Security & Reliability
• In security, the defender has to move first; the
attacker picks inputs to exploit weak defences
• To make software more secure, it has to be tested
against “untypical” usage patterns (but there are
typical attack patterns)

• In the Internet, hostile parties can provide input

• Do not “trust” your inputs

11
Security is about assets
Security = Protection of asset from harm

CIAA = confidentiality, integrity, availability, accountability

Assets - Examples
• Hardware: laptops, servers, routers, PDAs, mobile
phones, smart cards, …
• Software: applications, operating systems, database
systems, source code, object code, …
• Data & information: essential data for running and
planning your business, design plans, digital
content, data about customers, …
• Revenue from services
• Reputation of enterprise, customers‘ trust, brand
name
• Employees’ time

13
Damage / harm
• Disclosure of information, espionage
• Modification of data
• Being unable to do your job because required
resources are not available
• Identity spoofing (identity “theft”)
• Unauthorised access to services
• Lost revenue
• Damaged reputation
• Theft of equipment (CPU time)
• …
14
Share your opinion
Share your opinion
Go to menti.com – XXXX YYYY

Let’s identify the security objectives

Transaction > Account Balance >

Manager
App
Bank
Customer
Bank’s
Database
Confidentiality
• Prevent unauthorised disclosure of information
(prevent unauthorised reading)
– Preventing unauthorized parties from knowing (read) the
information
– Or even hiding the existence of information (see privacy)
• Secrecy: protection of data belonging to an organisation
• Historically, security and secrecy were closely related;
security and confidentiality are sometimes used as
synonyms

Example: “Credit card information of customer cannot be revealed”

17
Integrity
• Prevent unauthorised modification of information
(prevent unauthorised writing)
• Data Integrity – The state that exists when
computerized data is the same as that in the source
document and has not been exposed to accidental or
malicious alteration or destruction
– Detection (and correction) of intentional and
accidental modifications of transmitted/stored data
• Application integrity - preserving the correct
computational state

18
Availability
• The property of being accessible and usable upon
demand by an authorised entity
– Resources (info or services) can be used by authorized parties
that need them, within given time constraints (deadline)
– Service is correct (close to trustworthiness)
• Denial of Service (DoS): prevention of authorised access
of resources or the delaying of time-critical operations
• Very important aspect of computer security, but few
methods are around
• Distributed denial of service (DDoS) received a lot of
attention; systems are now designed to be more
resilient against these attacks
19
Accountability
• At the operating system level, audit logs record
security relevant events and the user identities
associated with these events
• If the link between a user (person) and a “user
identity” (e.g., user ID) can be established, the user
can be held accountable

• In distributed systems, cryptographic non-repudiation

mechanisms can be used to achieve the same goal

20
Non-repudiation
• Non-repudiation services provide unforgeable evidence
that a specific action occurred
• Non-repudiation of origin: protects against a sender of
data denying that data was sent (see authenticity)
• Non-repudiation of delivery: protects against a receiver
of data denying that data was received

• Danger – imprecise language: has mail been received

when it is delivered to your mailbox?

21
Authenticity
• The property that data originated from its
purported source (NIST glossary)

– Source: person, machine, server, app, …

– Focus: authentic origin

• Related to non-repudiation

22
Questions ?
More questions at a later time?

ric***do . scanda***to @ tuhh.de

Software Security
Learning objectives
• Contextualize this course in secure software
engineering

25
Secure Development Life-Cycle (SDL)
• Security is not an add-on feature
• You don’t write software and then make it “secure” by
adding a few security features (authentication, etc)
• You don’t write software and then make it “secure” by
removing vulnerabilities either (buffer overflow, etc)
• Security is an ongoing concern throughout the software
life cycle
– Security requirements, Secure design, Secure
development – deployment – maintenance (patching,
new releases, …)
27
Secure Development Life-Cycle (SDL)

Erik Poll, https://www.cs.ru.nl/E.Poll/ss/slides/1_Introduction.pdf

29
MSc course „Secure Software Engineering“

• Course in the Summer Semester ☺

• Beyond coding-related aspects

(focus of this course)

• Security requirements
• Secure design
• Security metrics
• Risk assessment…
30
Focus of this course
• We focus on the implementation (code!)

• Understand / avoid sw vulnerabilities

• Find vulnerabilities (static/dynamic testing)

33
Questions ?
More questions at a later time?

ric***do . scanda***to @ tuhh.de

Course structure and rules
Kudos
We warmly thank Prof. Dieter Gollmann (ret.)
for letting for sharing his slides!

We warmly thank Catherine Tony and Cuong

Bui Quang for the preparation of the labs

36
Feedback
Provide feedback on the course
(during the course!!!)
• I don’t expect everything to work well ;)

• Don’t be angry, share your opinion !

At the end, I will invite you to an anonymous

online survey
• 10 min of your time

• Very important for me

37
„Don’t try it at home“
• We intend to give code examples but will not
teach you how to write worms and viruses :)
• Distributing code that performs actions on other
peoples machines is likely to get you in conflict
with the law
• Experimenting with dangerous code at home is
dangerous
• Anti-virus researchers learned at their own
expense the importance to physically separate
experimental from operational systems

38
 Lectures and structure
Blocks Lectures

Intro W01 - Intro to Software Security

W02 - Software vulnerabilities
Low-level W03 - Low-level software security I
W04 - Low-level software security II
W05 - Low-level vulnerabilites defense
Web app sec W06 - Injection
W07 - XSS
W08 - CSRF and Timing attack
Identify W09 - Static Application Security Testing (SAST)
vulnerabilities W10 - Dynamic Application Security Testing (DAST)
W11 - Design-level weaknesses Must attend for study
(see later)
Fix and avoid W12 - Automatic vulnerability repair
W13 - API usage and secure programming
Outro W14 - Preparation for exam and feedback

39
Books Exam is based on slides / lectures / labs

• Mark G. Graff & Kenneth R. van Wyk: Secure

Coding, O’Reilly, 2003
• Gary McGraw: Exploiting Software: How to Break
Code, Addison-Wesley, February 2004
• Michael Howard & David LeBlanc: Writing Secure
Code, Microsoft Press, 2nd edition, 2002
• John Viega & Gary McGraw: Building Secure
Software, Addison-Wesley, 2001

Articles mentioned in each lecture

40
Wiki on Stud.IP
Contains the list of lectures and labs

Link to draft slides of the lectures

• Replaced by final PPT/PDF after the lecture,
which is the study material for the exam

Videos
• Last year: SAST, DAST

• This year: will try to record the missing sessions

41
Stud.IP
Files on Stud.IP
• Slides

• Lab assignments

• Lab solutions

Announcements on Stud.IP
• The way we (TAs, me) communicate with you

for management issues

42
 I do not answer messages on Stud.IP
Always forward as email !!!
I must be able to see your full name in the mail !

Say what course the

mail is about !

43
Lab infos J
• 2 fantastic TAs: Cuong, Torge
• Bring your own laptop

• Material in the exercises is relevant for the

exam

• +5 bonus points, in memory for 2 exam sessions

– We track attendance (only for the bonus!)
– You can skip only 1 lab (no questions asked)
– Bonus valid if the exam is above the “pass” threshold

44
Lab sessions 1/2
• Week 1 – No lab
• Week 2 – Tutorial on Docker
– October 26 (Wed), 9:45-11:15,
Room H-0.07 (40 seats)
– October 27 (Thu), 11:30-13:00,
Room D-0.010 (28 seats)
• Week 3 – No lab

45
Lab sessions 2/2
Week Date Topic

W04 Nov 9-10 Buffer overflow

W05 Nov 16-17 Format string attacks

W06 Nov 23-24 Buffer overflow and format string defenses

W07 Nov 30-Dec 1 SQL injection

W08 Dec 7-8 XSS

W09 Dec 14-15 Timing attacks

W10 Dec 21-22 SAST

W11 Jan 11-12 DAST

W12 Jan 18-19

Study – Design-level weaknesses
W13 Jan 25-26

W14 Feb 1-2 APR

46
Study
We will ask you to volunteer in an empirical study
on security weaknesses in design
• Security inspection of an application

(micro-services)

Motivation
• Investigate helpfulness of architectural diagram

Idea
• Virtual assistant for secure development tasks

47
Study
Informed consent

One class

Two lab sessions

(turn in your results, fill in a questionnaire)

No penalties if you do not participate

(counts as 1 skip)

More info will come !

48
Questions ?
More questions at a later time?

ric***do . scanda***to @ tuhh.de