Security Objectives and Design Information Security Management Dr - - PowerPoint PPT Presentation

Security Objectives and Design

Information Security Management Dr Hans Georg Schaathun

University of Surrey

Autumn 2010 – Week 2

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 1 / 54

The session

Outline

1

The session

2

Security Design

3

Perimeter Defences

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 2 / 54

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 the concept of security perimeters

1

Whitman and Mattord Ch. 2

2

‘Data-Centric Security’ IBM Whitepaper December 2006

3

Gollmann Ch. 2.2–2.6

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 3 / 54

Security Design

Outline

1

The session

2

Security Design Security and Simplicity Real Security Challenges CObIT

3

Perimeter Defences

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 4 / 54

Security Design Security and Simplicity

Outline

1

The session

2

Security Design Security and Simplicity Real Security Challenges CObIT

3

Perimeter Defences

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 5 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 6 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 6 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 7 / 54

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Add only 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 Security Objectives and Design Autumn 2010 – Week 2 8 / 54

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Add only 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 Security Objectives and Design Autumn 2010 – Week 2 8 / 54

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Add only 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 Security Objectives and Design Autumn 2010 – Week 2 8 / 54

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Add only 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 Security Objectives and Design Autumn 2010 – Week 2 8 / 54

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Add only 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 Security Objectives and Design Autumn 2010 – Week 2 8 / 54

Security Design Security and Simplicity

Secure design

No features ⇒ no security holes. Add only 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 Security Objectives and Design Autumn 2010 – Week 2 8 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 9 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 9 / 54

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 Security Objectives and Design Autumn 2010 – Week 2 9 / 54

Security Design Real Security Challenges

Outline

1

The session

2

Security Design Security and Simplicity Real Security Challenges CObIT

3

Perimeter Defences

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 10 / 54

Security Design Real Security Challenges

Question

If it is that simple, why are there so many security issues? Security was not prioritised when the system was built.

Now, it is a priority Too expensive to rebuild from scratch

Most developers are not trained for security

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 11 / 54

Security Design Real Security Challenges

Question

If it is that simple, why are there so many security issues? Security was not prioritised when the system was built.

Now, it is a priority Too expensive to rebuild from scratch

Most developers are not trained for security

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 11 / 54

Security Design Real Security Challenges

Question

If it is that simple, why are there so many security issues? Security was not prioritised when the system was built.

Now, it is a priority Too expensive to rebuild from scratch

Most developers are not trained for security

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 11 / 54

Security Design Real Security Challenges

Question

If it is that simple, why are there so many security issues? Security was not prioritised when the system was built.

Now, it is a priority Too expensive to rebuild from scratch

Most developers are not trained for security

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 11 / 54

Security Design Real Security Challenges

KISS

Keep it simple, stupid

What can we learn from the ideal design approach? When the task is to secure an existing, complex system? Consider simple components first

asset by asset – how can they be accessed? interface by interface – how can they be (ab)used? user by user – what can they do?

Analyse the composite sybsystems ...

when you understand the components fully

Throughout the module, look for ways to break the system or problem into smaller, simpler pieces.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 12 / 54

Security Design Real Security Challenges

KISS

Keep it simple, stupid

What can we learn from the ideal design approach? When the task is to secure an existing, complex system? Consider simple components first

asset by asset – how can they be accessed? interface by interface – how can they be (ab)used? user by user – what can they do?

Analyse the composite sybsystems ...

when you understand the components fully

Throughout the module, look for ways to break the system or problem into smaller, simpler pieces.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 12 / 54

Security Design Real Security Challenges

KISS

Keep it simple, stupid

What can we learn from the ideal design approach? When the task is to secure an existing, complex system? Consider simple components first

asset by asset – how can they be accessed? interface by interface – how can they be (ab)used? user by user – what can they do?

Analyse the composite sybsystems ...

when you understand the components fully

Throughout the module, look for ways to break the system or problem into smaller, simpler pieces.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 12 / 54

Security Design Real Security Challenges

KISS

Keep it simple, stupid

What can we learn from the ideal design approach? When the task is to secure an existing, complex system? Consider simple components first

