IN2178 Security Engineering

Prof. Alexander Pretschner

LS XXII Chair for Software Engineering
SoSe 2017
IN2178 Security Engineering
1 Introduction

Prof. Alexander Pretschner

LS XXII Chair for Software Engineering
SoSe 2017
I22: Software Engineering
Headed by Prof. Alexander Pretschner

Research focus: Accountability, Testing, Software Protection, Security.

Teaching:

https://www22.in.tum.de/lehre/

Numerous projects in information securitytalk to us!

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 3

Instructors
Lectures:

Prof. Alexander Pretschner, [email protected]

Sprechstunde Friday 1pm (please make an appointment with Frau
Fichtl)

Exercises:

Alei Salem, [email protected]

Lecture material available on moodle.

News and course information are also posted on moodle.

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 4

Organization
Lectures in Interimhrsaal 1 on Mondays from 12:15 13:45.

Exercises in Interimhrsaal 2 on Thursdays from 16:15 17:45.

Examination: written exam.

Ask questions! Language egal!

You receive exercises on Thursday, solutions discussed the following

week.

We cannot force you to do the exercises. However, they will prepare you
for the exam (and hopefully you will learn a lot by doing them).

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 5

Scheduling Issues
Holidays:

Monday, May 1st, 2017: May 1st

THEREFORE: Extra class in IHS 2 on April 27th@1615.
Thursday, May 25th 2017: Ascension Day
Monday, June 5th, 2017: Whit Monday
Thursday, June 15th, 2017: Corpus Christi

Check the moodle page/email for any change in the schedule.

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 6

Overview of todays lecture
What is security?

What is security engineering?

Overview of the class.

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 7

Goal of todays lecture
Get a deeper understanding of what security engineering is all about.

Understand what makes it so difficult.

See how security relates to other SW engineering activities.

Get an idea of what we will learn.

Come back next week!

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 8

Security Properties: CIA
Confidentiality
Can non-authorized parties see data?

Integrity
Has data been altered (and I should know this)?

Availability
Is data always accessible?

of data, and then of the systems that process data (including humans).
This distinction is nice, but in practice not clear-cut

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 9

More Security Properties
Non-repudiation
Impossibility to inappropriately deny a transaction or having sent a
message.
Auditability
Ability to reconstruct (certain aspects of) earlier states of a system
Accountability
Ability to hold an entity responsible for its actions. This is related to
non-repudiation and auditability
Privacy
No clear definition. Refers to security of personal information. Privacy
means that a person has appropriate control over which information
on him or her is generated, stored, processed, and deleted, and by
whom.
Anonymity
The identity of an entity is hidden; an aspect of privacy

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 10

Does it matter?
Private data
Medical records
Loyalty cards
Mobile telephone data including location
Commercial data
DRM
IP in distributed business processes
Government data
Military data
Intelligence

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 11

Relevance and Challenges
New security-sensitive applications
eVoting, car2car communication, internet banking and payment, DRM,

Security technologies are enablers and drivers
Fight against
Vulnerabilities, vulnerabilities, vulnerabilities, ....
Increasing threats and potential damages
Potential cyber crime, hooliganism, terrorism
National interests and secret services
Privacy issues
Lack of standards; lack of products/solutions
Lack of understanding

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 12

Relevance: Known incidents/vulnerabilities
We have seen all kinds of attacks and serious vulnerabilities in the wild,
increasingly over the years! Think of:

Shellshock: late 2014.

Heartbleed 2014: 60% of the internet under threat!!
NSA 2013: E. Snowden revealed espionage on citizens and governments
Sony 2011: Playstation network, private data of millions of user stolen
Stuxnet 2010: Attack to particular critical infrastructure using Siemens PLCs
Political statements constantly made by Anonymous:
DoS against commercial banking and governmental sites
Zeus malware: world-scale cyber-crime operation
Etc..

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 13

Yet ...
Do we really want security?
Makes systems hard or slow to use (and hence is circumvented)
How much is it, and who pays?
Whats the risk, really?

Is security a subproblem of risk analysis?

Different kinds of systems: your website, the universitys student records,
fresh water supply IT, weapons

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 14

Yet...
Do we really want privacy?
Trade-off with users liberties
Waive privacy for a cheese burger?
Do you use facebook?
I have nothing to hide
Whats the risk, really?

Trade-off between interests of individuals and society

Terrorism
Who pays for privacy?

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 15

