Dilemma and Design CSM27 Computer Security Dr Hans Georg Schaathun - - PowerPoint PPT Presentation

Dilemma and Design

CSM27 Computer Security Dr Hans Georg Schaathun

University of Surrey

Autumn 2007

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 1 / 30

The session

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 2 / 30

The session

Session objectives

Realise how difficult security is. Realise how easy security is. Consider some general design decisions which have to be made Understand how (much) security depends on both software features, physical features, and organisational structure and policy.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 3 / 30

Security Design

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 4 / 30

Security Design Security and Simplicity

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 5 / 30

Security Design Security and Simplicity

How difficult is security?

Which is the most challenging?

Building a secure system? Securing a built system?

Why?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 6 / 30

Security Design Security and Simplicity

How difficult is security?

Which is the most challenging?

Building a secure system? Securing a built system?

Why?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 6 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Patchwork security

Security added as an afterthought. Existing, insecure system is extremely complex. Reverse-engineering to find flaws. Many flaws found only upon attack.

Security experts on their heels Patching holes as they are exploited

System too complex to understand

Trial-and-Error

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 7 / 30

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Only add secure features. Default is always ‘access denied’.

Access given when demonstrateably necessary. Need-to-know policy

Security is maintained during the design and building.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 8 / 30

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Only add secure features. Default is always ‘access denied’.

Access given when demonstrateably necessary. Need-to-know policy

Security is maintained during the design and building.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 8 / 30

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Only add secure features. Default is always ‘access denied’.

Access given when demonstrateably necessary. Need-to-know policy

Security is maintained during the design and building.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 8 / 30

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Only add secure features. Default is always ‘access denied’.

Access given when demonstrateably necessary. Need-to-know policy

Security is maintained during the design and building.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 8 / 30

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Only add secure features. Default is always ‘access denied’.

Access given when demonstrateably necessary. Need-to-know policy

Security is maintained during the design and building.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 8 / 30

Security Design Security and Simplicity

Adding features to the box

Feature-oriented design

Users must be able to add data

Security-oriented design

Authorised users and nobody else must be able to add data.

We only add features if we can maintain security

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 9 / 30

Security Design Security and Simplicity

Adding features to the box

Feature-oriented design

Users must be able to add data

Security-oriented design

Authorised users and nobody else must be able to add data.

We only add features if we can maintain security

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 9 / 30

Security Design Security and Simplicity

Adding features to the box

Feature-oriented design

Users must be able to add data

Security-oriented design

Authorised users and nobody else must be able to add data.

We only add features if we can maintain security

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 9 / 30

Security Design The fundamental dilemma

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 10 / 30

Security Design The fundamental dilemma

Product and System

Product is a software package designed for general use in a variety of systems. System is a specific IT installation, with a particular purpose and

• perational environment.

A secure product can be deployed insecurily in a system. A system can incorporate non-standard security requirements of a particular application. Secure products can be mass-produced

Security affects many users.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 11 / 30

Security Design The fundamental dilemma

The fundamental dilemma

The users

Require security No security expertise

The expert

Security expertise Unfamiliar of the application and local requirements

Who can capture the local security requirements?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 12 / 30

Security Design The fundamental dilemma

The fundamental dilemma

The users

Require security No security expertise

The expert

Security expertise Unfamiliar of the application and local requirements

Who can capture the local security requirements?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 12 / 30

Security Design The fundamental dilemma

Security Policy

Security Policy Objective A statement of intent to protect an identified resource from unauthorised use. maybe add, from unauthorised modification, and ensure availability. Organisational Security Policy The laws, rules, and practices regulating how an organisation manages, protects, and distributes resources to achieve specified security policy

• bjectives.

Automated Security Policy Set of restrictions and properties that specify how a computing system prevents information and computing resources from being used to violate an

• rganisational security policy.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 13 / 30

Security Design The fundamental dilemma

Security Policy

Security Policy Objective A statement of intent to protect an identified resource from unauthorised use. maybe add, from unauthorised modification, and ensure availability. Organisational Security Policy The laws, rules, and practices regulating how an organisation manages, protects, and distributes resources to achieve specified security policy

• bjectives.

Automated Security Policy Set of restrictions and properties that specify how a computing system prevents information and computing resources from being used to violate an

• rganisational security policy.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 13 / 30

Security Design The fundamental dilemma

Security Policy

Security Policy Objective A statement of intent to protect an identified resource from unauthorised use. maybe add, from unauthorised modification, and ensure availability. Organisational Security Policy The laws, rules, and practices regulating how an organisation manages, protects, and distributes resources to achieve specified security policy

• bjectives.

Automated Security Policy Set of restrictions and properties that specify how a computing system prevents information and computing resources from being used to violate an

• rganisational security policy.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 13 / 30

Security Design The fundamental dilemma

Security Policy

Security Policy Objective A statement of intent to protect an identified resource from unauthorised use. maybe add, from unauthorised modification, and ensure availability. Organisational Security Policy The laws, rules, and practices regulating how an organisation manages, protects, and distributes resources to achieve specified security policy

• bjectives.

Automated Security Policy Set of restrictions and properties that specify how a computing system prevents information and computing resources from being used to violate an

• rganisational security policy.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 13 / 30

Security Design The fundamental dilemma

Scope of the Security Policy

The organisational security policy

aims to secure the resources of the organisation not limited to software, hardware or security the users are part of the system

The automated security policy

• ne of the means to implement the organisational security policy