asset by asset – how can they be accessed? interface by interface – how can they be (ab)used? user by user – what can they do?

Analyse the composite sybsystems ...

when you understand the components fully

Throughout the module, look for ways to break the system or problem into smaller, simpler pieces.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 12 / 54

Security Design Real Security Challenges

KISS

Keep it simple, stupid

What can we learn from the ideal design approach? When the task is to secure an existing, complex system? Consider simple components first

asset by asset – how can they be accessed? interface by interface – how can they be (ab)used? user by user – what can they do?

Analyse the composite sybsystems ...

when you understand the components fully

Throughout the module, look for ways to break the system or problem into smaller, simpler pieces.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 12 / 54

Security Design Real Security Challenges

On Eating an Elephant?

How do you eat an elephant? Take one little bit if more elephant, go to (1) Throughout the module, look for ways to cut bits off the elephant.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 13 / 54

Security Design Real Security Challenges

On Eating an Elephant?

How do you eat an elephant? Take one little bit if more elephant, go to (1) Throughout the module, look for ways to cut bits off the elephant.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 13 / 54

Security Design Real Security Challenges

On Eating an Elephant?

How do you eat an elephant? Take one little bit if more elephant, go to (1) Throughout the module, look for ways to cut bits off the elephant.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 13 / 54

Security Design Real Security Challenges

On Eating an Elephant?

How do you eat an elephant? Take one little bit if more elephant, go to (1) Throughout the module, look for ways to cut bits off the elephant.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 13 / 54

Security Design CObIT

Outline

1

The session

2

Security Design Security and Simplicity Real Security Challenges CObIT

3

Perimeter Defences

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 14 / 54

Security Design CObIT

The CObIT Information Criteria

Effectiveness Efficiency Confidentiality Integrity Availability Compliance Reliability

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 15 / 54

Security Design CObIT

Security is a means

CObIT — Control Objectives for IT The Information Criteria is more than security Security is a means to reaching objectives

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 16 / 54

Security Design CObIT

Security is a means

CObIT — Control Objectives for IT The Information Criteria is more than security Security is a means to reaching objectives

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 16 / 54

Security Design CObIT

Security is a means

CObIT — Control Objectives for IT The Information Criteria is more than security Security is a means to reaching objectives

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 16 / 54

Security Design CObIT

Effectiveness and Efficiency

Effectiveness relevance and suitability of information Information has to serve business processes accuracy, consistency and usability. Efficiency information with optimum use of resources minimise the cost of providing information and services

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 17 / 54

Security Design CObIT

The CIA Triad

Security Criteria

Confidentiality against unauthorised disclosure Integrity against unauthorised modification and falsification Availability for authorised users

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 18 / 54

Security Design CObIT

Compliance and Reliability

Compliance deals with the adherence to laws, regulations and rontractual agreements businesses need to obey the laws of the land stick to contracts with clients and suppliers

• bserve constent enforcement of own guidelines and

policies Reliability – Reliable Management Information appropriate information and metrics to support management of the organisation meta-information to allow management of the other criteria managing to meet requirements and make surplus

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 19 / 54

Perimeter Defences

Outline

1

The session

2

Security Design

3

Perimeter Defences City Walls The Man-Machine Scale The User End Product and System

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 20 / 54

Perimeter Defences City Walls

Outline

1

The session

2

Security Design

3

Perimeter Defences City Walls The Man-Machine Scale The User End Product and System

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 21 / 54

Perimeter Defences City Walls

Classic Security Measure

Walls protect the City Strict Access Control

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 22 / 54

Perimeter Defences City Walls

Trust within the City Walls

Whom do you have to trust under a wall-type defence? Whom do you protect against? Assumption A City Wall defence assumes

1

The enemy is outside the walls

2

We can trust anyone inside the walls

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 23 / 54

Perimeter Defences City Walls

Trust within the City Walls

Whom do you have to trust under a wall-type defence? Whom do you protect against? Assumption A City Wall defence assumes

1

The enemy is outside the walls

2