What to do?
Technically
Software and Systems Engineering
Cryptography
Physical at macro-level: access to buildings, secured areas (like computer
centers), shielding against electromagnetic radiation, etc.
Physical at micro-level: e.g. tamper-resistant devices, smart-cards
Biometric technology
Processor technology
Language security
Operating system security
Organizationally
Security policies, classification of information, defining responsibilities, etc.
People-related
Selection, motivation, education, etc.
Legally
Liability regulations, insurances, etc.

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 16

Humans in the loop
Social Engineering
Dont hack system; hack people

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 17

Humans in the loop
Social Engineering
Dont hack system; hack people
Impersonating IT staff
Playing on users' sympathy
Using intimidation tactics
Shoulder surfing

On a broad scale (internet banking data), and for single companies:

spear phishing

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 18

...and system vulnerabilities
Password Management Flaws
Weak passwords
Passwords easily accesible
Heavy re-use of passwords
Fundamental Operating System Design Flaws
Default permit policies
Race conditions
Software Bugs
Security holes as consequence of flawed design or implementation
Unchecked User Input
Buffer overflow attacks
SQL injections
Badly set-up and managed IT infrastructures that combine the above

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 19

OWASP Top 10 Vulnerabilities 2013

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 20

OWASP Top 10 Vulnerabilities 2013

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 21

Vulnerabilities over the years

https://web.nvd.nist.gov/view/vuln/statistics
Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 22
Security Engineering
Security Engineering = Software Engineering + Information Security
Software Engineering is the application of systematic, quantifiable
approaches to the development, operation, and maintenance of software;
i.e., the application of engineering to software.
Information Security focuses on methods and technologies to reduce risks
to Information Assets.
More refined (adopted from Anderson, Security Engineering)
Security Engineering is about building systems that remain
dependable in the face of malice, error, or mischance. As a discipline,
it focuses on the tools, processes, and methods needed to design,
implement, test, and evolve systems.
Security Engineering is not a mature discipline yet!

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 23

Security Engineering and Complexity

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 24

How to build a secure system?
Secure Development Lifecycles (SDL)

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 25

Touchpoints McGraw

Source: Gary McGraw, Software Security

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 26

Microsoft SDL

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 27

Agile?
Well have to discuss this!

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 28

Security and safety?
Safety considered in the realm of traditional software engineering
=> Goal is to avoid harm of people and infrastructures.

Is there anything special about security?

Safety: Is about the system doing harm to its environment.

Failures materialize as a consequence of normal and abnormal
operations that are potentially stochastic processes.

Security: Is about the environment doing harm to the system.

Failures materialize as a consequence of a malicious entity whose main
objective is to trigger the failure, or as a consequence of humans making
mistakes.

Is this a fundamental difference?

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 30
Safety and Security Fundamentally Different?
Many think so. I dont. One conjecture (to be proved or disproved) is that a
community of hackers can be modeled as a stochastic process, too. And I
believe that security fundamentally is a subdiscipline of risk analysis. There
is no 100% security.

That is, that there can be insurances for computer security: insurances
are based on probabilities and expected losses (see insurances for
physical safes)

