1 Principle of Easiest Penetration Principle of Easiest Penetration: - - PDF document

1

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 1

The Course So Far

• Middleware
• Time
• Global states
• Coordination
• Multicast
• Consensus
• Replication
• Transactions

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 2

Security in the Course

• Lectures

– Introduction (today) – Threat analysis (today) – Introduction to access control matrix (today) – Security policies – Cryptography – Key management – Authentication – Design principles – Access control mechanisms – Assurance – The future

• Literature

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 3

Security in Distributed Systems

• What is a system?

– A product or component – The above + OS, communications, etc – The above + one or more applications – Any or all of the above + IT staff – Any or all of the above + internal users and management – Any or all of the above + customers and other external users – Any or all of the above + the surronding environment including the media, competitors, regulators, and politicians

2

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 4

Principle of Easiest Penetration

Principle of Easiest Penetration: An intruder must be expected to use any available means of penetration. This is not necessarily the most obvious means, nor is it necessarily the one against which the most solid defence has been installed.

Pfleeger, 1997

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 5

The Basic Components

• Confidentiality

– The concealment of information or resources – Supported by access control mechanisms – Also applies to the existence of data – Resource hiding – Assumptions and trust underlie confidentiality mechanisms

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 6

The Basic Components (2)

• Integrity

– The trustworthiness of data or resources – Includes both data integrity and origin integrity – Two classes:

• prevention mechanisms
• detection mechanisms

– Relies on assumptions about

• the source of the data
• the trust in that source

3

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 7

The Basic Components (3)

• Availability

– The ability to use the information or resource desired – Reliability – System design – Hard to detect

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 8

Threats

• Threat – a potential

violation of security

• Attacks, attacker
• A classification of

threats (Shirey)

– Disclosure – Deception – Disruption – Usurpation

B A

Normal flow Information source Information destination

A B

Interruption

A B A B A B C

Interception

C C

Modification Fabrication

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 9

Threats (2)

• Some threats

– Snooping (disclosure)

• Confidentiality

– Modification, alteration (deception, disruption, usurpation)

• Integrity

– Masquerading, spoofing (deception, usurpation)

• Integrity

– Delegation

• One entity authorizes a second entity to perform functions
• n its behalf
• Not a violation of security

4

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 10

Threats (3)

• Some threats (cont.)

– Repudiation of origin (deception)

• Integrity

– Denial of receipt (deception)

• Integrity and availability

– Delay (usurpation, deception)

• Availability

– Denial of service (usurpation, deception)

• Availability

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 11

Threats (4)

• Passive attacks

– Hard to detect – Prevent

• Active attacks

– Easier to detect – Hard to prevent – Detect - Recover

Release of message contents Traffic analysis Masquerade Replay Modification of message contents Denial of service

Passive threats Active threats

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 12

Policy and Mechanism

• An example:

– Umeå University forbids copying some other student – A student sees that another student have not read protected its files and copies them. – Is anyone (or both) violating the security?

5

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 13

Policy and Mechanism (2)

• Policy language?
• Two cooperating entities?
• Def. A security policy is a statement of what is, and

what is not, allowed.

• Def. A security mechanism is a method, tool, or

procedure for enforcing a security policy.

• Mechanisms can be nontechnical

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 14

Goals of Security

• Prevention

– Preventive mechanism are often a hinder

• Detection

– Do not prevent compromises of the system

• Recovery

– Stop an attack – Assess and repair any damage – Recovery is complex – Retaliation?

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 15

Assumptions and Trust

• How does we determine if the policy

correctly describes the required level and type of security for the system?

• Security rests on assumptions
• Policy and assumptions

– The policy divides the system in secure and nonsecure states – The security mechanisms prevent the system from entering a nonsecure state

6

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 16

Assumptions and Trust (2)

• Trusting that mechanisms work requires

several assumptions

1. Each mechanism is designed to implement one

• r more parts of the security policy
• 2. The union of the mechanisms implements all

aspects of the security policy

• 3. The mechanisms are implemented correctly
• 4. The mechanisms are installed and administred

correctly

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 17

Assurance

• An attempt to provide a basis for

bolstering how much one can trust a system

• Requires specific steps to ensure that the

system will function properly

– Detailed specifications of the desired behavior – An analysis of the design of the components – Arguments or proofs that all “implementations” produce the desired behavior

• Def. A system is said to satisfy a specification if the

specification correctly states how the system will function.

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 18

Assurance (2)

• A specification is a statement of the

desired functioning of the system

– Formal or informal – Can be low-level – The set of requirements relevant to the system’s planned use

7

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 19

Assurance (3)

• The design of a system translates the

specifications into components that will implement them

– The design must satisfy the specification

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 20

Assurance (4)

• Given a design, the implementation creates

a system that satisfies that design

– Difficult proving that a program correctly implements the design (and, in turn, the specifications) – Proving correctness is hard, often testing is used instead

• Def. A program is correct if its implementation performs as

specified.

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 21

Operational Issues

• Cost-Benefit analysis

– Depends on the mechanism chosen to implement a particular security service and on the mechanisms chosen to implement other security services – Adding security mechanism is more expensive than designing them into the system in the first place

8

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 22

Operational Issues

• Risk analysis

– The level of protection is a function of the probability of an attack occurring and the effects of the attack should it succeed – Risk is a function of environment – The risks change with time – Many risks are quite remote but still exist – Analysis paralysis – making risk analyses with no effort to act on those analyses

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 23

Operational Issues

• Laws and customs

– Restrictions on availability and use of technology – Laws of multiple jurisdictions – Legal vs. acceptable practices – Psychological acceptability

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 24

Human Issues

• Organizational problems

– Security provides no direct financial reward – Security controls often add complexity – Is security worth it? – Clear chains of responsibility and power – Which people are trained in security? – Lack of resources

9

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 25

Human Issues (2)

• People problems

– The heart of any security system is people

• Insiders

– More access to resources – Careless/untrained users and system administrators – Users that steal – Users assisting external attacks

• Outsiders

– Social engineering

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 26

Tying It All Together

Threats Policy Specification Design Implementation Operation and Maintenance

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 27

The Future

The world is never going to be perfect, either on- or offline; so let´s not set impossibly high standards for online.

• Esther Dyson

10

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 28

Outline

• Introduction
• Threat analysis
• Introduction to access control matrix

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 29

Threat Analysis - A Successful Attack

• 1. Identify the target and gather information
• 2. Analyze the information and find a vulnerability
• 3. Achieve enough access to the target
• 4. Execute the attack
• 5. Erase the traces of the attack and avoid

retaliation

• It is often enough to stop one of the step above

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 30

Threat Analysis (2)

• Protection

– Physical security

• Social engineering

– Virtual security – Trust model

• Who you can trust and how much

– The life cycle of a system

• Protect all stages of the life cycle
• Detection
• Reaction

11

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 31

Threat Analysis (3)

• Protect against the greatest risks

– Value of the protected – Annual loss expectancy

• Attack trees

– According to Schneier

• Failure Modes and Effects Analysis (FMEA)

– Bottom up – How failure in a component affect the goal of the system

• Combine in a matrix

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 32

Introduction to Access Control Matrix

• On the whiteboard...

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 33

Summary

• Introduction
• Threat analysis
• Introduction

to access control matrix Threats Policy Specification Design Implementation Operation and Maintenance

12

4/10 - 05 Distributed systems - Jonny Pettersson, UmU 34

Next Time

• Security policies

– Confidentiality policies – Integrity policies – Hybrid policies