We can trust anyone inside the walls

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 23 / 54

Perimeter Defences City Walls

Security Perimeter

City Walls form a perimeter The perimeter defines the scope of the security mechanism Protection against threats originating outside the perimeter No protection againts inside threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 24 / 54

Perimeter Defences City Walls

Security Perimeter

City Walls form a perimeter The perimeter defines the scope of the security mechanism Protection against threats originating outside the perimeter No protection againts inside threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 24 / 54

Perimeter Defences City Walls

Security Perimeter

City Walls form a perimeter The perimeter defines the scope of the security mechanism Protection against threats originating outside the perimeter No protection againts inside threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 24 / 54

Perimeter Defences City Walls

Security Perimeter

City Walls form a perimeter The perimeter defines the scope of the security mechanism Protection against threats originating outside the perimeter No protection againts inside threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 24 / 54

Perimeter Defences City Walls

Perimeter Security

Perimeter Security (or Perimeter Defences) refer to

wall-like mechanisms protecting a large system/organisation ... like a city wall

Simple organisation:

concentrate all your resources on the perimeter maintain complete control of who and what is in the city

Other examples:

high-security buildings system-level access control fire-walls

Most data centres are secured this way

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 25 / 54

Perimeter Defences City Walls

Perimeter Security

Perimeter Security (or Perimeter Defences) refer to

wall-like mechanisms protecting a large system/organisation ... like a city wall

Simple organisation:

concentrate all your resources on the perimeter maintain complete control of who and what is in the city

Other examples:

high-security buildings system-level access control fire-walls

Most data centres are secured this way

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 25 / 54

Perimeter Defences City Walls

Perimeter Security

Perimeter Security (or Perimeter Defences) refer to

wall-like mechanisms protecting a large system/organisation ... like a city wall

Simple organisation:

concentrate all your resources on the perimeter maintain complete control of who and what is in the city

Other examples:

high-security buildings system-level access control fire-walls

Most data centres are secured this way

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 25 / 54

Perimeter Defences City Walls

Perimeter Security

Perimeter Security (or Perimeter Defences) refer to

wall-like mechanisms protecting a large system/organisation ... like a city wall

Simple organisation:

concentrate all your resources on the perimeter maintain complete control of who and what is in the city

Other examples:

high-security buildings system-level access control fire-walls

Most data centres are secured this way

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 25 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences City Walls

The fall of the wall

Why don’t modern cities have walls? Walls work very well when

1

you trust your insiders

large populations cannot be controlled ... complexity becomes overwhelming

2

you don’t want or need to deal with outsiders

why don’t we trust a Greek bearing gifts? the walls prevent trade

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 26 / 54

Perimeter Defences The Man-Machine Scale

Outline

1

The session

2

Security Design

3

Perimeter Defences City Walls The Man-Machine Scale The User End Product and System

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 27 / 54

Perimeter Defences The Man-Machine Scale

Security Perimeters

We discussed perimeters in terms of perimeter defences

let’s extend the concept of a perimeter

Every security control defines a perimeter

Abstract or Concrete perimeters

Only by recognising the perimeter can we understand

... which threats we control (outside) and which entities we have to trust (inside)

This will become clearer as we proceed Remember to look for the perimeters when we discuss controls ...

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 28 / 54

Perimeter Defences The Man-Machine Scale

Security Perimeters

We discussed perimeters in terms of perimeter defences

let’s extend the concept of a perimeter

Every security control defines a perimeter

Abstract or Concrete perimeters

Only by recognising the perimeter can we understand

... which threats we control (outside) and which entities we have to trust (inside)

This will become clearer as we proceed Remember to look for the perimeters when we discuss controls ...

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 28 / 54

Perimeter Defences The Man-Machine Scale

Security Perimeters

We discussed perimeters in terms of perimeter defences

let’s extend the concept of a perimeter

Every security control defines a perimeter

Abstract or Concrete perimeters

Only by recognising the perimeter can we understand

... which threats we control (outside) and which entities we have to trust (inside)

This will become clearer as we proceed Remember to look for the perimeters when we discuss controls ...

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 28 / 54