See the plethora of incident lists that classify vulnerabilities and sometimes
their occurrences (www.cert.org, www.osvdb.org, http://nvd.nist.gov )

Well learn about the detection of vulnerabilities (and countermeasures

against respective threats) in this class

We will also introduce/recall aspects from classical safety and discuss their
relation to the security of distributed systems.
Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 31
Safety and Security
Yet, even if there might not be a fundamental difference, there is a lot of
domain knowledge to be gained
writing code for a washing machine also is not fundamentally different
from writing code for an autopilot or a tax report software or a spreadsheet
But experience matters

Will security one day become a quantitative science?

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 32

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 33

Overview of the entire class (caveat!)

Fundamentals of Information Security

Requirements Eng.

Design

Implementation

V&V

Op&Maintenance

Risk Assessment and Management

Evaluation Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 34

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 35

Security Requirements; Design
Misuse cases and attack trees; comparison with classical
analysis techniques from safety analysis
Software Design
Patterns such as Policy Enforcement Points/Policy Decision
Points; Security Monitors
Systems Design
Patterns such as demilitarized zones; Security Monitors

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 36

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 37

Access and Usage Control
Govern access to and usage of data
Authentication, authorization, audit
Discretionary access control, mandatory access control
Conceptually and technically:
models, architectures, hardware
Multilevel security
Bell LaPadula: no read-up; no write-down
(integrity and confidentiality)
Biba (integrity only) Windows Vista
Multilateral security: Chinese Wall Policies

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 38

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 39

Time permitting
Block chains
Bitcoin

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 40

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 41

Privacy

Are there friends around me?

(Location-based services, FourSquare, Tinder).

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 42

Privacy

D Obvious solution:

Send both
coordinates to
trusted central server
and let decide

What about privacy?

Can we do better?

Are there friends around me?

(Location-based services, FourSquare, Tinder).

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 43

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 44

Implementation-level Security
SQL injections
SELECT fieldlist FROM table WHERE field = '$EMAIL';
Set $EMAIL = anything' OR 'x'='x
which yields
SELECT fieldlist FROM table WHERE field = ' anything' OR 'x'='x ';
Cross-site scripting
Buffer-overflow attacks
Overwrite return addresses

How to implement software protection? (i.e. DRM)

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 45

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 46

Information Flow
A priest is new in town. His first confessor is a murderer. At a
party, the priest meets Bob and tells him that, what a city, his first
confessor was a murderer. Bob later meets Charlie, and Charlie
tells him that he really likes the priest, and that he was the first to
confess with him.
What is information flow?
Explicit flow: data flow
Implicit flow: branching over secrets
Covert channels
Heat, CPU cycles consumed, time,
Will formalize and apply this notion:
the models of Goguen-Meseguer and Rushby

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 47

Information Flow II: Explicit Flow

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 48

Implicit Information Flow

cond1 |isrich

cond1 |taxdisc

monitor also untaken branch!

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 49

Security Testing
Vulnerability scanners
Constructing test cases for web apps
OWASP testing guide
Security reviews for systems and code

http://www.owasp.org/index.php/Category:OWASP_Project

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 50

Overview of the entire class
Security Requirements
Security Requirements
Threat modeling
Security Design
Security Design Principles
Access and Usage Control
(Advanced) Cryptographic schemes/technologies
Privacy enhancing technologies
Security vs. Usability
Secure Implementation and Software Protection
Implementation Issues
Software Protection
Security Testing
Non-interference and information slow
Static and dynamic analysis and testing
Risk Analysis
Evaluation Criteria: The Common Criteria

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 51

Risk Analysis and Assessment
100% security is
Unrealistic (nothing is 100% in life)
Too expensive
How safe is a (physical) safe?
How can we prioritize security goals and countermeasures
so that we get just right security?
And does this really make sense?
Can we re-use knowledge on prior system analyses to
analyze our own system?
Vulnerability catalogs
BSI baseline protection

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 52

What we want you to learn
Get the fundamental concepts of information security.

Know about the fundamental security problems at different stages of the

software engineering lifecycle.

Be able to embed security within your systems from early stages of

design/development.

Understand theres more than

1: code
2: improve and fix
3: goto 1

Know about the most common technologies, tools, catalogs, information

resources to help build secure, dependable systems.

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 53

What we want you to learn
Moreover we encourage you to think critically.

Come to the lecture and participate.

Go to tutorials and discuss.

Feel free to challenge what we say.

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 54

Want to focus more on ... ?
Cryptography (i7) Prof. Esparza Cryptography (WiSe)

Network Security (i8) Prof. Carle Network Security (WiSe)

P2P Systems (i8) Prof. Carle Peer-to-Peer Systems and Security

(SoSe)

Security in mobile systems (i20) Prof. Eckert Sichere Mobile

Systeme (SoSe) auf Deutsch

Different Topics in IT Security (i20) Prof. Eckert IT Sicherheit (WiSe)

auf Deutsch

Hands-on hacking experience Various labs/seminars at the TUM

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 55

Security at i22
We are also passionate about security:

Secure coding, Android security, software integrity

protection, security testing,

Check our website: www22.in.tum.de

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 56

Conclusions
Security is about protecting C-I-A (and NR)
Sometimes nasty, but an indispensable enabler and driver
Software Engineering is about building, maintaining, and managing
huge software systems
Security Engineering combines both
In this class, well look into
Fundamentals of information security
Security flaws and countermeasures during different activities of the
software development process
See you next week!

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 57

Literature

Ross Anderson, Security Engineering, 2nd ed. Wiley, 2008

A recommended source for everybody:

http://www.cl.cam.ac.uk/~rja14/book.html

Prof. Alexander Pretschner (I22) | Security Engineering | SoSe 2017 58