limited to software and hardware

Organisation and management

contributes to security privileges must be assigned intelligently privileged users must use their rights correctly.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 14 / 30

Security Design The fundamental dilemma

Scope of the Security Policy

The organisational security policy

aims to secure the resources of the organisation not limited to software, hardware or security the users are part of the system

The automated security policy

• ne of the means to implement the organisational security policy

limited to software and hardware

Organisation and management

contributes to security privileges must be assigned intelligently privileged users must use their rights correctly.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 14 / 30

Security Design The fundamental dilemma

Scope of the Security Policy

The organisational security policy

aims to secure the resources of the organisation not limited to software, hardware or security the users are part of the system

The automated security policy

• ne of the means to implement the organisational security policy

limited to software and hardware

Organisation and management

contributes to security privileges must be assigned intelligently privileged users must use their rights correctly.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 14 / 30

Security Design Design Decisions

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 15 / 30

Security Design Design Decisions

Five design decisions

1

What do you control? Users, data, or operations?

2

Where do you work on the Man-Machine scale?

3

Simple and secure, or complex and feature-rich?

4

Central or local policy-makers?

5

How do you prevent attackers from circumventing protection using a lower layer?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 16 / 30

Security Design Design Decisions

What do you control?

Data Define well-formated/legal data. Ensure internal consistens Not access control Operations Specify legal operations Which users are authorised? Which data can be operated on? Users Specify authorisation for each user. Which data can be observed? Which data can be altered?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 17 / 30

Security Design Design Decisions

Centralised or decentralised?

Who assigns usernames and passwords?

IT-Services (university-wide); school/faculty;

• r department?

Who desides access permissions for individual files?

Owner? Central policy maker?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 18 / 30

Security Design Design Decisions

The Man-Machine Scale

✬ ✫ ✩ ✪

applications

✬ ✫ ✩ ✪

services

✬ ✫ ✩ ✪

• perating

system

✗ ✖ ✔ ✕

OS kernel

✞ ✝ ☎ ✆

hardware

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 19 / 30

Security Design Design Decisions

The security perimeter

Castle walls No breakdown outside the perimeter matters An attack is dangerous when it appears inside the security perimeter. Every protection mechanism defines a security perimeter.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 20 / 30

Security Design Design Decisions

Vulnerabilities in lower layers

Vulnerable to attacks inside the security perimeter. Example A user with hardware access boots computer from a removable medium, mounts the harddrive, and replaces the password file as superuser. The box should only boot from the authorised harddrive. Example The users removes the hardrive and connects it to a different computer to replace the password file as superuser.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 21 / 30

Security Design Design Decisions

Vulnerabilities in lower layers

Vulnerable to attacks inside the security perimeter. Example A user with hardware access boots computer from a removable medium, mounts the harddrive, and replaces the password file as superuser. The box should only boot from the authorised harddrive. Example The users removes the hardrive and connects it to a different computer to replace the password file as superuser.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 21 / 30

Security Design Design Decisions

Vulnerabilities in lower layers

Vulnerable to attacks inside the security perimeter. Example A user with hardware access boots computer from a removable medium, mounts the harddrive, and replaces the password file as superuser. The box should only boot from the authorised harddrive. Example The users removes the hardrive and connects it to a different computer to replace the password file as superuser.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 21 / 30

Security Design Design Decisions

Vulnerabilities in lower layers

Vulnerable to attacks inside the security perimeter. Example A user with hardware access boots computer from a removable medium, mounts the harddrive, and replaces the password file as superuser. The box should only boot from the authorised harddrive. Example The users removes the hardrive and connects it to a different computer to replace the password file as superuser.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 21 / 30

Security Design Design Decisions

The Man-Machine Perimeters

The onion model might have been drawn like this.

✬ ✫ ✩ ✪

hardware

✬ ✫ ✩ ✪

OS kernel

✬ ✫ ✩ ✪

• perating system

✤ ✣ ✜ ✢

services

✗ ✖ ✔ ✕

applications

✞ ✝ ☎ ✆

user The user remains a vulnerability. Bribery, blackmail, extortions.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 22 / 30

Attack trees

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 23 / 30

Attack trees Attack trees

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 24 / 30

Attack trees Attack trees

The get password threat

Get Password Guess Password On-line Off-line Encrypted passwords Dictionary attack Ask Operator Impersonate user Bribe Spy Password Camera Microphone

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 25 / 30

Attack trees Attack trees

Different threats

Password Compromised Integrity Web pages PR Marks Confidentiality Teaching Exam papers Student files Research Availability Web PR Staff info Email

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 26 / 30

Attack trees Attack trees

Attack tree

Attack trees can clarify vulnerabilities or threats

highlight relations

Think of possible controls when you study the attack tree

Can we control an entire subtree with a single measure?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 27 / 30

Attack trees Exercises

Outline

1

The session

2

Security Design Security and Simplicity The fundamental dilemma Design Decisions

3

Attack trees Attack trees Exercises

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 28 / 30

Attack trees Exercises

Discussion Exercise

[Gollmann 1.6] Consider the theft of a central server from the university or faculty. Write down all the assets which could be jeopardised by such a theft. Construct an attack tree for this threat.

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 29 / 30

Attack trees Exercises

Discussion Exercise (2)

[Gollmann 2.7] Discuss: is a good graphical user interface an appropriate criterion for purchasing a security product?

Dr Hans Georg Schaathun Dilemma and Design Autumn 2007 30 / 30