Perimeter Defences The Man-Machine Scale

Security Perimeters

We discussed perimeters in terms of perimeter defences

let’s extend the concept of a perimeter

Every security control defines a perimeter

Abstract or Concrete perimeters

Only by recognising the perimeter can we understand

... which threats we control (outside) and which entities we have to trust (inside)

This will become clearer as we proceed Remember to look for the perimeters when we discuss controls ...

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 28 / 54

Perimeter Defences The Man-Machine Scale

Security Perimeters

We discussed perimeters in terms of perimeter defences

let’s extend the concept of a perimeter

Every security control defines a perimeter

Abstract or Concrete perimeters

Only by recognising the perimeter can we understand

... which threats we control (outside) and which entities we have to trust (inside)

This will become clearer as we proceed Remember to look for the perimeters when we discuss controls ...

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 28 / 54

Perimeter Defences The Man-Machine Scale

Security Perimeters

We discussed perimeters in terms of perimeter defences

let’s extend the concept of a perimeter

Every security control defines a perimeter

Abstract or Concrete perimeters

Only by recognising the perimeter can we understand

... which threats we control (outside) and which entities we have to trust (inside)

This will become clearer as we proceed Remember to look for the perimeters when we discuss controls ...

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 28 / 54

Perimeter Defences The Man-Machine Scale

The Man-Machine Scale

✬ ✫ ✩ ✪

applications

✬ ✫ ✩ ✪

services

✬ ✫ ✩ ✪

• perating

system

✗ ✖ ✔ ✕

OS kernel

✞ ✝ ☎ ✆

hardware Where on the scale do you put your controls (perimeters)?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 29 / 54

Perimeter Defences The Man-Machine Scale

Example

Operating System Access Control

OS requires username and password

• n the console when the box boots
• n remote login

‘Where’ is the security perimeter? What is inside and what is outside? Perimeter defence between software and terminal (keyboard/screen)

software inside; user outside

No defence between software and core hardware (harddisk)

the perimeter is not closed!

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 30 / 54

Perimeter Defences The Man-Machine Scale

Example

Operating System Access Control

OS requires username and password

• n the console when the box boots
• n remote login

‘Where’ is the security perimeter? What is inside and what is outside? Perimeter defence between software and terminal (keyboard/screen)

software inside; user outside

No defence between software and core hardware (harddisk)

the perimeter is not closed!

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 30 / 54

Perimeter Defences The Man-Machine Scale

Example

Operating System Access Control

OS requires username and password

• n the console when the box boots
• n remote login

‘Where’ is the security perimeter? What is inside and what is outside? Perimeter defence between software and terminal (keyboard/screen)

software inside; user outside

No defence between software and core hardware (harddisk)

the perimeter is not closed!

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 30 / 54

Perimeter Defences The Man-Machine Scale

Example

Operating System Access Control

OS requires username and password

• n the console when the box boots
• n remote login

‘Where’ is the security perimeter? What is inside and what is outside? Perimeter defence between software and terminal (keyboard/screen)

software inside; user outside

No defence between software and core hardware (harddisk)

the perimeter is not closed!

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 30 / 54

Perimeter Defences The Man-Machine Scale

Example

Operating System Access Control

OS requires username and password

• n the console when the box boots
• n remote login

‘Where’ is the security perimeter? What is inside and what is outside? Perimeter defence between software and terminal (keyboard/screen)

software inside; user outside

No defence between software and core hardware (harddisk)

the perimeter is not closed!

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 30 / 54

Perimeter Defences The Man-Machine Scale

Perimeter Observation

Operating System Access Control

Multi-dimensional

there is a physical dimension – hardware there is a more abstract dimension – software

A user is outside the security perimeter

until a successful login

The OS surrounds the entire system in a software sense

attacks through software interfaces are prevented

The hardware is also inside the OS perimeter

but the OS does not control the hardware (except peripheral devices, like the terminal)

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 31 / 54

Perimeter Defences The Man-Machine Scale

Perimeter Observation

Operating System Access Control

Multi-dimensional

there is a physical dimension – hardware there is a more abstract dimension – software

A user is outside the security perimeter

until a successful login

The OS surrounds the entire system in a software sense

attacks through software interfaces are prevented

The hardware is also inside the OS perimeter

but the OS does not control the hardware (except peripheral devices, like the terminal)

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 31 / 54

Perimeter Defences The Man-Machine Scale

Perimeter Observation

Operating System Access Control

Multi-dimensional

there is a physical dimension – hardware there is a more abstract dimension – software

A user is outside the security perimeter

until a successful login

The OS surrounds the entire system in a software sense

attacks through software interfaces are prevented

The hardware is also inside the OS perimeter

but the OS does not control the hardware (except peripheral devices, like the terminal)

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 31 / 54

Perimeter Defences The Man-Machine Scale

Perimeter Observation

Operating System Access Control

Multi-dimensional

there is a physical dimension – hardware there is a more abstract dimension – software

A user is outside the security perimeter

until a successful login

The OS surrounds the entire system in a software sense

attacks through software interfaces are prevented

The hardware is also inside the OS perimeter

but the OS does not control the hardware (except peripheral devices, like the terminal)

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 31 / 54

Perimeter Defences The Man-Machine Scale

Vulnerabilities in lower layers

City walls can be flown over or dug under. The OS can control vulnerabilities in the software layers Hardware is a lower and therefore unprotected layer

we can dig under the defence, through hardware

Can you think of examples of how to dig under the OS access control?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 32 / 54

Perimeter Defences The Man-Machine Scale

Vulnerabilities in lower layers

City walls can be flown over or dug under. The OS can control vulnerabilities in the software layers Hardware is a lower and therefore unprotected layer

we can dig under the defence, through hardware

Can you think of examples of how to dig under the OS access control?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 32 / 54

Perimeter Defences The Man-Machine Scale

Vulnerabilities in lower layers

City walls can be flown over or dug under. The OS can control vulnerabilities in the software layers Hardware is a lower and therefore unprotected layer

we can dig under the defence, through hardware

Can you think of examples of how to dig under the OS access control?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 32 / 54

Perimeter Defences The Man-Machine Scale

Hardware attacks

Boot the box from a removable medium (USB stick)

mount the harddrive and edit the password as superuser

The box should only boot from the authorised harddrive. Remove the harddrive and mount it on a different box

replace the password file as superuser

Physical locks on the cabinet In both cases we run an unauthorised OS

with access to assets of the authorised OS

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 33 / 54

Perimeter Defences The Man-Machine Scale

Hardware attacks

Boot the box from a removable medium (USB stick)

mount the harddrive and edit the password as superuser

The box should only boot from the authorised harddrive. Remove the harddrive and mount it on a different box

replace the password file as superuser

Physical locks on the cabinet In both cases we run an unauthorised OS

with access to assets of the authorised OS

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 33 / 54

Perimeter Defences The Man-Machine Scale

Hardware attacks

Boot the box from a removable medium (USB stick)

mount the harddrive and edit the password as superuser

The box should only boot from the authorised harddrive. Remove the harddrive and mount it on a different box

replace the password file as superuser

Physical locks on the cabinet In both cases we run an unauthorised OS

with access to assets of the authorised OS

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 33 / 54

Perimeter Defences The Man-Machine Scale

Hardware attacks

Boot the box from a removable medium (USB stick)

mount the harddrive and edit the password as superuser

The box should only boot from the authorised harddrive. Remove the harddrive and mount it on a different box

replace the password file as superuser

Physical locks on the cabinet In both cases we run an unauthorised OS

with access to assets of the authorised OS

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 33 / 54

Perimeter Defences The Man-Machine Scale

Hardware attacks

Boot the box from a removable medium (USB stick)

mount the harddrive and edit the password as superuser

The box should only boot from the authorised harddrive. Remove the harddrive and mount it on a different box

replace the password file as superuser

Physical locks on the cabinet In both cases we run an unauthorised OS

with access to assets of the authorised OS

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 33 / 54

Perimeter Defences The User End

Outline

1

The session

2

Security Design

3

Perimeter Defences City Walls The Man-Machine Scale The User End Product and System

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 34 / 54

Perimeter Defences The User End

The Man-Machine Perimeters

The onion model might have been drawn like this.

✬ ✫ ✩ ✪

hardware

✬ ✫ ✩ ✪

OS kernel

✬ ✫ ✩ ✪

• perating system

✤ ✣ ✜ ✢

services

✗ ✖ ✔ ✕

applications

✞ ✝ ☎ ✆

user Now, the user is the lower layer

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 35 / 54

Perimeter Defences The User End

Digging through the human layer

How can you exploit the user to circumvent security? Bribery ; Blackmail ; Extortions Evesdropping ; Surveillance Phishing Not to speak of carelessness ... Passwords stuck under the keyboard Easy-to-guess passwords

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 36 / 54

Perimeter Defences The User End

Digging through the human layer

How can you exploit the user to circumvent security? Bribery ; Blackmail ; Extortions Evesdropping ; Surveillance Phishing Not to speak of carelessness ... Passwords stuck under the keyboard Easy-to-guess passwords

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 36 / 54

Perimeter Defences The User End

Digging through the human layer

How can you exploit the user to circumvent security? Bribery ; Blackmail ; Extortions Evesdropping ; Surveillance Phishing Not to speak of carelessness ... Passwords stuck under the keyboard Easy-to-guess passwords

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 36 / 54

Perimeter Defences The User End

Digging through the human layer

How can you exploit the user to circumvent security? Bribery ; Blackmail ; Extortions Evesdropping ; Surveillance Phishing Not to speak of carelessness ... Passwords stuck under the keyboard Easy-to-guess passwords

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 36 / 54

Perimeter Defences The User End

Digging through the human layer

How can you exploit the user to circumvent security? Bribery ; Blackmail ; Extortions Evesdropping ; Surveillance Phishing Not to speak of carelessness ... Passwords stuck under the keyboard Easy-to-guess passwords

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 36 / 54

Perimeter Defences The User End

Controls in the human layer

How can you protect against the attacks in the human layer?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 37 / 54

Perimeter Defences Product and System

Outline

1

The session

2

Security Design

3

Perimeter Defences City Walls The Man-Machine Scale The User End Product and System

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 38 / 54

Perimeter Defences Product and System

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.

What are the differences between security planning for products and for systems?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 39 / 54

Perimeter Defences Product and System

Products

Products are designed for larger markets.

Security affects many users.

Generic – for a range of different users.

Has to suit as many clients as possible.

General Security Requirements.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 40 / 54

Perimeter Defences Product and System

Systems

Systems are designed for a particular user/corporation. Adapted to local security requirements

May be tailor made. ... or may be a configuration of a product

A secure product can be deployed insecurily in a system.

misconfiguration poor match with the requirements

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 41 / 54

Perimeter Defences Product and System

Security Pitfalls

Wasting money on products

failing to invest in configuration and training

Buying a good product for X

when you need a product for Y

Buying controls of threats you don’t face You had better understand what you need.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 42 / 54

The fundamental dilemma

Outline

1

The session

2

Security Design

3

Perimeter Defences

4

The fundamental dilemma Security versus Business Processes Data-Centric Security

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 43 / 54

The fundamental dilemma Security versus Business Processes

Outline

1

The session

2

Security Design

3

Perimeter Defences

4

The fundamental dilemma Security versus Business Processes Data-Centric Security

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 44 / 54

The fundamental dilemma Security versus Business Processes

The fundamental dilemma

IBM Whitepaper view

Ambivalent attitude to security in businesses

1

security problems cause serious losses

money reputation

2

security does not contribute to business processes

it becomes a pure cost, like insurance and estates

Security is important, but it has to be cheap Value for money is immeasurable in security ...

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 45 / 54

The fundamental dilemma Security versus Business Processes

The fundamental dilemma

Gollmann’s presentation

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? Without a link to business processses, managers don’t care

• cf. IBM Whitepaper

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 46 / 54

The fundamental dilemma Security versus Business Processes

The fundamental dilemma

Gollmann’s presentation

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? Without a link to business processses, managers don’t care

• cf. IBM Whitepaper

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 46 / 54

The fundamental dilemma Security versus Business Processes

The fundamental dilemma

Gollmann’s presentation

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? Without a link to business processses, managers don’t care

• cf. IBM Whitepaper

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 46 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Security versus Business Processes

The Manager’s Perspective

We want to buy insurance A firewall is good insurance

it prevents, maybe, 95% of attacks on a global scale if it fails, we can say we followed best ‘industry practice’

What potential attacks do we face?

are they typically attacks which can be prevented? maybe we only face the top 5% attacks?

The manufacturer does not know the business.

Products designed for a general market.

Insurance assumes that all clients are average or typical Businesses rarely are typical.

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 47 / 54

The fundamental dilemma Data-Centric Security

Outline

1

The session

2

Security Design

3

Perimeter Defences

4

The fundamental dilemma Security versus Business Processes Data-Centric Security

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 48 / 54

The fundamental dilemma Data-Centric Security

Data-Centric Security Model

Figure from IBM’s white paper

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 49 / 54

The fundamental dilemma Data-Centric Security

Data-Centric? Or Business-Centric?

Security starts with Business Management Understand the Business Processes

and the role of the data in the processes

Classify data according to their role Define data-control rules based on business needs Is this related to secure design as we discussed it?

need-to-know policy

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 50 / 54

The fundamental dilemma Data-Centric Security

Data-Centric? Or Business-Centric?

Security starts with Business Management Understand the Business Processes

and the role of the data in the processes

Classify data according to their role Define data-control rules based on business needs Is this related to secure design as we discussed it?

need-to-know policy

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 50 / 54

The fundamental dilemma Data-Centric Security

Data-Centric? Or Business-Centric?

Security starts with Business Management Understand the Business Processes

and the role of the data in the processes

Classify data according to their role Define data-control rules based on business needs Is this related to secure design as we discussed it?

need-to-know policy

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 50 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

The limits of perimeters

Perimeter defences protect systems

Build a firewall around the business Separate the insiders from the outsiders

Problems with Perimeter Thinking

People need to leave the safety of the walls Information needs to leave the safety of the walls One-size-fits-all – no granularity

wasting resources on low-value assets failing adequate controls of high-value assets

Insider threats

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 51 / 54

The fundamental dilemma Data-Centric Security

Data-Centric Security

Figure from IBM’s white paper

Data is the centre of security Regulations on data usage Who owns the data? Who needs the data? Who may change the data?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 52 / 54

Summary

Outline

1

The session

2

Security Design

3

Perimeter Defences

4

The fundamental dilemma

5

Summary

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 53 / 54

Summary

Conclusion

Two approaches to information systems design

building security in throughout every phase of development patching security onto a system which has grown out of hand

Which do you prefer and why? Two approaches to security management

systems-centric – perimeters around the institution data-centric – each category of data is a target of security

Which do you prefer and why? Perimeters fits one security mechanism on the entire system

data-sharing becomes hard perimeters rarely manage to enclose everything

What will future security look like?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 54 / 54

Summary

Conclusion

Two approaches to information systems design

building security in throughout every phase of development patching security onto a system which has grown out of hand

Which do you prefer and why? Two approaches to security management

systems-centric – perimeters around the institution data-centric – each category of data is a target of security

Which do you prefer and why? Perimeters fits one security mechanism on the entire system

data-sharing becomes hard perimeters rarely manage to enclose everything

What will future security look like?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 54 / 54

Summary

Conclusion

Two approaches to information systems design

building security in throughout every phase of development patching security onto a system which has grown out of hand

Which do you prefer and why? Two approaches to security management

systems-centric – perimeters around the institution data-centric – each category of data is a target of security

Which do you prefer and why? Perimeters fits one security mechanism on the entire system

data-sharing becomes hard perimeters rarely manage to enclose everything

What will future security look like?

Dr Hans Georg Schaathun Security Objectives and Design Autumn 2010 – Week 2 54 / 54